JVM异常处理不回退变量状态，而是通过异常表跳转执行catch或finally块；异常表含from、to、target、type四字段，按顺序匹配首个满足from≤异常位置且异常类型匹配的条目。
异常抛出后，JVM 并不直接“回退变量状态”，而是通过异常表定位到合适的 异常处理器（ExceptionHandler），跳转执行对应的 catch 或 finally 块。所谓“回退变量状态”，本质是局部变量表（Local Variable Table）中变量的生命周期自然终止，而非显式还原——JVM 不保存变量的历史值，也不会撤销赋值操作。
异常表（Exception Table）的作用不是回滚，而是跳转
每个方法的字节码都附带一张异常表，记录形如 [from, to, target, type] 的四元组：
- from / to：指定监控的字节码索引范围（含 from，不含 to）
- target：异常处理器入口地址（即 catch 块起始指令位置）
- type：捕获的异常类（如 Ljava/lang/NullPointerException;），为 null 表示 finally
当某条指令抛出异常时，JVM 按顺序查找异常表中第一个满足 from ≤ 异常发生位置 且 <code>异常实例可被 type 类型捕获 的条目，然后将程序计数器（PC）设为 target，继续执行。
局部变量不会“回退”，但作用域决定其是否可达
Java 中没有“回滚变量”机制。变量状态变化是不可逆的：
- 若变量在 try 块内被修改（如
int x = 1; x = 5;），该修改已写入局部变量表，不会因异常而恢复为 1 - 但若变量声明在 try 内部（如
int y = 10;），它在字节码中可能被分配在某个 slot，但超出作用域后，该 slot 可被后续代码复用——这不是回退，而是重用 - 编译器还可能对未逃逸的局部变量做优化（如分配到寄存器、消除冗余写），此时甚至没有“内存中的旧值”可供回退
finally 块能“覆盖”逻辑，但不是状态回退
异常表中 type 为 null 的条目对应 finally 块。无论是否异常、是否被捕获，只要执行流进入监控范围，finally 就会被触发：
- 如果 try 中修改了变量，finally 再次修改它（如置默认值），看起来像“恢复”，实则是新赋值
- JVM 会为每个 finally 插入多份字节码副本（例如：正常退出路径、异常未被捕获路径、异常被捕获后退出路径），确保语义正确
- 注意：return 语句在 try 中执行时，返回值会暂存，然后执行 finally；若 finally 里也有 return，则覆盖原返回值——这是语义规则，不是变量回退
真正需要“状态回退”的场景应由程序逻辑保障
若业务要求原子性（如转账失败需还原余额），必须手动编码实现，例如：
- 使用临时变量保存原始值，在异常分支中显式恢复
- 采用不可变对象，避免状态污染
- 借助事务机制（数据库、分布式事务框架）或补偿操作（Saga 模式）
- 利用 try-with-resources 确保资源清理，但它也不恢复业务状态
JVM 层面只负责控制流转移和栈帧清理，不介入业务状态管理。
