深入理解Java基礎之try-with-resource語法糖
背景
眾所周知,所有被打開的系統(tǒng)資源,比如流、文件或者Socket連接等,都需要被開發(fā)者手動關(guān)閉,否則隨著程序的不斷運行,資源泄露將會累積成重大的生產(chǎn)事故。
在Java的江湖中,存在著一種名為finally的功夫,它可以保證當你習武走火入魔之時,還可以做一些自救的操作。在遠古時代,處理資源關(guān)閉的代碼通常寫在finally塊中。然而,如果你同時打開了多個資源,那么將會出現(xiàn)噩夢般的場景:
public class Demo { public static void main(String[] args) { BufferedInputStream bin = null; BufferedOutputStream bout = null; try { bin = new BufferedInputStream(new FileInputStream(new File("test.txt"))); bout = new BufferedOutputStream(new FileOutputStream(new File("out.txt"))); int b; while ((b = bin.read()) != -1) { bout.write(b); } } catch (IOException e) { e.printStackTrace(); } finally { if (bin != null) { try { bin.close(); } catch (IOException e) { throw e; } finally { if (bout != null) { try { bout.close(); } catch (IOException e) { throw e; } } } } } } }
Oh My God?。?! 關(guān)閉資源的代碼竟然比業(yè)務代碼還要多 ?。?!這是因為,我們不僅需要關(guān)閉 BufferedInputStream
,還需要保證如果關(guān)閉 BufferedInputStream
時出現(xiàn)了異常, BufferedOutputStream
也要能被正確地關(guān)閉。所以我們不得不借助finally中嵌套finally??梢韵氲?,打開的資源越多,finally中嵌套的將會越深?。?!
Java 1.7中新增的try-with-resource語法糖來打開資源,而無需碼農(nóng)們自己書寫資源來關(guān)閉代碼。再也不用擔心我把手寫斷掉了!我們用try-with-resource來改寫剛才的例子:
public class TryWithResource { public static void main(String[] args) { try (BufferedInputStream bin = new BufferedInputStream(new FileInputStream(new File("test.txt"))); BufferedOutputStream bout = new BufferedOutputStream(new FileOutputStream(new File("out.txt")))) { int b; while ((b = bin.read()) != -1) { bout.write(b); } } catch (IOException e) { e.printStackTrace(); } } }
動手實踐
為了能夠配合try-with-resource,資源必須實現(xiàn) AutoClosable
接口。該接口的實現(xiàn)類需要重寫 close
方法:
public class Connection implements AutoCloseable { public void sendData() { System.out.println("正在發(fā)送數(shù)據(jù)"); } @Override public void close() throws Exception { System.out.println("正在關(guān)閉連接"); } }
調(diào)用類:
public class TryWithResource { public static void main(String[] args) { try (Connection conn = new Connection()) { conn.sendData(); } catch (Exception e) { e.printStackTrace(); } } }
運行后輸出結(jié)果:
正在發(fā)送數(shù)據(jù)
正在關(guān)閉連接
原理
那么這個是怎么做到的呢?我相信聰明的你們一定已經(jīng)猜到了,其實,這一切都是編譯器大神搞的鬼。我們反編譯剛才例子的class文件:
package com.codersm.trywithresource; public class TryWithResource { public TryWithResource() { } public static void main(String[] args) { try { Connection conn = new Connection(); Throwable var2 = null; try { conn.sendData(); } catch (Throwable var12) { var2 = var12; throw var12; } finally { if (conn != null) { if (var2 != null) { try { conn.close(); } catch (Throwable var11) { var2.addSuppressed(var11); } } else { conn.close(); } } } } catch (Exception var14) { var14.printStackTrace(); } } }
看到?jīng)],在第15~27行,編譯器自動幫我們生成了finally塊,并且在里面調(diào)用了資源的close方法,所以例子中的close方法在運行的時候被執(zhí)行。
異常屏蔽
細心的你們肯定又發(fā)現(xiàn)了,剛才反編譯的代碼(第21行)比遠古時的代碼多了一個 addSuppressed 。為了了解這段代碼的用意,我們稍微修改一下剛才的例子:我們將剛才的代碼改回遠古時代手動關(guān)閉異常的方式,并且在 sendData 和 close 方法中拋出異常:
public class Connection implements AutoCloseable { public void sendData() throws Exception { throw new Exception("send data"); } @Override public void close() throws Exception { throw new MyException("close"); } }
修改main方法:
public class TryWithResource { public static void main(String[] args) { try { test(); } catch (Exception e) { e.printStackTrace(); } } private static void test() throws Exception { Connection conn = null; try { conn = new Connection(); conn.sendData(); } finally { if (conn != null) { conn.close(); } } } }
運行之后我們發(fā)現(xiàn):
basic.exception.MyException: close
at basic.exception.Connection.close(Connection.java:10)
at basic.exception.TryWithResource.test(TryWithResource.java:82)
at basic.exception.TryWithResource.main(TryWithResource.java:7)
......
好的,問題來了,由于我們一次只能拋出一個異常,所以在最上層看到的是最后一個拋出的異常——也就是 close 方法拋出的 MyException ,而 sendData 拋出的 Exception 被忽略了。這就是所謂的異常屏蔽。由于異常信息的丟失,異常屏蔽可能會導致某些bug變得極其難以發(fā)現(xiàn),程序員們不得不加班加點地找bug,如此毒瘤,怎能不除!幸好,為了解決這個問題,從Java 1.7開始,大佬們?yōu)?Throwable 類新增了 addSuppressed 方法,支持將一個異常附加到另一個異常身上,從而避免異常屏蔽。那么被屏蔽的異常信息會通過怎樣的格式輸出呢?我們再運行一遍剛才用try-with-resource包裹的main方法:
java.lang.Exception: send data at basic.exception.Connection.sendData(Connection.java:5) at basic.exception.TryWithResource.main(TryWithResource.java:14) ...... Suppressed: basic.exception.MyException: close at basic.exception.Connection.close(Connection.java:10) at basic.exception.TryWithResource.main(TryWithResource.java:15) ... 5 more
可以看到,異常信息中多了一個 Suppressed 的提示,告訴我們這個異常其實由兩個異常組成, MyException 是被Suppressed的異常??上部少R!
注意事項
在使用try-with-resource的過程中,一定需要了解資源的 close 方法內(nèi)部的實現(xiàn)邏輯。否則還是可能會導致資源泄露。
舉個例子,在Java BIO中采用了大量的裝飾器模式。當調(diào)用裝飾器的 close 方法時,本質(zhì)上是調(diào)用了裝飾器內(nèi)部包裹的流的 close 方法。比如:
public class TryWithResource { public static void main(String[] args) { try (FileInputStream fin = new FileInputStream(new File("input.txt")); GZIPOutputStream out = new GZIPOutputStream(new FileOutputStream(new File("out.txt")))) { byte[] buffer = new byte[4096]; int read; while ((read = fin.read(buffer)) != -1) { out.write(buffer, 0, read); } } catch (IOException e) { e.printStackTrace(); } } }
在上述代碼中,我們從 FileInputStream
中讀取字節(jié),并且寫入到 GZIPOutputStream
中。 GZIPOutputStream
實際上是 FileOutputStream
的裝飾器。由于try-with-resource的特性,實際編譯之后的代碼在后面帶上finally代碼塊,并且在里面調(diào)用fin.close()方法和out.close()方法。我們再來看 GZIPOutputStream
類的close方法:
public void close() throws IOException { if (!closed) { finish(); if (usesDefaultDeflater) def.end(); out.close(); closed = true; } }
我們可以看到,out變量實際上代表的是被裝飾的 FileOutputStream
類。在調(diào)用out變量的 close 方法之前, GZIPOutputStream
還做了 finish 操作,該操作還會繼續(xù)往 FileOutputStream
中寫壓縮信息,此時如果出現(xiàn)異常,則會 out.close()
方法被略過,然而這個才是最底層的資源關(guān)閉方法。正確的做法是應該在try-with-resource中單獨聲明最底層的資源,保證對應的 close 方法一定能夠被調(diào)用。在剛才的例子中,我們需要單獨聲明每個 FileInputStream
以及 FileOutputStream
:
public class TryWithResource { public static void main(String[] args) { try (FileInputStream fin = new FileInputStream(new File("input.txt")); FileOutputStream fout = new FileOutputStream(new File("out.txt")); GZIPOutputStream out = new GZIPOutputStream(fout)) { byte[] buffer = new byte[4096]; int read; while ((read = fin.read(buffer)) != -1) { out.write(buffer, 0, read); } } catch (IOException e) { e.printStackTrace(); } } }
由于編譯器會自動生成 fout.close() 的代碼,這樣肯定能夠保證真正的流被關(guān)閉。
以上就是本文的全部內(nèi)容,希望對大家的學習有所幫助,也希望大家多多支持腳本之家。
相關(guān)文章
詳解Java中NullPointerException異常的原因詳解以及解決方法
這篇文章主要介紹了詳解Java中NullPointerException異常的原因詳解以及解決方法。文中通過示例代碼介紹的非常詳細,對大家的學習或者工作具有一定的參考學習價值,需要的朋友們下面隨著小編來一起學習學習吧2020-08-08java并發(fā)編程之深入理解Synchronized的使用
文詳細講述了線程、進程的關(guān)系及在操作系統(tǒng)中的表現(xiàn),這是多線程學習必須了解的基礎。本文將接著講一下Java線程同步中的一個重要的概念synchronized,希望能夠給你有所幫助2021-06-06SpringBoot整合Redis哨兵模式的實現(xiàn)示例
Redis哨兵模式是Redis高可用方案的一種實現(xiàn)方式,通過哨兵來自動實現(xiàn)故障轉(zhuǎn)移,從而保證高可用,本文主要介紹了SpringBoot整合Redis哨兵模式的實現(xiàn)示例,具有一定的參考價值,感興趣的可以了解一下2024-02-02Netty源碼分析NioEventLoop處理IO事件相關(guān)邏輯
這篇文章主要介紹了Netty源碼分析NioEventLoop處理IO事件相關(guān)邏輯,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進步,早日升職加薪2022-03-03