能，但仅当对象未逃逸且满足严格条件时：需开启逃逸分析与标量替换、无同步块、未重写可能泄露this的方法，且字段不递归替换。
逃逸分析开启后，new 出的对象真能不分配在堆上？
能，但只在满足严格条件时。JVM 会先判断对象是否“逃逸”——即它的引用会不会被方法外持有、传入其他线程、或被全局变量捕获。没逃逸，才可能触发标量替换。
常见误判点：只要方法里有 return obj、obj.toString()（重写了且访问了字段）、或哪怕只是 System.out.println(obj)，都可能导致逃逸判定失败。因为 JVM 无法静态确定这些调用会不会间接泄露引用。
-
-XX:+DoEscapeAnalysis必须显式开启（JDK 8 默认开，JDK 9+ 默认关闭） - 必须配合
-XX:+EliminateAllocations（标量替换开关），否则逃逸分析结果不用来优化分配 - 对象不能含有未被内联的同步块（
synchronized(obj)会让它“逃逸”到锁竞争层面）
toString() 或 hashCode() 被重写，为什么标量替换常失效？
因为 JVM 在逃逸分析阶段无法安全假设这些方法不暴露 this。比如你重写了 toString() 并返回 field.toString()，而这个 field 可能是外部传入的——分析器宁可保守放弃优化，也不冒险。
实操建议：
- 避免在轻量对象里重写
toString()、hashCode()、equals()，除非真需要 - 如果必须重写，确保方法体极简，且不访问任何可能逃逸的字段或调用外部方法
- 用
-XX:+PrintEscapeAnalysis看日志里是否出现not escaped，而不是只看 GC 日志里堆分配少了没
标量替换后，局部变量还叫“对象”吗？
不叫了。它被拆成独立的标量（int、long、double、Object 引用等），直接作为局部变量存在栈帧里，和普通方法参数地位一样。GC 根本看不到它——因为它压根没在堆上构造过。
但要注意：如果对象字段本身是引用类型（比如 String name），这个 name 字段仍需分配在堆上（除非它自己也满足标量替换条件）。标量替换只做一层拆解，不递归。
- 基本类型字段（
int x,boolean flag）→ 直接进栈帧局部变量表 - 引用类型字段（
String s）→ 仍走堆分配，但若s是字面量或已知不可变，JVM 可能进一步优化（如字符串常量池复用） - 数组字段（
int[] data）→ 永远不会被标量替换，数组对象强制堆分配
JDK 17 还值得为标量替换调优吗？
基本不值得。ZGC 和 Shenandoah 的分配成本已极低，而标量替换的触发条件太苛刻，实际业务代码中稳定受益的场景极少。更现实的收益来自：减少对象创建（用 builder 模式复用）、避免包装类（用 int 代替 Integer）、以及把短生命周期对象塞进 ThreadLocal 缓存。
真正容易被忽略的一点：标量替换不是“开了就生效”的魔法，它高度依赖 C2 编译器的内联决策。如果构造函数没被内联（比如被 @HotSpotIntrinsicCandidate 排除，或方法太大），逃逸分析连入口都进不去。
