Java嵌套try-finally块的等价性与JVM执行保障探究

两种嵌套结构示例 #

结构一：外层finally包裹内层try-finally #

try {
    s1;
} finally {
    try {
        s2;
    } finally {
        s3;
    }
}

结构二：外层try包裹内层try-finally #

try {
    try {
        s1;
    } finally {
        s2;
    }
} finally {
    s3;
}

两种结构的执行保障差异 #

正常执行或同步异常场景下，两种结构没有本质差异，都会按顺序执行所有清理逻辑：

• 结构一：s1执行完成或抛出异常后，进入外层finally，随后执行s2，无论s2结果如何都会执行s3
• 结构二：s1执行完成或抛出异常后，进入内层finally执行s2，内层逻辑结束后进入外层finally执行s3

但在异步异常场景下，两者存在关键区别：

• 结构一中，外层finally启动后，若在内部try块（s2的try）开始执行前触发异步异常（如虚拟机抛出的StackOverflowError、OutOfMemoryError），s2和s3的逻辑都不会被执行——此时内部try-finally还未激活，JVM没有执行它的义务。
• 结构二中，一旦进入内层try块执行s1，外层try和内层try的finally块都已绑定到当前执行上下文。无论s1执行中、s2执行中触发任何异常，内层finally（s2）和外层finally（s3）都会被JVM尝试执行，不会出现某部分清理逻辑完全不启动的情况。

finally块空白位置的异步异常问题 #

你提到的结构一中// not a statement的位置，确实存在理论上的异步异常风险：
根据《Java语言规范》11.1.3的异步异常条款，虚拟机抛出的错误可以在程序执行的任意点触发，包括语句之间的"空白"区域（编译后对应字节码指令的间隙）。如果在进入外层finally块后、内部try块的第一条指令执行前触发这类异常，内部的s2和s3逻辑就完全不会被执行。

对JLS异步异常条款的理解 #

你的理解没有错误：异步异常并非仅在有语句的位置抛出。JVM可以在执行过程中的任意时刻（包括字节码指令之间、甚至单个指令执行中）触发异步异常，这类异常不受普通try-catch的完全控制，只能通过finally块尽可能保障清理逻辑执行。而第二种嵌套结构正是通过提前绑定外层finally块，避免了"外层finally启动后部分清理逻辑未激活"的风险。

内容的提问来源于stack exchange，提问作者stonar96