正常完成时返回地址被精准复用，异常完成时被彻底忽略而由异常表接管跳转。正常完成：调用时pc值写入栈帧作为返回地址，return指令直接跳转；异常完成：栈帧强制弹出，虚拟机查异常表匹配handler_pc，不读取返回地址。
方法正常完成和异常完成对栈帧中返回地址的使用方式完全不同——不是“怎么用”，而是“用不用”。正常完成时，返回地址是核心调度依据；异常完成时，它被彻底绕过，由异常表接管跳转逻辑。
正常完成：返回地址全程参与、精准复用
调用发生时，JVM就把调用者下一条指令的地址（即PC值）写入被调用方法的栈帧，作为“返回地址”。这个地址不占额外空间，是入栈时就已确定的静态快照。
- 执行到 ireturn、areturn 或 return 等指令时，虚拟机直接读取该地址
- 栈帧出栈前，把返回值（如有）压入调用者操作数栈顶部
- PC寄存器被设为该地址，调用者从原中断点无缝继续执行
- 整个过程无查表、无匹配、无递归弹栈，行为确定且轻量
异常完成：返回地址被忽略，异常表成为唯一跳转依据
一旦抛出未捕获异常，栈帧里保存的返回地址立即失效。虚拟机不会读它、不依赖它，也不更新它。
- 当前栈帧被强制弹出，不执行返回值压栈操作
- 虚拟机转向该方法的异常表（Exception Table），按异常类型和抛出位置查找 handler_pc
- handler_pc 可能指向当前方法的 catch 块、上层方法的 try 区域，甚至更外层——与调用链无关
- 若未匹配成功，异常向上抛，触发连续多层栈帧弹出，可能快速耗尽栈空间
关键区别不在“存没存”，而在“用不用”
很多人误以为异常路径要另存一个地址。其实栈帧里只存了一个地址，且仅服务于正常出口。异常路径根本不走这套契约，而是切换到基于类文件元数据的静态调度机制。
- 返回地址本身在异常场景下形同虚设，既不被读取，也不被覆盖
- 异常表在类加载阶段就解析完毕，运行时只需常数时间匹配
- 真正损耗来自隐式行为：无返回值搬运 + 查表 + 可能的多层出栈，而非地址存储开销
对开发的实际提示
理解这点有助于写出更健壮的代码：
- 频繁抛异常且未捕获的方法，在深度递归或嵌套调用中更容易触发 StackOverflowError
- finally 块的执行不依赖返回地址，而是由编译器生成的异常表条目保障，所以即使 return 被跳过也能运行
- 反编译字节码时，能看到每个方法附带的异常表结构，它和 return 指令完全独立存在
