Java对象不一定在堆上分配，HotSpot通过逃逸分析可实现栈上分配和标量替换；需满足对象不逃逸、字段全为标量、无同步块等条件，并依赖C2编译及JVM参数验证。
对象真在堆上分配吗？别信“一定”
Java对象默认在堆上分配，但JIT编译器在运行时可能完全绕过堆——只要它能证明对象“不会逃逸”。这不是理论，是HotSpot（JDK8+）默认开启的实打实优化。关键不在于你写了new，而在于JVM能不能在C2编译阶段确认这个对象只活在当前方法里、不被返回、不被存进静态字段、不传给未知方法。
怎么验证栈上分配和标量替换是否生效？
不能靠猜，得看JIT日志和字节码行为。最直接的方式是加JVM参数跑起来观察：
-
-XX:+UnlockDiagnosticVMOptions -XX:+PrintEscapeAnalysis：输出逃逸分析决策过程，比如*** object does not escape或*** object escapes method -
-XX:+PrintCompilation：确认热点方法是否被C2编译（只有C2才做逃逸分析） -
-XX:+PrintAssembly（需hsdis）：看到机器码里根本没有new指令，而是直接操作int、long等局部变量，那就是标量替换了
注意：必须用-server模式（JDK9+默认），且代码要足够热（循环调用数百次以上），否则C2压根不介入。
为什么你的POJO没被标量替换？常见踩坑点
标量替换不是“对象小就换”，它有硬性限制：
立即学习“Java免费学习笔记（深入）”；
- 字段必须全是标量类型（
int、double、boolean等），含任何引用类型（哪怕只是String字段）就直接放弃 - 不能有
synchronized块或wait/notify调用——即使锁对象本身未逃逸，JIT也会保守禁用标量替换 - 构造器或方法里显式调用了
System.identityHashCode()或Object.finalize()，对象必须有唯一身份标识，无法拆解 - JDK版本影响大：JDK17后对数组字段更激进，但JDK8对含
final字段的类有时会误判为“可能逃逸”
例如：class Point { final int x, y; }在JDK8可能不被替换，但在JDK17+大概率可以——别拿老文档当真理。
锁消除真的安全吗？别被“单线程”骗了
逃逸分析触发的锁消除（如StringBuffer的append）只在对象绝对不跨线程时才生效。但这里有个隐蔽陷阱：
- 如果方法参数是
Object类型，哪怕你传的是新new Object()，JIT也可能因“调用目标未知”而放弃分析，不敢消除锁 - 使用Lambda或匿名内部类时，若捕获了局部对象，JIT可能因闭包语义复杂而放弃逃逸判断
- 哪怕对象没逃逸，如果类被动态代理（比如Spring AOP），JIT无法穿透代理逻辑，锁也会保留
所以，不要因为写了synchronized(obj)就以为性能没问题——先确认obj是不是真没逃逸，再确认有没有其他机制干扰JIT判断。
逃逸分析不是开关一开就自动变快，它是JIT在一堆约束条件下的动态博弈。真正起效的时刻，往往藏在你反复压测、打开日志、比对字节码之后。那些没被优化掉的对象，未必是代码写错了，更可能是JIT觉得“风险大于收益”。
