JVM内存结

JVM内存结构

 

首先JVM运行于操作系统之上，JVM需要的所有内存当然申请自操作系统。同时JVM在执行Java程序的过程中会将它从操作系统申请的内存根据“用途以及创建和销毁的时间”划分为多个不同的区域。这些区域如下图所示：

一、程序计数器

程序计数器就是一块较小的内存空间，可以将程序计数器理解为指向“当前线程Java代码的指令的指针”。子解码解释器工作时工作改变改变这个计数器的值来选取下一条要执行的字节码指令。

每个线程都有独立的程序计数器，因为多个线程“并发执行”是通过线程轮流切换并分配处理器执行时间的方式实现的。任何一个时刻一个处理器只会执行一个线程中的指令。因此为了线程切换后能恢复到之前正确的执行位置，每个线程都需要独立的程序计数器。

该计数器仅记录执行的虚拟机字节码的指令地址，如果执行的Native方法则不作记录。

二、Java虚拟机栈

Java虚拟机栈也是线程私有，它描述的是Java方法执行的内存模型：方法执行前有个一“栈帧”入栈，方法执行完后这个“栈帧”出栈，“栈帧”是一个内存块，存放的是有关方法和运行期数据的数据集，“栈帧”包含三类数据：

l  本地变量（LocalVariables），包括输入参数和输出参数以及方法内的变量；

l  栈操作（Operand Stack），记录出栈、入栈的操作；

l  栈帧数据（FrameData），包括类文件、方法

如下图所示：

         “栈帧”遵循如下使用规则：

                   设有三个方法：方法A、方法B。

                   A方法先被调用，那么随即产生一个“栈帧”被压入栈底，如下图：

                  

                   A方法里面调用B方法,B方法产生的“栈帧”再次被压入栈，但是压入到栈顶，如下图：

                  

                   当B方法执行完成后，“B方法栈帧”自动出栈，这时栈顶指针指向的是“A方法栈帧”，如下图：

                  

当A方法再次执行完成后，“A方法栈帧”也出栈：

到此为止，栈已经得到释放。所以对栈内存来说不存在垃圾回收，线程执行完成后，栈就被自动释放掉了。

在这个内存区域有两种异常情况：

         线程请求的栈深度大于虚拟机说允许的深度，将抛出“StackOverflowError”异常；

         如果虚拟机栈可以动态扩展，当扩展到无法申请到足够内存是会跑出OutOfMemoryError异常。

三、本地方法栈

Java虚拟机栈为执行Java方法(字节码)服务，而本地方法栈则是为Java使用到的Native方法服务。HotSpot虚拟机直接把本地方法栈和虚拟机栈合二为一。

与Java虚拟机栈一样，该区域也可能会抛出“StackOverflowError和OutOfMemoryError”异常。

四、Java堆

Java堆是JVM管理的内存中最大的一块。它被所有线程共享，几乎所有的对象实例以及数组都要在堆上分配。

Java堆是垃圾收集器管理的主要区域，故又称GC堆。现在的收集器基本都采用分代收集算法，所有Java堆具体细分为：新生代和老年代和永久代，新生代又细分为Eden、Survivor。如下图所示：

l  新生代[Young Generation Space]：

         新生区是类的诞生、成长、消亡的区域，一个对象在这里产生，最后被垃圾回收器收集，结束生命。新生代又分为两部分：伊甸区（Eden space）和幸存者区（Survivor pace），所有的对象都是在伊甸区被分配[new]。幸存区有两个：0区（Survivor 0 space）和1区（Survivor 1 space）。当伊甸区的空间用完时，程序又需要创建对象，JVM的垃圾回收器将对伊甸区进行垃圾回收，将伊甸区中的不再被其他对象所引用的对象进行销毁。然后将伊甸区中的剩余对象移动到幸存0区。若幸存0区也满了，再对该区进行垃圾回收，然后移动到1区。那如果1区也满了呢？再移动到养老区。

l  老年代[Tenure Generation Space]：

         养老区用于保存从新生区筛选出来的JAVA对象，一般池对象都在这个区域活跃。

l  永久代[Permanent Space]：

对于很多虚拟机来说，本身没有永久代这个概念的(比如BEA JRockit、IBM J9等)，对于HotSpot虚拟机，很多人愿意把方法区成为永久代，但两者并不等价，仅仅是因为HotSpot虚拟机的设计团选择吧GC分代收集扩展至方法区，或者说使用永久代来实现方法区而已。

因此这个区域的主要内容是存储以被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。

Java堆在实现时，既可以实现成固定大小的，也可以是可扩展的，可以通过以下两个虚拟机参数来控制：

         -Xms:最小堆内存[堆内存分配初始大小]

         -Xmx:最大堆内存[堆内存可以扩展的大小]

如果在堆中没有内存完成实例分配，并且堆也无法在扩展是，将会抛出OutOfMemoryError异常。

五、方法区

如同上面第四条说描述，在HotSpot虚拟机上的开发者习惯吧方法区称为“永久代”。这个区域的主要内容是存储以被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。Java虚拟机规范把方法区描述为堆的一个逻辑部分，但是它却有一个别名叫做“非堆”。

这个区域可以选择不实现垃圾收集。相对而言，垃圾收集行为在这个区域是比较少见的。但并非“永久代”名字一样就永久存在。这个区域的内存回收目标主要是针对常量池的回收和对类型的卸载，但是“回收成绩”难以令人满意，比如类型卸载，条件相当苛刻。

方法区无法满足内存分配需求是，将抛出OutOfMemoryError异常。

六、运行时常量池

从上面的图中明白，首先运行时常量池是方法区的一部分。Class文件中除了类的版本、字段、方法、接口等信息外，还有一项信息是常量池(Constant Pool Table)，用于存放编译期间生成的各种字面量和符号应用，这部分内容将在类加载后存放到方法区的运行时常量池中。

运行时常量池相对于Class文件常量池的另外一个重要特征是具备动态性，常量不一定只能在编译器产生，也就是并非预置入Class文件中常量池的内容才能进入方法区运行时常量池，运行期间也可能将新的常量放入池中，比如：String类的intern()方法。

常量池无法申请到内存时会抛出OutOfMemoryError异常。

七、直接内存

这部分内存不是虚拟机的运行时数据区的一部分，但是这部分内存也被频繁使用，在JDK1.4后引入的NIO类，他可以使用Native函数库直接分配对外内存，然后通过存储在Java堆里面的DirectBuffer对象作为这块内存的应用进行操作，这样避免了再Java堆和Native堆中来回复制数据，显著提高了性能。

由于直接内存来自操作系统，它的分配不会受到Java堆大小的限制，但是仍然受到本机总内存(物理内存+SWAP分区/分页文件)的大小及处理器寻址空间的限制。配置虚拟机参数时，根据实际内存设置-Xmx参数信息，经常会会略掉直接内存，使得各个内存区域的总和大于物理内存限制(包括物理内存和虚拟内存)，从而导致动态扩展是出现OutOfMemeoryError异常。