堆用于存储对象实例，是线程共享的gc管理区域；虚拟机栈用于方法执行，是线程私有的栈帧容器，只存局部变量和对象引用，不存对象本体。
堆和虚拟机栈是 JVM 中两个完全独立、职责分明的内存区域，不能混用，也不能互相替代。 堆用于存储对象实例（包括数组），是线程共享的；虚拟机栈用于支撑 Java 方法执行，是线程私有的。搞混它们，轻则抛 OutOfMemoryError 或 StackOverflowError，重则导致逃逸分析失效、GC 行为异常或 JIT 优化退化。
堆：所有对象的“户籍所在地”
堆是 JVM 启动时创建的、最大的一块线程共享内存区域。几乎所有对象实例都分配在堆上——哪怕你写了 new Object()，JVM 默认就往堆里扔。例外情况极少，比如 JIT 编译器通过逃逸分析确认某个对象不会被方法外访问，才可能把它分配到栈帧中（标量替换），但这只是优化结果，不是开发者可控行为。
关键点：
- 堆大小由
-Xms和-Xmx控制，新生代/老年代比例由-XX:NewRatio决定 - 对象分配优先走 Eden 区；大对象可直接进老年代（靠
-XX:PretenureSizeThreshold触发） - 堆是 GC 主战场，分代回收策略（如 G1、ZGC）全围绕它设计
- 堆里的数据对所有线程可见，所以必须配合锁、volatile 或 CAS 等机制保证并发安全
虚拟机栈：每个线程独享的“调用快照”
虚拟机栈描述的是 Java 方法执行的线程内存模型。每个线程启动时就分配好自己的栈空间，生命周期与线程一致。每次调用一个 Java 方法，JVM 就压入一个栈帧（Stack Frame），里面存着局部变量表、操作数栈、动态链接、返回地址等——这些全是“运行时上下文”，不存对象本体，只存基本类型值和对象引用（即指向堆中某块内存的指针）。
常见误区：
- 误以为“栈上能存对象”：栈里只能存
Object obj这种引用，obj指向的对象本身一定在堆里（除非逃逸分析成功且 JIT 实际做了标量替换） - 混淆
StackOverflowError和OutOfMemoryError：前者是栈深度超限（如无限递归），后者可能是栈空间不足（-Xss设太小）或堆内存耗尽 - 忽略 HotSpot 的 “mixed stack” 实现：虽然 JVM 规范把 Java 栈和本地方法栈分开定义，但 HotSpot（OpenJDK 默认 VM）实际只维护一个混合栈，Java 帧和 native 帧共存于同一调用栈
为什么不能把对象塞进虚拟机栈？
栈帧随方法调用而生、随方法返回而灭，生命周期极短。如果允许在栈帧里直接分配对象，那方法一 return，对象就该销毁——但 Java 允许把对象引用返回给调用方，甚至放进全局集合。这就要求对象本身必须存活更久，只能放在堆里，靠 GC 判断是否可达来决定回收时机。
换句话说：
- 栈帧解决“怎么执行”，堆解决“存什么数据”
- 栈帧大小在编译期基本确定（局部变量表槽位数、操作数栈深度等），堆大小在运行期动态伸缩
- 栈溢出（
StackOverflowError）通常反映代码逻辑问题（如递归失控）；堆溢出（OutOfMemoryError: Java heap space）往往暴露内存泄漏或配置不合理
真正容易被忽略的是：堆和栈的边界在 JIT 层面其实有模糊地带——逃逸分析不是 always-on，默认开启但可能被关闭（如加了 -XX:-DoEscapeAnalysis），而且是否触发标量替换还取决于对象字段是否可分解、是否含 monitor 等。这意味着你以为“栈上分配”的对象，在不同 JVM 参数或不同 OpenJDK 版本下，行为可能完全不同。
