Java虚拟机不迁移已分配对象，而是通过逃逸分析在对象创建时就决定栈上分配或标量替换；满足未逃逸、类结构简单、无finalizer等条件时，JIT跳过堆分配，将字段拆为局部变量存栈或寄存器，实现零GC开销。
Java 虚拟机并不会把已经分配在堆上的对象“搬”到栈上，而是通过逃逸分析，在对象创建的**那一刻就决定不走堆分配流程**。真正发生的是：JIT 编译器根据分析结果，跳过 new 指令的堆内存申请，转而用更轻量的方式处理——要么在栈帧中预留空间（栈上分配），要么干脆不构造对象实体，直接把字段拆成局部变量（标量替换）。
逃逸分析怎么判断对象能栈分配
核心是看这个对象的引用会不会被方法外“看到”。JIT 在编译热点方法时，会追踪每个 new 出来的对象：
- 它有没有作为返回值传出去
- 有没有赋值给 static 字段、this 字段、数组元素或放入集合等堆中长期存活的位置
- 有没有作为参数传给可能保存引用的方法（比如 submit()、put()、println()、反射调用等）
三者全否，才标记为“未逃逸”，这是栈分配的前提。
栈上分配和标量替换的实际动作
HotSpot 当前（JDK 8–21）没有实现传统意义的“整对象连续栈内存布局”，但标量替换已稳定启用并默认生效，效果等价于栈分配：
立即学习“Java免费学习笔记（深入）”；
- 若对象字段全是基本类型（int、long）或不可逃逸的 final 引用（如 String），JVM 就不建对象，而是把每个字段当作独立局部变量，放进栈帧的局部变量表，甚至直接塞进 CPU 寄存器
- 对象头、引用指针、内存对齐等堆专属开销全部消失
- 方法结束时，这些字段随栈帧自动销毁，零 GC 成本
例如一个只有 final int x, y 的 Point 类，在循环里高频创建，JIT 很可能只生成两条 mov 指令把值放进寄存器，根本不会触发 new。
让逃逸分析真正起作用的关键条件
逃逸分析默认开启（-XX:+DoEscapeAnalysis），但标量替换要落地，还需满足：
- 方法必须被 JIT 编译（通常是执行超 10000 次），解释执行阶段不优化
- 类结构简单：避免非 final 字段、虚方法调用、内部数组（如 StringBuffer.value）、动态代理等
- 未禁用分层编译，未设置 -XX:TieredStopAtLevel=1 等限制 C2 编译器的参数
- -XX:+EliminateAllocations 必须开启（JDK 8+ 默认开启）
怎么确认优化发生了
不能靠 debug 或堆 dump 看，得靠 JVM 运行时反馈：
- 启动加参数：-XX:+PrintEscapeAnalysis -XX:+UnlockDiagnosticVMOptions，观察日志中是否出现 “not escaped” 或 “allocates on stack” 类似提示
- 配合 -XX:+PrintGCDetails，对比开启/关闭逃逸分析后 Young GC 次数和 Eden 区分配量的变化
