iconst_1 是将整数 1 压入操作数栈的单字节指令，不访问局部变量表，专用于 -1~5 小整数，与 iload/istore 无关，常见于 return 1 或初始化场景，现代 jvm 可能将其常量折叠优化掉。

iconst_1 是把整数 1 压入操作数栈，不涉及局部变量表

它不是“给变量赋值”，也不是“从变量读值”，纯粹是向当前方法的操作数栈顶部推入一个 int 类型的常量 1。JVM 执行时不会访问局部变量表，也不修改任何变量槽（slot）。常见误解是以为它和 iload_1 或 istore_1 一样在操作变量槽——其实完全无关。

典型使用场景：方法里写 return 1;、if (x) return 1; 中的字面量分支、或者 int a = 1; 的初始化阶段（注意：赋值动作由后续的 istore_n 完成，iconst_1 只管提供数值）。

• iconst_1 指令长度仅 1 字节，比 bipush 1 更紧凑，JVM 专为 -1~5 这 7 个常用小整数设计了独立指令
• 它压入的是 int，不是 byte 或 short；即使源码写 byte b = 1;，编译后仍是 iconst_1 + istore_n，类型截断发生在存储时
• 没有“对应变量编号”的概念——iconst_1 后面不跟任何索引数字，而 iload_1 的 _1 才是指局部变量表第 1 号槽

为什么反编译看不到 iconst_1？它被优化掉了

现代 JDK（尤其是 JDK 8u292+ 和所有 JDK 17+）在类加载或 JIT 编译阶段可能直接折叠常量，导致 iconst_1 在最终生成的字节码中消失。你用 javap -c 看到的可能是 iconst_0、iconst_2，但唯独缺 iconst_1，尤其在简单 getter 或常量返回方法里。

• 确认是否真被优化：用 java -XX:+PrintAssembly（需 hsdis）看 JIT 后的汇编，或用 javap -v 查看常量池引用，再比对原始 class 文件（用 xxd 或十六进制编辑器）
• 禁用常量折叠：加 JVM 参数 -XX:-OptimizeFillArray 无效，真正影响字节码生成的是编译器（javac），不是运行时；要保留原指令，得用老版本 JDK（如 JDK 7）或手动写 .class
• IDEA 或 Eclipse 的字节码查看插件默认启用“简化显示”，勾选“Show raw bytecode”才能看到未修饰的指令流

和 iload_1 / istore_1 混用时，栈与变量表怎么协同？

三者分工明确：iconst_1 准备值，iload_1 从局部变量表取值，istore_1 把栈顶值存进局部变量表第 1 槽。它们之间靠操作数栈“中转”。容易出错的是顺序和栈深度不匹配。

比如这段 Java：

int a = 1;
int b = a + 1;

对应关键字节码是：

iconst_1        // 栈: [1]
istore_1        // 栈: [], 局部变量表 slot1 = 1
iload_1         // 栈: [1]
iconst_1        // 栈: [1, 1]
iadd            // 栈: [2]
istore_2        // 栈: [], 局部变量表 slot2 = 2

• 漏掉 istore_1 就会导致后续 iload_1 加载未定义值（实际是 0，因为 slot 默认初始化为 0，但语义上错误）
• iadd 要求栈顶两个 int，如果中间插入了对象引用指令（如 aload_0），就会报 VerifyError: Expecting to find integer on stack
• 局部变量表槽位编号从 0 开始，this（非 static 方法）占 slot 0，所以 iload_1 通常才是第一个参数或局部变量

用 ASM 或 Javassist 修改字节码时，iconst_1 的坑在哪

直接替换 iconst_1 为 iconst_2 看似简单，但要注意：指令替换必须保持栈变化一致，且不能破坏控制流图（CFG）。ASM 的 MethodVisitor 对这类常量指令非常敏感。

• 不要用 visitInsn(ICONST_1) 后紧跟 visitInsn(ICONST_2) —— 这会多压一个值，导致栈失衡；应先 visitInsn(POP) 再压新值，或直接用 visitIntInsn(SIPUSH, 2) 替代（但长度不同，需重计算帧）
• Javassist 的 insertBefore() 如果插在 iconst_1 前，新代码会先执行，可能污染栈；推荐用 replace() 并确保替换后指令数不变
• 某些混淆器（如 Allatori）会把 iconst_1 改成 ldc "1" + Integer.parseInt()，此时搜索 iconst_1 就找不到目标

真正难的从来不是认出 iconst_1，而是判断它在整个方法控制流里是否被跳过、是否在异常处理器范围内、以及它压入的 1 是否会被后续的 lookupswitch 当作 case 值——这些上下文，光看单条指令根本没法确定。