标量替换是让对象“消失”的关键动作，它不移动对象而是直接拆解为int、long等标量局部变量；前提为对象未逃逸、可分解且JVM启用相关优化。
逃逸分析本身不改变对象分配位置，标量替换才是让“对象消失”的关键动作。它不是把对象从堆搬到栈，而是直接不生成对象——把字段拆成局部变量，用 int、long、Object 引用等标量替代整个对象实例。
标量替换发生的前提条件很严格
必须同时满足以下三点，JIT 才可能触发标量替换：
- 对象未发生逃逸（即：不被方法外访问，不被线程共享，不被存储到静态字段或堆中数组）
- 对象可被分解（字段都是标量或可进一步标量替换的聚合量）
- JVM 启用了逃逸分析和标量替换（
-XX:+DoEscapeAnalysis和-XX:+EliminateAllocations；JDK 7+ 默认开启，无需手动加）
常见误判点：字段含 final 不代表不逃逸；new Object() 被传入 synchronized 块内，若锁对象生命周期仅限当前方法，仍可能被消除——但若该对象被赋值给成员变量或放入 ConcurrentHashMap，立刻逃逸。
标量替换 vs 栈上分配：别被名字带偏
“栈上分配”是容易引发误解的说法。实际执行中，JVM 并不会在栈帧里划一块内存去存一个完整的 User 对象结构（含对象头、对齐填充等）。真正发生的是：
- 假设
User类含int id、String name两个字段 - 逃逸分析确认该
User实例只在当前方法内使用且不逃逸 - JIT 编译后，代码逻辑等效于直接声明两个局部变量：
int id = 123;和String name = "Alice"; -
id可能进 CPU 寄存器，name引用仍指向堆中字符串常量池，但User这个“容器”彻底不存在了
所以你用 jstat 或 GC 日志看不到对应对象的分配记录，-XX:+PrintEliminateAllocations 会输出类似 Eliminated allocation of class User 的提示。
为什么有时候加了 -XX:+PrintEliminateAllocations 却没日志？
这通常不是参数没生效，而是逃逸分析根本没判定成功。排查方向包括：
- 方法是否被 JIT 编译？冷启动时解释执行阶段不触发逃逸分析，加
-XX:+TieredStopAtLevel=1强制 C1 编译，或跑足够多轮次让方法热起来 - 对象是否真的没逃逸？检查是否隐式逃逸：比如调用
toString()、hashCode()（若未重写，会触发对象标识哈希计算，强制堆分配）；或字段引用了外部对象（如把user.name赋给静态Map） - 是否用了不支持标量替换的结构？例如对象字段是
Object[]数组，或含 native 方法调用，JIT 会保守放弃优化
一个可靠验证方式：对比开启/关闭逃逸分析时的 GC 日志。如果关闭后（-XX:-DoEscapeAnalysis）出现大量 Young GC，而开启后 GC 次数骤降甚至为 0，说明标量替换已在生效——哪怕没看到日志，也已悄然工作。
标量替换真正难的不是理解概念，而是写出能让 JVM 看懂“不逃逸”的代码。字段越简单、作用域越窄、调用链越浅，越容易被识别；一旦引入任意一层间接引用或跨方法数据流，优化就大概率失效。
