能，但仅在jit编译后的热点代码中生效，且需逃逸分析判定为“不逃逸”；解释执行阶段不支持，对象必须满足不逃逸、字段可分解等条件才能标量替换。
Java 的 -XX:+DoEscapeAnalysis 真的能让对象栈上分配吗？
能，但只在 JIT 编译后的热点代码中生效，且必须满足逃逸分析判定为“不逃逸”。JVM 不会在解释执行阶段做栈上分配，也不会对所有对象一视同仁。
常见错误现象：new Object() 看似简单，但如果它被传入了 System.out.println()、作为返回值、或赋给了 static 字段，就会被判定为“逃逸”，直接进堆。
- 标量替换的前提是：对象字段可分解（即全是基本类型或未逃逸的引用），且整个对象不逃逸
- 开启逃逸分析需同时启用：
-XX:+DoEscapeAnalysis -XX:+EliminateAllocations（后者控制是否执行标量替换） - JDK 8 默认开启，JDK 9+ 仍默认开启，但某些 GC（如 ZGC）可能禁用部分优化，需实测验证
- 别依赖
-Xmx变小来判断栈上分配成功——堆内存变化受太多因素干扰，应结合-XX:+PrintEscapeAnalysis或 JFR 事件确认
怎么确认某个对象真的被标量替换了？
不能靠肉眼猜，得看 JVM 输出或字节码行为。标量替换后，原对象不再存在，字段变成独立局部变量，甚至可能被进一步优化掉。
使用场景：高频创建短生命周期 DTO（如 Point、Pair），且仅在方法内计算、不暴露引用。
- 加参数
-XX:+PrintEscapeAnalysis，运行时会打印类似escaped to unknown或not escaped的判定结果 - 更可靠的方式是用 JFR 启动录制：
-XX:+FlightRecorder -XX:StartFlightRecording=duration=60s,filename=rec.jfr，然后在 JDK Mission Control 中查看 “Allocation in new TLAB” 事件是否消失 - 注意：即使判定为
not escaped，若方法未被 JIT 编译（比如只跑一次），也不会触发标量替换
final 字段和构造器里赋值，会影响逃逸分析吗？
不影响判定本身，但会影响标量替换能否发生。逃逸分析看的是引用是否“传出当前方法作用域”，不是看字段是否可变。
关键点在于：只要对象没被 return、没存入堆结构、没传给 native 方法，哪怕字段是 public 或非 final，只要没实际逃逸，就仍可能被优化。
- 构造器里
this.field = x是安全的，只要x本身也不逃逸 - 但若构造器里调用了
register(this)这类方法，哪怕this是局部变量，也会立刻被判逃逸 -
final字段有助于 JIT 做常量传播，间接提升标量替换后进一步优化（如死代码消除）的概率，但不是必要条件
为什么本地测试总看不到栈上分配效果？
最常见原因是代码没被 JIT 编译，或者逃逸路径太隐蔽。JVM 对逃逸分析非常保守，宁可多分配，也不愿错优化。
性能影响很实在：标量替换后，不仅省去堆分配开销，还避免了 GC 扫描和内存带宽压力；但若误判逃逸，会导致严重 bug（所以 JVM 宁肯不优化）。
- 确保循环执行足够多次（通常 >10000 次），触发 C2 编译；可用
-XX:+PrintCompilation观察 - 避免日志、断点、JMX 监控等干扰——它们可能引入隐式逃逸（如把对象传给
toString()） - 不要在 Lambda 或匿名内部类里创建待优化对象，捕获引用大概率导致逃逸
- 同一方法中混用逃逸/不逃逸逻辑（比如条件分支中一个分支 return 对象），整个对象会被视为逃逸
真正难的不是打开开关，而是让 JVM 相信你写的代码“确实不需要堆”。它不信你，你就得把所有可能的出口都堵死。
