深入理解 Java 中的 try-with-resource

2019-11-11 07:48:06

字體：大中小

來源：轉載

供稿：網友

學習java的同學注意了?。?！學習過程中遇到什么問題或者想獲取學習資源的話，歡迎加入Java學習交流群，群號碼：183993990 我們一起學Java！

背景

眾所周知，所有被打開的系統資源，比如流、文件或者Socket連接等，都需要被開發者手動關閉，否則隨著程序的不斷運行，資源泄露將會累積成重大的生產事故。

在Java的江湖中，存在著一種名為finally的功夫，它可以保證當你習武走火入魔之時，還可以做一些自救的操作。在遠古時代，處理資源關閉的代碼通常寫在finally塊中。然而，如果你同時打開了多個資源，那么將會出現噩夢般的場景：

12345678910111213141516171819202122232425262728293031323334353637

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) {                    e.printStackTrace();                }                finally {                    if (bout != null) {                        try {                            bout.close();                        }                        catch (IOException e) {                            e.printStackTrace();                        }                    }                }            }        }    }}

Oh My God?。?！關閉資源的代碼竟然比業務代碼還要多！??！這是因為，我們不僅需要關閉BufferedInputStream，還需要保證如果關閉BufferedInputStream時出現了異常， BufferedOutputStream也要能被正確地關閉。所以我們不得不借助finally中嵌套finally大法?？梢韵氲?，打開的資源越多，finally中嵌套的將會越深?。?！

更為可惡的是，Python程序員面對這個問題，竟然微微一笑很傾城地說：“這個我們一點都不用考慮的嘞~”：

但是兄弟莫慌！我們可以利用Java 1.7中新增的try-with-resource語法糖來打開資源，而無需碼農們自己書寫資源來關閉代碼。媽媽再也不用擔心我把手寫斷掉了！我們用try-with-resource來改寫剛才的例子：

1234567891011121314

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();        }    }}

是不是很簡單？是不是很刺激？再也不用被Python程序員鄙視了！好了，下面將會詳細講解其實現原理以及內部機制。

動手實踐

為了能夠配合try-with-resource，資源必須實現AutoClosable接口。該接口的實現類需要重寫close方法：

12345678910

public class Connection implements AutoCloseable {    public void sendData() {        System.out.println("正在發送數據");    }    @Override    public void close() throws Exception {        System.out.println("正在關閉連接");    }}

調用類：

12345678910

public class TryWithResource {    public static void main(String[] args) {        try (Connection conn = new Connection()) {            conn.sendData();        }        catch (Exception e) {            e.printStackTrace();        }    }}

運行后輸出結果：

12	正在發送數據正在關閉連接

通過結果我們可以看到，close方法被自動調用了。

原理

那么這個是怎么做到的呢？我相信聰明的你們一定已經猜到了，其實，這一切都是編譯器大神搞的鬼。我們反編譯剛才例子的class文件：

1234567891011121314151617181920212223242526272829303132

public class TryWithResource {    public TryWithResource() {    }    public static void main(String[] args) {        try {            Connection e = new Connection();            Throwable var2 = null;            try {                e.sendData();            } catch (Throwable var12) {                var2 = var12;                throw var12;            } finally {                if(e != null) {                    if(var2 != null) {                        try {                            e.close();                        } catch (Throwable var11) {                            var2.addSuppressed(var11);                        }                    } else {                        e.close();                    }                }            }        } catch (Exception var14) {            var14.printStackTrace();        }    }}

看到沒，在第15~27行，編譯器自動幫我們生成了finally塊，并且在里面調用了資源的close方法，所以例子中的close方法會在運行的時候被執行。

異常屏蔽

我相信，細心的你們肯定又發現了，剛才反編譯的代碼（第21行）比遠古時代寫的代碼多了一個addSuppressed。為了了解這段代碼的用意，我們稍微修改一下剛才的例子：我們將剛才的代碼改回遠古時代手動關閉異常的方式，并且在sendData和close方法中拋出異常：

12345678910

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方法：

1234567891011121314151617181920212223

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();            }        }    }}

運行之后我們發現：

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)	......

好的，問題來了，由于我們一次只能拋出一個異常，所以在最上層看到的是最后一個拋出的異?！簿褪?code style="font-family:consolas,Menlo,'PingFang SC','Microsoft YaHei',monospace; font-size:13px; padding:2px 4px; word-break:break-all; background:rgb(238,238,238)">close方法拋出的MyException，而sendData拋出的Exception被忽略了。這就是所謂的異常屏蔽。由于異常信息的丟失，異常屏蔽可能會導致某些bug變得極其難以發現，程序員們不得不加班加點地找bug，如此毒瘤，怎能不除！幸好，為了解決這個問題，從Java 1.7開始，大佬們為Throwable類新增了addSuppressed方法，支持將一個異常附加到另一個異常身上，從而避免異常屏蔽。那么被屏蔽的異常信息會通過怎樣的格式輸出呢？我們再運行一遍剛才用try-with-resource包裹的main方法：

12345678

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的異常。可喜可賀！

一個小問題

在使用try-with-resource的過程中，一定需要了解資源的close方法內部的實現邏輯。否則還是可能會導致資源泄露。

舉個例子，在Java BIO中采用了大量的裝飾器模式。當調用裝飾器的close方法時，本質上是調用了裝飾器內部包裹的流的close方法。比如：

123456789101112131415

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中讀取字節，并且寫入到GZIPOutputStream中。GZIPOutputStream實際上是FileOutputStream的裝飾器。由于try-with-resource的特性，實際編譯之后的代碼會在后面帶上finally代碼塊，并且在里面調用fin.close()方法和out.close()方法。我們再來看GZIPOutputStream類的close方法：

123456789

public void close() throws IOException {    if (!closed) {        finish();        if (usesDefaultDeflater)            def.end();        out.close();        closed = true;    }}

我們可以看到，out變量實際上代表的是被裝飾的FileOutputStream類。在調用out變量的close方法之前，GZIPOutputStream還做了finish操作，該操作還會繼續往FileOutputStream中寫壓縮信息，此時如果出現異常，則會out.close()方法被略過，然而這個才是最底層的資源關閉方法。正確的做法是應該在try-with-resource中單獨聲明最底層的資源，保證對應的close方法一定能夠被調用。在剛才的例子中，我們需要單獨聲明每個FileInputStream以及FileOutputStream：

12345678910111213141516

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()的代碼，這樣肯定能夠保證真正的流被關閉。