面试官太难伺候？一个try-catch问出这么多花样

刚刚面试回来的面试B哥又在吐槽了：现在的面试官太难伺候了，放着好好的官太堆、栈、难伺方法区不问，问出上来就让我从字节码角度给他分析一下try-catch-finally（以下简称TCF）的多花执行效率......

我觉得应该是面试官在面试的过程中看大家背的八股文都如出一辙，觉得没有问的面试必要，便拐着弯的官太考大家的理解。今天趁着B哥也在，难伺我们就来好好总结一下TCF相关的问出知识点，期待下次与面试官对线五五开！多花

环境准备：IntelliJ IDEA 2020.2.3、面试JDK 1.8.0_181

执行顺序

我们先来写一段简单的官太代码：

public static int test1() {

int x = 1;

try {

return x;

} finally {

x = 2;

}

}

答案是1不是2，你答对了吗？难伺

大家都知道在TCF中，执行到return的问出时候会先去执行finally中的操作，然后才会返回来执行return，多花那这里为啥会是1呢？我们来反编译一下字节码文件。

命令：javap -v xxx.class

字节码指令晦涩难懂，香港云服务器那我们就用图解的方式来解释一下（我们先只看前7行指令）：首先执行 int x = 1;

然后我们需要执行try中的return x;

此时并不是真正的返回x的值，而是将x的值存到局部变量表中作为临时存储变量进行存储，也就是对该值进行保护操作。

最后进入finally中执行x=2;

此时虽然x已经被赋值为2了，但是由于刚才的保护操作，在执行真正的return操作时，会将被保护的临时存储变量入栈返回。

为了更好的理解上述操作，我们再来写一段简单代码：

public static int test2() {

int x = 1;

try {

return x;

} finally {

x = 2;

return x;

}

}

大家思考一下执行结果是几？答案是2不是1。

我们再来看下该程序的字节码指令

通过对比发现，第6行一个是iload_1，一个是iload_0，这是由什么决定的站群服务器呢？原因就是我们上边提到的保护机制，当在finally中存在return语句时，保护机制便会失效，转而将变量的值入栈并返回。

小结

return的执行优先级高于finally的执行优先级，但是return语句执行完毕之后并不会马上结束函数，而是将结果保存到栈帧中的局部变量表中，然后继续执行finally块中的语句； 如果finally块中包含return语句，则不会对try块中要返回的值进行保护，而是直接跳到finally语句中执行，并最后在finally语句中返回，返回值是在finally块中改变之后的值；

finally 为什么一定会执行

细心地小伙伴应该能发现，上边的字节码指令图中第4-7行和第9-12行的字节码指令是完全一致的，那么为什么会出现重复的指令呢？

首先我们来分析一下这些重复的指令都做了些什么操作，源码库经过分析发现它们就是x = 2;return x;的字节码指令，也就是finally代码块中的代码。由此我们有理由怀疑如果上述代码中加入catch代码块，finally代码块对应的字节码指令也会再次出现。

public static int test2() {

int x = 1;

try {

return x;

} catch(Exception e) {

x = 3;

} finally {

x = 2;

return x;

}

}

反编译之后

果然如我们所料，重复的字节码指令出现了三次。让我们回归到最初的问题上，为什么finally代码的字节码指令会重复出现三次呢？

原来是JVM为了保证所有异常路径和正常路径的执行流程都要执行finally中的代码，所以在try和catch后追加上了finally中的字节码指令，再加上它自己本身的指令，正好三次。这也就是为什么finally 一定会执行的原因。

finally一定会执行吗？

为什么上边已经说了finally中的代码一定会执行，现在还要再多此一举呢？请