不会自动放栈上，而是JIT编译器在方法内联且逃逸分析通过后，对未逃逸对象进行标量替换或栈上分配，需满足字段可拆解、无同步、无虚引用等约束。
逃逸分析开启后，Java 会不会自动把对象放到栈上？
不会自动“放栈上”，而是由 JIT 编译器在方法内联 + 逃逸分析通过后，对未逃逸对象做标量替换（Scalar Replacement）或栈上分配（Stack Allocation）优化。关键点在于：这是运行时的 JIT 行为，不是 JVM 启动时就决定的，也不是所有未逃逸对象都会被栈分配——JIT 需要确认该对象字段可拆解、无同步、无虚引用等约束。
实操建议：
- 必须启用
-XX:+DoEscapeAnalysis（JDK 8 默认开启，JDK 9+ 默认仍开启但受 G1 GC 影响可能降级） - 禁用分层编译（
-XX:-TieredStopAtLevel1）或等待 C2 编译器充分预热（通常需执行数万次热点方法调用） - 避免对象被
static字段、线程外传参、System.out.println()、toString()等间接引用——这些都构成逃逸 - 用
-XX:+PrintEscapeAnalysis观察分析日志，例如出现allocated on stack或scalar replaced
为什么 new 出来的对象还是进了堆？常见逃逸场景有哪些？
最典型的是“方法返回对象引用”和“跨线程传递”。只要对象引用离开当前方法作用域，JIT 就无法保证其生命周期可控，逃逸分析直接失败。
常见逃逸触发点：
- 方法返回
new MyObj()（即使调用方没存，JIT 仍视为逃逸） - 将对象传给
Thread.start()、Executor.submit()、Arrays.asList()等接收引用的 API - 对象字段是非 final 的，且被外部读写（JIT 无法证明无副作用）
- 使用反射访问对象字段（如
Field.set()），逃逸分析会保守放弃 - GC 类型影响：ZGC/Shenandoah 下逃逸分析更激进；G1 在并发周期中可能临时禁用标量替换
怎么验证某个对象真被栈分配了？
不能靠 Object.hashCode() 或 System.identityHashCode() 判断——它们在栈分配下仍会正常返回值（JVM 保证语义一致）。真正可靠的验证方式只有两种：
- 启用
-XX:+PrintEscapeAnalysis -XX:+PrintOptoAssembly，搜索日志中是否出现scalar replaced或对应对象类名被标记为not escaped - 配合 JFR（Java Flight Recorder）录制“Allocation in New TLAB”事件，若某对象完全不出现，且方法执行耗时下降、GC pause 明显减少，是间接佐证
- 注意：
jstat -gc看不到栈分配对象，因为它根本不在堆里；jmap -histo也不会统计它们
栈分配对性能的实际影响有多大？哪些情况反而更慢？
收益集中在高频短生命周期对象（如 Point、LocalDate 计算中间态、Builder 内部状态），能显著降低年轻代分配速率与 Minor GC 次数。但要注意：
- 标量替换后字段被拆成独立局部变量，若方法内存在大量字段读写 + 复杂控制流，可能增加寄存器压力，C2 编译后代码体积变大、ICache 命中率下降
- 对象含数组字段（如
int[] data）几乎无法标量替换，JIT 会直接放弃整块优化 - 开启
-XX:+AlwaysTenure或使用 Serial GC 时，逃逸分析效果会被削弱——因为 JIT 会倾向认为“反正回收快，不如堆上放着” - 调试模式（
-Xdebug）或 Attach Agent（如 JProfiler）会强制关闭逃逸分析
真正起效的从来不是“栈分配”这个动作本身，而是它带来的标量替换 + 消除冗余对象头 + 避免 write barrier 开销——这些细节藏在 JIT 生成的汇编里，看不见，但压测时 GC 日志和延迟毛刺会诚实反馈。
