标量替换需JIT通过逃逸分析确认对象全程未逃逸，而非手动拆解字段；须切断所有逃逸路径、使用干净不可变结构（如record）、避免触发反射或外部可见操作，并通过日志和GC数据验证实际效果。
不能靠“手动打散”来触发标量替换——JVM 不会因为你把 new Point(x, y) 改成写两个 int x, y 就开启优化。真正起作用的是让 JIT 编译器在运行时确认：这个对象从诞生到消亡，全程没被任何外部看到过。它自动决定要不要跳过 new 指令，把字段当局部变量用。
让对象“彻底隐身”：切断所有逃逸路径
标量替换的前提是逃逸分析判定对象“未逃逸”。只要引用被存入堆位置、传给外部方法、或可能被其他线程观察到，优化就立即失效。
- 避免赋值给
static字段、类级别集合（如CACHE.put(k, obj)） - 不要调用
System.out.println(obj)、obj.toString()（哪怕你重写的版本很轻量） - 禁止
synchronized(obj)、obj.getClass()、System.identityHashCode(obj) - 别把对象放进数组或集合（哪怕只有一行
list.add(p)）
设计利于标量替换的对象结构
对象本身要足够“干净”，字段要可分解、无副作用，才能被 JIT 安全拆解。
- 优先用
record（Java 14+），例如record Point(int x, int y) {}—— final 字段 + 不可变 + 无逻辑方法 - 字段类型必须是标量：基本类型（
int、double）、不可变引用（如String），避免嵌套可变对象（如AtomicInteger、ArrayList） - 不重写
toString()、hashCode()、equals()，除非业务强依赖；若必须重写，方法体须极简，且不访问外部对象或触发反射
验证是否真被拆解，而不是“以为被拆了”
光看参数开启没用，得看运行时证据。JIT 编译有预热门槛，需让目标方法被高频调用（数千次以上）后再观测。
- 加启动参数：
-XX:+DoEscapeAnalysis -XX:+EliminateAllocations -Xlog:gc+allocation=debug - 用
-XX:+PrintEscapeAnalysis查日志，找*** object is not escaping和*** scalar replaceable提示 - 对比 GC 日志中同一逻辑的堆分配字节数，优化后应显著下降甚至归零
- 进阶验证可用调试版 JDK 配合
-XX:+PrintOptoAssembly，搜索汇编输出里是否还有new Point相关指令
常见误区提醒
很多尝试失败，不是因为代码写得不够“聪明”，而是无意中踩中了 JVM 的保守策略。
- 加
@Contended、用Unsafe、把字段全设为final，都不能“强制”标量化 - 开启
-XX:+EliminateAllocations不等于一定生效——它只是逃逸分析成功的副产品 - 不要试图复用一个大对象来“省 allocation”，标量替换的本质是让对象根本不出现在堆上
- 别把它当对象池使：标量替换针对的是临时、短命、完全封闭的局部对象
