面試官太難伺候？一個(gè)try-catch問出這么多花樣
剛剛面試回來的B哥又在吐槽了：現(xiàn)在的面試官太難伺候了，放著好好的堆、棧、方法區(qū)不問，上來就讓我從字節(jié)碼角度給他分析一下try-catch-finally（以下簡(jiǎn)稱TCF）的執(zhí)行效率......
我覺得應(yīng)該是面試官在面試的過程中看大家背的八股文都如出一轍，覺得沒有問的必要，便拐著彎的考大家的理解。今天趁著B哥也在，我們就來好好總結(jié)一下TCF相關(guān)的知識(shí)點(diǎn)，期待下次與面試官對(duì)線五五開！
環(huán)境準(zhǔn)備：IntelliJ IDEA 2020.2.3、JDK 1.8.0_181
執(zhí)行順序
我們先來寫一段簡(jiǎn)單的代碼：
public static int test1() {
int x = 1;
try {
return x;
} finally {
x = 2;
}
}
答案是1不是2，你答對(duì)了嗎？
大家都知道在TCF中，執(zhí)行到return的時(shí)候會(huì)先去執(zhí)行finally中的操作，然后才會(huì)返回來執(zhí)行return，那這里為啥會(huì)是1呢？我們來反編譯一下字節(jié)碼文件。
命令：javap -v xxx.class
字節(jié)碼指令晦澀難懂，那我們就用圖解的方式來解釋一下（我們先只看前7行指令）：首先執(zhí)行 int x = 1;
然后我們需要執(zhí)行try中的return x;
此時(shí)并不是真正的返回x的值，而是將x的值存到局部變量表中作為臨時(shí)存儲(chǔ)變量進(jìn)行存儲(chǔ)，也就是對(duì)該值進(jìn)行保護(hù)操作。
最后進(jìn)入finally中執(zhí)行x=2;
此時(shí)雖然x已經(jīng)被賦值為2了，但是由于剛才的保護(hù)操作，在執(zhí)行真正的return操作時(shí)，會(huì)將被保護(hù)的臨時(shí)存儲(chǔ)變量入棧返回。
為了更好的理解上述操作，我們?cè)賮韺懸欢魏?jiǎn)單代碼：
public static int test2() {
int x = 1;
try {
return x;
} finally {
x = 2;
return x;
}
}
大家思考一下執(zhí)行結(jié)果是幾？答案是2不是1。
我們?cè)賮砜聪略摮绦虻淖止?jié)碼指令
通過對(duì)比發(fā)現(xiàn)，第6行一個(gè)是iload_1，一個(gè)是iload_0，這是由什么決定的呢？原因就是我們上邊提到的保護(hù)機(jī)制，當(dāng)在finally中存在return語句時(shí)，保護(hù)機(jī)制便會(huì)失效，轉(zhuǎn)而將變量的值入棧并返回。
小結(jié)
- return的執(zhí)行優(yōu)先級(jí)高于finally的執(zhí)行優(yōu)先級(jí)，但是return語句執(zhí)行完畢之后并不會(huì)馬上結(jié)束函數(shù)，而是將結(jié)果保存到棧幀中的局部變量表中，然后繼續(xù)執(zhí)行finally塊中的語句；
- 如果finally塊中包含return語句，則不會(huì)對(duì)try塊中要返回的值進(jìn)行保護(hù)，而是直接跳到finally語句中執(zhí)行，并最后在finally語句中返回，返回值是在finally塊中改變之后的值；
finally 為什么一定會(huì)執(zhí)行
細(xì)心地小伙伴應(yīng)該能發(fā)現(xiàn)，上邊的字節(jié)碼指令圖中第4-7行和第9-12行的字節(jié)碼指令是完全一致的，那么為什么會(huì)出現(xiàn)重復(fù)的指令呢？
首先我們來分析一下這些重復(fù)的指令都做了些什么操作，經(jīng)過分析發(fā)現(xiàn)它們就是x = 2;return x;的字節(jié)碼指令，也就是finally代碼塊中的代碼。由此我們有理由懷疑如果上述代碼中加入catch代碼塊，finally代碼塊對(duì)應(yīng)的字節(jié)碼指令也會(huì)再次出現(xiàn)。
public static int test2() {
int x = 1;
try {
return x;
} catch(Exception e) {
x = 3;
} finally {
x = 2;
return x;
}
}
反編譯之后
果然如我們所料，重復(fù)的字節(jié)碼指令出現(xiàn)了三次。讓我們回歸到最初的問題上，為什么finally代碼的字節(jié)碼指令會(huì)重復(fù)出現(xiàn)三次呢？
原來是JVM為了保證所有異常路徑和正常路徑的執(zhí)行流程都要執(zhí)行finally中的代碼，所以在try和catch后追加上了finally中的字節(jié)碼指令，再加上它自己本身的指令，正好三次。這也就是為什么finally 一定會(huì)執(zhí)行的原因。
finally一定會(huì)執(zhí)行嗎？
為什么上邊已經(jīng)說了finally中的代碼一定會(huì)執(zhí)行，現(xiàn)在還要再多此一舉呢？請(qǐng)??看
在正常情況下，它是一定會(huì)被執(zhí)行的，但是至少存在以下三種情況，是一定不執(zhí)行的：
- try語句沒有被執(zhí)行到就返回了，這樣finally語句就不會(huì)執(zhí)行，這也說明了finally語句被執(zhí)行的必要而非充分條件是：相應(yīng)的try語句一定被執(zhí)行到；
- try代碼塊中有System.exit(0);這樣的語句，因?yàn)镾ystem.exit(0);是終止JVM的，連JVM都停止了，finally肯定不會(huì)被執(zhí)行了；
- 守護(hù)線程會(huì)隨著所有非守護(hù)線程的退出而退出，當(dāng)守護(hù)線程內(nèi)部的finally的代碼還未被執(zhí)行到，非守護(hù)線程終結(jié)或退出時(shí)，finally 肯定不會(huì)被執(zhí)行；
TCF 的效率問題
說起TCF的效率問題，我們不得不介紹一下異常表，拿上邊的程序來說，反編譯class文件后的異常表信息如下：
- from：代表異常處理器所監(jiān)控范圍的起始位置；
- to：代表異常處理器所監(jiān)控范圍的結(jié)束位置（該行不被包括在監(jiān)控范圍內(nèi)，是前閉后開區(qū)間）；
- target：指向異常處理器的起始位置；
- type：代表異常處理器所捕獲的異常類型；
圖中每一行代表一個(gè)異常處理器
工作流程：
- 觸發(fā)異常時(shí)，JVM會(huì)從上到下遍歷異常表中所有的條目；
- 比較觸發(fā)異常的行數(shù)是否在from-to范圍內(nèi)；
- 范圍匹配之后，會(huì)繼續(xù)比較拋出的異常類型和異常處理器所捕獲的異常類型type是否相同;
- 如果類型相同，會(huì)跳轉(zhuǎn)到target所指向的行數(shù)開始執(zhí)行；
- 如果類型不同，會(huì)彈出當(dāng)前方法對(duì)應(yīng)的java棧幀，并對(duì)調(diào)用者重復(fù)操作；
- 最壞的情況下JVM需要遍歷該線程 Java 棧上所有方法的異常表；
拿第一行為例：如果位于2-4行之間的命令（即try塊中的代碼）拋出了Class java/lang/Exception類型的異常，則跳轉(zhuǎn)到第8行開始執(zhí)行。
8: astore_1是指將拋出的異常對(duì)象保存到局部變量表中的1位置處
從字節(jié)碼指令的角度來講，如果代碼中沒有異常拋出，TCF的執(zhí)行時(shí)間可以忽略不計(jì)；如果代碼執(zhí)行過程中出現(xiàn)了上文中的第6條，那么隨著異常表的遍歷，更多的異常實(shí)例被構(gòu)建出來，異常所需要的棧軌跡也在生成。該操作會(huì)逐一訪問當(dāng)前線程的棧幀，記錄各種調(diào)試信息，包括類名、方法名、觸發(fā)異常的代碼行數(shù)等等。所以執(zhí)行效率會(huì)大大降低。
