深入理解Java基礎之try-with-resource語法糖
背景
眾所周知，所有被打開的系統(tǒng)資源，比如流、文件或者Socket連接等，都需要被開發(fā)者手動關閉，否則隨著程序的不斷運行，資源泄露將會累積成重大的生產事故。
在Java的江湖中，存在著一種名為finally的功夫，它可以保證當你習武走火入魔之時，還可以做一些自救的操作。在遠古時代，處理資源關閉的代碼通常寫在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?。?！ 關閉資源的代碼竟然比業(yè)務代碼還要多 ！??！這是因為，我們不僅需要關閉 BufferedInputStream ，還需要保證如果關閉 BufferedInputStream 時出現(xiàn)了異常， BufferedOutputStream 也要能被正確地關閉。所以我們不得不借助finally中嵌套finally?？梢韵氲?，打開的資源越多，finally中嵌套的將會越深?。。?/p>
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();
}
}
}動手實踐
為了能夠配合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("正在關閉連接");
}
}
調用類：
public class TryWithResource {
public static void main(String[] args) {
try (Connection conn = new Connection()) {
conn.sendData();
}
catch (Exception e) {
e.printStackTrace();
}
}
}
運行后輸出結果：
正在發(fā)送數(shù)據(jù)
正在關閉連接
原理
那么這個是怎么做到的呢？我相信聰明的你們一定已經猜到了，其實，這一切都是編譯器大神搞的鬼。我們反編譯剛才例子的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();
}
}
}
看到沒，在第15~27行，編譯器自動幫我們生成了finally塊，并且在里面調用了資源的close方法，所以例子中的close方法在運行的時候被執(zhí)行。
異常屏蔽
細心的你們肯定又發(fā)現(xiàn)了，剛才反編譯的代碼（第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();
}
}
}
}
運行之后我們發(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 方法內部的實現(xiàn)邏輯。否則還是可能會導致資源泄露。
舉個例子，在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 中讀取字節(jié)，并且寫入到 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 操作，該操作還會繼續(xù)往 FileOutputStream 中寫壓縮信息，此時如果出現(xiàn)異常，則會 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() 的代碼，這樣肯定能夠保證真正的流被關閉。
以上就是本文的全部內容，希望對大家的學習有所幫助，也希望大家多多支持腳本之家。
相關文章
SpringBoot同時支持HTTPS與HTTP的實現(xiàn)示例
本文主要介紹了SpringBoot同時支持HTTPS與HTTP的實現(xiàn)示例，文中通過示例代碼介紹的非常詳細，對大家的學習或者工作具有一定的參考學習價值，需要的朋友們下面隨著小編來一起學習學習吧2022-07-07
這篇文章主要介紹了JavaWeb中的常用的請求傳參注解說明，具有很好的參考價值，希望對大家有所幫助。如有錯誤或未考慮完全的地方，望不吝賜教2023-04-04
這篇文章主要介紹了令人目瞪口呆的?Java?代碼技巧,本文從寫?Java?程序的小方面一直寫到大方面，來闡述了如何才能寫好?Java?程序，并告訴讀者們如何才能提高自身的編碼水平，需要的朋友可以參考下2022-05-05
這篇文章主要介紹了Spring?Boot超大文件上傳實現(xiàn)秒傳功能,在實現(xiàn)分片上傳的過程，需要前端和后端配合，比如前后端的上傳塊號的文件大小，前后端必須得要一致，否則上傳就會有問題，需要的朋友可以參考下2022-12-12
這篇文章主要介紹了jpanel設置背景圖片的二個小例子，實現(xiàn)了動態(tài)加載圖片做背景的方法,需要的朋友可以參考下2014-03-03
這篇文章主要介紹了Java的編譯執(zhí)行與解釋執(zhí)行，對編譯和解釋感興趣的同學，可以參考下2021-04-04
這篇文章主要介紹了mybatis-plus 時間字段的比較，具有很好的參考價值，希望對大家有所幫助。如有錯誤或未考慮完全的地方，望不吝賜教2021-08-08
volatile關鍵字雖然從字面上理解起來比較簡單，但是要用好不是一件容易的事情。這篇文章主要介紹了Java中volatile關鍵字的作用與用法詳解的相關資料,需要的朋友可以參考下2016-09-09
這篇文章主要介紹了Java List 用法詳解及實例分析的相關資料,需要的朋友可以參考下2017-07-07
這篇文章主要為大家詳細介紹了java設計模式之裝飾器模式Decorator，具有一定的參考價值，感興趣的小伙伴們可以參考一下2017-01-01