栈上分配是逃逸分析成功后jvm将未逃逸对象在栈中分配内存的优化，其性能提升源于避免堆分配、gc扫描和回收开销，而非栈本身更快。
栈上分配本身不直接提升性能，它只是逃逸分析成功后的结果；真正起作用的是逃逸分析识别出对象不会逃逸后，JVM省去了堆分配、GC扫描和内存回收的开销。
什么是栈上分配（Stack Allocation）
栈上分配是指JVM在满足条件时，将本该在堆中创建的对象，改为在当前线程的Java虚拟机栈中分配内存。这个过程对开发者完全透明，由JIT编译器在运行时决定。
关键前提：对象必须经过逃逸分析，且被判定为“未逃逸”——即对象的引用不会被方法外的代码访问，也不会被其他线程访问。
逃逸分析如何触发栈上分配
逃逸分析是JIT编译器（如HotSpot的C2）在方法内联优化后进行的一项数据流分析。它追踪对象的引用传播路径，判断其是否“逃逸”出当前方法或线程。
立即学习“Java免费学习笔记（深入）”；
- 局部对象仅作为参数传入无逃逸风险的私有方法 → 可能不逃逸
- 对象被赋值给静态字段、作为返回值传出、发布到线程共享容器（如ConcurrentHashMap）→ 确定逃逸
- 对象数组元素被外部引用，或通过反射暴露 → 通常视为逃逸
只有当分析确认对象“不逃逸”，且JVM开启相关优化（如-XX:+DoEscapeAnalysis，默认开启），才可能启用栈上分配。
栈上分配的实际收益与限制
收益不是因为“栈比堆快”，而是规避了三类开销：
- 堆内存分配需要同步或TLAB管理，而栈分配只需移动栈顶指针（近乎零成本）
- 对象不进堆 → 减少Young GC频率和单次扫描对象数
- 无堆对象 → 不参与GC标记、清理、压缩，降低STW时间
但要注意：栈上分配仅适用于生命周期严格受限于当前方法调用的对象；一旦对象被缓存、跨方法传递或用于闭包捕获，就会退回到堆分配。
如何验证是否发生栈上分配
没有直接日志显示“某对象已栈分配”，但可通过间接方式观察效果：
- 启用-XX:+PrintEscapeAnalysis查看逃逸分析决策（输出较简略）
- 配合-XX:+PrintGCDetails对比开启/关闭逃逸分析（-XX:-DoEscapeAnalysis）时的GC次数与耗时变化
- 使用JMH压测典型场景（如频繁创建短生命周期DTO），观察吞吐量与GC时间差异
注意：栈上分配是JIT优化行为，只发生在预热后的热点代码中，冷启动阶段无法体现。
基本上就这些。栈上分配不是银弹，它依赖逃逸分析的准确性与代码结构的配合；写好局部、避免无意暴露引用，比强行“手动栈分配”更有效。
