标量替换是JIT在对象不逃逸且仅作字段使用时跳过堆分配、直接将字段存于栈或寄存器的优化；它不是拆对象存储，不改变语义，但绕过new、GC及间接访问。
标量替换是什么，不是什么
标量替换不是把对象“拆开存”，而是 JIT 在确定对象不会逃逸、且仅被当作若干独立字段使用时，跳过对象分配，直接把字段值放在栈上或寄存器里。它不改变语义，但彻底绕过了 new、堆分配、GC 压力和内存访问间接性。
常见误判：看到 @Contended 或 Unsafe 操作就以为能触发标量替换——其实只要对象引用被写入堆（比如放进 static 字段、数组、其他对象字段），逃逸分析就失败，标量替换立刻禁用。
怎么确认你的代码真被标量替换了
JIT 不会告诉你“我替换了”，得靠日志和反汇编交叉验证。开启 -XX:+PrintCompilation 和 -XX:+UnlockDiagnosticVMOptions -XX:+PrintEscapeAnalysis 是基础，但关键要看 EliminateAllocations 是否为 true，以及是否出现 scalar replaced 字样。
- 必须用 Server VM（
java -server或 JDK 9+ 默认），Client VM 已废弃且不支持 - 逃逸分析默认开启，但若堆内存压力大（如频繁 GC），JIT 可能动态关闭它——观察
-XX:+PrintGCDetails中的 GC 频率 -
-XX:+DoEscapeAnalysis要显式加，JDK 8u20 之后某些 build 会默认关掉
哪些写法会让标量替换失效
逃逸分析对“逃逸”的定义非常严格：哪怕只有一行代码把局部对象赋给了 this.field、array[i] 或传给 System.out.println()（因为 println 接收 Object，可能被子类重写并持有引用），整个方法就失去优化资格。
立即学习“Java免费学习笔记（深入）”；
- 调用任何非
final方法（包括toString()、equals()），除非 JIT 能 100% 确定不会逃逸 - 把对象作为参数传给
varargs方法（如String.format()），JIT 无法静态分析数组是否被缓存 - 在 lambda 表达式中捕获局部对象引用——即使 lambda 没逃出方法，JIT 当前版本仍视为潜在逃逸
- 使用
ThreadLocal、ConcurrentHashMap等容器存放该对象，哪怕只是临时 put-get
性能影响比你想象的更具体
标量替换不是“越用越好”。它省的是堆分配 + GC，但换来的是更多寄存器压力和更大的机器码体积。在短生命周期、字段少（≤4）、无复杂计算的场景下收益明显；一旦字段多或方法内联深度超阈值（-XX:MaxInlineLevel 默认 9），JIT 可能放弃内联，进而放弃逃逸分析。
典型受益场景：Point、Range、Pair 这类纯数据结构在循环体内高频构造；典型负向案例：把 StringBuilder 局部化并反复 append——虽然没逃逸，但 JIT 更倾向复用已分配对象而非标量化（因涉及大量字段更新）。
真正难调的点在于：它依赖整个调用链的逃逸状态。一个被内联的辅助方法里有逃逸，会导致外层所有相关对象都不可标量化——这种跨方法隐式耦合，日志里只显示“not escaped”却没说谁破坏了它。
