标量替换和同步消除均依赖逃逸分析判定对象“未逃逸”，但优化目标不同：前者将对象字段拆解为栈上局部变量，后者删除无竞争的内置锁指令；二者可共存或独立发生。
标量替换和同步消除是 JVM 在逃逸分析基础上触发的两种不同优化，它们不互为前提，但共享同一个判断依据：对象是否“未逃逸”。
标量替换的本质是字段拆解，不是手动优化
标量替换发生在 JIT 编译阶段（C2 编译器），前提是逃逸分析确认对象完全未逃逸——即该对象仅在当前方法内创建、不被返回、不存入任何堆结构（如数组、集合、实例/静态字段）、不被传入任何可能持有引用的外部方法（包括 System.out.println()、String.format()、lambda 捕获等）。
一旦满足条件，JVM 不会真的把对象分配在栈上，而是将对象的每个字段（如 int x, int y, String name）直接作为独立局部变量放入栈帧中，跳过 new 指令、对象头构造、堆内存申请等开销。效果等价于你手写：
int x = 10; int y = 20; String name = "test";
但代码里仍写 new Point(10, 20) ——这是 JIT 自动完成的，不可手动模拟。
- 仅适用于非数组、非 volatile 字段、且总大小不超过 -XX:MaxStackAllocationSize（默认 64 字节）的对象
- 不支持 final 修饰强制触发；加 @Contended 或用 Unsafe 反而可能干扰逃逸判定
- 验证需配合日志参数：-XX:+PrintEscapeAnalysis -XX:+PrintEliminateAllocations -XX:+UnlockDiagnosticVMOptions
同步消除只针对内置锁，且要求无竞争+未逃逸
同步消除（Lock Elimination）不是偏向锁（Biased Locking）的退化，也不是锁升级流程的一部分。它专指 JIT 在编译时删除 synchronized 块中的 monitorenter/monitorexit 指令，前提是：所用锁对象（如 new Object() 或局部 final 对象）被逃逸分析判定为“不会被其他线程看到”，且整个同步块内没有实际线程竞争可能。
典型可消除场景：
Object lock = new Object();
synchronized (lock) { /* 纯本地计算，无共享状态 */ }
- 若锁是 this，基本无法消除——因为 this 几乎总会逃逸（比如被返回、存入集合、日志打印）
- ReentrantLock 不会被同步消除，JIT 只识别 JVM 内置 monitor 锁
- 即使没竞争，只要锁对象被传给任意一个非内联方法（如 log.debug(lock)），逃逸分析即失败，消除失效
二者都依赖逃逸分析，但触发条件不重叠
标量替换关注“对象字段能否拆成局部变量”，同步消除关注“synchronized 块是否真需要加锁”。它们可以共存（比如一个未逃逸对象既被标量替换，又作为锁被消除），也可以只发生其一。
- 逃逸分析失败 → 两者都不发生
- 对象未逃逸但没用作锁 → 可能只发生标量替换
- 对象未逃逸且恰好用作 synchronized 锁 → 可能只发生同步消除（若字段复杂不满足标量条件）
- Server VM 必须启用：-XX:+DoEscapeAnalysis -XX:+EliminateAllocations（JDK 8u20 后部分版本默认关闭）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
