标量替换是逃逸分析成功后jit自动触发的优化，将不逃逸的小对象拆解为字段存栈或寄存器，跳过堆分配；需满足对象无逃逸、字段均为标量且无副作用，可通过日志、gc分配量及汇编验证。
标量替换不是手动调优的开关，而是逃逸分析成功后 JIT 编译器自动触发的优化行为。它不改变代码写法，只在运行时把“没跑出去”的小对象拆成字段，直接存栈或寄存器，彻底跳过堆分配。
对象必须真正“不逃逸”
逃逸分析是前提，标量替换是结果。只要对象出现以下任一行为，JIT 就放弃优化：
- 被赋值给 static 字段、实例字段（如 this.name = new Person()）
- 作为参数传入非内联方法（比如 log.info(p) 或第三方库方法）
- 调用 getClass()、identityHashCode() 或进入 synchronized(p)
- 字段引用了可变对象（如 private List
tags ），且该字段后续被读写
结构越简单，越容易被拆解
标量替换只对“可分解”的对象生效。JIT 要能证明每个字段都被独立使用，且本身也是标量（基本类型或不可变引用）：
- 推荐用 record 定义数据类（如 record Point(int x, int y) {}），final + 无副作用，逃逸友好度最高
- 避免在 getter 中打印日志、更新计数器等隐式副作用
- 不要重写 equals/hashCode，除非必要；若必须，确保不触发反射或新建对象
- 含 AtomicInteger、ConcurrentHashMap 等同步类型字段的对象，直接阻断标量替换
验证是否真的生效
不能只看 JVM 参数是否开启，得看运行时证据：
- 加 -XX:+PrintEscapeAnalysis，日志中出现 *** object is not escaping 和 *** scalar replaceable
- 用 -Xlog:gc+allocation=debug 对比同一逻辑前后 Eden 区分配字节数——标量替换后应明显下降甚至归零
- 配合调试版 JDK 加 -XX:+PrintOptoAssembly，搜索汇编里是否还有 new Person 指令（没有 = 已拆解）
- JIT 需预热，单次执行或短循环无效，目标方法至少被调用数千次再观察
默认已开，但有隐性边界
HotSpot 自 JDK 8u60 起默认启用逃逸分析与标量替换相关参数：
- -XX:+DoEscapeAnalysis（逃逸分析）
- -XX:+EliminateAllocations（标量替换）
- -XX:+UseTLAB（提升局部分配效率，间接支持优化）
但这些只是“允许优化”，不代表一定发生。对象大小、字段复杂度、JIT 编译时机、甚至 GC 类型（如 ZGC 对逃逸分析支持更积极）都会影响最终决策。
