exception table 是 class 文件中方法的结构化信息，jvm 在异常抛出时实时查表跳转，决定执行哪个 catch 或 finally 块；它真实运行时起作用，且从 jdk 1.0 到 21 结构未变。
Exception Table 是什么，它真在运行时起作用吗
Exception Table 不是 Java 源码里的语法，也不是编译期生成的注解或元数据——它是 class 文件里每个方法的结构化信息，由 JVM 在方法调用栈展开（exception propagation）时实时查表用的。它不参与字节码执行流程，但一旦抛出异常，JVM 就停下手头指令，立刻跳转到这张表里匹配：当前异常发生位置（即 PC 偏移量）、抛出的异常类型、是否在 try 范围内，然后决定跳去哪个 catch 块的起始偏移量。
常见错误现象：javap -v 看不到 Exception Table？其实是默认不显示；得加 -l（小写 L）参数才输出行号和异常表。没加就以为“没生成”，其实它一定存在（哪怕空 try-catch 也会有条目）。
- 使用场景：调试 class 文件结构、理解异常传播底层机制、做字节码插桩（如 AOP 异常拦截）时必须读这张表
- 性能影响：查表是 O(n) 的线性扫描，但 n 通常极小（一个方法最多几个 catch），对运行时无感知
- 兼容性：从 JDK 1.0 到 JDK 21，表结构没变过，字段始终是
start_pc、end_pc、handler_pc、catch_type
怎么用 javap 查看并解读 Exception Table 条目
javap -v -l MyClass 输出中，每个 Code: 段落下方会出现 Exception table:，每行对应一条规则。格式固定为：from to target type，分别对应 start_pc、end_pc、handler_pc、catch_type。
关键点在于：end_pc 是**开区间**——异常发生在 [start_pc, end_pc) 范围内才匹配；而 handler_pc 是 catch 块第一条指令的偏移量（不是 catch (Exception e) 那行源码，是字节码里 astore_1 或类似指令的位置）。
立即学习“Java免费学习笔记（深入）”；
- 常见错误现象：
from=10 to=20 target=35 type=java/lang/NullPointerException，但你在源码第 15 行 throw，却没进 catch？检查第 20 行字节码是否已是finally或方法结尾——end_pc超出范围就不匹配 - 参数差异：
type=0表示 finally 块（不是异常类型，而是通配），此时catch_type字段为 0，JVM 会无条件跳转 - 注意：
catch_type存的是常量池索引，javap已帮你解析成类名；但如果你用 ASM 手动读 class，得用constant_pool.get(catch_type).toString()取真实类名
finally 怎么塞进 Exception Table，为什么会有两条记录
一个带 finally 的 try-catch-finally，javac 会生成**至少两条** Exception Table 条目：一条给具体异常类型（如 IOException），另一条 type=0 给 finally。这是因为 JVM 规范要求：无论正常 return、异常抛出、还是 break/continue 出 try 块，都必须执行 finally 对应的字节码段。
实操验证：写个 try { m1(); } catch(Exception e){} finally{ m2(); }，用 javap -v -l 查看——你会看到两条记录，target 指向同一段字节码（m2() 的指令起始处），但其中一条 type 是具体类，另一条是 0。
- 容易踩的坑：以为 finally 是“语法糖”，其实它强制依赖 Exception Table 实现；没有这张表，JVM 根本不知道该在哪插 finally 的跳转逻辑
- 性能影响：多一条表项几乎零开销，但要注意——如果 try 块很大（比如几千行），
from/to跨度大，JVM 仍需逐条比对，不过实践中极少构成瓶颈 - 兼容性细节：JDK 8+ 对 try-with-resources 编译后，会把资源 close() 插入 finally 分支，同样走 type=0 的那条记录
自定义 ClassLoader 或字节码增强时，Exception Table 容易漏改什么
如果你用 ASM、Byte Buddy 或 Javassist 修改方法字节码（比如在 catch 前加日志），只改指令但忘了同步更新 Exception Table，JVM 运行时会直接报 java.lang.VerifyError: Expecting a stackmap frame 或更隐蔽的 NoClassDefFoundError（因校验失败导致类加载中断）。
核心原则：任何对 Code 段指令的增删，都会导致所有 PC 偏移量变化，进而让原有 Exception Table 的 from/to/target 全部失效。
- 必须重算：插入新指令后，所有原
handler_pc >= 插入点的条目，handler_pc += 新增字节数；同理from/to也要按位置偏移调整 - 工具建议：ASM 的
MethodVisitor默认不维护 Exception Table，得自己覆写visitTryCatchBlock并缓存，最后在visitEnd里重新 emit；Byte Buddy 的Advice内置处理了这点，但 Advice 本身不能修改 try/catch 结构 - 最容易被忽略的地方：finally 块的
type=0条目常被当成“无关项”跳过修正，但它指向的target一旦错位，finally 就永远不执行——线上静默故障的典型来源
