对象是在堆上分配还是在栈上逃逸

如果只停留在名词层面，后面无论做方案选型、性能治理还是线上排障，都很容易走到一半就断线。Java 专题 里最容易反复踩坑的，往往也正是这些边界问题。

先说结论

• 对象分配位置会直接影响 GC 压力
• 逃逸分析不是神优化，但会影响热点代码成本
• 真正值得关注的是对象生命周期和临时对象数量

一、这个问题本质上在解决什么

对象是在堆上分配还是在栈上逃逸 的核心，不是记住几个配置项或几条命令，而是先想清楚：当前到底要解决吞吐、延迟、一致性、隔离性，还是可维护性问题。

适合把类加载、双亲委派和运行时对象分配放到一起系统看。当你把问题放回完整链路里看，很多看似复杂的选型，其实都会自然收敛。

二、真正需要抓住的三个判断

1. 先看主目标

对象分配位置会直接影响 GC 压力。如果目标不清楚，后面无论是参数调优、模型设计还是组件选择，都会变成碰运气。

2. 再看工程边界

逃逸分析不是神优化，但会影响热点代码成本。工程里真正难的通常不是“有没有能力”，而是“这个能力接进来之后会不会把系统复杂度一起抬高”。

3. 最后看故障恢复路径

真正值得关注的是对象生命周期和临时对象数量。如果一项方案在异常场景下无法快速回退、定位或补偿，那它在生产里通常就不算真正稳。

三、实战里更推荐怎么落

1. 先把当前链路里的关键约束列出来：吞吐、延迟、容量、可恢复性、变更成本。
2. 再只针对最关键的瓶颈做方案收敛，不要一开始把所有复杂机制都接进来。
3. 上线前至少补一组验证：正常路径、边界输入、失败恢复和观察指标。
4. 把关键判断写成团队可复用的说明，而不是只留在个人经验里。

如果当前主题偏 基础学习，那就更要在“观测、止血、回滚”这条线上把动作提前设计好。

四、常见误区

1. 把所有对象创建都当成性能问题

很多问题不是不会用，而是没有先分清当前到底是哪类场景。

2. 脱离压测数据讨论栈上分配

3. 忽略短命对象洪峰带来的 GC 频率

真正能长期复用的知识，不只是“能跑通”，而是“出事后还能收得回来”。