本文摘自深入理解 Java 虚拟机第三版
概述
Java 虚拟机在执行 Java 程序的过程中会把它所管理的内存划分为若干个不同的数据区域，这些区域有各自的用途，以及创建和销毁的时间，有的区域随着虚拟机进程的启动而一直存在，有的区域则是依赖用户线程的启动和结束而创建和销毁。因此，我们可以根据这个特点将区域划为为线程公有区域和线程私有区域两部分
程序计数器
程序计数器（Program Counter Register）是一块较小的内存空间，可以看作是当前线程所执行的字节码的行号指示器。字节码解释器通过改变计数器的值来选取下一条需要执行的字节码指令，程序的执行流程都依赖该计数器来完成
由于 Java 虚拟机的多线程是通过线程切换、分配处理器执行时间的方式来执行的，在任一时刻，一个处理器只能执行一条线程中的指令。为了保证线程切换后能恢复到原来正在执行的位置，每条线程都需要有一个独立的程序计数器。因此程序计数器是线程私有的，各个线程之间的计数器互不影响，独立存储
如果线程正在执行的是一个 Java 方法，计数器记录的就是正在执行的虚拟机字节码指令的地址；如果执行的是本地方法，则计数器对应的值为空。程序计数器是唯一一个在 Java 虚拟机规范中没有规定 OutOfMemoryError 情况的区域，至于为什么，可以看看下面的官方解释：
The Java Virtual Machine's pc register is wide enough to hold a returnAddress or a native pointer on the specific platform
翻译过来就是：Java 虚拟机的 pc 寄存器足够宽，可以在特定平台上保存 returnAddress 或本机指针。也就是说，程序计数器存储的只是一个值，这个值指向下一条要执行的指令的位置，而这个值不可能超过 pc 寄存器的范围，自然也就不存在内存溢出的问题了
Java 虚拟机栈
Java 虚拟机栈（Java Virtual Machine Stack）也是线程私有的，其描述的是 Java 方法执行的线程内存模型：每个方法被执行时，Java 虚拟机都会同步创建一个栈帧（Stack Frame）用于存储局部变量表、操作数栈、动态连接、方法出口等信息。每个方法被调用直至执行完毕的过程，就对应着一个栈帧从入栈到出栈的过程
局部变量表存放了编译器可知的各种 Java 虚拟机基本数据类型、对象引用以及 returnAddress（指向了一条字节码指令的地址）。这些数据类型在局部变量表中的存储空间以局部变量槽（Slot）来表示，其中 64 位的 long 和 double 类型会占用两个 Slot，其余只占一个。局部变量表所需的内存空间是在编译期就完成分配的，运行期间不会改变局部变量表的大小，这里的大小指的是 Slot 的数量，至于一个 Slot 占用多少空间，则是由虚拟机自行决定的事情
在 Java 虚拟机规范中，对这个内存区域规定了两类异常状况：如果线程请求的栈深度大于虚拟机所允许的深度，将抛出 StackOverflowError 异常；如果 Java 虚拟机栈容量可以动态扩展，则当栈扩展无法申请足够的内存时会抛出 OutOfMemoryError 异常（HotSpot 虚拟机是无法动态扩展的，因此只有当线程请求栈空间失败时才会抛出 OOM 异常）
本地方法栈
本地方法栈（Native Method Stacks）与虚拟机栈的作用是类似的，其区别只是虚拟机栈为虚拟机执行 Java 方法服务，而本地方法栈则是为虚拟机执行本地方法服务，本地方法栈也是线程私有的
Java 虚拟机规范对本地方法栈所使用的语言、使用方式、数据结构并没有强制规定，具体的虚拟机可以根据需要自由实现。HotSpot 虚拟机直接就把本地方法栈和虚拟机栈合二为一。与虚拟机栈一样，本地方法栈也会抛出 StackOverflowError 和 OutOfMemoryError 异常
Java 堆
Java 堆（Heap）是虚拟机所管理的内存中最大的一块内存区域，被所有线程共享，此区域的唯一目的就是存放对象实例，几乎所有的对象实例都在这里分配内存
Java 堆是垃圾收集器管理的内存区域，所以从内存回收的角度来看，由于现代垃圾收集器大部分都基于分代收集理论设计，所以 Java 堆中经常出现“新生代”、“老年代”、“永久代”、“Eden 空间”、“From Survivor 空间”、“To Survivor 空间”等名词。在这里要指明的是，这些区域仅仅是一部分垃圾收集器的共同特性或者说设计风格而已，并非某个 Java 虚拟机具体实现的内存布局
根据 Java 虚拟机规范规定，Java 堆可以处于物理上不连续的内存空间，但在逻辑上必须视为连续。但对于大对象（如数组对象），多数虚拟机出于实现简单、存储高效的考虑，很有可能会要求连续的数组
Java 堆既可以被实现成固定大小，也可以是可扩展的（通过参数 -Xmx 和 -Xms 设定），如果没有内存可分配给实例，并且堆也无法再扩展时，会抛出 OutOfMemoryError 异常
方法区
方法区（Method Area）与 Java 堆一样，也是线程共享区域，用于存储已被虚拟机加载的类型信息、常量、静态变量、即时编译器编译后的代码缓存等数据。虽然在 Java 虚拟机规范中把方法区描述为堆的一个逻辑部分，但是它还有一个别名叫作“非堆”，目的就是与 Java 堆区分开来
如何实现方法区取决于虚拟机的具体实现，并不受 Java 虚拟机规范管束。对于 HotSpot 虚拟机，JDK8 以前方法区是使用永久代实现的，永久代属于 JVM 运行时内存区域的一部分，这样使得 HotSpot 的垃圾收集器能像管理 Java 堆一样管理这部分内存
但现在回头看，使用永久代实现方法区并不是一个好主意，这会导致 Java 应用更容易遇到内存溢出的问题，为此我们需要设置 -XX:MaxPermSize 的上限。在 JDK6 的时候 HotSpot 的开发团队就有放弃永久代，采用本地内存（Native Memory）来实现方法区的计划（这样只要不触碰到机器内存上限就不会溢出）。从 JDK7 开始，已经把原来放在永久代的字符串常量池、静态变量等移出，到了 JDK8，终于完全废弃永久代的概念，采用本地内存实现的元空间（Meta-Space）来替代，把 JDK7 中永久代还剩余的内容（主要是类型信息）全部移到元空间
和 Java 堆一样，方法区除了可以不需要连续的内存和可以选择固定大小或可扩展外，甚至可以选择不实现垃圾收集。相对而言，垃圾收集行为在这个区域比较少出现，但并不意味着不需要垃圾收集，这个区域的内存回收目标主要是针对常量池的回收和类型的卸载。根据 Java 虚拟机规定，如果方法区无法满足新的内存分配需求，将抛出 OutOfMemoryError 异常
运行时常量池
运行时常量池（Runtime Constant Pool）是方法区的一部分。Class 文件中除了有类的版本、字段、方法、接口等描述信息外，还有一项信息是常量池表（Constant Pool Table），用于存放编译期生成的各种字面量和符号引用，这部分内容将在类加载后存放到方法区的运行时常量池中
对于运行时常量池，Java 虚拟机规范并没有做任何细节的要求，不同的虚拟机可以根据需要来自主实现。一般来说，除了保存 Class 文件中描述的符号引用外，还会把由符号引用翻译出来的直接引用也存储在运行时常量池
运行时常量池相对于 Class 文件常量池的一个重要特征就是具备动态性，Java 语言并不要求常量一定只能在编译期才能产生，也就是说，并非预置入 Class 文件常量池的内容才能进入方法区运行时常量池，运行期间也可以将新的常量放入池中，用得最多的便是 String 类的 intern() 方法
直接内存
直接内存（Direct Memory）并不是虚拟机运行时数据区的一部分，但这部分也被频繁使用，也可能导致 OutOfMemoryError 异常
在 JDK1.4 新加入了 NIO 类，这是一种基于通道（Cancel）与缓冲区（Buffer）的 I/O 方式，可以使用 Native 函数直接分配堆外内存，然后通过一个存储在 Java 堆中 DirectByteBuffer 对象作为这块内存的引用进行操作，既能提高性能，还避免了 Java 堆和直接内存的频繁交换数据
本机直接内存的分配虽然不受 JVM 限制，但还是会受本机内存大小以及处理器寻址空间的限制。服务器管理员配置虚拟机参数时，同时也要考虑直接内存的因素，来设置合理的 -Xmx 等参数信息
相关文章
