i++这行代码，几乎每个写 Java 的人都敲过成千上万遍，但真被问一句“它到底在 JVM 里走了几步”，能当场说清楚的人并不多。更微妙的是，很多人背过“JVM 栈帧包含局部变量表、操作数栈、动态链接、方法返回地址”，背得滚瓜烂熟，可一旦把i++和栈帧放在一起问——“这一条自增指令改的是谁的内存”“i = i++为什么结果是 0”——脑子里的结构图就散了。这篇东西就是想把这两件事焊在一起：用i++这个最小的标本，把 JVM 栈帧的结构、字节码的读写节奏、以及编译器在背后做的那些小动作，一层层剥开。

内容会从一行源码讲到javap的输出，从局部变量表的槽位编号讲到操作数栈的压栈出栈，再到方法调用时栈帧怎么创建、怎么销毁、StackOverflowError跟帧大小有什么关系。适合两类人看：一类是刚学完 Java 语法、准备啃 JVM 但被一堆名词劝退的；另一类是工作几年、平时写业务没问题，但面试或者排障时被字节码问住的。文中所有字节码都是我本地用javap实打实跑出来的，参数计算过程也写在里面，你可以对着自己的环境复现一遍——这类知识光看是记不住的，得手推一次。

1. 一个i++牵出的整条链路：整体思路拆解

1.1 为什么我拿i++当学栈帧的切口

讲栈帧最容易犯的毛病，是一上来就画一个方框，里面套四个小方框，标上“局部变量表”“操作数栈”“动态链接”“返回地址”，然后开始念定义。这种讲法的问题是：结构图是静态的，而栈帧是活的。你得看到数据在里面怎么流动，才能真正记住哪个格子装什么。

i++恰好是最好的流动样本。它足够小——小到能在一屏字节码里看完全过程；它又足够典型——同时踩中了局部变量表（变量i住在哪）、操作数栈（中间值临时放哪）、字节码指令（谁负责搬、谁负责算）三个关键点。更妙的是，它有个著名的反直觉结论：i = i++执行完i不变。这个结论如果你不理解栈帧的读写分离机制，就只能死记；理解了之后，它是必然的。

我自己的经验是，先把i++这一条链路彻底推演透，后面再去看try-catch的异常表、synchronized的 monitor 记录、方法内联后的栈帧消除，会发现它们是同一套底层逻辑的不同应用。所以我一直建议：学 JVM 执行引擎，别从“运行时数据区”那张大图开始，从一行自增开始。

1.2 从源码到栈帧：链路上每一环在干什么

一行i++走到真正执行，中间隔着好几道工序，搞清楚每一道负责什么，后面看字节码才不会被“凭空冒出来的指令”搞懵。

第一道是javac 编译。它负责把 Java 源码翻译成 class 文件里的字节码，同时算好两个关键数字：max_locals（这个方法最多需要多少个局部变量槽位）和max_stack（操作数栈最深会到几层）。这两个数字写在方法的Code属性里，是编译期就定死的，运行时不再变。这一步的意义在于：JVM 拿到的不是一个“随便长”的方法，而是一个尺寸已知的盒子。

第二道是类加载。class 文件被读进方法区（JDK 8 之后是元空间），字节码被验证、准备、解析。这一步跟i++关系不大，但它决定了后面常量池里的引用能不能解析成功。

第三道是执行引擎。解释器逐条读字节码，遇到方法调用就在 Java 虚拟机栈上压一个新栈帧。栈帧里的局部变量表按max_locals分配好空间，操作数栈按max_stack划好深度。从这里开始，i++就变成了一串对栈帧内部格子的读写操作。

这个链路里有个容易被忽略的点：栈帧是方法级的，不是变量级的。i++不会自己造一个帧，它只是在main方法那个已经存在的帧里，往第 1 号槽位写了个值、又从里面读了个值。很多人把“变量在栈上”理解成“每个变量一个小格子挂在线程上”，这个直觉是错的，纠过来之后很多问题就通了。

1.3 栈帧里四个部件在i++中的分工

一个栈帧标准结构是四块加一块附加信息，我按i++的场景把它们的职责翻译成人话。

局部变量表是“仓库”。方法的所有参数、方法体内声明的局部变量，都按顺序摆在这里，从 0 号槽位往后编号。int i = 0里的i就住在某个编号的槽位里，一直住到方法结束。注意是“按槽位编号”，不是“按变量名”——变量名在运行时压根不存在，除非你编译时加了-g生成了LocalVariableTable调试信息。

操作数栈是“工作台”。JVM 不支持下一条指令直接读上一条指令的结果，所有中间值必须经过这个栈中转。想给i加 1，得先把值搬到工作台上，算完再搬回仓库。i++之所以能一条iinc搞定，是因为 JVM 专门给了它一个“就地加工”的特权。

动态链接是“回程地址簿”。栈帧里存着一个指向运行时常量池中该方法的引用，方法里用到别的类、别的字段时，靠它找到真实地址。i++本身用不上，但一旦涉及System.out这种跨类调用，就得靠它。

方法返回地址是“从哪儿来回哪儿去”。main方法里调用add(1,2)，add的帧跑完得知道把返回值交给谁、下一条指令从哪个偏移继续。这个地址在调用发生时就被记在新帧里。

理解了这四个角色的分工，i++的字节码就不再是天书：本质上就是“从仓库搬到工作台（或者干脆在仓库里就地改）→ 算 → 搬回去”的组合动作。

2. 核心细节解析：iinc、iload、istore到底在动谁的奶酪

2.1 局部变量表：从slot 0开始数格子

局部变量表是一个以**槽位（slot）**为单位的数组，编号从 0 开始。这里有几个坑，我一个个说。

第一个坑：实例方法的 0 号槽位是this，静态方法不是。这解释了为什么同一个方法，加个static关键字，字节码里的槽位编号全往前挪一位。你写public void foo(int a)，a在 1 号槽；改成public static void foo(int a)，a就跑到了 0 号槽。看字节码时如果没注意这一点，很容易把iload_1误读成“加载了某个局部变量”，其实是加载了this的引用（当然int方法里不会这么干，但看别的代码时会遇到）。

第二个坑：long和double占两个槽位。这是历史遗留设计，为了让 32 位虚拟机也能处理 64 位数据。所以一个方法里声明long a; int b;，a占 0、1 两个槽，b从 2 号开始，而不是 1 号。这直接影响max_locals的计算，也影响你数槽位时的判断。写代码时看不出来，看字节码时如果按“一个变量一个槽”去数，必然错位。

第三个坑：槽位会复用。两个作用域不重叠的局部变量，可以共用同一个槽位。比如{int a = 1;}后面再{int b = 2;}，a和b很可能都在 1 号槽。这是编译器省空间的手段，max_locals因此比“声明的变量总数”要小。看字节码时如果发现两个变量的读写都指向同一个槽位，不要慌，这是正常的。

第四个坑：变量名不保留。运行时只有槽位编号，没有名字。所以线上排查时你拿到一个栈帧，只能看到slot 1，看不到i。想要名字，编译时加-g，把LocalVariableTable打进 class 文件，调试器和javap -l才能把编号还原成名字。

注意：很多人以为“局部变量表里存的是变量的引用”，这个说法对对象类型勉强成立，对int这种基本类型完全不对——槽位里存的就是值本身，32 位一个槽，没有额外包装。理解这一点，i++的“就地修改”才说得通。

2.2 操作数栈：一张后进先出的草稿纸

操作数栈的最大特点是后进先出，而且深度在编译期就确定了。max_stack这个数字不是估算的，是 javac 精确算出来的最大值。为什么会这样？因为 JVM 需要在方法进入时就一次性把栈空间划好，不能中途扩容——那样太慢，也不好做内存布局。

这个栈里的“一格”也是 32 位。int、float、引用占一格，long、double占两格。所以你看到ladd这种指令时，它一次弹出四个格子的内容（两个 long）再压回去两个格子（一个 long 占两格）。

操作数栈在i++里出现的频率取决于写法。纯i++语句（自增结果不使用），javac 会走iinc这条路，根本不碰操作数栈。这就是为什么iinc是个特殊指令——它是唯一一个能直接对局部变量表做算术的指令，不需要把值搬到栈上再搬回来。

但只要自增的结果被使用了，比如int j = i++，就绕不开操作数栈了：得先把i的旧值压栈留着（因为j要的是旧值），再改局部变量表，最后把栈上那个旧值取出来赋给j。这个“压栈留旧值”的动作，就是i = i++结果为 0 的根源。

iinc本身还有个体积上的限制：它的操作数是两个字节，一个给槽位编号（0~255），一个给增量（-128~127）。所以局部变量超过 255 个，或者自增的常量超出这个范围，javac 就没法用iinc了，只能退回iload+ 常量 +iadd+istore的笨办法。这个细节平时遇不到，但在看一些自动生成的超大方法时会撞上，知道有这么回事就行。

2.3 i++和++i的字节码差异对照

这块一定要看字节码，光靠文字描述记不住。我准备了一段代码，把三种写法放在一起：

public class IncDemo { public static void main(String[] args) { int i = 0; i++; // 自增结果不使用 int j = i++; // 后置：先用后加 int k = ++i; // 前置：先加后用 System.out.println(i + "," + j + "," + k); } }

javac -g IncDemo.java之后javap -c IncDemo，核心片段是这样的（省略了System.out那部分的invokedynamic/getstatic细节）：

0: iconst_0 1: istore_1 // i = 0 2: iinc 1, 1 // i++ 直接改槽位1 5: iload_1 // 压入 i 的当前值 1 6: iinc 1, 1 // i 变成 2 9: istore_2 // j = 1（栈上那个旧值） 10: iinc 1, 1 // i 变成 3 13: iload_1 // 压入 3 14: istore_3 // k = 3

把三条写法的区别摊开看：

规律很清楚：后置自增是“先读后改”，前置自增是“先改后读”。落到字节码上，就是iload和iinc这两条指令的先后顺序不同。记住这一点，比背“++在前先加”这种口诀靠谱得多，因为口诀解释不了i = i++为什么是 0。

还有一个细节值得注意：iinc的偏移量是 2 字节，所以从 2 跳到 5，从 6 跳到 9。看javap输出时侯如果发现偏移量不是连续递增 1，别以为漏了什么，是这条指令占两个字节。

2.4 为什么 i = i++ 之后 i 还是 0

这是最经典的坑，也是检验有没有真理解栈帧的试金石。代码：

public class SelfAdd { public static void main(String[] args) { int i = 0; i = i++; System.out.println(i); // 输出 0 } }

字节码：

0: iconst_0 1: istore_1 // i = 0，槽位1 2: iload_1 // 把 i 的当前值 0 压到操作数栈顶 3: iinc 1, 1 // 局部变量表里 i 变成 1 6: istore_1 // 把栈顶的 0 写回槽位1

分步骤推一遍，节奏就出来了：

1. iload_1：把槽位 1 的值（0）复制一份，压到操作数栈顶。此刻栈上有个 0，槽位里也还是 0。
2. iinc 1,1：直接给槽位 1 加 1。此刻槽位里是 1，但栈上那个 0 没动。
3. istore_1：把栈顶的值弹出，写入槽位 1。此刻槽位被覆盖回 0。

看到了吗？自增确实执行了，槽位确实短暂变成了 1，但紧接着被istore用那个陈旧的 0 覆盖掉了。整个过程的要害在于：操作数栈上的旧值是一个副本，它不知道槽位后来变了。

把这个机制和int j = i++对照，你会发现它们其实是同一串指令，只是最后istore的目标不同——istore_2就是“赋给 j”，istore_1就是“赋回 i”。赋值回自己的时候，就出现了“自增白干”的效果。所以这根本不是什么诡异行为，而是赋值语句的右值在自增前就被求值并保存了这一语义的直接体现。

提示：i = ++i的结果是 1。你可以自己推一遍——iinc在前，iload在后，栈上拿到的是新值。两条写法的差别就在于指令顺序，这个练习建议动手做一次。

3. 实操过程：从javap到逐帧推演

3.1 环境和命令准备

工具链很简单，JDK 自带就够，不需要额外装什么。我常用的三步：

# 1. 编译时带上调试信息，保留局部变量名和行号 javac -g -d out src/IncDemo.java # 2. 看字节码指令（-c） javap -c -p out/IncDemo.class # 3. 看完整信息：常量池、max_stack、max_locals、异常表 javap -v -p out/IncDemo.class

-g这个参数值得单独说。不加它，字节码里就没有LocalVariableTable，javap -l输出是空的，你只能看到slot 1、slot 2这种抽象编号；加上它，才能把编号和源码里的变量名对应起来。学习阶段强烈建议一直加-g，排查线上问题时如果 class 文件没带这个信息，就只能用编号反推，会累一些。

-v和-c的区别也要清楚：-c只给指令列表，-v会额外输出常量池、方法签名、Code属性里的stack、locals、args_size三个数字。后面算栈深度，全靠这三个数字，所以分析问题时我基本只用-v。

顺带提一句，IDE 里也有快捷方式，IntelliJ IDEA 的View → Show Bytecode能直接看，还有第三方插件可以做字节码的可视化编辑。但我建议学习阶段坚持用命令行javap，因为命令行输出的是最原始的样子，没有 IDE 帮你做任何美化，你能看到偏移量、能看到指令的原始助记符，这些细节在建立直觉时很重要。

3.2 逐条指令对照：一次完整的栈帧内外搬运

拿一个稍微复杂一点的例子，把“局部变量表 + 操作数栈”的配合完整走一遍：

public class AddDemo { public int add(int a, int b) { int c = a + b; return c * 2; } }

javap -v里这个方法的Code属性头是：stack=2, locals=4, args_size=3。先解读这三个数字：

• args_size=3：三个“参数槽位”，包括隐藏的this（实例方法），加上a、b。
• locals=4：局部变量表总共 4 个槽位。this(0)、a(1)、b(2)、c(3)。注意long/double才占两格，这里全是int，所以 4 个变量正好 4 个槽。
• stack=2：操作数栈最深 2 层。为什么是 2？因为a + b需要同时把两个操作数压栈，这是最深的一刻。

指令序列：

0: iload_1 // 压入 a，栈深 1 1: iload_2 // 压入 b，栈深 2 ← max_stack 就是这一刻 2: iadd // 弹出两个，相加，压回结果，栈深 1 3: istore_3 // 弹出结果写入 c，栈深 0 4: iload_3 // 压入 c，栈深 1 5: iconst_2 // 压入常量 2，栈深 2 6: imul // 弹出两个，相乘，压回结果，栈深 1 7: ireturn // 弹出栈顶作为返回值，帧销毁

把每一步的“栈深”标出来，max_stack=2是怎么来的就一目了然了——它是整个执行过程中栈深的峰值，不是最后的值。这也是 javac 计算max_stack的方法：模拟一遍执行，记录峰值。

我习惯在纸上画两条竖线，左边一列写槽位编号 0~3，右边画一个向上生长的栈，每执行一条指令就动一下笔。这个方法笨，但比我见过的任何动画演示都管用，因为手上动过一遍的东西，脑子里才留得住。推两三个方法之后，你看到iload就知道要往上加一格，看到istore就知道要往下减一格，形成肌肉记忆。

3.3 方法调用时栈帧的创建与销毁

上面都是在同一个帧里折腾，现在看帧和帧之间的交接。改一下代码：

public class FrameDemo { static int add(int a, int b) { int c = a + b; return c; } public static void main(String[] args) { int r = add(1, 2); System.out.println(r); } }

main方法（静态，所以没有this，args在 0 号槽）：

0: iconst_1 // 压入 1 1: iconst_2 // 压入 2 2: invokestatic #2 // 调用 add:(II)I 5: istore_1 // 把返回值存入 r

add方法（静态，a在 0 号槽，b在 1 号，c在 2 号）：

0: iload_0 1: iload_1 2: iadd 3: istore_2 4: iload_2 5: ireturn

invokestatic这一条指令干了四件事，值得拆开说：

1. 参数传递：从当前帧（main）的操作数栈顶弹出n个参数（这里是 2 个：1 和 2），注意是按顺序弹出再按顺序放进新帧的低位槽位。所以栈上压的是1, 2，弹出来后a=1在 0 号槽、b=2在 1 号槽。
2. 创建新帧：在 Java 虚拟机栈上压入add的栈帧，按它自己的max_locals=3、max_stack=2分配空间。
3. 转移控制：程序计数器跳到add的第一条指令偏移 0。
4. 记录返回点：把main里invokestatic的下一条指令偏移（5）记在新帧的返回地址里。

add执行到ireturn，动作是反过来的：弹出返回值 → 弹出当前帧 → 恢复到main的帧 → 把返回值压到main的操作数栈顶 → PC 跳到偏移 5。然后istore_1把它存进r。

整个过程里有个关键点：每个方法的栈帧是独立的，参数值是从调用者的操作数栈“复制”过去的，不是共享的。add里怎么改a、b，都不会影响main里那个1和2——因为它们本来就是字面量，压根不是变量。这也顺便解释了 Java 的“值传递”：基本类型传的是值的副本，对象类型传的是引用的副本，两句话说的是同一件事——传的都是栈上那个 32 位格子里装的东西。

3.4 手算一个栈深度，验证javap的数字

光看javap给的stack=2不解渴，我更喜欢自己先算一遍再对答案，这样能验证理解是不是到位。拿一个稍复杂的表达式举例：

public static int calc(int x, int y, int z) { return (x + y) * (z - 1) + 5; }

手算的思路是“括号优先、从左到右”，模拟 javac 的求值顺序：

1. 压x（深 1）
2. 压y（深 2）
3. iadd（深 1）—— 第一个括号结果
4. 压z（深 2）
5. 压1（深 3）
6. isub（深 2）—— 第二个括号结果
7. imul（深 1）—— 两个括号相乘
8. 压5（深 2）
9. iadd（深 1）
10. ireturn

峰值出现在第 5 步和第 8 步，都是 3。所以max_stack应该是 3。实际跑javap -v，stack=3，对上了。

这个方法我强烈推荐你多用几次，尤其是遇到a.b().c().d()这种链式调用、或者复杂的条件表达式时。手算一遍，再对javap的答案，错在哪里立刻就暴露了——通常错在“以为某个操作数是共享的”或者“忘了长整型占两格”。这种错误在纸面上犯一次，比在线上犯一次划算太多。

关于max_locals的手算，规则是：实例方法 +1（this），long/double各 +2，其余 +1，再加上参数。比如public long f(int a, double b)，this(1) +a(1) +b(2) = 4 个槽位，加一个局部变量long c就是 6。这个数字不参与逻辑，但它决定了方法进入时要划多大一块内存，跟后面的栈溢出分析直接相关。

4. 常见问题与排查技巧实录

4.1 反编译结果和源码对不上，先查这几件事

第一次认真看字节码的人，十个里有八个会问“我代码里明明没写这个指令，它哪来的”。这不是你看错了，是编译器在你没注意的地方动了手脚。常见的几类：

常量折叠。int x = 2 * 3 * 4;你在源码里写了三个乘号，字节码里只有bipush 24。javac 在编译期就算完了，运行时一次乘法都不做。final static int A = 5;被引用时也会直接内联成字面量，这也是为什么改了常量所在类之后，引用方也得重新编译——不然用的还是旧值。

字符串拼接。JDK 8 里"a" + b会编译成StringBuilder的append链；JDK 9 之后改成了invokedynamic加makeConcatWithConstants。所以你在不同 JDK 上javap同一个文件，看到的指令完全不一样，这不是你操作错了，是编译策略变了。看清楚自己用的 JDK 版本，别拿网上的示例硬套。

泛型擦除带来的checkcast。你写List<String> list，list.get(0)后面会多出一条checkcast java/lang/String，因为运行时 List 里存的其实是 Object。这条多余的检查是擦除机制的代价，看字节码时会频繁见到。

三目运算符的类型提升。int a = flag ? 1 : 2L;这种写法，两个分支类型不一致，编译器会做类型提升，字节码里可能出现i2l、l2i这类转换指令。这类细节平时不影响业务，但看字节码时会觉得“怎么多了一步”。

自动装箱。Integer i = 1;编译成Integer.valueOf(1)，是方法调用，不是赋值。这在循环里尤其要命——每一轮都创建一个对象，max_stack也会跟着变。用基本类型还是包装类型，字节码上一眼就能看出区别。

心得：遇到“对不上”的情况，先别怀疑工具，先怀疑自己是不是漏了编译期优化。我的习惯是把javap -v的完整输出和源码并排放，逐条指令找对应的源码行（-g编译的会有LineNumberTable，能直接对上行号），对不上的那一条，八成就是上面某类优化。

4.2 循环里的i++，编译器到底做了什么

for (int i = 0; i < n; i++)这个写法太常见了，但它的字节码结构跟你想的可能不太一样。核心骨架是这样的：

0: iconst_0 1: istore_1 // i = 0 2: iload_1 3: iload_2 // n 4: if_icmpge XX // i >= n 就跳出 7: ...循环体... XX: iinc 1, 1 // i++ XX: goto 2

关键点：循环体执行完之后才iinc，然后goto回去重新判断条件。这是“先判断后执行”结构，跟while编译出来的东西基本一致。所以你在源码里写for还是while，字节码层面差别不大，别指望换个写法能提升性能。

真正影响性能的是另一件事：循环条件里的表达式会不会每轮重算。经典例子是for (int i = 0; i < list.size(); i++)，list.size()每轮都调一次。这里有两层机制在起作用：一是 JIT 的方法内联，size()通常只有一行return size;，会被内联成读字段；二是循环不变量提升，如果 JIT 能证明size在循环里不变，会把它提到循环外面只读一次。

但“能证明”是有条件的。如果循环体里调用了可能修改list的方法，JIT 就不敢提升，只能老老实实每轮读。所以养成for (int i = 0, len = list.size(); i < len; i++)的习惯，在热路径上仍然是有意义的——不是因为它一定更快，而是因为它把“优化”这件事从“指望 JIT”变成了“编译期就确定”。

至于i++本身在循环里，几乎不会有性能问题。iinc是一条指令，改成++i也还是iinc，字节码完全一样。网上那些“++i比i++快”的说法，针对的是 C++ 里的运算符重载（对象自增会构造临时对象），在 Java 里对基本类型完全不成立。对包装类型也基本不成立，因为Integer是不可变的，i++和++i都得拆箱、加、装箱，成本一样。

4.3 多线程下i++的坑，和栈帧的关系

面试常问“i++是原子操作吗”，标准答案是“不是”，但我想把原因讲透一点，因为它跟栈帧的层级有关。

如果是方法内的局部变量，i++编译成单条iinc，而iinc是对当前线程栈帧里的局部变量表操作。局部变量表是线程私有的，别的线程根本访问不到，所以这种情况下不存在线程安全问题——它本来就是原子的，因为压根没有共享。

问题出在共享变量上，比如类的静态字段或实例字段。这时候i++编译出来是另一副样子：

getstatic i // 读静态字段，压栈 iconst_1 iadd putstatic i // 写回

三条指令，三步操作：读、加、写。这中间任何一步都可能被打断。线程 A 读到 0，还没写回；线程 B 也读到 0，也加 1 写回 1；然后 A 把 1 写回。两次自增，结果只加了 1。这就是丢失更新。

更隐蔽的是可见性问题。就算没有交错，A 线程改了字段，B 线程看到的可能还是旧值，因为工作内存和主内存之间没有强制同步。volatile能解决可见性，但解决不了原子性——volatile int i; i++;依然是有问题的。正确的做法是用AtomicInteger的incrementAndGet()（底层是 CAS 循环），或者干脆加锁。

注意：synchronized块在字节码层面是monitorenter/monitorexit，同时会在当前栈帧里分配一个锁记录（Lock Record）空间。这个空间也是栈帧的一部分，会影响帧的大小。所以一个方法里锁用得越多，帧可能越大，这跟后面讲的栈溢出是有联系的。

4.4 常见问题速查表

把上面几类问题整理成表，遇到时直接对号入座：

5. 把栈帧知识用到真实排障上

5.1 StackOverflowError跟栈帧大小的关系

StackOverflowError这个异常名字起得很直白，但很多人只知道“递归太深会爆”，不知道“深”具体是什么决定的。答案就在栈帧上。

Java 虚拟机栈是线程私有的，每个线程有自己的栈空间，大小由-Xss指定。每次方法调用压一个帧，帧的大小 ≈max_locals × 槽宽 + max_stack × 槽宽 + 固定开销。固定开销包括返回地址、指向方法元数据的指针、可能的锁记录等，量级在几十字节，具体随平台和版本变化，我这里给不了精确值，但量级是清楚的。

于是一个很朴素的除法就出来了：能容纳的调用深度 ≈ 线程栈大小 / 平均帧大小。假设-Xss1m（1MB），平均帧 200 字节，那大概能压 5000 层左右。实际会少一些，因为还有别的开销，而且 JIT 编译后的帧布局跟解释执行时可能不同。

这个除法解释了两个常见现象。一是同样的递归代码，换个方法签名就爆栈了——比如把参数从 2 个int变成 5 个long，帧一下子大了一截，深度上限就掉下来了。二是同一个程序，调大-Xss之后不爆了——不是因为代码变好了，是分母变大了。

反过来说，如果你在排查一个StackOverflowError，第一步不是加-Xss，而是看栈轨迹里有没有意外的重复。真正健康的递归，栈深度是可控的；如果轨迹里出现了成千上万个重复的帧，而你的代码里并没有对应的递归逻辑，那就得怀疑是不是有隐藏的循环调用——比如两个对象的toString()互相引用，或者equals/hashCode实现里互相调用。这类问题加多少-Xss都没用，只会把崩溃点往后推。

5.2 -Xss怎么调，调之前先算什么

调-Xss这件事，我见过两种极端：一种是不敢动，遇到栈溢出就改代码；另一种是随手加个-Xss10m，结果线程一多内存爆了。两种都不对，正确的做法是先算再调。

先看默认值。不同平台、不同 JDK 版本的默认线程栈大小不一样，别靠记忆。查的办法很直接：

java -XX:+PrintFlagsFinal -version | grep ThreadStackSize

输出的值单位是 KB，主流 x64 平台上一般是 1024 上下。以实际输出为准，网上抄来的数字不可靠。

再算内存账。线程栈占的是虚拟内存，不是物理内存，但也不能无限开。粗算公式是：线程数 × 栈大小。1000 个线程 × 1MB = 1GB 虚拟地址空间，在 64 位上通常还好，但如果栈开到 10MB，同样 1000 个线程就是 10GB，很快就会撞上系统限制，表现为OutOfMemoryError: unable to create new native thread。

所以调-Xss的本质是在“单线程能递归多深”和“总共能开多少线程”之间做交换。我的经验法则是：

• 业务代码基本用不上深递归，栈溢出多半是 bug，优先改代码，别调参数。
• 确实需要深递归（比如某些解析器、树遍历），先估算最大深度，乘以单帧大小，再留一倍余量。
• 线程数多的服务，宁可栈小一点，把内存留给堆。

还有一个容易被忽略的点：减小帧本身比调大栈更有效。把一个大方法拆成几个小方法，每个方法的max_locals和max_stack都会变小；把递归改成迭代，用显式栈（ArrayDeque）代替调用栈，深度限制直接消失，还能避免爆栈。这类改法收益比调参数高得多，只是改起来麻烦，所以经常被跳过——但从长期看，改代码是唯一不会在下次流量翻倍时又崩的办法。

5.3 我踩过的几个认知坑

最后分享几个我自己理解错过的点，都是那种“看资料觉得懂了、动手才发现错了”的类型。

第一个坑：以为栈帧在方法调用结束后立刻被 GC 相关机制处理。其实栈帧的销毁跟垃圾回收完全没关系，方法返回时帧直接就弹出了，里面的局部变量引用随之消失（如果这是最后一个引用，对象才变得可回收）。栈帧不参与堆内存管理，这一点搞混了，看 GC 日志时会一直找不着北。

第二个坑：以为操作数栈里的东西能跨指令保存。实际上除了dup系列指令，绝大多数指令都会把操作数消耗掉。我一开始总想着“把结果留在栈上给下一条用”，结果发现每条指令的语义都是自洽的，栈只是一个极短暂的缓冲区。理解了这一点，才能明白为什么 javac 要费劲算max_stack——它真的很小。

第三个坑：以为javap输出就是运行时执行的指令。不是。解释器执行的是字节码，但方法热起来之后，JIT 会把它编译成本地机器码，那时候的指令跟字节码完全是两回事，栈帧的布局也可能不一样（比如做了标量替换之后，某些对象压根不在堆上，也不在栈帧里）。所以看javap只是看“可能的执行路径”，不是“确定的执行路径”。想确认 JIT 干了什么，得加-XX:+PrintCompilation看编译日志，或者用-XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly看汇编输出——后者门槛高一些，但看到内联之后i++变成一条本地inc指令时，那种“原来如此”的感觉挺值的。

字节码看得多了会有个副作用：写业务代码时会不自觉地在脑子里翻译一遍，然后对一些“看起来没必要的写法”产生怀疑。我的态度是，分析问题时看字节码，写业务时别看。业务代码的可读性永远优先，把i++换成++i这种微优化，省下来的那点时间还不够评审时解释的。真要优化，去看火焰图，去看数据库慢查询，比盯着字节码强得多。