面试官太难伺候？一个try-catch问出这么多花样
原创：微信公众号 【阿Q说代码】，欢迎分享，转载请保留出处。
哈喽大家好，我是阿Q！
刚刚面试回来的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
image
字节码指令晦涩难懂，那我们就用图解的方式来解释一下（我们先只看前7行指令）：首先执行 int x = 1;
image
然后我们需要执行try中的return x;
image
此时并不是真正的返回x的值，而是将x的值存到局部变量表中作为临时存储变量进行存储，也就是对该值进行保护操作。
最后进入finally中执行x=2;
image
此时虽然x已经被赋值为2了，但是由于刚才的保护操作，在执行真正的return操作时，会将被保护的临时存储变量入栈返回。
为了更好的理解上述操作，我们再来写一段简单代码：
public static int test2() {
int x = 1;
try {
return x;
} finally {
x = 2;
return x;
}
}
大家思考一下执行结果是几？答案是2不是1。
我们再来看下该程序的字节码指令
image
通过对比发现，第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;
}
}
反编译之后
image
果然如我们所料，重复的字节码指令出现了三次。让我们回归到最初的问题上，为什么finally代码的字节码指令会重复出现三次呢？
原来是JVM为了保证所有异常路径和正常路径的执行流程都要执行finally中的代码，所以在try和catch后追加上了finally中的字节码指令，再加上它自己本身的指令，正好三次。这也就是为什么finally 一定会执行的原因。
finally一定会执行吗？
为什么上边已经说了finally中的代码一定会执行，现在还要再多此一举呢？请👇看
在正常情况下，它是一定会被执行的，但是至少存在以下三种情况，是一定不执行的：
-
try语句没有被执行到就返回了，这样finally语句就不会执行，这也说明了finally语句被执行的必要而非充分条件是：相应的try语句一定被执行到； -
try代码块中有System.exit(0);这样的语句，因为System.exit(0);是终止JVM的，连JVM都停止了，finally肯定不会被执行了； - 守护线程会随着所有非守护线程的退出而退出，当守护线程内部的
finally的代码还未被执行到，非守护线程终结或退出时，finally肯定不会被执行；
TCF 的效率问题
说起TCF的效率问题，我们不得不介绍一下异常表，拿上边的程序来说，反编译class文件后的异常表信息如下：
image
- from：代表异常处理器所监控范围的起始位置；
- to：代表异常处理器所监控范围的结束位置（该行不被包括在监控范围内，是前闭后开区间）；
- target：指向异常处理器的起始位置；
- type：代表异常处理器所捕获的异常类型；
图中每一行代表一个异常处理器
工作流程：
- 触发异常时，
JVM会从上到下遍历异常表中所有的条目； - 比较触发异常的行数是否在
from-to范围内； - 范围匹配之后，会继续比较抛出的异常类型和异常处理器所捕获的异常类型
type是否相同; - 如果类型相同，会跳转到
target所指向的行数开始执行； - 如果类型不同，会弹出当前方法对应的
java栈帧，并对调用者重复操作； - 最坏的情况下
JVM需要遍历该线程Java栈上所有方法的异常表；
拿第一行为例：如果位于2-4行之间的命令（即try块中的代码）抛出了Class java/lang/Exception类型的异常，则跳转到第8行开始执行。
8: astore_1是指将抛出的异常对象保存到局部变量表中的1位置处
从字节码指令的角度来讲，如果代码中没有异常抛出，TCF的执行时间可以忽略不计；如果代码执行过程中出现了上文中的第6条，那么随着异常表的遍历，更多的异常实例被构建出来，异常所需要的栈轨迹也在生成。该操作会逐一访问当前线程的栈帧，记录各种调试信息，包括类名、方法名、触发异常的代码行数等等。所以执行效率会大大降低。
看到这儿，你是否对TCF有了更加深入的了解呢？下次让你对线面试官，你会五五开吗？如果你有不同的意见或者更好的idea，欢迎联系阿Q，添加阿Q还可以加入技术交流群参与讨论呦！
