ASM中LocalVariableSorter的newLocal返回异常局部变量索引问题咨询

我来帮你拆解这个问题——你遇到的槽位差异（预期第二个变量是5，实际是7），核心原因大概率是局部变量表中存在你没注意到的隐式占用，或者LocalVariableSorter的状态被意外修改了，具体分析如下：

1. 初始槽位计算正确，但中间有隐式变量占用了槽位 #

先确认你的初始槽位逻辑是对的：

• 实例方法的第一个槽位（索引0）是this（引用类型，占1个槽）
• long类型的参数占用索引1和2（2个槽）
• 第一个通过newLocal添加的long变量占用3和4，返回3，这部分完全符合预期

那为什么第二个变量会跳到7？说明索引5和6被某个你没意识到的变量占用了。常见的隐式变量场景：

• 编译器生成的辅助变量：比如你的方法里有字符串拼接（编译器会自动生成StringBuilder局部变量）、try-with-resources语句（生成资源管理变量）、lambda表达式（生成捕获外部变量的局部变量），哪怕你没显式写局部变量，编译器也会偷偷添加。
• 异常处理的隐式变量：如果方法里有catch块，编译器会生成存储异常对象的局部变量，占用槽位。

2. LocalVariableSorter的状态被其他操作意外修改 #

LocalVariableSorter通过nextLocal变量跟踪下一个可用槽位，如果你在两次newLocal调用之间做了这些操作，会导致nextLocal异常增加：

• 调用了visitLocalVariable注册宽类型变量：比如你不小心在中间插入了visitLocalVariable，指定索引5、类型为long，LocalVariableSorter会自动把nextLocal更新到5+2=7。
• 串联了其他ASM转换器：如果在LocalVariableSorter之前还有其他ClassVisitor（比如代码插桩工具），它可能已经提前添加了局部变量，占用了槽位5和6。

3. ASM版本的兼容性bug #

旧版本的ASM（比如5.x及更早）的LocalVariableSorter在处理宽类型变量时可能存在槽位分配逻辑的bug，导致nextLocal计算错误。如果你的项目用的是老版本ASM，可以尝试升级到9.x的稳定版本，看是否能解决问题。

快速验证方法 #

你可以通过以下方式定位问题：

• 用javap -v命令反编译目标方法，查看LocalVariableTable部分，确认是否有隐式变量存在。
• 自定义LocalVariableSorter子类，在两次newLocal调用之间打印nextLocal的值，看它是从5跳到7的具体触发点。
• 暂时移除其他ASM转换器，单独用LocalVariableSorter测试，看是否还会出现槽位跳变的情况。

内容的提问来源于stack exchange，提问作者Haasip Satang