方法逃逸是栈上分配和标量替换的前提，决定对象能否避免堆分配；线程逃逸是同步消除的必要条件，仅减少锁开销而不影响对象生命周期。
方法逃逸和线程逃逸虽然都属于逃逸分析的判断维度，但它们触发的优化能力、适用范围和实际影响量级有明显差异——方法逃逸是栈上分配和标量替换的前提，线程逃逸则是同步消除的必要条件；前者直接影响内存分配路径与GC压力，后者主要减少锁开销，不改变对象生命周期。
方法逃逸决定对象是否能“不上堆”
方法逃逸关注的是对象引用能否离开当前方法作用域。只要对象没被返回、没赋值给成员变量、没传给外部方法（且未被保存），JVM 就可能把它“就地拆解”或“就地栈上分配”。这种优化直接绕过堆内存分配，避免 GC 扫描，对高频短生命周期对象（如 StringBuilder、临时 DTO）效果显著。
- 栈上分配：对象不再出现在堆中，随方法栈帧弹出自动消失，彻底免于 GC
- 标量替换：对象被拆成 int、long、reference 等局部变量，分散在栈帧或寄存器里，节省对象头、对齐填充等固定开销（通常 12–16 字节）
- 一旦发生方法逃逸（比如 return obj 或 this.field = obj），这两项优化立即失效，对象必须走常规堆分配流程
线程逃逸决定同步是否可“直接去掉”
线程逃逸判断的是对象是否可能被其他线程访问。典型场景包括：赋值给 static 字段、作为共享容器元素（如 ConcurrentHashMap.put）、发布到线程池任务中。只有确认对象仅被单一线程独占访问，JVM 才敢移除 synchronized 块或 volatile 写屏障。
- 同步消除（Lock Elimination）不改变内存分配位置，对象仍在堆上，只是省掉了 monitor enter/exit 的指令和竞争检测逻辑
- 收益集中在 CPU 指令数减少和缓存行争用降低，对吞吐提升可见，但无法缓解堆内存增长或 GC 频次
- 若对象已发生方法逃逸（比如作为参数传入另一个方法），即使该方法只被单线程调用，线程逃逸分析也可能因上下文不可控而保守放弃优化
两者的依赖关系与影响权重
方法逃逸是更基础、更前置的判断。JVM 必须先确认对象“没跑出方法”，才继续评估它“会不会被别的线程看到”。换句话说：没有方法逃逸，线程逃逸无从谈起；但方法逃逸成立时，线程逃逸未必成立（比如局部对象被写入 volatile 字段）。
- 方法逃逸优化失败 → 对象进堆 → GC 压力上升 → 可能引发 STW 停顿 → 影响整体响应延迟
- 线程逃逸优化失败 → 多执行几条同步指令 → 单线程下几乎无感，高并发下才体现锁竞争瓶颈
- 实测表明，在典型 Web 服务中，关闭逃逸分析（-XX:-DoEscapeAnalysis）后 Young GC 次数平均增加 15%~30%，而同步消除缺失带来的吞吐下降通常低于 5%
如何快速识别哪种逃逸正在发生
观察代码中对象的“出口”即可定位：
- 方法逃逸迹象：new 出的对象出现在 return 表达式中、被赋给 this.xxx 或 XXX.INSTANCE、作为参数传入非内联方法且该方法体有存储行为
- 线程逃逸迹象：对象被放入 static 集合、被提交到 ExecutorService、作为监听器注册到全局事件总线、被写入 volatile / AtomicReference 字段
- 验证手段：启用 -XX:+PrintEscapeAnalysis 和 -XX:+UnlockDiagnosticVMOptions，配合 -XX:+PrintEliminateAllocations 查看 JIT 是否执行了标量替换
