JVM内存模型的核心运作规律是：按照线程隔离区与共享区的划分，遵循一套预设的分配、回收与调优规则来管理Java对象的完整生命周期。很多Java开发者被OOM（内存溢出）折磨过，根本原因就是对这块“看不见的地盘”缺乏整体认知，下面用一种拟人化的讲述方式，结合真实操作路径，带你彻底看透JVM内存内部的分工协作。
运行时数据区：JVM的“五口之家”与“两间共享客厅”
JVM的内存模型在《Java虚拟机规范》里有明确定义，主要分为五个区域：程序计数器、虚拟机栈、本地方法栈、堆、方法区，如果把这五个区域比作一个家庭，前三个是“各住各的卧室”，后两个是“全家人共享的客厅和储物间”。
线程私有区：程序计数器、虚拟机栈、本地方法栈
每个线程一诞生,JVM就给它发三张“私人房卡”。
- 程序计数器：这是块极小的内存空间，记录当前线程正在执行的字节码行号，它是唯一不会出现OOM的区域，线程切换后能恢复到正确位置，全指望它。
- 虚拟机栈：这是Java方法执行的内存模型核心，每次方法调用都会创建栈帧，帧里有局部变量表、操作数栈、动态链接、方法出口，你写的每个
int a = 1，Object obj = new Object()，引用都存在这里，栈深度超限就抛StackOverflowError，内存耗尽则抛OOM。 - 本地方法栈：为
native方法服务的区域，HotSpot虚拟机直接把虚拟机栈和本地方法栈合二为一，大多数场景下不需要单独调优。
线程共享区：堆与方法区
这是故事的主战场。
- 堆（Heap）：所有对象实例和数组都在这里分配内存，也是垃圾回收器（GC）主要工作的区域，业内专家指出，JVM调优约70%以上的精力都花在堆上，堆内部又可以细分为新生代（Eden区、两个Survivor区）和老年代，这种分代设计是为了让GC更高效。
- 方法区（Method Area）：存储类元信息、静态变量、常量池，JDK 8之后HotSpot用元空间（Metaspace）取代了永久代，一个重大变化是它使用本地内存而不是JVM堆内存，默认情况下元空间上限只受物理内存限制，所以类元信息加载过多同样可能导致OOM，需要配合
-XX:MaxMetaspaceSize来约束。
表格对比一下JDK 8前后的差异：
| 版本 | 方法区实现 | 内存位置 | 默认上限 |
|---|---|---|---|
| JDK 7 | 永久代 | JVM堆内存 | 有限制，易OOM |
| JDK 8+ | 元空间 | 本地内存 | 物理内存大小 |
对象创建全流程：从new到内存分配的“入住手续”
一次Object obj = new Object()的底层操作，远比一句话复杂，按以下步骤走：
- 类加载检查：JVM收到
new指令后，先去常量池定位类的符号引用，检查类是否已加载、解析、初始化过，没有则先触发类加载。 - 分配内存：类加载完就给对象在堆里“量地皮”，分配方式有两种指针碰撞（内存绝对规整时）和空闲列表（内存碎片化时），因为对象创建频繁，JVM还做了TLAB（线程本地分配缓冲）优化，让每个线程在Eden区先圈一小块私有地盘，减少并发冲突。
- 初始化零值：内存分配好后，JVM将对象字段初始化为零值（数值为0，引用为null），这样才能保证字段不赋值时也能直接使用。
- 设置对象头：记录对象属于哪个类、哈希码、GC分代年龄、锁状态等元数据。
- 执行构造方法：按程序员意愿初始化字段值。
这几个步骤在任何一本JVM书籍或任何一次Java面试怎么回答JVM内存模型的解析中都是标准答案。
内存溢出排查：当“共享客厅”真的挤爆了
堆内存溢出是最常见的故障,JVM内存溢出排查是Java工程师的必修课，当你看到java.lang.OutOfMemoryError: Java heap space异常，按以下路径处理：
- 先用
jmap -dump:format=b,file=heap.bin <pid>导出堆转储快照。 - 用MAT（Memory Analyzer Tool）或VisualVM分析快照，查看支配树确认哪个对象占用最大。
- 重点排查两类问题：持有静态集合导致对象无法回收，以及IO流未关闭导致资源泄漏。
如果是元空间溢出（Metaspace错误），优先关注动态生成代理类、反射或CGLIB增强类的代码，并调大-XX:MaxMetaspaceSize。JVM内存参数调优指南里经常把-Xms和-Xmx设置为相同值，这样能避免堆容量动态伸缩带来的性能抖动。
常见JVM排查命令速查表：
| 场景 | 命令 | 作用 |
|---|---|---|
| 查看堆使用概况 | jstat -gc <pid> 1000 |
每1秒输出一次GC情况 |
| 查看线程状态 | jstack <pid> |
抓取线程dump分析死锁或阻塞 |
| 堆转储快照 | jmap -dump:live,format=b,file=heap.bin <pid> |
仅导出存活对象 |
垃圾回收模型与常见收集器
GC是内存模型里最核心的执行者,新生代垃圾收集频次高、速度快，用的是复制算法；老年代对象存活率高，用标记-清除或标记-整理算法，主流收集器分成两派：
- CMS：曾经的主流，以最短停顿时间为目标的并发收集器，但标记阶段采用标记-清除算法，容易产生内存碎片。
- G1：JDK 9之后的默认垃圾回收器，把堆划分成多个大小相等的Region，可预测停顿时间，整体上规避了CMS的碎片问题。
- ZGC：新一代超低停顿收集器，停顿时间基本控制在10ms以内，适合超大堆（几十GB甚至TB级别）场景。
调优参数方面,JVM内存参数调优指南里常见的组合是：
java -Xms4g -Xmx4g -XX:MaxMetaspaceSize=512m -XX:+UseG1GC -XX:MaxGCPauseMillis=200
这段配置表示初始堆和最大堆均为4GB（避免动态扩容），元空间上限512MB，使用G1收集器，期望GC停顿不超过200毫秒，更进阶的-XX:SurvivorRatio=8表示Eden与Survivor比例为8:1，-XX:NewRatio=2表示新生代与老年代比例为1:2，身为开发者，先把这些跑通，再深究底层。
内存分配策略：对象到底去新生代还是老年代
大多数对象在Eden区诞生,但有几条“破格录取”规则：
- 大对象直接进入老年代，避免大对象在Eden和Survivor之间复制造成性能浪费，用
-XX:PretenureSizeThreshold=1m可以设置大小阈值。 - 长期存活的对象晋升老年代，对象每熬过一次MinorGC，年龄加1，默认到15岁进入老年代（
-XX:MaxTenuringThreshold=15）。 - 动态年龄判定，Survivor区中同龄对象总大小超过一半，大于等于该年龄的对象直接进入老年代，不用等够15岁。
Q&A
问题1：JVM堆内存和栈内存的区别是什么？
堆内存存放所有对象实例,是线程共享的，生命周期跟随GC；栈内存存放方法调用帧和局部变量，是线程私有的，方法结束自动释放，堆内存需要重点调优和排查OOM，栈内存主要在递归过深时出现StackOverflowError。
问题2：经常听说“内存泄漏”和“内存溢出”，这两者是什么关系？
内存泄漏是程序逻辑问题对象已经不被使用了，但GC依然认为其存活，因为还有引用链存在，常见于监听器未移除、ThreadLocal使用不当等场景，内存泄漏积累到一定程度就会触发内存溢出（OOM），排查OOM问题，本质上是在找谁在往里塞无用的对象。
问题3：JDK 8默认堆内存大小是多少？
通常默认初始堆大小为物理内存的1/64，最大堆大小为物理内存的1/4，例如一台16GB内存的服务器，默认最大堆约为4GB，具体数值在不同平台和JVM版本上有差异，不需要刻意记忆，掌握基础规则更重要。
明白了JVM内存模型中各区域的职责边界,再结合参数配置、GC机制，就能在日常开发中做出正确的优化判断，遇到线上故障时，按上面讲的排查步骤操作导出堆栈、分析线程、核查参数，多数情况下都能在很短时间内定位问题根源。