逃逸分析判断对象是否被其他线程或方法访问，仅当“not escaped”且满足标量替换条件时，才可能拆解字段为局部变量；栈上分配极少发生，核心价值是消除对象头和GC开销。
对象逃逸分析到底在判断什么
JVM 并不“主动把对象分配到栈上”，而是通过逃逸分析（Escape Analysis）发现某个对象**根本不会被其他线程或方法访问到**，才可能触发标量替换（Scalar Replacement），进而让对象的字段直接拆解成局部变量——看起来像“在栈上创建”。关键点在于：逃逸分析是优化前提，标量替换才是结果，而栈上分配只是极少数场景下的表象。
常见错误现象：javac 编译完没反应，java -XX:+PrintEscapeAnalysis 却显示“not escaped”，但对象依然在堆里——因为逃逸分析只是 JIT 编译器（C2）的输入，且默认只在 Server 模式、高负载下触发；Client 模式或低迭代次数时直接跳过。
- 必须启用 C2 编译器：
-server（Java 8 及以前）或确保使用 HotSpot Server VM（Java 9+ 默认） - 需要足够预热：方法至少被调用
10000次（-XX:CompileThreshold=10000）才会进入 C2 编译队列 - 逃逸状态是方法粒度的：即使
StringBuilder在方法内新建又立即返回，只要返回值被外部持有，整个对象就被判定为 GlobalEscape
怎么验证一个对象真没逃逸
不能只看代码结构，得看 JVM 实际分析结果。最可靠方式是开启诊断参数并观察日志输出，而不是依赖 IDE 提示或静态分析工具。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 加参数运行：
-XX:+UnlockDiagnosticVMOptions -XX:+PrintEscapeAnalysis -XX:+DoEscapeAnalysis - 关注输出中的关键词：
allocated to stack很少出现；更常见的是not escaped或arg escape - 配合
-XX:+PrintOptoAssembly（需 hsdis）可看到编译后是否真的消除了对象分配指令，但门槛高；日常用-XX:+PrintGCDetails对比 GC 日志中对象晋升量变化更实际
注意：-XX:+DoEscapeAnalysis 在 Java 8u60+ 默认开启，但某些容器环境（如 OpenJ9、部分云 JVM 镜像）可能禁用，务必确认。
哪些写法会立刻破坏“不逃逸”条件
哪怕只有一行看似无害的代码，也可能让整个对象从 not escaped 变成 global escape，导致优化完全失效。
典型破坏点：
- 将对象赋值给
static字段：Cache.HOLDER = new MyObj(); - 作为参数传入未知方法：
log.info(obj.toString());—— 因为toString()可能被重写并泄露引用 - 放入任何集合（哪怕局部声明）：
List<myobj> list = new ArrayList(); list.add(obj);</myobj> - 对对象调用
synchronized：JVM 无法证明锁范围可控，视为潜在逃逸
性能影响很直接：本可拆成几个 int/long 局部变量的操作，变成一次堆分配 + 后续 GC 压力。尤其在高频 short-lived 场景（如 Netty 的 ByteBuf 临时包装）中，逃逸失败会让吞吐量掉 5%~15%。
为什么你几乎看不到“栈上分配”的日志
因为真正完成标量替换、彻底消除对象头和内存布局的案例极少。JVM 更倾向保守优化：只要对象字段有任意一个可能被反射读取、序列化、或作为 Object 传给泛型方法，就会放弃标量替换，退回到“分配在 TLAB 中”——这仍是堆，只是更快。
容易被忽略的限制：
- 对象不能有
final字段以外的非基本类型字段（比如含String引用就无法拆） - 不能重写
finalize()方法（Java 9+ 已废弃，但旧代码仍影响分析） - 数组永远不参与标量替换，哪怕
int[4]这种小数组也老老实实堆上走
所以别纠结“栈上分配”，盯住 not escaped 和 GC 日志里对应对象的存活率下降更实在。真正的优化价值不在内存位置，而在消除不必要的对象头、填充字节、GC 跟踪开销——这些才是逃逸分析想干的事。
