从一个真实案例理解 JVM 标量替换

这不是一篇概念科普文，而是从真实代码出发，一步一步走到 JVM 能力边界的分析记录。

什么是标量替换

标量替换是 JIT（主要是 C2 编译器）的一种优化：如果 JVM 能证明一个对象不逃逸、生命周期完全受控、不需要对象身份（identity），就会彻底消除对象分配，将对象的字段拆成若干个局部变量（标量）。

举个例子：

java 复制代码

Point p = new Point(x, y);
use(p.x, p.y);

满足条件时，JIT 可能直接变成：

java 复制代码

int px = x;
int py = y;
use(px, py);

这里有个关键区别：标量替换不是"对象很快被 GC"，而是对象从未存在过。

一个看起来必然能被标量替换的例子

下面是一个简化后的真实案例：

java 复制代码

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);
        }
    }
}

使用方式：

java 复制代码

for (int i = 0; i < N; i++) {
    Monitor.TimeContext ctx = Monitor.timer("123");
    ctx.end();
}

看起来完全满足条件：对象只在方法内使用，没有返回给外部、没有放进集合、没有跨线程、没有同步。直觉上，这个对象应该被标量替换。

实验结果：它没有被标量替换

通过实验（关闭逃逸分析对照、jmap 观察等）可以确认：

jmap -histo 中可以看到 TimeContext 实例
关闭标量替换（-XX:-DoEscapeAnalysis）后性能变化不大

JVM 没有对它做标量替换。

根因：问题出在这一行

java 复制代码

timerInstanceManager.record(key, cost);

哪怕没有传 this、只传了字段值 key，JVM 仍然拒绝做标量替换。

这个直觉看起来合理：record(key) 即使把 key 保存到别的地方，也不影响 TimeContext 本身被销毁，为什么还不行？

关键区别：GC 语义 ≠ 标量替换语义

JVM 做标量替换时问的不是"这个对象之后能不能被 GC？"，而是：

如果我从一开始就不创建这个对象，程序的所有可观察行为会不会发生变化？

这是两道完全不同的问题。

在 JVM 和 Java 内存模型（JMM）中，可观察行为包括：内存写入顺序、happens-before 关系、并发可见性、对象构造语义（尤其是 final 字段）、JVMTI / safepoint 可见性。

标量替换意味着 JVM 要"假装这个对象从未存在过"。

一个最小反例

考虑这个完全合法的代码：

java 复制代码

class Recorder {
    static volatile String published;
    static volatile boolean ready;

    static void record(String key) {
        published = key;
        ready = true;
    }
}

原始逻辑：

java 复制代码

TimeContext ctx = new TimeContext();
ctx.key = "123";
Recorder.record(ctx.key);

另一个线程：

java 复制代码

while (!Recorder.ready) {}
System.out.println(Recorder.published);

不做标量替换时，ctx.key = "123" 正常发生，happens-before 关系成立，输出一定是 123。

如果 JVM 强行标量替换，变成：

java 复制代码

String k = "123";
Recorder.record(k);

ctx.key = "123" 这个写入从未发生，构造与字段写入的内存语义被抹掉，JVM 无法证明并发可见性仍然完全等价------语义不再可证明等价。

JVM 的硬边界

从 JIT 的角度，规则可以总结成一句话：

只要一个对象的字段值被传入了 JVM 无法完全建模的调用中，JVM 就不能假装这个对象从未存在过。

在本例中，record() 是跨类、跨实例、不可完全内联的"黑盒"，JVM 无法证明它没有副作用，对象生命周期无法在编译期"闭合"，标量替换被放弃。

这不是"逃逸分析失败"

需要澄清一点：对象可能是 NoEscape，但仍然不会被标量替换。

标量替换不是逃逸分析的必然结果，而是一个额外、可选、极其保守的优化。JVM 宁可少优化，也绝不破坏 Java 语义------跨方法、跨线程、跨内存模型的证明成本太高，一旦出错就是 JVM 级别的语义 bug。

总结

这个案例的结论：对象逻辑上可被 GC，但不能被标量替换，原因是字段值进入了不可建模的外部调用，JVM 无法证明"对象从未存在过"是语义透明的。

标量替换不是"对象很快死掉"，而是"对象从未存在过"。

工程启示

不要在设计时依赖标量替换。高频路径下，要么设计为无对象，要么接受 TLAB + 短命对象的开销。标量替换是锦上添花，不是设计目标。