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

億方雲發表於2016-10-11

子曾經曰過:所有的炒冷飯都是溫故而知新。

背景

眾所周知,所有被開啟的系統資源,比如流、檔案或者Socket連線等,都需要被開發者手動關閉,否則隨著程式的不斷執行,資源洩露將會累積成重大的生產事故。

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

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來改寫剛才的例子:

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

public class Connection implements AutoCloseable {
    public void sendData() {
        System.out.println("正在傳送資料");
    }
    @Override
    public void close() throws Exception {
        System.out.println("正在關閉連線");
    }
}

呼叫類:

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

執行後輸出結果:

正在傳送資料
正在關閉連線

通過結果我們可以看到,close方法被自動呼叫了。

原理

那麼這個是怎麼做到的呢?我相信聰明的你們一定已經猜到了,其實,這一切都是編譯器大神搞的鬼。我們反編譯剛才例子的class檔案:

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。為了瞭解這段程式碼的用意,我們稍微修改一下剛才的例子:我們將剛才的程式碼改回遠古時代手動關閉異常的方式,並且在sendDataclose方法中丟擲異常:

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

執行之後我們發現:

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變得極其難以發現,程式設計師們不得不加班加點地找bug,如此毒瘤,怎能不除!幸好,為了解決這個問題,從Java 1.7開始,大佬們為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的異常。可喜可賀!

一個小問題

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

舉個例子,在Java BIO中採用了大量的裝飾器模式。當呼叫裝飾器的close方法時,本質上是呼叫了裝飾器內部包裹的流的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中讀取位元組,並且寫入到GZIPOutputStream中。GZIPOutputStream實際上是FileOutputStream的裝飾器。由於try-with-resource的特性,實際編譯之後的程式碼會在後面帶上finally程式碼塊,並且在裡面呼叫fin.close()方法和out.close()方法。我們再來看GZIPOutputStream類的close方法:

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

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

總結

怎麼樣,是不是很簡單呢,如果學會了話

相關文章