字节码偏移量是javap -c输出中每条指令前的数字，表示该指令在方法字节码数组中的下标（从0开始），异常表中的from、to、target均为此偏移量；from包含、to不包含，范围为[from, to)，用于jvm异常跳转定位。
字节码偏移量在异常表里到底指什么
它就是 javap -c 输出中每条指令前面那个数字，代表该指令在当前方法字节码数组里的下标位置（从 0 开始）。异常表（Exception table）里的 from、to、target 全是这种偏移量，不是行号，也不是 Java 源码的逻辑位置。
常见错误现象：看到异常栈里报 java.lang.ArrayIndexOutOfBoundsException，但源码里对应行没明显数组访问；或者用 javap 查异常表时，发现 from=5 到 to=12 范围覆盖了多条指令，却不确定哪条真正抛了异常——本质就是混淆了「源码行号」和「字节码偏移」。
-
from是包含的（inclusive），to是不包含的（exclusive），即监控范围是[from, to) - 如果某条指令的偏移量落在这个区间内，并且执行时抛出匹配的异常类型，JVM 就跳转到
target偏移量处执行（通常是athrow或异常处理逻辑） - 注意：
to值可能等于整个方法字节码长度，表示“直到方法末尾”，不是 bug
怎么快速定位某行 Java 代码对应的字节码偏移
别靠肉眼数，用 javap -c -l（-l 表示输出行号表 LineNumberTable）。
使用场景：调试 try-catch 范围是否覆盖预期语句，或分析为什么某个异常没被 catch 住。
立即学习“Java免费学习笔记（深入）”；
示例输出片段：
public void test() {
0: iconst_1
1: istore_1
2: iload_1
3: ifeq 10
6: aload_0
7: invokevirtual #4 // Method java/lang/Object.toString:()Ljava/lang/String;
10: return
LineNumberTable:
line 5: 0
line 6: 2
line 7: 6
line 8: 10
}
这里 line 6: 2 表示 Java 源码第 6 行编译后从偏移量 2 开始；而异常表中的 from=2, to=10 就对应这行及之后直到 return 前的所有指令。
- 偏移量是编译器生成的，跟是否加
final、是否内联无关，但跟优化等级有关（如-g:none会丢掉 LineNumberTable） - 局部变量表（LocalVariableTable）和行号表是独立的，不能用变量名反推偏移
异常表中监控范围不生效的典型原因
最常见的是 to 值设小了，或者异常类型不匹配——但更隐蔽的是：构造函数调用、synchronized 块、lambda 表达式内部的字节码结构会让范围“断开”。
性能影响很小，但写错会导致异常静默吞掉或跳转到错误位置。
- 空的 try 块（比如只有
try { }）会被 javac 优化掉，异常表里可能根本没有对应项 -
synchronized方法隐式有异常监控（确保 monitorexit 执行），其异常表项的from/to可能跨很大范围，和你写的 try 无关 - catch 多个异常类型时，异常表会为每个类型生成独立项，顺序按源码中 catch 出现顺序，不是按继承关系
- Java 7+ 的 multi-catch 编译后仍拆成多个异常表项，
from/to相同但catch_type不同
用 javap 看异常表时容易漏掉的关键信息
javap -c 默认不显示异常表，必须加 -verbose；而且只显示 Exception table: 下面那几列，不自动关联到源码行号。
示例异常表输出：
Exception table:
from to target type
2 10 13 Class java/lang/NullPointerException
13 15 13 Class java/lang/NullPointerException
这里 from=2, to=10 监控的是上面字节码中偏移 2～9 的指令；target=13 是跳转目标，得去查偏移 13 处是什么指令（通常是 astore_1 存异常对象）。
- type 列显示的是常量池索引（如
#23），加-verbose才会展开成类名；不加就只能看到数字 - 没有
throws声明的方法，也可能生成异常表（比如 synchronized 或 try-with-resources 自动生成的） - 泛型擦除后，异常捕获的类型是运行时真实类型，异常表里的
type也是擦除后的，跟源码写的泛型无关
偏移量本身没语义，只是 JVM 调度的下标。真正难的是把偏移映射回你改的那行代码——尤其当用了 Lombok、注解处理器或字节码插桩工具时，javap 输出的行号可能已经失效。
