【深入理解Java虚拟机】Java内存区域模型、对象创建过程、常见OOM

本文内容来源于《深入理解Java虚拟机》一书，非常推荐大家去看一下这本书。

1、内存模型

java虚拟机在执行java程序的过程中会把它说管理的内存划分为若干个不同的数据区域，如下图所示：

图片来源于网络

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

     线程私有。程序计数器是一块较小的内存空间，可以看作是 当前线程所执行的字节码的行号指示器。字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令，分支、循环、跳转、异常处理、线程恢复登记处功能都需要依赖这个计数器的值来完成。 为了线程切换后能恢复到正确的执行位置，每个线程都需要有一个独立的程序计数器，各条线程之间的计数器互不影响，独立存储。这类内存区域称为 “线程私有”的内存。

     程序计数器，是唯一一个在java虚拟机规范中没有规定任何OutOfMemoryError的区域。

（2）Java虚拟机栈

    也是 线程私有的，生命周期与线程相同。虚拟机栈描述的是Java方法执行的内存模型： 每个方法在执行的同时，都会创建一个栈帧，用于存储 局部变量表、 操作数栈、 动态链接、 方法出口等信息。平常我们把java分为堆内存和栈内存，其中的 “栈”就是现在讲的虚拟机栈，或者说是虚拟机栈中局部变量表部分。局部变量表所需的内存空间在 编译期间完成分配，当进入一个方法时， 这个方法需要在栈帧中分配多大的局部变量空间是完全确定的，在方法运行期间不会改变局部变量表的大小。

    对于java虚拟机栈，有两种异常情况：

    1）如果线程请求的栈深度大于虚拟机所允许的深度，将抛出 StackOverflowError异常；

    2）如果虚拟机栈在动态扩展时，无法申请到足够的内存，就会抛出 OutOfMemoryError；

    

      Java虚拟机的解释执行引擎称为“基于栈的执行引擎”，其中所指的“栈”就是操作数栈。因此我们也称Java虚拟机是基于栈的，这点不同于Android虚拟机，Android虚拟机是基于寄存器的。

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

     线程私有。本地方法栈和虚拟机栈所发挥的作用非常相似，它们之间的区别主要是， 虚拟机栈是为虚拟机执行Java方法（也就是字节码）服务的，而本地方法栈则为虚拟机使用到的Native方法服务。

    与虚拟机栈类似，本地方法栈也会抛出 StackOverflowError和 OutOfMemoryError异常。

（4）Java堆（Java Heap）

     所有线程共享。Java堆在 虚拟机启动时创建，是Java虚拟机所管理的内存中最大的一块。 Java堆的唯一目的就是存放对象实例和数组。

    Java堆是垃圾收集器管理的主要区域，因此也成为“GC堆”。从 内存回收的角度来看，由于现在收集器大都采用分代收集算法，所以Java堆可以细分为： 新生代和 老年代；再细分一点： Eden空间、 From Survivor空间、  To Survivor 空间等。从 内存分配角度来看，线程共享的Java堆可以划分出多个 线程私有的分配缓冲区（Thread Local Allocation Buffer，TLAB）。但是不管怎么划分，哪个区域，存储的都是对象实例。

    Java堆物理上不需要连续的内存，只要逻辑上连续即可。如果堆中没有内存完成实例分配，并且也无法再扩展时，将会抛出 OutOfMemoryError异常。

（5）方法区（Method Area）

     所有线程共享。用于存储 已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。方法区也有一个别名叫做Non-Heap（非堆），用于与Java堆区分。对于HotSpot虚拟机来说，方法区又习惯称为“永久代”（Permancent Generation），但这只是对于HotSpot虚拟机来说的，其他虚拟机的实现上并没有这个概念。相对而言，垃圾收集行为在这个区域比较少出现，但也并非不会来收集， 这个区域的内存回收目标主要是针对常量池的回收和对类型的卸载上。

    

     运行时常量池：

    运行时常量池属于方法区。Class文件中除了有类的版本、字段、方法、接口等描述信息外，还有一项信息是常量池，用于 存放编译期生成的各种字面常量和符号引用，这部分内容 将在类加载后进入方法区的运行时常量池中存放。也就是说，这部分内容，在编译时只是放入到了常量池信息中，到了加载时，才会放到 运行时常量池中去。 运行时常量池县归于Class文件常量池的另外一个重要特征是具备动态性，Java语言并不要求常量一定只有编译期才能产生，也就是 并非预置入Class文件中常量池的内容才能进入方法区的运行时常量池，运行期间也可能将新的常量放入池中，这种特性被开发人员利用的比较多的是String类的intern()方法。

    当方法区无法满足内存分配需求时，将抛出OutOfMemoryError异常，常量池属于方法区，同样可能抛出 OutOfMemoryError异常。

（6）直接内存（Direct Memory）

     直接内存并不是虚拟机运行时数据区的一部分，也不是Java虚拟机规范中定义的内存区域。但是这部分内存也被频繁的使用，也可能会导致 OutOfMemoryError异常。直接内存的分配不会受到Java堆大小的限制，但需要收到本机总内存的大小以及处理器寻址空间的限制。典型的一个使用直接内存的例子，就是JDK1.4中加入的NIO 。

内存区域模型小结：

    （1）线程私有的区域：程序计数器、虚拟机栈、本地方法栈；

    （2）所有线程共享的区域：Java堆、方法区；（注：直接内存不属于虚拟机内存模型的部分）

    （3）没有异常的区域：程序计数器；

    （4）StackOverflowError异常：Java虚拟机栈、本地方法栈；

   （5）OutOfMemoryError异常：除程序计数器外的其他四个区域，Java虚拟机栈、本地方法栈、Java堆、方法区；直接内存也会出现OutOfMemoryError。

2、对象的创建、对象内存布局、对象的访问定位

2.1 对象的创建过程    

Java在语言层面，通过一个关键字new来创建对象。在虚拟机中，当遇到一条new指令后，将开始如下创建过程：

     （1）判断类是否加载、解析、初始化

    虚拟机遇到一条new指令时，先去检查这个指定的参数是否能在常量池中定位到一个类的符号引用，并且检查这个符号引用代表的类是否已被加载、解析和初始化过。如果没有，那先执行相应的类加载过程。

     （2）为新对象分配内存

    前面说到，对象的内存分配是在Java堆中的。为对象分配空间的任务等同于把一块确定大小的内存从Java堆中划分出来，此时Java堆中的情况有两种可能，一种是Java堆中内存是绝对规整的，一种是Java堆中的内存并不是规整的。因此有两种分配方式：

    1）Java堆内存是规整的，即所有用过的内存都放在一边，空闲的内存放在另一边，中间放着一个指针作为分界点的指示器，此时， 分配内存仅需要把这个指针向空闲空间那边挪动一段与对象大小相等的距离，这种方式也称为“ 指针碰撞”（Bump the Pointer）；

    2）Java堆内存不是规整的，即已使用的内存和空闲的内存相互交错，就没有办法简单地进行指针的移动，此时的分配方案是， 虚拟机必须维护一个列表，记录上哪些内存块是可用的，在分配的时候从列表中找到一块足够大的控件划分给对象实例，并更新列表上的记录，这种方式也称为“ 空闲列表”（Free List）；

    选择哪种分配方式由Java堆是否规整决定，而Java堆是否规整又由所采用的垃圾收集器是否带有压缩整理功能决定。因此，对于Serial、ParNew等带Compact过程的垃圾收集器，系统采用的是指针碰撞算法；对于CMS这种基于Mark-Sweep算法的收集器，通常采用空闲列表算法。

     （3）解决并发安全问题

    确定了如何划分内存空间之后，还有一个问题就是，对象的创建在虚拟机中是非常频繁的行为，比如，可能出现正在给对象A分配内存，指针还没来得及修改，对象B又同时使用了原来的指针来分配内存的情况，解决这种并发问题，一般有两种方案：

    1）对分配内存空间的动作进行同步处理，比如，虚拟机采用CAS配上失败重试的方式保证更新操作的原子性；

    2）另一种方式是，把内存分配的动作按照线程划分在不同的空间之中进行，即每个线程在Java堆中预先分配一小块内存，称为本地线程分配缓冲（Thread Local Allocation Buffer，TLAB），哪个线程要分配内存，就在哪个线程的TLAB上分配。只有TLAB用完并分配新的TLAB时，才需要同步锁定，虚拟机是否使用TLAB，可以通过-XX:+/-UserTLAB参数来设定。

     （4）初始化分配到的内存空间

    内存分配完成后，虚拟机将分配到的内存空间都初始化为零值（不包括对象头），如果使用TLAB，这一工作也可以提前至TLAB分配时进行。也正是这一步操作， 才保证了我们对象的实例字段在Java代码中可以不赋初值就直接使用。注意， 此时对象的实例字段全部为零值，并没有按照程序中的初值进行初始化。

     （5）设置对象实例的对象头

    上面工作完成后，虚拟机对对象进行必要的设置，主要是设置对象的对象头信息，比如，这个对象是哪个类的实例、如何才能找到类的元数据信息、对象的哈希码、对象的GC分代年龄等...

    

     （6）初始化对象<init>方法

    其实，上面工作完成后，从虚拟机角度来看，一个新的对象已经产生了，但从Java程序的角度来看，对象创建才刚刚开始，对象实例中的字段仅仅都为零值，还需要通过<init>方法进行初始化，把对象按照程序员的意愿进行初始化。此时，一个真正可用的对象才算完全产生出来。

2.2 对象的内存布局  

经过前面的创建工作，一个对象已经成功产生，也已经在Java堆中分配好了内存。那这个对象在Java堆内存中到底是什么形态呢？又包括哪些部分呢？这就涉及到了对象的内存布局了。

    不同的虚拟机实现中，对象的内存布局有差别，以最常用的HotSpot虚拟机为例，对象在内存中存储的布局分为3块区域： 对象头（Header）、 实例数据（Instance Data）、 对齐填充（Padding）。

     1）对象头：包含两部分信息，一部分是用于 存储对象自身的运行时数据，如哈希码、GC分代年龄、锁状态标志等；另一部分是 类型指针，即对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例。如果对象是一个Java数组，对象头中还有一块用于记录数组长度的数据，因为虚拟机可以通过普通Java对象的元数据信息确定Java对象的大小，但是从数组的元数据中却无法确定数组大小。

     2）实例数据： 真正存储对象有效信息的部分。也就是在程序中定义的各种类型的字段内容，包括从父类继承下来的，以及子类中定义的，都会在实例数据中记录。

    3）对齐填充：不是必然存在的，仅起着占位符的作用，对于HotSpot来说，虚拟机的自动内存管理系统要求对象其实地址必须是8字节的整数倍，因此，如果对象实例数据部分没有对齐时，就需要通过对齐填充的方式来补全。

2.3 对象的访问定位  

建立了对象是为了使用对象，我们对数据的使用是通过栈上的reference数据来操作堆上的具体对象，对于不同的虚拟机实现，reference数据类型有不同的定义，主要是如下两种访问方式：

     1）使用句柄访问。此时，Java堆中将会划出一块内存来作为 句柄池，reference中存储的就是对象的句柄地址，而句柄中包含了 对象实例数据与 类型数据各自的 具体地址信息，如下图：    

     2）使用直接指针访问。此时reference中存储的就是对象的地址。如下图：

上面所说的，所谓对象类型，其实就是指，对象所属的哪个类。

    

上面两种对象访问方式各有优势，使用句柄访问的最大好处就是reference中存储的是稳定的句柄地址，在对象被移动（垃圾收集时移动对象是非常普遍的行为）时，只会改变句柄中的实例数据指针，而reference本身不需要修改；使用直接指针访问方式的最大好处就是速度更快，它节省了一次指针定位的时间开销（根据上图，节省的是对象实例数据的指针定位），由于对象的访问在Java中非常频繁，因此，这类开销积少成多后也是一项非常可观的执行成本。对于HotSpot而言，选择的是第二种方式。

3、常见的OOM和SOF

OOM分为两种情况： 内存溢出（Memory Overflow）和 内存泄漏（Memory Leak）。

OOM： OutOfMemoryError异常 ，

    即 内存溢出，是指程序在申请内存时， 没有足够的空间供其使用，出现了Out Of Memory，也就是 要求分配的内存超出了系统能给你的，系统不能满足需求，于是产生溢出。

    内存溢出分为 上溢和下溢， 比方说栈，栈满时再做进栈必定产生空间溢出，叫上溢，栈空时再做退栈也产生空间溢出，称为下溢。

    

    有时候 内存泄露会导致内存溢出，所谓 内存泄露（memory leak），是指 程序在申请内存后，无法释放已申请的内存空间，一次内存泄露危害可以忽略，但内存泄露堆积后果很严重，无论多少内存,迟早会被占光，举个例子，就是说系统的篮子（内存）是有限的，而你申请了一个篮子，拿到之后没有归还（忘记还了或是丢了），于是造成一次内存泄漏。在你需要用篮子的时候，又去申请，如此反复，最终系统的篮子无法满足你的需求，最终会由 内存泄漏造成内存溢出。

    遇到的OOM：

    （1） Java Heap 溢出

    J ava堆用于存储对象实例，我们只要不断的创建对象，而又没有及时回收这些对象（即 内存泄漏 ），就会在对象数量达到最大堆容量限制后产生内存溢出异常。

    （2） 方法区溢出

    方法区用于存放Class的相关信息，如类名、访问修饰符、常量池、字段描述、方法描述等。

异常信息：java.lang.OutOfMemoryError:PermGen space

方法区溢出也是一种常见的内存溢出异常，一个类如果要被垃圾收集器回收，判定条件是很苛刻的。在经常动态生成大量Class的应用中，要特别注意这点。

SOF：StackOverflow（堆栈溢出）

     当应用程序递归太深而发生堆栈溢出时，抛出该错误。 因为栈一般默认为1-2m，一旦出现死循环或者是大量的递归调用，在不断的压栈过程中，造成栈容量超过1m而导致溢出。

    栈溢出的原因：

    （1）递归调用

    （2）大量循环或死循环

    （3）全局变量是否过多

    （4）数组、List、Map数据过大

（注：文章中图片来源于网络）