i++ 字节码执行流程解析

i++ 在 JVM 中本质上是非原子操作，其字节码执行流程明确拆解为 iload（读旧值）、iinc 或 iadd（计算新值）、istore 或 putfield（写回——且常是旧值而非新值）三个可被线程中断的独立步骤；无论是否使用 volatile 修饰，都无法改变这一复合操作的非原子性本质，因为 volatile 仅保障单次读/写的可见性与有序性，不覆盖多步字节码间的竞态风险；真正可靠的理解依据唯有 javap -c 反编译出的字节码，它揭示了 Java 行为在 JVM 规范层面的确定性真相，而非依赖底层 CPU 汇编或直觉猜测。

看 iload、iinc、istore 三步分离才是关键

直接看字节码就能确认：i++ 在 JVM 层面绝不是一条指令，而是至少三个可被中断的独立操作。用 javap -c 反编译后，典型结构是：iload_1（读变量值到操作数栈）、iinc 1 by 1（局部变量自增）、istore_1（把旧值写回——注意，不是新值）。这个“先读旧值、再算新值、最后存旧值”的流程，就是非原子性的铁证。

iinc 指令不等于“原子加一”，它只改局部变量表

iinc 是个特殊指令，它直接在局部变量表上做 +1，不经过操作数栈。但它**不负责读取也不负责写回主内存中的字段值**——如果 i 是实例字段（如 private int i），那真正读写字段的动作由 getfield 和 putfield 完成；而 iinc 只对局部变量有效。所以你在 main() 里写 int i = 0; i++; 看到的是 iinc，但换成 this.i++ 就变成 getfield → iadd → putfield 三步，每一步都可能被线程切换打断。

volatile 修饰字段也无法让 i++ 原子化

很多人误以为加了 volatile 就能保证 i++ 安全，其实它只保障单次读/写的可见性与禁止重排序，**不保障复合操作的原子性**。字节码里仍是 getfield → iadd → putfield 三步，中间两步之间完全可能被其他线程插入执行。实测 10 个线程各调用 1000 次 volatile int i++，最终结果几乎必然小于 10000 —— 这就是三步被交叉执行的直接证据。

别信“CPU 汇编三步”类比，JVM 字节码才是唯一可靠依据

从 x86 汇编推导 Java 行为是危险的：JVM 不承诺映射到某条 CPU 指令，且现代 JIT 编译器可能内联、消除、甚至重排字节码（只要语义等价）。唯一稳定、可验证、跨平台一致的依据，就是 javap -c 输出的字节码。你看到 getfield、iadd、putfield 分开出现，就说明它在 JVM 规范层面就是非原子的——不管底层 CPU 怎么优化，JVM 必须保证这三步的可观测性与可中断性。

到这里，我们也就讲完了《i++ 字节码执行流程解析》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！