标量替换是JVM在满足逃逸分析通过、字段全为标量、启用相关参数等严格条件下自动触发的JIT优化，将对象拆解为寄存器中的独立变量而非堆分配。

标量替换不是你“应用”的算法，而是 JVM 在满足严格条件时自动触发的 JIT 编译优化。它不靠手写逻辑、不调 API、也不改数据结构——你写的还是 new Point(x, y)，但最终机器码里可能根本没有对象分配。

关键不在“怎么用”，而在“怎么让 JVM 敢用”。

---

标量替换真正生效的硬性前提

• 对象必须全程不逃逸
  JVM 要 100% 证明：这个对象的引用没被存到任何堆位置、没传给任何外部方法、没被其他线程可见。哪怕只有一行 list.add(p) 或 System.out.println(p)，整个方法的标量替换就直接放弃。

• 字段必须可静态分解
  所有字段得是标量（int、long、boolean）或本身也满足标量替换条件的嵌套对象（如 record Range(int lo, int hi) 中的 lo/hi）。含 String、List、AtomicInteger 等引用类型字段，基本就断了路。

• 运行环境必须支持且启用

  • 必须是 Server VM（JDK 9+ 默认，用 java -version 确认含 “Server VM”）
  • 显式开启逃逸分析：-XX:+DoEscapeAnalysis
  • 开启分配消除：-XX:+EliminateAllocations（JDK 8u20 后部分版本默认关闭，务必显式加）
  • GC 压力不能太大：频繁 Full GC 会令 JIT 主动停掉逃逸分析

---

让代码更“标量友好”的实操写法

• 优先用 record 定义纯数据类
  record Point(int x, int y) {} 天然 final、不可变、无隐藏逻辑，JIT 分析成本低、成功率高。

• 避免任何可能暴露引用的操作
  不调 toString()、equals()、hashCode()（除非内联确认无副作用）；不用 synchronized(p)；不调 getClass() 或 System.identityHashCode(p)。

• 别在 lambda 或匿名类里捕获局部对象
  Runnable r = () -> process(p); 当前 HotSpot 版本一律视为潜在逃逸，直接禁用。

• 字段别带可变引用或同步语义
  反例：private final AtomicInteger counter = new AtomicInteger(); —— AtomicInteger 是堆对象 + volatile + 锁，JIT 绝对绕道走。

---

验证它到底有没有发生

光看参数没用，得看运行时证据：

• 加启动参数：
  -XX:+PrintEscapeAnalysis -XX:+PrintEliminateAllocations -XX:+UnlockDiagnosticVMOptions

• 关键日志线索：

  • 出现 *** object is not escaping
  • 出现 *** scalar replaceable
  • EliminateAllocations 显示为 true
  • 编译日志中该方法对应行有 scalar replaced 标记

• 进阶确认（需调试版 JDK）：
  加 -XX:+PrintOptoAssembly，搜索汇编输出里是否还有 new Point 相关指令或对象字段偏移访问（如 mov %rax, 0x8(%rbx)）——没有，才说明真拆了。

注意：JIT 编译有预热过程，单次调用或小循环不会触发，要让目标方法执行数千次以上再采样。

---

标量替换不是魔法开关，它是 JVM 对你代码信任度的量化反馈。写得越干净、越克制、越“无副作用”，它就越愿意把对象从堆上抹掉，换成寄存器里的两个整数。