i++在JVM中非原子：iload_1读旧值→iinc 1自增局部变量→istore_1写回旧值，三步可中断；volatile不保障复合操作原子性，字节码才是唯一可靠依据。
看 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 必须保证这三步的可观测性与可中断性。
