new出来的对象不一定在堆上，因逃逸分析可判定其是否逃逸：未逃逸时JVM可栈上分配或标量替换；方法逃逸或线程逃逸则必须堆分配。
对象逃逸分析不是玄学，而是一套可观察、可验证的编译期推理机制。它不改变 Java 语法，但直接决定一个 new 出来的对象究竟落在堆上还是栈上——关键不在“能不能”，而在“JVM 能不能证明它不会逃逸”。真正影响栈上分配的，从来不是代码写得多漂亮，而是有没有触发 JIT 的保守退化策略。
逃逸判定的三个硬性层级
逃逸不是二值判断（逃或不逃），而是一个由内向外的三级漏斗：
- 不逃逸（No Escape）：对象仅作为局部变量存在，未被赋值给任何字段、未传参、未返回、未被反射/同步/序列化访问。这是栈上分配的唯一准入门槛。
- 方法逃逸（Method Escape）：对象作为返回值或参数传递给其他方法。即使接收方是私有方法，JIT 仍视为潜在跨作用域引用，放弃栈分配。
- 线程逃逸（Thread Escape）：对象被写入静态变量、实例字段、ThreadLocal、ConcurrentMap 或任何可能被其他线程读取的位置。此时不仅不能栈分配，还可能触发锁粗化或禁止标量替换。
让对象留在栈上的实操约束
满足“不逃逸”只是前提，JVM 还要确认分配行为本身安全可行。以下任一条件不满足，栈上分配就会静默失败：
-
对象大小受限：HotSpot 默认阈值为 128 字节（可通过
-XX:MaxBoundedArraySize等参数微调），超限对象强制堆分配，避免栈帧膨胀引发 StackOverflowError。 -
禁止虚方法调用干扰：哪怕对象没逃逸，只要调用了未内联的虚方法（如
obj.toString()、obj.hashCode()），JIT 无法 100% 排除监控或代理介入，倾向保守堆分配。 -
同步块即否决票：
synchronized(obj) { ... }要求对象具备稳定内存地址（用于 monitor 锁记录），而栈上对象随方法退出即失效，因此该语句会直接关闭栈分配通道。 -
反射与 JNI 是逃逸开关：任何
Field.set(obj, ...)、Method.invoke(...)或 JNI 函数传入对象引用，都会导致逃逸分析中止并标记为逃逸。
标量替换：比栈上分配更激进的优化
当对象被判定为不逃逸，且所有字段均为基本类型或不可变引用（如 String 常量），JIT 可启用标量替换（需开启 -XX:+EliminateAllocations）：
- 对象不再以整体形式存在，而是拆解为独立局部变量（例如
Point p = new Point(3, 4)→ 编译后变为int px = 3; int py = 4;）。 - 字段访问变成直接寄存器读写，无对象头开销、无内存对齐填充、无 GC 元数据。
- 该优化比栈上分配要求更高：不允许任何字段被取地址、不允许字段参与 synchronized、不允许字段被反射访问。
验证是否生效的可靠方式
别依赖直觉或日志，用 JVM 自带工具交叉验证：
- 加参数
-XX:+PrintEscapeAnalysis -XX:+PrintOptoAssembly，查看 JIT 日志中是否出现allocates on stack或scalar replaced字样。 - 使用 JMH 基准测试对比：同一逻辑开启
-XX:+DoEscapeAnalysis与关闭时的吞吐量和 GC 次数差异（注意关闭后需加-XX:-UseTLAB控制变量）。 - 通过
jstat -gc <pid></pid>观察 Young GC 频率下降幅度——栈分配对象不入 Eden 区，GC 压力降低是其最直接外在表现。
