什么是标量替换标量替换是 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、只传了字段值keyJVM 仍然拒绝做标量替换。这个直觉看起来合理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 短命对象的开销。标量替换是锦上添花不是设计目标。本文来自博客园作者无所事事O_o转载请注明原文链接http
从一个真实案例理解 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、只传了字段值keyJVM 仍然拒绝做标量替换。这个直觉看起来合理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 短命对象的开销。标量替换是锦上添花不是设计目标。本文来自博客园作者无所事事O_o转载请注明原文链接http
