剛剛面試回來的B哥又在吐槽了：現(xiàn)在的面試官太難伺候了，放著好好的堆、棧、方法區(qū)不問，上來就讓我從字節(jié)碼角度給他分析一下try-catch-finally（以下簡稱TCF）的執(zhí)行效率......

我覺得應(yīng)該是面試官在面試的過程中看大家背的八股文都如出一轍，覺得沒有問的必要，便拐著彎的考大家的理解。今天趁著B哥也在，我們就來好好總結(jié)一下TCF相關(guān)的知識點(diǎn)，期待下次與面試官對線五五開！

環(huán)境準(zhǔn)備：IntelliJ IDEA 2020.2.3、JDK 1.8.0_181

執(zhí)行順序

我們先來寫一段簡單的代碼：

public static int test1() {
    int x = 1;
    try {
        return x;
    } finally {
        x = 2;
    }
}

答案是1不是2，你答對了嗎？

大家都知道在TCF中，執(zhí)行到return的時候會先去執(zhí)行finally中的操作，然后才會返回來執(zhí)行return，那這里為啥會是1呢？我們來反編譯一下字節(jié)碼文件。

命令：javap -v xxx.class

字節(jié)碼指令晦澀難懂，那我們就用圖解的方式來解釋一下（我們先只看前7行指令）：首先執(zhí)行 int x = 1;

然后我們需要執(zhí)行try中的return x;

此時并不是真正的返回x的值，而是將x的值存到局部變量表中作為臨時存儲變量進(jìn)行存儲，也就是對該值進(jìn)行保護(hù)操作。

最后進(jìn)入finally中執(zhí)行x=2;

此時雖然x已經(jīng)被賦值為2了，但是由于剛才的保護(hù)操作，在執(zhí)行真正的return操作時，會將被保護(hù)的臨時存儲變量入棧返回。

為了更好的理解上述操作，我們再來寫一段簡單代碼：

public static int test2() {
    int x = 1;
    try {
        return x;
    } finally {
        x = 2;
        return x;
    }
}

大家思考一下執(zhí)行結(jié)果是幾？答案是2不是1。

我們再來看下該程序的字節(jié)碼指令

通過對比發(fā)現(xiàn)，第6行一個是iload_1，一個是iload_0，這是由什么決定的呢？原因就是我們上邊提到的保護(hù)機(jī)制，當(dāng)在finally中存在return語句時，保護(hù)機(jī)制便會失效，轉(zhuǎn)而將變量的值入棧并返回。

小結(jié)

• return的執(zhí)行優(yōu)先級高于finally的執(zhí)行優(yōu)先級，但是return語句執(zhí)行完畢之后并不會馬上結(jié)束函數(shù)，而是將結(jié)果保存到棧幀中的局部變量表中，然后繼續(xù)執(zhí)行finally塊中的語句；
• 如果finally塊中包含return語句，則不會對try塊中要返回的值進(jìn)行保護(hù)，而是直接跳到finally語句中執(zhí)行，并最后在finally語句中返回，返回值是在finally塊中改變之后的值；

finally 為什么一定會執(zhí)行

細(xì)心地小伙伴應(yīng)該能發(fā)現(xiàn)，上邊的字節(jié)碼指令圖中第4-7行和第9-12行的字節(jié)碼指令是完全一致的，那么為什么會出現(xiàn)重復(fù)的指令呢？

首先我們來分析一下這些重復(fù)的指令都做了些什么操作，經(jīng)過分析發(fā)現(xiàn)它們就是x = 2;return x;的字節(jié)碼指令，也就是finally代碼塊中的代碼。由此我們有理由懷疑如果上述代碼中加入catch代碼塊，finally代碼塊對應(yīng)的字節(jié)碼指令也會再次出現(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é)碼指令會重復(fù)出現(xiàn)三次呢？

原來是JVM為了保證所有異常路徑和正常路徑的執(zhí)行流程都要執(zhí)行finally中的代碼，所以在try和catch后追加上了finally中的字節(jié)碼指令，再加上它自己本身的指令，正好三次。這也就是為什么finally 一定會執(zhí)行的原因。

finally一定會執(zhí)行嗎？

為什么上邊已經(jīng)說了finally中的代碼一定會執(zhí)行，現(xiàn)在還要再多此一舉呢？請??看

在正常情況下，它是一定會被執(zhí)行的，但是至少存在以下三種情況，是一定不執(zhí)行的：

• try語句沒有被執(zhí)行到就返回了，這樣finally語句就不會執(zhí)行，這也說明了finally語句被執(zhí)行的必要而非充分條件是：相應(yīng)的try語句一定被執(zhí)行到；
• try代碼塊中有System.exit(0);這樣的語句，因?yàn)镾ystem.exit(0);是終止JVM的，連JVM都停止了，finally肯定不會被執(zhí)行了；
• 守護(hù)線程會隨著所有非守護(hù)線程的退出而退出，當(dāng)守護(hù)線程內(nèi)部的finally的代碼還未被執(zhí)行到，非守護(hù)線程終結(jié)或退出時，finally 肯定不會被執(zhí)行；

TCF 的效率問題

說起TCF的效率問題，我們不得不介紹一下異常表，拿上邊的程序來說，反編譯class文件后的異常表信息如下：

• from：代表異常處理器所監(jiān)控范圍的起始位置；
• to：代表異常處理器所監(jiān)控范圍的結(jié)束位置（該行不被包括在監(jiān)控范圍內(nèi)，是前閉后開區(qū)間）；
• target：指向異常處理器的起始位置；
• type：代表異常處理器所捕獲的異常類型；

   圖中每一行代表一個異常處理器

工作流程：

1.    觸發(fā)異常時，JVM會從上到下遍歷異常表中所有的條目；
2.    比較觸發(fā)異常的行數(shù)是否在from-to范圍內(nèi)；
3.    范圍匹配之后，會繼續(xù)比較拋出的異常類型和異常處理器所捕獲的異常類型type是否相同;
4. 如果類型相同，會跳轉(zhuǎn)到target所指向的行數(shù)開始執(zhí)行；
5. 如果類型不同，會彈出當(dāng)前方法對應(yīng)的java棧幀，并對調(diào)用者重復(fù)操作；
6. 最壞的情況下JVM需要遍歷該線程 Java 棧上所有方法的異常表；

拿第一行為例：如果位于2-4行之間的命令（即try塊中的代碼）拋出了Class java/lang/Exception類型的異常，則跳轉(zhuǎn)到第8行開始執(zhí)行。

8: astore_1是指將拋出的異常對象保存到局部變量表中的1位置處

從字節(jié)碼指令的角度來講，如果代碼中沒有異常拋出，TCF的執(zhí)行時間可以忽略不計(jì)；如果代碼執(zhí)行過程中出現(xiàn)了上文中的第6條，那么隨著異常表的遍歷，更多的異常實(shí)例被構(gòu)建出來，異常所需要的棧軌跡也在生成。該操作會逐一訪問當(dāng)前線程的棧幀，記錄各種調(diào)試信息，包括類名、方法名、觸發(fā)異常的代碼行數(shù)等等。所以執(zhí)行效率會大大降低。