try-catch-finally的深入理解

关于try-catch-finally的执行顺序说明：

• try块是必须的，catch和finally块都是可选的，但必须存在一个或者都存在。try时不能单独存在的。
• try块里的语句运行中出现异常，会跳过try块的其他语句，直接运行catch里的语句。
• 无论try块中是否有异常，无论catch块中的语句是否实现，都会执行finally块里的语句。
• 如果try块或者catch块中有return语句，finally块里的语句都会执行在try块或catch块中的return语句之前。
• 如果finally块中有return语句，则直接返回，而不执行try块或者catch块中的return语句。
• finally块里的语句在try或者catch里的任何return前执行。

首先看一个例子：

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

        在try、catch、finally中，当执行到return时会先去执行finally中的操作，然后才会返回再执行return。上述代码的输出结果为：1。我们可以进行简单的分析，这段代码的字节码文件如下：

        我们以图解的方式进行分析，其执行过程如下：

（1）执行int x = 1

 

（2）执行try中的return x

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

（3）进入finally中执行x = 2

         此时尽管x已经被赋值为2，但由于刚才的保护操作，在执行真正的return操作时，会将北博埃胡德临时存储变量入栈返回。

        再看一段代码：

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

         这段代码的输出结果为2，其字节码指令如下：

        对比第一段代码，可以发现：第六行一个是iload_0，一个是iload_1。这是因为前面提到的保护机制，当在finally中存在return语句时，保护机制就会失效，从而将变量的值入栈并返回。

综上所述：

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

接下来讨论几个问题：

1、finally为什么一定会执行

        查看第二段代码的字节码文件，可以发现：第4-7行和第9-12行的字节码指令是完全一致的。这段字节码其实就是x = 2； return x; 的字节码指令，也就是finally代码块中的代码。那么如果在上述代码中加入catch代码块，finally代码块对应的字节码指令也会再次出现。

public static int test(){
        int  x = 1;
        try{
            return x;
        } catch (Exception e){
            x = 3;
        } finally{
            x = 2;
            return x;
        }
    }

字节码文件如下：

        可以看到：重复的字节码指令出现了三次，其原因在于：JVM为了保证所有的一场路径和正常路径的执行流程都要执行finally中的代码，所以在try和catch后追加了finally中的字节码指令，再加上其本身的指令，正好三次，这也就是为什么finally一定会执行的原因。

2、finally一定会执行吗？

        有人会觉得1和2是矛盾的。你不是都说了嘛，finally一定会执行的，现在又说finally一定会执行吗？这不是自相矛盾吗。

        其实上述讨论的是正常情况下的执过程，但是也存在一些特殊情况，是一定不执行的。

• try语句没有被执行到就返回了，这样finally语句就不会执行，这也说明了finally语句被执行的必要而非充分条件是：相应的try语句一定被执行到；
• try代码块中有System.exit(0);这样的语句，因为System.exit(0);是终止JVM的，连JVM都停止了，finally肯定不会被执行了；
• 守护线程会随着所有非守护线程的退出而退出，当守护线程内部的finally的代码还未被执行到，非守护线程终结或退出时，finally 肯定不会被执行；

3、try、catch、finally的效率问题

 来看一下上面代码的异常表：

参数说明：

• from：代表异常处理器所监控范围的起始位置；
• to：代表异常处理器所监控范围的结束位置（该行不被包括在监控范围内，是前闭后开区间）；
• target：指向异常处理器的起始位置；
• type：代表异常处理器所捕获的异常类型；

图中的每一行代表一个异常处理器。工作流程如下：

1. 触发异常时，JVM会从上到下遍历异常表中所有的条目；
2. 比较触发异常的行数是否在from-to范围内；
3. 范围匹配之后，会继续比较抛出的异常类型和异常处理器所捕获的异常类型type是否相同;
4. 如果类型相同，会跳转到target所指向的行数开始执行；
5. 如果类型不同，会弹出当前方法对应的java栈帧，并对调用者重复操作；
6. 最坏的情况下JVM需要遍历该线程 Java 栈上所有方法的异常表；

        以第一行为例：如果位于2-4行之间的命令（即try块中的代码）抛出了Class java/lang/Exception类型的异常，则跳转到第8行开始执行。而8: astore_1是指将抛出的异常对象保存到局部变量表中的1位置处。

综上所述：

        从字节码指令的角度来讲，如果代码中没有异常抛出，其执行时间可以忽略不计；如果代码执行过程中出现了上文中的第6条，那么随着异常表的遍历，更多的异常实例被构建出来，异常所需要的栈轨迹也在生成。该操作会逐一访问当前线程的栈帧，记录各种调试信息，包括类名、方法名、触发异常的代码行数等等。所以执行效率会大大降低。