【转】JVM虚拟机内存模型

转发声明：

本文原创作者：书呆子Rico 
作者博客地址：http://blog.csdn.net/justloveyou_/

摘要：

　　我们都知道，Java程序在执行前首先会被编译成字节码文件，然后再由Java虚拟机执行这些字节码文件从而使得Java程序得以执行。事实上，在程序执行过程中，内存的使用和管理一直是值得关注的问题。Java虚拟机在执行Java程序的过程中会把它所管理的内存划分为若干个不同的数据区域，这些数据区域都有各自的用途，以及创建和销毁的时间，并且它们可以分为两种类型：线程共享的方法区和堆，线程私有的虚拟机栈、本地方法栈和程序计数器。在此基础上，我们探讨了在虚拟机中对象的创建和对象的访问定位等问题，并分析了Java虚拟机规范中异常产生的情况。

　　本文内容是基于 JDK 1.6 的，不同版本虚拟机之间也许会有些许差异，但不影响我们对JVM 内存模型的整体把握和了解。

　　关于JVM垃圾回收机制的更多内容，请移步我的博文《 Java 垃圾回收机制概述》。

一. Java 虚拟机内存模型

　　Java虚拟机在执行Java程序的过程中会把它所管理的内存划分为若干个不同的数据区域，这些数据区域可以分为两个部分：一部分是线程共享的，一部分则是线程私有的。其中，线程共享的数据区包括方法区和堆，线程私有的数据区包括虚拟机栈、本地方法栈和程序计数器。如下图所示：

　　线程私有的数据区 包括 程序计数器、 虚拟机栈 和 本地方法栈 三个区域，它们的内涵分别如下：

　　我们知道，线程是CPU调度的基本单位。在多线程情况下，当线程数超过CPU数量或CPU内核数量时，线程之间就要根据 时间片轮询抢夺CPU时间资源。也就是说，在任何一个确定的时刻，一个处理器都只会执行一条线程中的指令。因此，为了线程切换后能够恢复到正确的执行位置，每条线程都需要一个独立的程序计数器去记录其正在执行的字节码指令地址。

　　因此，程序计数器是线程私有的一块较小的内存空间，其可以看做是当前线程所执行的字节码的行号指示器。如果线程正在执行的是一个 Java 方法，计数器记录的是正在执行的字节码指令的地址；如果正在执行的是 Native 方法，则计数器的值为空。

　　程序计数器是唯一一个没有规定任何 OutOfMemoryError 的区域。

　　虚拟机栈描述的是Java方法执行的内存模型，是线程私有的。每个方法在执行的时候都会创建一个栈帧，用于存储局部变量表、操作数栈、动态链接、方法出口等信息，而且 每个方法从调用直至完成的过程，对应一个栈帧在虚拟机栈中入栈到出栈的过程。其中，局部变量表主要存放一些基本类型的变量（int, short, long, byte, float, double, boolean, char）和 对象句柄，它们可以是方法参数，也可以是方法的局部变量。

　　虚拟机栈有两种异常情况：StackOverflowError 和 OutOfMemoryError。我们知道，一个线程拥有一个自己的栈，这个栈的大小决定了方法调用的可达深度（递归多少层次，或嵌套调用多少层其他方法，-Xss 参数可以设置虚拟机栈大小），若线程请求的栈深度大于虚拟机允许的深度，则抛出 StackOverFlowError 异常。此外，栈的大小可以是固定的，也可以是动态扩展的，若虚拟机栈可以动态扩展（大多数虚拟机都可以），但扩展时无法申请到足够的内存(比如没有足够的内存为一个新创建的线程分配栈空间时)，则抛出 OutofMemoryError 异常。下图为栈帧结构图：

3)、本地方法栈

　　本地方法栈与Java虚拟机栈非常相似，也是线程私有的，区别是虚拟机栈为虚拟机执行 Java 方法服务，而本地方法栈为虚拟机执行 Native 方法服务。与虚拟机栈一样，本地方法栈区域也会抛出 StackOverflowError 和 OutOfMemoryError 异常。

　　线程共享的数据区 具体包括 Java堆 和 方法区 两个区域，它们的内涵分别如下：

　　Java 堆的唯一目的就是存放对象实例，几乎所有的对象实例（和数组）都在这里分配内存。Java堆是线程共享的，类的对象从中分配空间，这些对象通过new、newarray、 anewarray 和 multianewarray 等指令建立，它们不需要程序代码来显式的释放。

　　由于Java堆唯一目的就是用来存放对象实例，因此其也是垃圾收集器管理的主要区域，故也称为称为 GC堆。从内存回收的角度看，由于现在的垃圾收集器基本都采用分代收集算法，所以为了方便垃圾回收Java堆还可以分为 新生代 和 老年代 。新生代用于存放刚创建的对象以及年轻的对象，如果对象一直没有被回收，生存得足够长，对象就会被移入老年代。新生代又可进一步细分为 eden、survivorSpace0 和 survivorSpace1。刚创建的对象都放入 eden，s0 和 s1 都至少经过一次GC并幸存。如果幸存对象经过一定时间仍存在，则进入老年代。更多关于Java堆和分代收集算法的介绍，请移步我的博文《Java 垃圾回收机制概述》。下图给出了Java堆的结构图：

　　注意，Java堆可以处于物理上不连续的内存空间中，只要逻辑上是连续的即可。而且，Java堆在实现时，既可以是固定大小的，也可以是可拓展的，并且主流虚拟机都是按可扩展来实现的（通过-Xmx(最大堆容量) 和 -Xms(最小堆容量)控制）。如果在堆中没有内存完成实例分配，并且堆也无法再拓展时，将会抛出 OutOfMemoryError 异常。
　　 　　
(1)、TLAB (Thread Local Allocation Buffer，线程私有分配缓冲区)

　　Sun Hotspot JVM 为了提升对象内存分配的效率，对于所创建的线程都会分配一块独立的空间 TLAB，其大小由JVM根据运行的情况计算而得。在TLAB上分配对象时不需要加锁(相对于CAS配上失败重试方式 )，因此JVM在给线程的对象分配内存时会尽量的在TLAB上分配，在这种情况下JVM中分配对象内存的性能和C基本是一样高效的，但如果对象过大的话则仍然是直接使用堆空间分配。

　　在下文中我们提到，虚拟机为新生对象分配内存时，需要考虑修改指针 (该指针用于划分内存使用空间和空闲空间) 时的线程安全问题，因为存在可能出现正在给对象A分配内存，指针还未修改，对象B又同时使用原来的指针分配内存的情况。TLAB 的存在就是为了解决这个问题：每个线程在Java堆中预先分配一小块内存 TLAB，哪个线程需要分配内存就在自己的TLAB上进行分配，若TLAB用完并分配新的TLAB时，再加同步锁定，这样就大大提升了对象内存分配的效率。

　　方法区与Java堆一样，也是线程共享的并且不需要连续的内存，其用于存储已被虚拟机加载的 类信息、常量、静态变量、即时编译器编译后的代码等数据。方法区通常和永久区(Perm)关联在一起，但永久代与方法区不是一个概念，只是有的虚拟机用永久代来实现方法区，这样就可以用永久代GC来管理方法区，省去专门内存管理的工作。根据Java虚拟机规范的规定，当方法区无法满足内存分配的需求时，将抛出 OutOfMemoryError 异常。

(1)、运行时常量池

　　运行时常量池（Runtime Constant Pool）是方法区的一部分，用于存放编译期生成的各种 字面量 和 符号引用。其中，字面量比较接近Java语言层次的常量概念，如文本字符串、被声明为final的常量值等；而符号引用则属于编译原理方面的概念，包括以下三类常量：类和接口的全限定名、字段的名称和描述符 和 方法的名称和描述符。因为运行时常量池（Runtime Constant Pool）是方法区的一部分，那么当常量池无法再申请到内存时也会抛出 OutOfMemoryError 异常。

　　运行时常量池相对于Class文件常量池的一个重要特征是具备动态性。Java语言并不要求常量一定只有编译期才能产生，运行期间也可能将新的常量放入池中，比如字符串的手动入池方法intern()。

　　Java堆是 Java代码可及的内存，是留给开发人员使用的；而非堆（Non-Heap）是JVM留给自己用的，所以方法区、JVM内部处理或优化所需的内存 (如JIT编译后的代码缓存)、每个类结构 (如运行时常量池、字段和方法数据)以及方法和构造方法的代码都在非堆内存中。

　　方法区的内存回收目标主要是针对 常量池的回收 和 对类型的卸载。回收废弃常量与回收Java堆中的对象非常类似。以常量池中字面量的回收为例，假如一个字符串“abc”已经进入了常量池中，但是当前系统没有任何一个String对象是叫做“abc”的，换句话说是没有任何String对象引用常量池中的“abc”常量，也没有其他地方引用了这个字面量，如果在这时候发生内存回收，而且必要的话，这个“abc”常量就会被系统“请”出常量池。常量池中的其他类（接口）、方法、字段的符号引用也与此类似。

　　判定一个常量是否是“废弃常量”比较简单，而要判定一个类是否是“无用的类”的条件则相对苛刻许多。类需要同时满足下面3个条件才能算是“无用的类”：

• 该类所有的实例都已经被回收，也就是Java堆中不存在该类的任何实例；
• 加载该类的ClassLoader已经被回收；
• 该类对应的 java.lang.Class 对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。

  　　虚拟机可以对满足上述3个条件的无用类进行回收(卸载)，这里说的仅仅是“可以”，而不是和对象一样，不使用了就必然会回收。特别地，在大量使用反射、动态代理、CGLib等bytecode框架的场景，以及动态生成JSP和OSGi这类频繁自定义ClassLoader的场景都需要虚拟机具备类卸载的功能，以保证永久代不会溢出。

二. Java对象在虚拟机中的创建与访问定位

　　Java是一门面向对象的编程语言，在Java程序运行过程中无时无刻都有对象被创建和使用。在此，我们以最流行的HotSpot虚拟机以及常用的内存区域Java堆为例来探讨在虚拟机中对象的创建和对象的访问等问题。

　　(1). 检查虚拟机是否加载了所要new的类，若没加载，则首先执行相应的类加载过程。虚拟机遇到new指令时，首先去检查这个指令的参数是否能在常量池中定位到一个类的符号引用，并且检查这个引用代表的类是否已经被加载、解析和初始化过。

• 指针碰撞：如果Java堆中内存绝对规整，所有用过的内存放在一边，空闲内存放在另一边，中间一个指针作为分界点的指示器，那分配内存就仅仅是把那个指针向空闲空间那边挪动一段与对象大小相同的距离。
• 空闲列表：如果Java堆中内存并不规整，那么虚拟机就需要维护一个列表，记录哪些内存块是可用的，以便在分配的时候从列表中找到一块足够大的空间划分给对象实例，并更新列表上的记录。

• 对分配内存空间的动作进行同步处理：采用CAS+失败重试的方式保证更新操作的原子性；
• 把内存分配的动作按照线程划分的不同的空间中：每个线程在Java堆中预先分配一小块内存，称为本地线程分配缓冲（TLAB），哪个线程要分配内存，就在自己的TLAB上分配，如果TLAB用完并分配新的TLAB时，再加同步锁定。

　　创建对象是为了使用对象，我们的Java程序通过栈上的reference数据来操作堆上的具体对象。在虚拟机规范中，reference类型中只规定了一个指向对象的引用，并没有定义这个引用使用什么方式去定位、访问堆中的对象的具体位置。目前的主流的访问方式有使用句柄访问和直接指针访问两种。

• 句柄访问：Java堆中会划分出一块内存作为句柄池，栈中的reference指向对象的句柄地址，句柄中包含了对象实例数据和类型数据各自的具体地址信息，如下图所示。

  　　　　　　　　　　

• 直接指针访问：reference中存储的就是对象地址。

  　　　　　　　　　　

三. 内存异常产生情况分析

1、Java堆溢出 (OOM)

　　Java堆用于存储对象的实例，只要不断地创建对象，并且保证GC roots到对象之间有可达路径来避免垃圾回收机制清除这些对象，那么在对象数量到达最大堆的容量限制后就会产生内存溢出异常。如下所示，

public class Test {

public static void main(String[] args){
        List list=new ArrayList();   // 持有“大对象”的引用，防止垃圾回收
        while(true){
            int[] tmp = new int[10000000];  // 不断创建“大对象”
            list.add(tmp);
        }
    }
}

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10

　　要解决这个异常，一般先通过内存映像分析工具对堆转储快照分析，确定内存的对象是否是必要的，即判断是 内存泄露 还是 内存溢出。如果是内存泄露，可以进一步通过工具查看泄露对象到GC Roots的引用链，比较准确地定位出泄露代码的位置。如果是内存溢出，可以调大虚拟机堆参数，或者从代码上检查是否存在某些对象生命周期过长的情况。

(1). SOF

　　如果线程请求的栈深度大于虚拟机栈允许的最大深度，将抛出StackOverflowError异常。我们知道，每当Java程序启动一个新的线程时，Java虚拟机会为它分配一个栈，并且Java虚拟机栈以栈帧为单位保持线程运行状态。每当线程调用一个方法时，JVM就压入一个新的栈帧到这个线程的栈中，只要这个方法还没返回，这个栈帧就存在。 那么可以想象，如果方法的嵌套调用层次太多，比如递归调用，随着Java虚拟机栈中的栈帧的不断增多，最终很可能会导致这个线程的栈中的所有栈帧的大小的总和大于-Xss设置的值，从而产生StackOverflowError溢出异常。看下面的栗子：

public class Test {

    public static void main(String[] args) {
          method();
    }

    // 递归调用导致 StackOverflowError
    public static void method(){
        method();
    }
}

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11

　　上面的SOF异常就是由递归引起的，具体而言就是因为method()方法中没有递归终止条件，从而使得该方法不断递归调用、不断创建栈帧导致的。

　　如果虚拟机在拓展栈时无法申请到足够的内存空间，则抛出OutOfMemoryError异常。在虚拟机栈和本地方法栈发生OOM异常场景如下：当Java 程序启动一个新线程时，若没有足够的空间为该线程分配Java栈(一个线程Java栈的大小由-Xss设置决定)，JVM将抛出OutOfMemoryError异常。

　　运行时常量池溢出的情况： String.intern()是一个native方法，在JDK1.6及之前的版本中，它的作用是：如果字符串常量池中已经包含一个等于此String对象的字符串，则返回代表池中这个字符串的String对象，否则将此String对象包含的字符串添加到常量池中，并且返回此String对象的引用。由于常量池分配在永久代中，如果不断地使用intern方法手动入池字符串，则会抛出OutOfMemoryError异常。但在JDK1.7及其以后的版本中，对intern（）方法的实现作了进一步改进，其不会再复制实例到常量池中，而仅仅是在常量池中记录首次出现的实例的引用。看下面的例子（在JDK1.7中运行），

public class Test {
    public static void main(String[] args) {  

        String str1 = new StringBuilder("计算机").append("软件").toString();
        System.out.println(str1.intern() == str1);

        String str2 = new StringBuilder("java").toString();
        System.out.println(str2.intern() == str2);
    }/* Output:
        true
        false
     *///:~  

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12

　　为什么第一个返回true，而第二个返回false呢？因为在JDK1.7中，intern（）方法的实现不会再复制实例，只是在常量池中记录 首次 出现的实例的引用，因此str1.intern()和str1指向的是同一个字符串，所以返回true。同一个引用。对于“java”这个字符串，由于在执行StringBuilder.toString() 之前已经出现过，所以字符串常量池中在new StringBuilder(“java”).toString()之前已经有它的引用了，不符合首次出现的原则，因此返回fasle。有人可能心里可能就要嘀咕了，为啥第二个不符合首次出现的原则，而第一个就符合首次出现的原则呢？ 实际上，

String str2 = new StringBuilder("java").toString();

• 1

等价于：

String s1 = "java";
StringBuilder sb = new StringBuilder(s1);
String str2 = sb.toString();

// StringBuilder 的 toString()方法
public String toString() {
        // Create a copy, don‘t share the array
        return new String(value, 0, count);
}

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9

　　由上面代码可知，字符串”java”早就出现了，因此不符合首次出现的原则，返回false。同理，“计算机软件”这个字符串在new StringBuilder(“计算机”).append(“软件”).toString()之前从未出现过，因此符合首次出现的原则，返回true。

　　要想更彻底地了解本实例，建议移步我的博文 《Java String 综述(上篇)》 和 《Java String 综述(下篇)》进行进一步了解。

　　更多关于JSP本质的全面介绍，请移步我的博文 《Java Web基础 — Jsp 综述(上)》 和 《Java Web基础 — Jsp 综述(下)》。

四. 更多

　　更多关于Java 垃圾回收机制概述的知识，包括对象是否可以回收的判别算法，典型的垃圾回收算法的基本思想、经典垃圾收集器的介绍及内存分配规则等，请见我的博文《 Java 垃圾回收机制概述》。

　　更多关于Java String类及其手动入池的全面介绍，请移步我的博文 《Java String 综述(上篇)》 和 《Java String 综述(下篇)》。

　　更多关于JSP本质的全面介绍，请移步我的博文 《Java Web基础 — Jsp 综述(上)》 和 《Java Web基础 — Jsp 综述(下)》。

　　更多关于 Java SE 进阶 方面的内容，请关注我的专栏 《Java SE 进阶之路》。本专栏主要研究 JVM基础、Java源码和设计模式等Java进阶知识，从初级到高级不断总结、剖析各知识点的内在逻辑，贯穿、覆盖整个Java知识面，在一步步完善、提高把自己的同时，把对Java的所学所思分享给大家。万丈高楼平地起，基础决定你的上限，让我们携手一起勇攀Java之巅…

引用:

《深入理解Java虚拟机：JVM高级特性与最佳实践》
《Java基础总结》
《JVM系列文章(四):类加载机制》
JVM方法区内存回收
JAVA CAS原理深度分析

原文地址：https://www.cnblogs.com/stankangyong/p/10807420.html