字节码指令行号表是什么
写Java代码时，谁没碰上过 NullPointerException？控制台一报错，堆栈信息唰唰地往上冒，点开一看，行号清清楚楚。可你有没有想过，编译后的 class 文件里根本没有源码，JVM 是怎么知道异常发生在第几行的？秘密就在“字节码指令行号表”里。
行号表（LineNumberTable）是 class 文件中的一种调试信息，属于 Code 属性的一部分。它记录了字节码指令偏移量（offset）和源代码行号之间的映射关系。换句话说，它告诉 JVM：“这条指令对应的是源文件的第 X 行”。
为什么它在故障排查中很重要
想象一个场景：线上服务突然报错，日志显示异常出现在 UserServlet.class 的第 42 行。但你打开源码，发现那行是个简单的变量声明，根本不可能出问题。这时候别急着怀疑人生，先检查下编译产物有没有带上行号表。
有些构建脚本为了减小体积，会用 javac 的 -g:none 参数编译，结果就把 LineNumberTable 给去掉了。没了这张表，JVM 打印的堆栈信息里的行号就可能是 -1 或者不准确，误导排查方向。你以为是第 42 行，实际可能是在后面某个逻辑分支里。
怎么查看行号表是否存在
用 JDK 自带的 javap 工具就能看。比如有个 Test.class，执行：
javap -v Test.class输出里如果看到类似这样的内容，说明行号表在：
LineNumberTable:
line 10: 0
line 11: 3
line 12: 6这表示偏移量为 0 的指令对应源码第 10 行，偏移量 3 对应第 11 行，以此类推。如果压根没这个结构，那堆栈里的行号就别太当真。
常见问题与应对
有时候你会发现，断点打不进去，或者 IDE 显示“源码不可用”。除了确认 src 是否附加，也得看 class 文件是否包含足够的调试信息。除了行号表，还有 LocalVariableTable（局部变量表），它能让调试器显示变量名和值。生产环境不一定需要这些，但测试环境最好保留。
如果你负责发布流程，建议在打包时明确控制调试信息的保留。比如 Maven 的 compiler plugin 可以这样配置：
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<debug>true</debug>
<debuglevel>lines,vars</debuglevel>
</configuration>
</plugin>这能确保生成的 class 文件包含行号和局部变量信息，方便后续排查。
下次再看到堆栈里的行号，别无脑跟着走。先确认那张“地图”——行号表还在不在。不然，你可能正朝着错误的方向狂奔。