JVM栈上分配实为标量替换，由JIT基于逃逸分析自动触发：对象未逃逸（不返回、不存字段、不传参、不被反射暴露）时，拆解为字段级局部变量存栈帧或寄存器，跳过堆分配与GC。
JVM 栈上分配不是靠代码显式声明触发的，而是由 JIT 编译器在运行时自动完成的优化行为——它依赖逃逸分析结果 + 正确的 JVM 参数配置 + 严格受限的对象使用方式。代码中“生效”的关键，是写出能让 JVM 确认“对象未逃逸”的结构。
核心前提：对象必须“不逃逸”
只有当一个新创建的对象满足全部以下条件，JVM 才可能对其启用标量替换（即所谓“栈上分配”的实际机制）：
- 不作为方法返回值传出
- 不赋值给任何静态字段、实例字段或数组元素
- 不传递给可能引发逃逸的方法（如 Thread.start()、Executor.submit()、ConcurrentHashMap.put()、synchronized 块外的对象锁等）
- 不被反射、JNI 或序列化等间接路径暴露
典型可优化的代码模式
这类写法最容易被识别为未逃逸，也最常被 JIT 成功优化：
-
纯计算型局部对象：如
new Point(1, 2).distance(new Point(4, 6))，对象仅用于中间计算，生命周期完全封闭在表达式内 -
链式调用且无引用保留：如
new StringBuilder().append("a").append("b").toString()，StringBuilder 实例未被变量持有，也未传出 -
final 字段 + 基本类型为主的小对象：如
new User(25, "Alice")，其中 id、name 均为 final，且 name 指向字符串常量池，无堆内引用传播风险
代码中要避免的“逃逸陷阱”
哪怕只有一行破坏性代码，整个对象就会退回到堆分配：
- 写成
User u = new User(...); return u;→ 直接逃逸（返回引用） - 写成
cache.put("key", new User(...));→ 逃逸到全局容器 - 写成
static User HOLDER = new User(...);→ 逃逸到类静态域 - 写成
synchronized(new Object()) { ... }→ 虽然看似临时，但锁对象可能被 JVM 视为需保证内存可见性，抑制标量替换
验证是否真生效，不能只看代码
写了合规代码 ≠ 一定优化成功。必须配合 JVM 参数并检查日志：
- 启动时加：
-XX:+DoEscapeAnalysis -XX:+EliminateAllocations -XX:+PrintEscapeAnalysis -XX:+PrintEliminateAllocations - 运行后观察输出是否有 scalar replaced 或 eliminated allocation of 'xxx'
- 若无日志匹配，说明逃逸分析未触发（比如方法还没被 JIT 编译），可加
-XX:CompileThreshold=100加速验证（仅测试用）
