finally块的执行由jvm异常表和编译期插入的冗余字节码共同保障，与athrow指令无直接调用关系；athrow仅抛出异常并触发jvm查异常表跳转至预置的finally字节码。
finally块的执行不依赖athrow指令，而是由JVM在编译期插入异常表（exception table）和冗余字节码共同保障的；athrow仅负责抛出异常，真正触发finally逻辑的是JVM的异常分发机制和控制流重定向。
编译器会为每个try-finally生成重复的finally字节码
Java编译器（javac）不会等到运行时才决定是否执行finally——它在编译阶段就将finally块的字节码**显式复制**到所有可能的出口路径中：
- 正常执行完try后，紧跟一个goto跳转到finally代码段
- try中遇到return语句，先保存返回值（如astore_1），再跳转到finally
- try中发生异常且未被catch捕获，JVM查异常表定位handler，而该handler的代码体以finally字节码开头
也就是说，你写的1个finally块，在.class文件里通常对应多份字节码副本，分别服务于“正常退出”“return退出”“异常未被捕获退出”等场景。
athrow只做一件事：抛出异常对象并清空操作数栈
athrow是JVM的一条原子指令，语义明确：
- 要求操作数栈顶必须是一个Throwable子类实例
- 立即终止当前方法执行，不执行后续任何字节码
- 触发JVM查找当前方法的异常表（Exception Table），按from–to范围和catch_type匹配最近的handler
注意：athrow本身不执行finally，也不修改栈帧。它只是“喊一声有异常”，后续由JVM根据异常表跳转——而那个跳转目标，往往是编译器早已塞进去的、包含finally逻辑的字节码区域。
异常表（exception table）是finally能兜底的关键基础设施
每个方法的Code属性中都附带一张异常表，结构为：[start_pc, end_pc, handler_pc, catch_type]。对try-finally（无catch）而言：
- start_pc 和 end_pc 覆盖整个try块的字节码范围
- handler_pc 指向finally块起始位置（不是try之后的第一条指令，而是专门准备好的入口）
- catch_type 为0（表示匹配任意异常），即无论抛出什么异常都会命中此handler
正是这张表，让JVM在athrow之后能精准跳入finally逻辑——而不是靠finally“监听”athrow事件。
return与athrow在finally面前地位平等：都被拦截重定向
JVM不区分“是return还是athrow导致退出”，只要退出点落在try范围内，就会被异常表或编译插入的goto捕获：
- 遇到return：编译器已把return前的astore + goto finally写死在字节码里
- 遇到athrow：JVM查表跳转到同一份finally字节码
- 甚至System.exit()这种JVM级中断，也无法绕过已进入的finally（因它发生在JVM层面，不经过字节码控制流）
所以finally的“必然执行”，本质是编译期静态植入 + 运行期异常表驱动的双重保障，和athrow指令没有直接调用关系。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
