标量替换是JIT在逃逸分析确认对象不逃逸后，自动将对象字段拆为栈上局部变量、跳过new和堆分配的优化；它不由代码改写触发，需Server VM、-XX:+DoEscapeAnalysis等参数配合，并通过JIT日志验证。
标量替换不是手动拆对象，而是让 JIT 自动决定要不要跳过 new
标量替换不能靠改写代码“手动拆” Point 或 Range 类来触发——它完全由 JVM 的逃逸分析 + JIT 编译器在运行时动态决策。你写的还是 new Point(x, y)，但最终生成的机器码可能压根不执行 new 指令，而是直接把 x 和 y 当作两个局部 int 变量用。
常见错误是以为加了 @Contended、用 Unsafe、或把字段全改成 final 就能“强制标量化”。其实只要对象引用被写入堆（哪怕只有一行 array[0] = p;），逃逸分析立刻失败，标量替换直接禁用。
- 必须用 Server VM（JDK 9+ 默认，
java -version看到Server VM才行） -
-XX:+DoEscapeAnalysis和-XX:+EliminateAllocations要显式开启（JDK 8u20 后某些 build 默认关了） - 逃逸分析本身会动态关闭：如果 GC 频繁（比如
-Xmx设太小），JIT 可能直接停掉整个逃逸分析流程
哪些写法会让逃逸分析直接失败
逃逸分析对“逃逸”的判定极其严格，不是“我没传出去”，而是“JVM 能 100% 证明没人能拿到引用”。以下任意一行都足以让整个方法失去标量替换资格：
-
this.point = p;（写入实例字段） -
list.add(p);（进容器，哪怕ArrayList是局部变量） -
System.out.println(p);（println(Object)是非 final 方法，JIT 无法排除子类重写后持有引用） -
String.format("%s", p);（varargs 会构造数组，JIT 无法静态确定是否缓存） -
Runnable r = () -> use(p);（lambda 捕获局部对象，在当前 HotSpot 版本中一律视为潜在逃逸）
连 p.toString() 都危险：除非 JIT 能内联并确认该方法没逃逸行为，否则也会放弃优化。所以纯数据类别乱加 toString() 或 equals()，尤其不要调用外部方法。
怎么验证标量替换真发生了
JVM 不会输出“已标量替换”，得靠日志交叉比对。关键不是看有没有 scalar replaced，而是看 EliminateAllocations 是否为 true，以及编译日志里是否出现 alloc 相关消除记录。
启动参数示例：
-XX:+PrintCompilation -XX:+UnlockDiagnosticVMOptions -XX:+PrintEscapeAnalysis -XX:+PrintEliminateAllocations -XX:+TraceClassLoading
观察输出中是否有类似：
567 43 3 java.lang.Math::min (11 bytes)
@ 3 java.lang.Math::min (11 bytes) inline (hot)
@ 7 Test::calc (23 bytes) inline (hot)
alloc 'Test$Point' is not escaped and not captured → scalar replaced
如果只看到 not escaped 却没提 scalar replaced，大概率是字段太多（>4）、方法没被内联（-XX:MaxInlineLevel 默认 9）、或 JIT 放弃了该方法的优化。
性能收益有明确边界，别在错的地方强求
标量替换省的是堆分配 + GC 压力 + 间接内存访问，但它换来的是更多寄存器占用和更大机器码体积。收益明显的场景非常具体：
- 字段少（≤4 个基本类型，不含嵌套对象）
- 生命周期极短（只在单个方法内创建、读取、丢弃）
- 高频调用（比如循环体内每轮都 new 一个
Pair<int, int>）
反例：把 StringBuilder 局部化并在循环里反复 append()，虽然不逃逸，但 JIT 更倾向复用已分配对象——因为字段更新频繁，标量化反而增加寄存器压力；又比如 Student 类含 Teacher 引用，即使 Teacher 本身也不逃逸，JVM 仍需做二级逃逸分析，成功率大幅下降。
真正要动手优化时，优先确认 GC 日志里是不是真有大量 Young GC 由这些小对象触发；否则花半天调参数，可能还不如换个更紧凑的数据结构。
