HotSpot JVM未实现栈上分配，所谓“栈分配”实为标量替换；验证需用-XX:+PrintEscapeAnalysis观察逃逸分析日志，并结合-XX:+PrintOptoAssembly确认字段是否拆入寄存器。
怎么确认循环里 new 的对象真被栈上分配了
逃逸分析本身不保证栈上分配，HotSpot JVM 目前（JDK 8–21）并未实际启用栈上分配（Stack Allocation）优化，官方文档和源码注释中明确标注为“未实现”。你看到的性能提升，大概率来自标量替换（Scalar Replacement）或 JIT 内联 + 消除冗余对象创建，而非真正把对象压进虚拟机栈。
验证方式不是看内存 dump，而是结合日志和字节码行为：
- 用
-XX:+PrintEscapeAnalysis -XX:+UnlockDiagnosticVMOptions启动，观察日志中是否出现allocates to stack—— 实际不会出现，只会看到does not escape或escapes method - 配合
-XX:+PrintOptoAssembly（需 hsdis）看最终生成的汇编，若对象字段被拆成独立寄存器操作（如%rax,%rdx），说明发生了标量替换 - 关闭逃逸分析：
-XX:-DoEscapeAnalysis，对比循环执行耗时 —— 若差异显著（比如从 120ms → 350ms），说明逃逸分析确实触发了后续优化（通常是标量替换或锁消除）
为什么 for 循环里 new StringBuffer 不会被栈分配
因为 StringBuffer 是可变对象，且其内部持有 char[] 数组引用。即使你在循环内不返回它，只要 JIT 无法 100% 证明该数组不会被其他代码观测（比如通过反射、JNI、或 JIT 认为可能发生的异常路径泄露引用），就会保守判定为「方法逃逸」。
典型误判场景：
- 调用
sb.append(...)后又调用sb.toString()：虽然返回的是新字符串，但toString()内部仍会访问sb.value，JIT 可能无法完全追踪该数组生命周期 - 循环体中存在分支或异常处理块，导致逃逸分析路径爆炸，JIT 放弃精确分析，直接标记为逃逸
- 使用了非 final 字段、非 private 方法，或涉及虚方法调用（如
sb.length()是虚调用），削弱逃逸分析可信度
怎样写才能让循环内对象大概率被标量替换
标量替换是当前 HotSpot 唯一稳定落地的逃逸分析受益项。它不要求对象整体“在栈上”，而是把对象拆成字段级变量，直接存寄存器或局部变量槽 —— 效果等价于没创建对象。
关键约束条件：
- 对象类必须是「不可变」或「事实不可变」：所有字段
final，且类型本身也满足（如int,long,String等） - 避免任何可能暴露引用的操作：不调用非内联方法、不传参给外部方法、不赋值给非局部变量、不放入集合或数组
- 推荐结构：
for (int i = 0; i < 1000; i++) { Point p = new Point(i, i * 2); // final int x, y sum += p.x + p.y; }其中Point类无方法、无继承、字段全final，JIT 很可能将其字段直接提升为循环变量
容易被忽略的性能陷阱
很多人以为开启逃逸分析就等于“自动优化”，但实际效果高度依赖运行时上下文：
- JIT 编译层级必须达到 C2（即第 4 层），而 C2 触发需要方法被频繁调用（默认 10000 次回边计数）。冷启动阶段循环哪怕跑百万次，只要没被 C2 编译，逃逸分析根本不会运行
- 使用 JMH 做基准测试时，若未加
@Fork和足够预热轮次，测出的其实是解释执行或 C1 编译结果，和生产环境脱节 - 开启
-XX:+PrintEscapeAnalysis会强制禁用 C2 编译（因诊断选项影响编译器稳定性），此时看到的“未逃逸”日志，不代表线上也会这样优化
真正起作用的，从来不是“有没有逃逸分析”，而是“JIT 是否在足够高的优化层级下，对足够稳定的代码路径做了足够激进的标量替换”。别盯着日志里的 does not escape，盯住最终生成的汇编和 GC 日志里的 Allocation Rate 才算数。
