想知道 Java 程序为什么会突然崩溃？为什么同样的代码，别人跑起来流畅，你却频繁 OOM？其实，这些问题大多与 JVM 运行时内存区域的 “运作逻辑” 有关。

理解 JVM 内存结构，是掌握 Java 程序运行机制、做好性能调优和故障排查的核心。今天，我们就来系统拆解 JVM 运行时的内存区域，帮你从根源上搞懂它！

先看一张图：JVM 内存区域全景

一、线程私有的内存区域

每个线程创建时，都会 “自带” 以下内存区域，生命周期与线程一致，线程结束后自动销毁。

1. 程序计数器（Program Counter Register）

• 作用
• 相当于线程执行的 “书签”，记录当前线程正在执行的字节码行号。字节码解释器通过修改它的值，确定下一条要执行的指令（比如分支、循环、异常处理等都依赖它）。
• 特点
• 线程私有，各线程的计数器互不干扰。
• 是《Java 虚拟机规范》中唯一没有规定 OutOfMemoryError 的区域（永远不会内存溢出）。

2. Java 虚拟机栈（Java Virtual Machine Stack）

• 作用
• 描述 Java 方法执行的内存模型。每个方法调用时，会创建一个 “栈帧”（方法的 “运行状态快照”），入栈执行；方法结束后，栈帧出栈。
• 栈帧的构成
• 局部变量表：存放基本数据类型（int、boolean 等）、对象引用（类似指针）、returnAddress 类型（指向字节码指令地址）。
• 操作数栈：用于方法执行中的计算（比如 iadd 指令会弹出栈顶两个元素相加，再压回结果）。
• 动态链接：指向运行时常量池中该方法的引用，将符号引用转为直接引用（方法调用的关键）。
• 方法返回地址：记录调用者的程序计数器值，确保方法结束后能回到正确位置。
• 异常
• StackOverflowError：线程请求的栈深度超过虚拟机允许值（比如无限递归）。
• OutOfMemoryError：虚拟机栈动态扩展时，无法申请到足够内存。

3. 本地方法栈（Native Method Stack）

• 作用
• 与虚拟机栈类似，但为 Native 方法（如 C/C++ 编写的方法）服务。
• 特点
• HotSpot 虚拟机直接将本地方法栈与虚拟机栈合并，不再单独区分。
• 异常
• 同样会抛出 StackOverflowError 和 OutOfMemoryError。

二、线程共享的内存区域

所有线程共享这些区域，随虚拟机启动而创建，随虚拟机退出而销毁。

1. 堆（Heap）

• 作用
• Java 世界的 “对象仓库”，几乎所有对象实例和数组都在这里分配内存。也是垃圾收集器（GC）的主要工作区域，因此常被称为 “GC 堆”。
• 划分（从 GC 角度）
• 新生代：新对象先在这里 “安家”，包括 Eden 区（新对象首选）和 Survivor 区（S0、S1，存放 Minor GC 后存活的对象，总有一个为空）。
• 老年代：存放 “长寿对象”（多次 GC 后仍存活的对象）。
• 异常
• OutOfMemoryError（堆中无法分配新实例，且无法扩展时抛出，常见于内存泄漏或堆空间设置过小）。

2. 方法区（Method Area）

• 作用
• 存储已加载的类信息（版本、字段、方法等）、常量、静态变量、即时编译器编译后的代码缓存等。
• 实现差异
• JDK 8 之前：称为 “永久代”（PermGen），受 JVM 内存限制。
• JDK 8 及以后：改为 “元空间”（Metaspace），使用本地内存（不受 JVM 内存限制，但受物理内存限制）。
• 运行时常量池
• 方法区的一部分，存储 Class 文件中的字面量和符号引用（类加载后进入此处）。
• 异常
• OutOfMemoryError（方法区 / 元空间无法分配内存时抛出，JDK8 前常见 “PermGen space” 错误，元空间中则因物理内存不足导致）。

总结：一张表理清所有区域

补充：直接内存（Direct Memory）

它不是 JVM 规范定义的内存区域，但频繁被使用（如 NIO），也可能导致 OOM。

• 来源：JDK 1.4 引入的 NIO 通过 Native 函数库直接分配堆外内存，用 Java 堆中的 DirectByteBuffer 对象引用操作。
• 优势：避免 Java 堆与 Native 堆之间的数据复制，提升性能。
• 异常：受本机总内存限制，若各区域内存总和超过物理内存，会抛出 OutOfMemoryError。

理解 JVM 内存区域，就像掌握了 Java 程序的 “解剖图”。无论是排查 OOM 故障，还是优化 GC 性能，都能从这里找到突破口。希望这篇文章能帮你彻底搞懂 JVM 的 “内存逻辑”！

（如果觉得有用，欢迎点赞 + 转发，让更多 Java 开发者少走弯路～）