标量替换是逃逸分析成功的副产品，仅当对象未逃逸且字段可分解时，JIT才自动将其拆为栈上局部变量；它不依赖手动代码改写，也不因开启参数而必然生效。
标量替换不是开关，而是逃逸分析的副产品
标量替换不会因为你加了 -XX:+EliminateAllocations 就一定发生——它必须建立在 JVM 成功完成逃逸分析（Escape Analysis）的基础上。如果对象被判定“逃逸”，哪怕开了所有相关参数，标量替换也完全不生效。
常见逃逸触发点包括：
- 把局部对象赋值给 static 字段或类级别集合（如 CACHE.put(k, obj)）
- 将对象作为参数传入非内联方法（尤其是第三方库方法，JIT 可能无法跨 jar 分析）
- 调用 obj.getClass()、System.identityHashCode(obj) 或任何同步块（synchronized(obj)）
- 对象字段是可变引用类型（如 private List），且该字段后续被读写
什么样的对象结构最容易被标量替换
标量替换只对“可分解”的聚合量有效，而分解的前提是：所有字段本身都是标量（int、long、boolean、Object 引用等基本类型或不可再分引用），且 JIT 能证明这些字段被独立使用。
推荐写法：
- 用 record 定义纯数据载体（Java 14+），例如 record Point(int x, int y) {} —— 不可变 + final 字段 + 无逻辑方法，逃逸分析友好度最高
- 避免 getter/setter 中引入副作用（如日志、计数器），否则 JIT 可能放弃优化
- 不要重写 equals/hashCode，除非必要；若必须，确保实现不触发反射或额外对象分配
反例：class Point { private final AtomicInteger x = new AtomicInteger(); } —— AtomicInteger 是堆对象，且含同步语义，直接阻断标量替换。
如何验证标量替换是否实际生效
不能只看参数是否开启，得看运行时行为。最可靠方式是结合 GC 日志与逃逸分析输出交叉比对：
启动参数建议：
- -XX:+DoEscapeAnalysis -XX:+EliminateAllocations（JDK7+ 默认已开，但显式写出便于确认）
- -Xlog:gc+allocation=debug（JDK10+）观察每毫秒堆分配量，重点对比优化前后同一逻辑的 allocated 字节数
- -XX:+PrintEscapeAnalysis 查看日志中是否出现 *** object is not escaping 和 *** scalar replaceable 类似提示
- 若需深度确认，配合调试版 JDK 使用 -XX:+PrintOptoAssembly，搜索生成代码中是否还有 new Point 相关指令（没有 = 已被拆解）
注意：JIT 编译有预热过程，单次运行或小循环不足以触发优化；务必让目标方法被调用数千次以上再采样。
别把标量替换当对象池用
标量替换本质是“零成本消除对象”，不是“复用对象”。它不适用于需要跨方法传递、生命周期超出当前栈帧、或需保持引用一致性（如回调上下文、缓存 key）的场景。
容易忽略的关键点：
- 标量替换后，原对象的 == 语义彻底消失（因为根本没创建对象）
- 若代码里写了 if (p == null) 或依赖 p.hashCode()，优化后可能抛 NullPointerException 或行为突变
- 多线程环境下，即使对象未逃逸，只要存在潜在共享可能（如通过 Unsafe 操作地址），JVM 会保守放弃优化
真正该考虑对象池的场景，是那些**必须保留对象身份**但又高频创建的小对象（如 Netty 的 ByteBuf）；标量替换解决的是另一类问题：**压根不需要对象身份，只要字段值**。
