栈上分配通过逃逸分析优化对象内存分配，避免堆分配及gc开销；标量替换进一步拆解对象为栈上局部变量，消除对象头。需满足不逃逸、final类、字段不可变等条件，且仅对jit编译的热点代码生效。
栈上分配（Escape Analysis）到底在优化什么
栈上分配不是把对象真挪到栈里，而是JVM通过逃逸分析判定：这个对象只在当前方法内创建、使用、消亡，且不会被其他线程或方法“拿到”，那它就不用走堆分配那一套——不进Eden区、不触发GC、不产生指针引用开销。本质是省掉堆内存生命周期管理的全部成本。
常见错误现象：OutOfMemoryError: Java heap space没出现，但gc.log里看到大量小对象快速晋升到老年代——说明逃逸分析失效了，对象被迫堆分配。
- 必须开启
-XX:+DoEscapeAnalysis（JDK8默认开启，JDK9+默认仍开，但部分JIT编译层级可能跳过） - 对象不能被
return、不能赋值给static字段、不能作为参数传给未知方法（比如logger.debug(obj)这种反射/泛型调用常导致逃逸） - 数组即使长度固定，只要元素被外部读取（如
arr[0]返回给调用方），整个数组就逃逸
标量替换（Scalar Replacement）和栈上分配是什么关系
标量替换是栈上分配的“升级操作”：如果JVM发现一个对象连“整体”都不需要存在，它的字段可以拆成独立变量（即标量），直接分配在栈帧的局部变量表里——连对象头都省了。比如Point p = new Point(1, 2)，若Point只有x、y两个int字段，且未逃逸，JVM可能直接生成两个int局部变量，连new Point()字节码都可能被优化掉。
使用场景：高频构造的不可变小对象（如LocalDateTime计算中间值、自定义Vec2、Range等）。
立即学习“Java免费学习笔记（深入）”；
- 对象必须是
final类，所有字段final且为基本类型或不可变引用（如String） - 禁用标量替换：加
-XX:-EliminateAllocations（调试时可关掉看性能差异） - 注意
toString()、equals()等方法会强制对象“具象化”，哪怕只是日志打印一句log.info("pos={}", p)，也可能让标量替换失效
怎么验证栈上分配和标量替换是否生效
不能只看代码“长得像能优化”，得靠JVM输出证据。最直接的是启用-XX:+PrintEscapeAnalysis和-XX:+PrintOptoAssembly（后者需hsdis支持，较重），日常用轻量级组合：
- 加
-XX:+UnlockDiagnosticVMOptions -XX:+PrintEscapeAnalysis -XX:+LogCompilation，启动时搜allocated on stack或scalar replaced - 对比GC日志：同一段逻辑，关闭逃逸分析（
-XX:-DoEscapeAnalysis）后Allocation Rate明显升高，说明原来有对象被消除 - 用
jstat -gc <pid></pid>观察EC（Eden容量）变化率——优化生效时，Eden分配速率会显著下降
注意：PrintEscapeAnalysis输出里出现not escaped只是必要条件，不代表一定栈分配；还要看是否被JIT编译器真正应用，而JIT编译需方法执行足够多次（默认10000次），所以微基准测试要预热。
为什么有时候加了@HotSpotIntrinsicCandidate也没用
这个注解只是告诉JVM“这段代码我允许你内联或特殊处理”，但它不触发逃逸分析，也不保证标量替换。真正起作用的是JIT编译器对字节码模式的识别——比如new Pair(a, b); return pair.x + pair.y;这种链式使用，比Pair p = new Pair(a,b); int x = p.x; int y = p.y; return x+y;更容易被识别为可替换。
- 避免在循环内创建对象再立即拆解：JIT可能因控制流复杂放弃分析
- 不要手动“帮JVM拆对象”，比如写
int x = p.getX(); int y = p.getY();代替p.x + p.y——字段访问本身可能触发逃逸（尤其getter有副作用时） - JDK版本影响大：JDK17的GraalVM EE默认开启更激进的逃逸分析，而OpenJDK11在某些嵌套调用场景下会保守放弃
最常被忽略的一点：这些优化只对热点代码生效。冷路径里写的再“干净”，JVM也懒得分析——所以别在单元测试里纠结new BigDecimal("1.0")有没有栈分配，它根本不会被JIT编译。
