从一个真实案例理解 JVM 标量替换
这不是一篇概念科普文，而是从真实代码出发，一步一步走到 JVM 能力边界的分析记录。
什么是标量替换
标量替换是 JIT（主要是 C2 编译器）的一种优化：如果 JVM 能证明一个对象不逃逸、生命周期完全受控、不需要对象身份（identity），就会彻底消除对象分配，将对象的字段拆成若干个局部变量（标量）。
举个例子：
Point p = new Point(x, y);
use(p.x, p.y);
满足条件时，JIT 可能直接变成：
int px = x;
int py = y;
use(px, py);
这里有个关键区别：标量替换不是"对象很快被 GC"，而是对象从未存在过。
一个看起来必然能被标量替换的例子
下面是一个简化后的真实案例：
class Monitor {
static TimerInstanceManager timerInstanceManager;
static TimeContext timer(String key) {
TimeContext ctx = new TimeContext();
ctx.key = key;
ctx.startTime = System.nanoTime();
return ctx;
}
static class TimeContext {
String key;
long startTime;
void end() {
long cost = System.nanoTime() - startTime;
timerInstanceManager.record(key, cost);
}
}
}
使用方式：
for (int i = 0; i < N; i++) {
Monitor.TimeContext ctx = Monitor.timer("123");
ctx.end();
}
看起来完全满足条件：对象只在方法内使用，没有返回给外部、没有放进集合、没有跨线程、没有同步。直觉上，这个对象应该被标量替换。
实验结果：它没有被标量替换
通过实验（关闭逃逸分析对照、jmap 观察等）可以确认：
jmap -histo中可以看到TimeContext实例- 关闭标量替换（
-XX:-DoEscapeAnalysis）后性能变化不大
JVM 没有对它做标量替换。
根因：问题出在这一行
timerInstanceManager.record(key, cost);
哪怕没有传 this、只传了字段值 key，JVM 仍然拒绝做标量替换。
这个直觉看起来合理：record(key) 即使把 key 保存到别的地方，也不影响 TimeContext 本身被销毁，为什么还不行？
关键区别：GC 语义 ≠ 标量替换语义
JVM 做标量替换时问的不是"这个对象之后能不能被 GC？"，而是：
如果我从一开始就不创建这个对象，程序的所有可观察行为会不会发生变化？
这是两道完全不同的问题。
在 JVM 和 Java 内存模型（JMM）中，可观察行为包括：内存写入顺序、happens-before 关系、并发可见性、对象构造语义（尤其是 final 字段）、JVMTI / safepoint 可见性。
标量替换意味着 JVM 要"假装这个对象从未存在过"。
一个最小反例
考虑这个完全合法的代码：
class Recorder {
static volatile String published;
static volatile boolean ready;
static void record(String key) {
published = key;
ready = true;
}
}
原始逻辑：
TimeContext ctx = new TimeContext();
ctx.key = "123";
Recorder.record(ctx.key);
另一个线程：
while (!Recorder.ready) {}
System.out.println(Recorder.published);
不做标量替换时，ctx.key = "123" 正常发生，happens-before 关系成立，输出一定是 123。
如果 JVM 强行标量替换，变成：
String k = "123";
Recorder.record(k);
ctx.key = "123" 这个写入从未发生，构造与字段写入的内存语义被抹掉，JVM 无法证明并发可见性仍然完全等价——语义不再可证明等价。
JVM 的硬边界
从 JIT 的角度，规则可以总结成一句话：
只要一个对象的字段值被传入了 JVM 无法完全建模的调用中，JVM 就不能假装这个对象从未存在过。
在本例中，record() 是跨类、跨实例、不可完全内联的"黑盒"，JVM 无法证明它没有副作用，对象生命周期无法在编译期"闭合"，标量替换被放弃。
这不是"逃逸分析失败"
需要澄清一点：对象可能是 NoEscape，但仍然不会被标量替换。
标量替换不是逃逸分析的必然结果，而是一个额外、可选、极其保守的优化。JVM 宁可少优化，也绝不破坏 Java 语义——跨方法、跨线程、跨内存模型的证明成本太高，一旦出错就是 JVM 级别的语义 bug。
总结
这个案例的结论：对象逻辑上可被 GC，但不能被标量替换，原因是字段值进入了不可建模的外部调用，JVM 无法证明"对象从未存在过"是语义透明的。
标量替换不是"对象很快死掉"，而是"对象从未存在过"。
工程启示
不要在设计时依赖标量替换。高频路径下，要么设计为无对象，要么接受 TLAB + 短命对象的开销。标量替换是锦上添花，不是设计目标。
