深入理解JVM内存模型(运行时数据区域)

Java虚拟机在执行Java程序的过程中会把它所管理的内存划分为若干个不同的数据区域。这些区域有各自的用途，以及创建和销毁的时间，有的区域随着虚拟机进程的启动而一直存在，有些区域则是依赖用户线程的启动和结束而建立和销毁。根据《Java虚拟机规范》的规定，Java虚拟机所管理的内存将会包括以下几个运行时数据区域，如图所示。

JVM内存模型指的是Java虚拟机在运行时所管理的内存的模型；
Java内存模型指的是Java内存规范概念,实际并不存在。

程序计数器

一句话介绍: 程序控制流的指示器。线程私有。

程序计数器是一块较小的内存空间。它可以看做是当前程序执行所指向的行号指示器。在Java虚拟机的概念模型里，字节码解释器在工作时就是通过改变这个计数器的值来获取下个执行的指令。分支、循环、跳转、异常、线程恢复等基础功能都需要依赖这个计数器来完成。
程序计数器是线程私有的。

Java的线程执行是抢占式的方式，因此在任何一个确定时刻、一个处理器（对于多核处理器而言是一个内核）只会执行一个线程中的指令。为了在线程切换后能够恢复正常运行，每一个线程都需要一个独立的程序计数器。
各个线程的计数器独立工作，互不影响。

如果当前执行的是Java方法，程序计数器记录的是当前执行的指令的地址；
如果当前执行的Native方法，程序计数器的值为空（Undefined）。

程序计数器所在的区域是《Java虚拟机规范》中唯一一个没有规定任何OutOfMemeryError异常的区域。

Java虚拟机栈

一句话介绍：Java方法执行的线程模型。线程私有。

一个Java方法对应一个栈桢；每执行一个方法，Java虚拟机都会创建一个对应的栈桢，用于存在局部变量表、操作数栈、动态连接、方法出口等信息。每一个方法被调用直至执行完毕的过程，就对应一个栈桢从入栈到出栈的过程。

栈桢是方法执行时非常重要的基础数据结构，以后有重点介绍。

在《Java虚拟机规范中》此内存区域规定了两个内存异常：
线程请求的栈深度大于虚拟机所允许的最大深度，则抛出StackOrderFlowError异常；
如果虚拟机支持栈深度动态扩展，则当栈无法进行扩展时，抛出OutOfMemeryError异常。

本地方法栈

一句话介绍：在使用上与Java虚拟机一样，只不过服务于Native方法。

本地方法栈只服务于Native方法，《Java虚拟机规范》对于本地方法栈中的方法使用的语言、使用的方式以及数据结构任何规定。但StackOverFlowError和OutOfMemeryError异常规定和虚拟机栈是一样的。

Java堆

一句话介绍：Java堆是虚拟机管理的最大的一块内存，所有线程共享，虚拟机启动时创建。

在Java的世界里，“几乎”所有的对象实例都在这里分配。《Java虚拟机规范》中对Java堆的描述是：“所有的对象实例以及数组都应该分配在堆内存中”。而我们说的“几乎”是指从现实的角度来看，随着Java技术的发展，已经有一些迹象表明日后可能会出现值类型的支持；即使是现在，由于及时编译器的进步，尤其是逃逸分析技术日渐强大，站上分配、标量替换已经导致一些微妙的变化正在悄然发生。因此，所有的对象实例都分配在堆内存上也渐渐地变得不是那么绝对了。

及时编译器的优化、逃逸分析技术等都是近代Java技术发展的重要里程碑。以后有重点介绍。

从内存回收的角度来看，由于经典的垃圾回收器都是基于分代理论设计的，因此Java堆中经常会出现一些名词：年轻代、老年代、永久代、Eden区、Surviver区等。
在G1垃圾收集器出现之前，由于垃圾收集器都是基于分代理论实现的，需要年轻代、老年代垃圾收集器配合工作，因此以上名词划分非严格意义上来说是正确的。但是随着垃圾收集器技术的发展，从G1垃圾收集器的诞生开始，以上的说法就需要区别对待了！

G1垃圾收集器：垃圾回收技术的重要里程碑，因为它没有采取经典的分代理论而是采取了基于Region理念设计的，这是从底层设计思想上的转变，因此说它是重要里程碑。
没有采取经典的分代理论，并不是说G1垃圾收集中没有年轻代、老年代的说法，以后有重点介绍。

从内存分配的角度来看，通常情况下，对象实例是直接分配在Java堆中的，但分配的方式有两种：指针碰撞、空闲列表。

指针碰撞
假设Java堆内存是绝对规整的，使用过的内存在一边，未使用过的内存在另一边，中间使用一个指示器作为分界点，那么在分配对象内存时，仅仅需要将指示器向未使用的一边挪动与对象实例大小相等的距离即可，这种方式称为“指针碰撞”。

空闲列表
如果已使用内存和未使用内存是交互在一起的，那么就没有办法使用“指针碰撞”的方式来分配内存了，虚拟机必须维护一个列表，用于记录哪些内存是可用的，在分配内存时，从列表中找到可用的内存空间分配给对象实例，并更新列表的可用空间。这种方式就称为“空闲列表”。

Java堆内存大小设置
Java堆既可以被实现成固定大小的，也可以是可扩展的，不过当前主流的Java虚拟机都是按照可扩展来实现的（通过参数-Xmx和-Xms设定）。如果在Java堆中没有内存完成实例分配，并且堆也无法再扩展时，Java虚拟机将会抛出OutOfMemoryError异常。

方法区

一句话介绍：用于存储已被虚拟机加载的类型信息、常量、静态变量、即时编译器编译后的代码缓存等数据。线程共享。

方法区还有一个别名-非堆（Non-Heap）。目的是用于和堆区分开来。

方法区和永久代

在JDK8以前，很多人都将方法区称呼为永久代，将二者混为一谈。其实方法区和永久代本质上是完全不同的概念。永久代的概念是在JDK8以前，HotSpot虚拟机实现方法区的一种方式。目的是为了将分代垃圾收集扩展时方法区从而省去为专门为方法区的内存管理的代码工作。但是其他虚拟机入：J9、JRockit等就没有永久代的概念。

回过头来看，HotSpot虚拟机采用永久代来实现方法区并不是一个好主意，这种设计导致了方法区大小受限（永久代有-XX：MaxPermSize的上限），同时使得Java应用更容易出现内存溢出的风险。因此到了JDK8，HotSpot虚拟机完全放弃了永久代，与J9、JRockit虚拟机一样，采用元空间（Meta Data）来代替。

方法区的垃圾回收

《JVM虚拟机规范》对方法区的约束是非常宽松的。除了和Java堆一样不需要连续的内存和可以选择固定大小或者可扩展外，甚至还可以选择不实现垃圾收集。
事实上，垃圾收集在这个区域的的效果是非常不理想的，尤其是类型的卸载，条件是非常苛刻的。但是对这个区域的收回也是有一定的必要性（Sun公司的Bug列表证实了这一点）。很纠结！

类型回收的条件：
1.当前类型已经没有任何实例存在；
2.当前类型的类加载器已经被卸载；
3.当前类型的Class对象没有被任何地方使用。
要同时满足以上三个条件，真的很难，尤其是第二条。

运行时常量池

一句话介绍：运行时常量池是方法区中的一部分，用于存储Class文件编译手产生的给中符号引用和字面量。

运行时常量池相对于Class文件常量池的另外一个重要特征是具备动态性，Java语言并不要求常量一定只有编译期才能产生，也就是说，并非预置入Class文件中常量池的内容才能进入方法区运行时常量池，运行期间也可以将新的常量放入池中，这种特性被开发人员利用得比较多的便是String类的intern()方法。
既然运行时常量池是方法区的一部分，自然受到方法区内存的限制，当常量池无法再申请到内存时会抛出OutOfMemoryError异常。

直接内存

在JDK 1.4中新加入了NIO（New Input/Output）类，引入了一种基于通道（Channel）与缓冲区（Buffer）的I/O方式，它可以使用Native函数库直接分配堆外内存，然后通过一个存储在Java堆里面的DirectByteBuffer对象作为这块内存的引用进行操作。这样能在一些场景中显著提高性能，因为避免了在Java堆和Native堆中来回复制数据。

一般服务器管理员配置虚拟机参数时，会根据实际内存去设置-Xmx等参数信息，但经常忽略掉直接内存，使得各个内存区域总和大于物理内存限制（包括物理的和操作系统级的限制），从而导致动态扩展时出现OutOfMemoryError异常。

总结

到这里，Java虚拟机运行时的数据区域（JVM内存模型）就学习完毕。

参考文章
《深入理解Java虚拟机：JVM高级特性与最佳实践》
特别说明：本文没有任何商业目的，仅供交流。