正常退出时返回地址复用入栈时保存的调用者下一条指令地址，完成栈帧清理、返回值传递和PC寄存器更新；异常退出则忽略该地址，直接弹出栈帧并查异常表定位handler_pc，不压栈返回值，可能引发多层递归出栈。
正常退出时方法返回地址如何影响栈帧
方法执行到 return 指令（如 ireturn、areturn、return 等）时，虚拟机从当前栈帧中读取预先保存的“返回地址”——这个地址是调用者方法中调用指令的下一条字节码位置。它本身不新增开销，而是复用入栈时已写入的值。
此时栈帧出栈过程完整：局部变量表和操作数栈被清理，返回值按类型压入调用者栈帧的操作数栈顶部，PC 寄存器被设为该返回地址，调用者可无缝继续执行。
- 栈空间释放干净，无残留状态
- 返回值传递成功，调用链逻辑完整
- 异常表不参与，无额外查找开销
异常抛出时方法返回地址为何绕过栈帧保存逻辑
当方法因未捕获异常而退出，虚拟机**不会使用栈帧里保存的返回地址**。因为异常出口不面向调用者“返回”，而是面向异常处理机制跳转。此时栈帧被直接弹出，其中的返回地址字段形同虚设，也不再用于恢复 PC。
虚拟机转而查询该方法元数据中的异常表（Exception Table），根据异常类型和抛出位置，匹配 handler_pc（异常处理器起始地址）。这个地址与调用点无关，可能落在当前方法的 catch 块、上层方法的 try-catch 区域，甚至更外层。
- 栈帧被强制出栈，不执行返回值压栈
- 异常表查找引入一次查表开销（常数时间，但非零）
- 若无匹配 handler，异常继续向上抛，触发多层栈帧连续弹出
两种路径对虚拟机栈的实际损耗差异
损耗不在于“内存占用大小”，而在于**出栈行为的完整性与附带操作**：
- 正常退出：一次出栈 + 一次返回值搬运 + 一次 PC 赋值 → 行为确定、轻量、可预测
- 异常退出：一次出栈（无返回值搬运）+ 异常表匹配（可能失败）+ 多次递归出栈（若持续未捕获）→ 行为分支多、隐式开销叠加、易引发 StackOverflowError
尤其在深度嵌套调用中反复抛异常且未捕获，会快速耗尽线程栈空间，比同等深度的正常返回更易触达栈上限。
关键细节：返回地址本身并不“存储两次”
很多人误以为异常退出要“另存一个返回地址”。实际上：栈帧中只存了正常出口用的返回地址；异常出口根本不用它，也**不往栈帧里写新地址**。handler_pc 来自类文件静态解析好的异常表，全程与当前栈帧内容无关。所以异常路径的“损耗”本质是跳过了栈帧设计的协作契约，改走另一套调度逻辑。
