标量替换是JVM在逃逸分析确认对象不逃逸后，跳过对象创建、直接使用其字段的优化；依赖C2编译器精确分析，要求对象不可逃逸、仅含标量字段（如record）、无同步/反射/引用传递等行为，最终消除堆分配开销。
标量替换不是“让对象少分配一点”，而是直接跳过对象创建这一步——只要JVM确认对象不逃逸、字段可独立使用，就不再生成对象实例，连对象头、对齐填充、堆寻址这些开销都归零。
逃逸分析是前提，不是开关
标量替换不会因为加了-XX:+EliminateAllocations就自动生效。它必须依赖C2编译器完成准确的逃逸分析：对象不能被赋值给static字段、不能作为参数传入非内联方法（尤其是第三方库）、不能参与synchronized、不能调用getClass()或identityHashCode()。一旦其中任一条件触发，整个优化链就中断。
- 例如：
Point p = new Point(1, 2); return p.x + p.y;——若p未逃逸且Point仅含final int字段，JIT可能只保留两个int变量 - 但若写成
synchronized(p) { ... }或CACHE.put("key", p)，哪怕只出现一次，p立刻被判定为逃逸，标量替换完全失效
对象结构决定能否被“拆解”
标量替换只作用于“可分解”的聚合量。所谓标量，是指不能再拆、无身份、无引用语义的基本单元：int、long、boolean，以及仅含标量字段的不可变对象（如record Point(int x, int y)）。
- 推荐用record定义数据载体：final字段 + 无副作用方法 + 不重写equals/hashCode → JIT分析友好度最高
- 避免字段是AtomicInteger、ArrayList这类堆对象；哪怕一个字段是Object引用，只要该引用后续被读写，且JIT无法证明其不逃逸，整块替换就放弃
- getter/setter里加日志、计数器、反射调用，都会让JIT放弃优化——它只信任纯数据流
验证不是看参数，而是看行为
启动时加上-XX:+DoEscapeAnalysis -XX:+PrintEscapeAnalysis，运行足够多次（建议方法调用超5000次）后观察日志：
- 出现
*** object is not escaping和*** scalar replaceable提示，说明逃逸分析通过且具备替换条件 - 配合-Xlog:gc+allocation=debug对比优化前后同一逻辑的allocated字节数——下降显著才代表真实生效
- 终极验证用调试版JDK加-XX:+PrintOptoAssembly，搜索汇编输出中是否还有
new Point相关指令；没有，才真正“彻底消除”
它不是替代方案，而是零成本隐式优化
标量替换不改变代码语义，也不需要你改写逻辑或引入对象池。它的价值在于：对高频构造的小型值对象（如坐标、区间、上下文元数据），在满足条件时，把每次new的开销压缩为几个寄存器赋值——没有堆分配、没有GC跟踪、没有缓存行浪费。这种优化由C2编译器在热点方法上自动完成，开发者只需写出逃逸友好的代码，剩下的交给JIT。
