i++真的等于i+1？Java自增自减运算符深度剖析

先问个看起来有点傻的问题：i++ 到底等于 i + 1 吗？

如果你在 IDE 里写 int a = i++ + i++，打算让 a 等于 i + (i + 1)，那你大概率已经在面试或笔试里翻过车了。我见过太多简历写着"精通 Java"的人，被一道 i = i++ 的输出题问得当场沉默。这个运算符看似简单到能用一句话概括，实际上牵扯出的是 Java 语言最底层的求值机制、字节码执行顺序，甚至多线程安全边界。它看起来是入门第一周就该掌握的内容，却能在中级工程师的代码评审会上引发争论。

这篇文章我打算一次性把自增自减运算符讲透。不管你是刚学到"运算符和表达式"章节的零基础新手，还是在背"Java 八股文"准备面试的求职者，又或者是写了好几年业务代码但从没深究过 i++ 和 ++i 字节码差异的开发，下面的内容都值得你静下心看完。

1. 先从两个最简单的符号说起：前置与后置的真正区别

++ 和 -- 这两个符号，作用直观得不能再直观：让一个变量自增 1 或自减 1。但它们偏偏分出了 ++i（前置）和 i++（后置）两种写法。这俩有什么区别？你肯定听过那句经典口诀：前置先加后用，后置先用后加。

你可能会说，就这？那我也知道啊。好，那我们用一道最基础但细思极恐的题目来验验货：

java复制int i = 1;
int a = i++;
System.out.println("a = " + a);   // a = 1
System.out.println("i = " + i);   // i = 2

这道题大多数人都能答对：i++ 这个表达式整体的返回值是 i 自增之前的值，也就是 1，所以 a 拿到了 1，而 i 本身变成了 2。反过来：

java复制int i = 1;
int a = ++i;
System.out.println("a = " + a);   // a = 2
System.out.println("i = " + i);   // i = 2

++i 的表达式返回值是自增之后的值，所以 a 和 i 都是 2。

到这里，你可能觉得你已经完全掌握了。但真正的陷阱在后面——这两行代码的结果，你真的能推对吗？

java复制int i = 1;
i = i++;
System.out.println(i);  // 猜猜是几？

我猜九成以上的人会脱口而出：2 啊，i 先自增再赋值给自己，不是 2 吗？错，答案是 1。

这道题是我见过所有 Java 面试题里杀伤力最大的一道，没有之一。它看着简单，但背后藏着 JVM 局部变量表和操作数栈的运作逻辑。先把答案记在心里，后面我会专门用一节从字节码层面把它的老底掀开。

现在你再想想另一个问题：既然 i++ 和 ++i 在单独使用的时候完全相同：

java复制for (int i = 0; i < 10; i++) { }
for (int i = 0; i < 10; ++i) { }

这两段循环跑出来的效果一模一样，那 for 循环里到底该写 i++ 还是 ++i？这个问题在不少技术社群里能吵出一两百楼。

从纯语法角度说，两个写法没差别。从字节码层面看，在 for 循环的更新表达式里，i++ 和 ++i 最终生成的字节码也几乎一样，都是 iinc 1, 1 指令，根本不存在"后置会创建临时变量导致性能下降"这种说法——那是 C++ 里自定义类型才需要担心的问题，Java 的 int 升级增量操作根本不会产生额外对象。

但从习惯和语义清晰度来说，我个人的建议是：循环更新表达式里统一写 i++。不是为了性能，而是因为 i++ 是几乎所有程序员最早接触、最顺手的写法，读起来也符合"每轮访问完当前值再推进"的语义直觉。你非要写 ++i 也没毛病，关键是团队统一，别一会儿前一会儿后，让看代码的人每次都要停下来琢磨你是有意为之还是手滑。

2. 底层视角：局部变量表与操作数栈决定了 i = i++ 的最终结局

很多 Java 学习者都有一个痛点：语法背得滚瓜烂熟，一到 i = i++ 这种题目就懵。原因很简单——你学的是"Java 语法"，但真正执行的是"JVM 字节码"。要理解自增自减的深层行为，必须从底层机制入手。

JVM 在方法执行时，会给每个方法分配一块栈帧，栈帧里有两个核心区域：

• 局部变量表（Local Variables）：存放方法里的局部变量，以 Slot 为单位，int 类型占 1 个 Slot。
• 操作数栈（Operand Stack）：临时存放计算中间结果的栈结构，JVM 的字节码指令围绕它运作。

我们用 javap -c 反编译工具，看看 i = i++ 到底经历了什么。先写一段测试代码：

java复制public class Test {
    public void test() {
        int i = 1;
        i = i++;
    }
}

在命令行执行 javap -c Test，得到如下字节码（我会加上行内注解）：

java复制public void test();
    Code:
       0: iconst_1       // 将常量 1 压入操作数栈
       1: istore_1       // 将栈顶值 1 弹出，存入局部变量表下标为 1 的位置（即变量 i）
       2: iload_1        // 将局部变量表下标 1 的值（i=1）加载到操作数栈
       3: iinc     1, 1  // 直接将局部变量表下标 1 的值原地加 1（此刻 i 变成 2）
       6: istore_1       // 将操作数栈顶的值（刚才加载的 1）弹出，覆盖到局部变量表下标 1（i 重新变为 1）
       7: return

过程非常清晰了：

1. iload_1 先把 i 的旧值 1 复制一份压入操作数栈。
2. iinc 1, 1 指令直接对局部变量表里的 i 做自增，i 在局部变量表里变成了 2，但操作数栈里那个副本仍然是 1。
3. istore_1 把操作数栈顶的值 1 弹出来，覆盖回局部变量表的 i 位置，于是 i 被重新赋值为 1。

这就是 i = i++ 结果为 1 的根本原因：后置自增先保存旧值作为表达式的值，再修改变量，最后赋值操作又把旧值写回去了。你看到的"先自增再赋值"的直觉，在字节码层面恰好是反的——自增确实发生了，但被紧随其后的覆盖写操作抹掉了。

看，这才是真相。所有背口诀的人如果看不到字节码，永远只能靠"我记得答案是1"来应对面试题，一旦题目变形就抓瞎。

我们再来看一个高频变体，彻底检验你是否真的懂了这个机制：

java复制int i = 1;
int j = i++ + i++;
System.out.println("i = " + i);   // i = 3
System.out.println("j = " + j);   // j = 3

很多人算错这道题，是因为他们心里没有"JVM 求值顺序是确定的"这个概念。Java 语言规范规定：操作数的求值顺序是从左到右，且必须立即完成。也就是说，i++ + i++ 的求值过程：

• 先求左边 i++：把 i 的当前值 1 压栈作为表达式结果，然后 i 变为 2。
• 再求右边 i++：把 i 的当前值 2 压栈作为表达式结果，然后 i 变为 3。
• 最后执行加法：1 + 2 = 3。

所以 j = 3，i = 3。你可能会问：C 语言里同样的表达式不一定是这个结果，C 的行为是"未定义"的，但 Java 不一样，Java 严格规定了从左到右求值，所以这个结果在任何 JVM 上都是确定的。这也是为什么 Java 适合作为教学语言的原因之一——你能凭理性推算出结果，而不是依赖编译器心情。

再发散一下，连笔都别停，继续看这个稍微加了乘法优先级的版本：

java复制int i = 1;
int j = i++ * 2 + i++;
System.out.println("i = " + i);   // i = 3
System.out.println("j = " + j);   // j = 2 + 3 = 5？错！

注意，乘法的优先级高于加法是语法层面的，但操作数的求值顺序依然是从左到右先做完，再进行运算。所以：

1. 先求左边 i++：结果 1，i 变 2。
2. 再求 2：结果 2。
3. 再求右边 i++：结果 2，i 变 3。
4. 然后按运算符优先级和结合性计算：1 * 2 + 2 = 4。

所以 j 不是 5，而是 4。很多人在这里栽跟头，就是混淆了"运算符优先级"和"操作数求值顺序"两个概念。优先级决定的是表达式树怎么构建，而求值顺序决定的是每个操作数什么时候被取值。这是两个维度，千万别混在一起。

3. 运算符优先级陷阱：为什么 a = b++ + ++b 这类题容易让人怀疑人生

上一节提到了运算符优先级，这里我想专门展开一下，因为自增自减运算符的优先级本身也有讲究——它比其他绝大多数运算符都高，而且后缀形式（x++）比前缀形式（++x）优先级更高。

来一道经典的精神折磨题：

java复制int b = 1;
int a = b++ + ++b;
System.out.println("a = " + a);   // 4
System.out.println("b = " + b);   // 3

一步一步来，别跳：

1. b++ 是后缀自增，优先级最高，先求值：表达式的值是 b 的旧值 1，同时 b 变为 2。
2. ++b 是前缀自增，优先级略低于后缀（但依然高于加法），再求值：先让 b 自增为 3，表达式的值是 3。
3. 做加法：1 + 3 = 4，a = 4。

如果你把 b++ + ++b 理解成"两个表达式同时开始，b 既被加又被加"，那肯定晕。实际上 JVM 是严格串行的，一步一步来，中间变量 b 的值会不断变化，但你最终拿到的两个操作数分别是两个时刻的快照。

这种题的实战意义是什么？说实话，现代工程代码里你几乎不会写出这种反人类的表达式。但它在面试中出现频率极高，因为它能精准区分出"背答案型选手"和"真正理解执行模型型选手"。而且，理解这种求值顺序的逻辑，对排查代码里隐蔽 bug 是有真实帮助的。我曾经在一个生产环境日志里看到过这样一段简化后的代码：

java复制items.add(items.size()++);

这行代码的意图是：先把当前 size 位置的元素加到集合里，再把 size 加 1。但实际执行结果非常诡异，因为 size++ 是先取 size 的旧值作为表达式值，再去修改 size 变量。由于 items.add 和 size 之间可能存在隐式关联，索引和实际集合大小错位，最终导致数据错乱。排查了整整一个下午才定位到这行"看上去人畜无害"的代码。所以说，自增自减不是弱鸡知识点，它在真实代码里埋炸弹的能力超乎你的想象。

如果你现在去面试，遇到这种表达式题，我教一个通用思路：把求值步骤拆开写。永远不要尝试心算出最终结果，你只需要严格遵守以下步骤：

1. 确定表达式树结构（根据运算符优先级和结合性）。
2. 从左到右，逐个对操作数求值。
3. 遇到自增自减时，区分"表达式的值"和"变量的新值"。
4. 所有操作数都求值完毕后，再从树底向上执行运算符。

用这个流程，任何自增自减表达式题都能一步步做出来，前提是你足够耐心。我甚至见过有人把这种题目做成表格，列上"当前 b 的值""表达式中间结果"两列，最终答案绝不会错。

4. 循环遍历、数组下标与边界条件：自增在实战中的使用艺术

聊完了理论，回到我们每天写代码的真实场景。自增自减最常见的使用场景无非三个：循环计数、数组下标移动、迭代器推进。这三个场景如果你只是无脑用 i++，大概率没问题，但如果你深入想过边界条件，会发现不少细节值得打磨。

4.1 for 循环中的 i++：从 0 到 n 还是从 1 到 n

写数组遍历时，最常见的正确姿势是：

java复制int[] arr = new int[]{1, 2, 3, 4, 5};
for (int i = 0; i < arr.length; i++) {
    System.out.println(arr[i]);
}

这里有两个边界细节：

• 初始值 i = 0 是因为数组下标从 0 开始。
• 循环条件是 i < arr.length 而不是 i <= arr.length，因为最后一个合法下标是 length - 1。

如果你在循环体里又把 i 当普通变量自增了一次，比如：

java复制for (int i = 0; i < arr.length; i++) {
    if (arr[i] == 3) {
        i++;  // 跳过下一个元素
    }
}

这种写法在某些算法题里确实能省几行代码（比如"删除重复元素"类型的题目），但它会造成循环步长不固定的隐性逻辑。源码可读性会下降，而且一旦循环体内还要用 i 做其他事，很容易产生 off-by-one 错误。

我自己的经验是：循环体内尽量别改循环变量。如果真的需要"跳过某个元素"的语义，用 continue 加一个辅助布尔变量，或者直接改用 while 循环显式控制步长，可读性会好非常多。

4.2 从尾到头遍历：i-- 的边界条件最容易踩坑

如果你需要从数组末尾往前遍历，代码框架一般长这样：

java复制for (int i = arr.length - 1; i >= 0; i--) {
    System.out.println(arr[i]);
}

这里的陷阱是循环条件 i >= 0。一旦误写成 i > 0，数组第 0 个元素就会被遗漏。这是 off-by-one 错误的经典来源。

另一个跟自减相关的边界条件出现在"删除元素"中。假如你要用类似"覆盖法"原地删除数组里某个元素，通常要做一个从后往前遍历，用后一个元素覆盖前一个元素：

java复制int[] arr = new int[]{1, 2, 3, 4, 5};
int targetIndex = 2;
for (int i = targetIndex; i < arr.length - 1; i++) {
    arr[i] = arr[i + 1];
}
// 此时数组为 1, 2, 4, 5, 5，尾部的 5 属于冗余值

这个代码里的 arr[i + 1] 就是典型的自增思想的应用——你不需要真的写 i++，但你要理解"下一个位置"的索引是 i + 1，这和 i++ 的"让变量往后挪一位"完全是一个逻辑。

4.3 哨兵值与自增：二分查找里的 mid = low + (high - low) / 2

二分查找是自增自减思想最密集的算法之一。比如标准二分查找的 while 循环里，经常需要移动 low 和 high：

java复制int low = 0, high = arr.length - 1;
while (low <= high) {
    int mid = low + (high - low) / 2;
    if (arr[mid] < target) {
        low = mid + 1;   // 相当于 mid++ 但更安全
    } else if (arr[mid] > target) {
        high = mid - 1;  // 相当于 mid-- 但更安全
    } else {
        return mid;
    }
}

为什么这里不直接写 low = mid++？因为 mid++ 是先把 mid 的旧值赋给 low，再让 mid 自增，结果 low 根本不会变成 mid + 1，而是变成 mid。这又是一处容易隐蔽出错的地方。在赋值和自增同时出现时，一定要想清楚你到底是想要"自增后的值"还是"自增前的值"再赋给左边。

顺便说一句，low = mid + 1 这种写法远远好于 low = ++mid，因为前者的意图一目了然，后者虽然结果等价，但让读代码的人不得不停下来想一下。代码是给人读的，能在语义上直白就别玩花活。

5. 类型晋升与强制转换：byte 和 short 的自增自减有哪些隐蔽规则

很多初学者没意识到，自增自减并不是"所有数值类型都能随意用"。尤其是 byte 和 short，这两类变量做自增时，编译器会做一些你可能没注意到的隐式类型转换。

先看这段代码：

java复制byte b = 1;
b = b + 1;   // 编译报错：不兼容的类型，从 int 转换到 byte 可能会有损失

为什么报错？因为 Java 中整数运算时，byte 会自动晋升为 int，b + 1 的结果是 int，你试图把 int 赋给 byte，在不显式强转的情况下编译器直接拒绝。

但下面这段代码却能通过编译：

java复制byte b = 1;
b++;         // 编译通过

这就很有意思了：同样是让 b 加 1，为什么 b = b + 1 报错，而 b++ 不报错？

原因在于 JLS（Java 语言规范）对复合赋值和自增自减的特殊规定：自增自减运算符在编译时会自动执行隐式窄化转换，且结果会转换回变量的原始类型。也就是说，b++ 等价于 b = (byte)(b + 1)，编译器自动帮你插入了强制类型转换。

你可能会问：那如果我让 b 加到超过 byte 的范围怎么办？比如：

java复制byte b = 127;
b++;
System.out.println(b);  // -128

结果不是 128，而是 -128。因为 b + 1 先得到 int 类型的 128，然后强制转换为 byte 时发生了溢出，取低 8 位，得到 -128。这就是数值溢出的经典场景。

这类问题在实际业务里真的会出现吗？说实话，纯 byte 类型自增溢出很少见，但在一些协议解析、位运算、二进制数据处理的场景里，比如读文件头、解析网络包时，byte 和 short 依然活跃，溢出问题就值得警惕。如果你写的是支付金额、库存数量这种业务数值，一般都会用 int 或 long，但也逃不过 Integer.MAX_VALUE 的边界。所以理解"自增可能溢出"这个点，能帮你避免很多隐蔽的 bug。

再扩展一个相关知识点：char 类型也能自增。这听起来很反直觉，但在某些场景下确实能用。比如 char c = 'a'; c++; 之后 c 变成 'b'。因为 char 本质上是无符号的 16 位整数，对一个字符变量自增，实际上是对它对应的 Unicode 码点自增。在一些字符遍历的题目里（比如输出连续字母表），用 char 自增可以写出很简洁的代码。但同样的，System.out.println('a' + 1); 输出的是 98 而不是 'b'，因为 'a' + 1 中 'a' 被提升为 int，结果是整数。这个区别也是面试的基础高频点。

6. String 拼接陷阱：自增运算符别想碰字符串

聊一个容易踩的小坑：++ 只能用在变量上，不能用在字面量或表达式上。比如：

java复制int a = 1;
int b = 2;
int c = a + b++;  // 合法
int d = (a + b)++; // 编译报错：unexpected type

等号右边是一个完整的表达式，不能对表达式做自增。你只能对"变量"做自增。这个规则看着简单，但初学者常犯的错误是把 sum++ 和字符串拼接混在一起：

java复制String s = "count: ";
int count = 1;
System.out.println(s + count++);
System.out.println(count);   // 2

这里 count++ 是作为一个 int 值参与字符串拼接的，拼接时先取 count 的旧值 1，拼成字符串 "count: 1"，然后 count 才变成 2。如果你想输出 "count: 2"，就必须写 ++count 或者先自增再拼接。字符串拼接和自增的优先级问题也是面试里常被拿来出题的。

再看一个我见过很多次的 bug 型写法：

java复制System.out.println("result: " + i++ + i);

这段代码的输出到底什么？假设 i 初始为 5，那么：

1. 先拼接 "result: " 和 i++ 的结果 5，得到 "result: 5"，i 变为 6。
2. 再拼接 i 的当前值 6，得到最终输出 "result: 56"。

你没看错，结果是 56，两个数字粘在一起了。如果你想表达 5 + 6 = 11，那就需要加括号改变优先级和拼接顺序。这种 bug 在自己的代码里很难发现，但在别人 review 时往往一眼就能看出来。建议字符串拼接和自增不要同时出现在同一行，拆开写不但安全，可读性也好得多。

7. 多线程视角：为什么说 i++ 不是原子操作

自增自减除了语法层面的坑，在多线程场景下还有一个更严重的本质问题：i++ 不是原子操作。这也是 Java 并发面试里的高频考点。

你可能会想：CPU 执行一条 i++ 指令不是一下子就好了吗？怎么会不是原子操作？

关键在 JVM 字节码层面。回到我们前面看的字节码，i++ 在执行时包含了至少三步：

1. 从主内存读取 i 的值到线程的工作内存（对应 iload）。
2. 在工作内存中把值加 1（对应 iinc）。
3. 把新值写回主内存（对应 istore）。

这三个步骤之间可能被线程调度随时打断。假设两个线程同时执行 i++，初始 i = 0：

• 线程 A 读取 i = 0，准备自增，但还没来得及写回，CPU 切到线程 B。
• 线程 B 读取 i = 0，执行自增，写回 i = 1。
• 线程 A 恢复执行，把自增结果 1 写回 i = 1。

最终 i 应该是 2，却变成了 1。这就是经典的"丢失更新"问题。生产环境中，如果你用一个普通 int 变量做多线程计数器，并发量一大，最终值几乎必然小于理论值。

解决方式有三条路线：

• 使用 AtomicInteger：它的 incrementAndGet() 方法基于 CAS（Compare-And-Swap）实现，能够保证自增的原子性。
• 使用 synchronized 或 ReentrantLock：给自增操作加锁，保证同一时刻只有一个线程能执行。
• 使用 LongAdder：在高并发下比 AtomicInteger 性能更好，适合统计类场景。

对应到自减也一样，i-- 同样不是原子操作。所以如果你在多线程环境里写了一个共享计数器，千万不要图省事直接 count--。

我见过一个真实案例：一个统计在线人数的模块，并发高峰时计数总是对不上，最大值和理论值差出一大截。排查了半天，最后定位到一行 onlineCount--，这就是典型的多线程自增自减陷阱。后来改成 AtomicInteger.decrementAndGet()，问题立刻消失。自增自减"看起来简单"的这个属性，恰恰是它容易让你放松警惕、埋下并发事故的原因。

为了让你对"非原子"的理解更直观，我建议你在本地跑一下这个简单的复现代码：

java复制public class AtomicityTest {
    private static int count = 0;

    public static void main(String[] args) throws InterruptedException {
        int threadCount = 20;
        int incrementsPerThread = 10000;
        Thread[] threads = new Thread[threadCount];

        for (int i = 0; i < threadCount; i++) {
            threads[i] = new Thread(() -> {
                for (int j = 0; j < incrementsPerThread; j++) {
                    count++;   // 非原子操作
                }
            });
            threads[i].start();
        }

        for (Thread t : threads) {
            t.join();
        }

        System.out.println("Expected: " + (threadCount * incrementsPerThread));
        System.out.println("Actual  : " + count);
    }
}

在绝大多数环境下，实际值会小于期望值 200000。这就是 count++ 在多线程下的真实表现。

8. 代码规范与 code review：如何在团队中优雅地使用自增自减

最后聊一点软技能。作为一个写过多年 Java、也做过不少 code review 的人，我对自增自减在工程里的使用规范有一些个人体会。

8.1 禁止在复杂表达式中使用自增自减

我给自己立过一个规矩：如果一个表达式里出现了超过一次自增或自减，就要拆开重写。理由很简单：无论你多熟悉优先级和求值顺序，每多看一眼这种表达式，代码的阅读成本就会翻倍。代码评审的时候，一个 a = b++ + c-- 就能让 reviewer 停下来算半天，这纯粹是自己给自己添堵。

团队里如果有想写这种"秀操作"代码的同事，我的建议是温和地拦住他：能用三行写清楚的逻辑，不要用一行去表达。可读性 > 炫技，这条适用于任何代码。

8.2 for 循环更新表达式的统一约定

对于 for 循环更新部分，团队可以约定统一使用 i++。不是说 ++i 有错，而是统一风格可以避免无意义的争论。但有一个例外：如果你的 for 循环体内部要用到"先自增再判断"的逻辑，那就只能使用前缀形式。比如：

java复制int i = 0;
while (++i < 10) {
    // 先自增再比较
}

这个循环体会执行几次？答案是 9 次，i 从 1 递增到 9，每次都 < 10，直到 i = 10 时条件为 false 退出循环。如果你写成 i++ < 10，那循环体会执行 10 次，i 从 0 递增到 9。两个行为完全不同。这种细微差别在实际代码里非常常见，尤其是实现某些"从下一个位置开始处理"的算法时。

8.3 警惕 IDE 的自动重构

现代 IDE 比如 IntelliJ IDEA 经常会提供"简化代码"的重构建议，偶尔会把一些循环改写成用自增表达式的形式。我不反对用 IDE 提供的建议，但每次接受重构前，我都建议你先确认一下语义是否等价。特别是涉及 i++ 和 ++i 的转换，IDE 有时会默认改成它认为"更简洁"的形式，但很可能改变边界行为。

我记得有一次，IDE 建议我把一个 while 循环改写成 for 循环，其中 i++ 被改写进了 for 循环的更新表达式里。表面上等价，但因为原来的 while 循环里 i++ 是在循环体末尾执行的，改写后 for 循环的更新表达式每轮结束后才执行，两者执行时机略有差别，最终导致数组越界。这种坑完全躲过了编译器的检查，只有运行时才会暴露，排起来极其耗时。

8.4 善用工具和测试

如果你在团队里推行自增自减代码规范，可以考虑配置 CheckStyle 或 SpotBugs，在 CI 阶段就拦截掉复杂表达式中的多次自增。比如 CheckStyle 有一个 AvoidInlineConditionals 风格检查，虽然它主要管三元表达式，但你同样可以自定义规则扫描"同一表达式中出现两次以上自增"的代码。

另外，任何涉及边界条件的自增自减代码，都应该配上单元测试。写几组针对 0、最大值、最小值、负数的用例，能轻易抓出 off-by-one 错误。我在做数组和链表算法题时，会习惯性写一个"哨兵值"测试用例，比如空数组、单元素数组、满容量数组，这几乎成了我的固定动作。

9. 面试官视角：自增自减到底想考你什么

很多备面经的读者可能会背一堆"最新网络热词"里的面试八股，但我想换个角度——站在面试官立场，说说为什么他们那么爱考 i++ 和 ++i。据我观察，一道自增自减题至少能考察出三方面：

第一，你对执行模型的理解深度。i = i++ 的输出不是靠记忆力能答对的，它考察你是否知道 JVM 字节码层面的局部变量表和操作数栈。如果你能讲出 iload、iinc、istore 的顺序，面试官基本能确认你有阅读字节码的能力，这是很多自称"资深"的候选人达不到的。

第二，你对语言规范的尊重程度。Java 相比 C/C++，优势之一就是定义了严格的求值顺序。如果你能说出"Java 规定从左到右求值"这一点，说明你系统学习过 JLS，而不是只刷了几百道面经题。

第三，你的代码安全意识。面对"为什么 i++ 在多线程下不安全"这类问题，答得好的候选人通常会主动提到指令重排序、内存可见性、CAS 等概念，说明他不仅会写 Java，还理解 JMM（Java 内存模型）。

所以，如果你想准备面试，不要只背 i++ 和 ++i 的结果，把背后的原理串起来讲，会让你的回答一下子跟其他人拉开差距。比如你可以主动说："i++ 的字节码包含 iload、iinc、istore 三条指令，因此它不具备原子性，多线程下需要配合锁或使用 AtomicInteger。"这句话一出，面试官至少会给你加一分。

10. 写在最后的经验之谈：自增自减本质上是"修改变量"而非"计算值"

我一直觉得，自增自减之所以让这么多人栽跟头，是因为大多数人对它的理解停留在"这是 i = i + 1 的简写"。这句话没有全错，但漏掉了最关键的一点：自增自减更像是"给变量下达的修改命令"，而不是"返回一个计算后的值"。

当你写 i++ 时，你同时在做两件事：

• 让 i 这个变量自增 1（副作用）
• 返回 i 自增之前的值（表达式结果）

当你写 ++i 时，同样做两件事：

• 让 i 这个变量自增 1（副作用）
• 返回 i 自增之后的值（表达式结果）

副作用是一样的，区别只在于表达式返回值。如果你把自增自减理解成"带副作用且返回值有讲究的表达式"，那么 i = i++ 的结果为 1 就变得非常自然了：副作用确实发生了（i 变成 2），但表达式的返回值是旧值（1），赋值操作又把旧值写回去了。这不是 bug，这是规则。

在我带过的开发者中，凡是能把这一点吃透的，后面学复合赋值运算符、理解多线程安全问题、甚至阅读字节码，都会顺畅得多。

最后分享一个我自己的复盘习惯：每次在代码里遇到自增自减相关的 bug，我都会把这段代码反编译成字节码看一眼。这个习惯帮我建立起了"Java 代码 -> 字节码 -> JVM 执行"的完整心智模型，也让我的排错速度快了不少。如果你也想真正吃透 Java，不要满足于会写 for 循环，花一个下午的时间把 javap 工具玩熟，你会打开新世界的大门。