深入理解 Java 中的 try-with-resource
背景
眾所周知,所有被開啟的系統資源,比如流、檔案或者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
。為了瞭解這段程式碼的用意,我們稍微修改一下剛才的例子:我們將剛才的程式碼改回遠古時代手動關閉異常的方式,並且在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();
-
}
-
}
-
}
-
}
執行之後我們發現:
-
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)