jdk 6u23 后服务端模式下逃逸分析默认开启，无需手动加 -xx:+doescapeanalysis，但依赖分层编译和 c2 编译器；禁用 c2 或设 -xx:tieredstopatlevel=1 会使其失效。
Java逃逸分析默认开启吗？-XX:+DoEscapeAnalysis 还要手动加吗？
JDK 6u23 之后，-XX:+DoEscapeAnalysis 已默认开启（服务端模式 -server 下），无需显式添加。但注意：它依赖分层编译（-XX:+TieredStopAtLevel=1 会禁用）和 C2 编译器；如果用了 -XX:TieredStopAtLevel=1 或强制关闭 C2（如 -XX:-UseCompiler），逃逸分析就直接失效。
- 常见错误现象：
javap -c看到本该栈上分配的对象仍出现在堆 dump 中，不是代码问题，很可能是编译器没跑起来 - 使用场景：短生命周期对象密集创建（如 JSON 解析、字符串拼接中间对象）
- 性能影响：开启后，部分对象可栈上分配、同步消除、标量替换，GC 压力明显下降；但逃逸分析本身有编译开销，仅在 C2 编译的热点方法中生效
怎么确认逃逸分析真正在起作用？
不能只看参数是否开启，得验证实际优化效果。最直接的方式是结合 JVM 启动参数 + 日志观察：
- 加上
-XX:+PrintEscapeAnalysis：输出每个方法的逃逸结论（如scalar replaceable表示可标量替换） - 配合
-XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining，确认方法是否被 C2 编译（有inlined日志才可能触发逃逸分析） - 常见陷阱：本地开发用 IDE 默认启动参数常含
-XX:TieredStopAtLevel=1，此时即使写了-XX:+DoEscapeAnalysis也白搭
-XX:+EliminateLocks 和逃逸分析什么关系？
同步消除（锁消除）是逃逸分析的下游优化，不是独立开关。只有当分析出一个对象“不逃逸”，且其上的 synchronized 锁作用域完全封闭（比如锁对象是方法内 new 的），JVM 才会应用 -XX:+EliminateLocks —— 但这个参数在 JDK 8+ 已被移除，它现在是逃逸分析的自动副产物。
- 使用场景：大量使用
StringBuffer（同步）、或手写小范围临界区时 - 容易踩的坑：
- 锁对象被传入其他方法（哪怕只是
toString()），就可能被判定为“可能逃逸”而放弃消除 -
System.identityHashCode()会强制对象分配在堆上（破坏栈分配前提），连带让锁消除失效 - 日志里看不到 “lock eliminated”，不等于没发生——它只在
-XX:+PrintOptoAssembly级别才详细打印，日常没必要开
- 锁对象被传入其他方法（哪怕只是
逃逸分析对对象分配的影响到底有多大？
它不改变 new 的语义，只改变分配位置：逃逸对象 → 堆；非逃逸对象 → 可能栈上分配，也可能被拆成字段（标量替换）。但注意：
立即学习“Java免费学习笔记（深入）”；
- 栈上分配 ≠ 对象真的在栈帧里：HotSpot 实际仍通过“栈上分配内存块 + 指针偏移”模拟，本质是避免 GC 跟踪
- 标量替换更激进：比如一个
Point类只有x、y两个int字段，且未逃逸，JVM 可能直接把x、y当作局部变量处理，连对象头都省了 - 兼容性风险：某些依赖对象身份（
==、System.identityHashCode()、JNI 引用）的代码，在逃逸分析生效后行为可能变化（比如原来能拿到唯一 hash，优化后抛UnsupportedOperationException）
逃逸分析不是银弹，它高度依赖运行时编译决策，而编译决策又受预热、负载、JVM 版本、甚至 GC 类型（ZGC 下部分优化路径不同）影响。想靠它“一招调优”，往往先得看清 C2 是否真正介入。
