第2章 Java内存区域与内存溢出异常

Java与C++之间有一堵由内存动态分配和垃圾收集技术所围成的高墙，墙外面的人想进去，墙里面的人却想出来。

2.1 概述

​ 相对于c、c++在内存管理方面java把控制内存的权力基本都交给了java虚拟机，这样做的好处无疑是非常明显的，开发人员就算对内存管理一无所知也可以进行程序的编写，然而一旦出现内存泄漏和溢出方面的问题，如果不了解虚拟机是怎样使用内存的，那排查错误、修正问题将会成为一项异常艰难的工作。

2.2 运行时数据区域

图2-1 Java虚拟机运行时数据区

2.2.1 程序计数器

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

​ java虚拟机的多线程是通过线程轮流切换，分配处理器执行时间的方式来实现的。任一时刻，任一处理器(内核)，只能执行一条线程中的指令。因此为了保证线程切换后能恢复到正确位置，每个线程都有一个独立的程序计数器，我们称这类内存区域为“线程私有”的内存。

2.2.2 Java虚拟机栈

​ 与程序计数器一样，java虚拟机栈也是线程私有的，它的生命周期与线程相同。虚拟机栈描述的是java方法执行的线程内存模型：每个方法执行的时候，java虚拟机都会创建一个栈帧用于存储局部变量表、操作数栈、动态连接、方法出口等信息。方法调用时—>入栈，执行完毕—>出栈。

​ 局部变量所需要的内存空间在编译期间完成分配，进入一个方法时，这个方法需要在栈帧中分配多大的局部变量空间是完全确定的，在方法的运行期间不会改变局部变量表的大小，这里的大小指的是变量槽的数量。

2.2.3 本地方法栈

​ 本地方法栈与虚拟机栈的作用类似，区别是虚拟机栈为虚拟机执行java方法(字节码)服务，而本地方法栈则是为虚拟机执行本地方法服务。

2.2.4 Java堆

​ 对于Java应用程序来说，Java堆(Java Heap)是虚拟机所管理的内存中最大的一块。Java堆是被所有线程共享的一块内存区域，在虚拟机启动时创建。此内存区域的唯一目的就是存放对象实例，Java世界里"几乎"所有对象实例都在这里分配内存。

​ Java堆是垃圾收集器管理的内存区域，因此一些资料中它也被称作GC堆(Garbage Collected Heap)。从回收内存的角度来看，由于现代垃圾收集器大部分都是基于分代收集理论设计的，所有Java堆中经常出现”新生代“、”老年代“、”永久带的“”“Eden空间”、“From Survivor空 间”、“To Survivor空间”等名词。(详细了解可参照https://www.cnblogs.com/kxm87/p/7205414.html)

​ 无论从什么角度，无论如何划分，都不会改变Java堆中存储内容的共性(共享性)，无论是哪个区域，存储的都只能是对象的实例，将java堆细分的目的只是为了更好的分配内存或回收内存。

Java堆可以是固定大小，也可以是可扩展的。目前主流的Java虚拟机都是按照可扩展来实现的(通过参数-Xmx和-Xms设定)。如果Java内存不够分配给实例，并且堆也不可扩展时，Java虚拟机将会抛出OutOfMemoryError异常。

2.2.5 方法区

​ 方法区(Method Area)与Java堆一样，是各个线程共享的内存区域，它用于存储已被虚拟机加载的类型信息、常量、静态变量、即时编译器编译后的代码缓存等数据。

​ HotSpot虚拟机在JDK 8以前是存在永久代的概念的，并使用永久代来实现方法区，导致很多Java程序员都习惯把方法区称为永久代，但本质上这两个是不等价的。在JDK 6的 时候HotSpot开发团队就有放弃永久代，逐步改为采用本地内存（Native Memory）来实现方法区的计 划了[1]，到了JDK 7的HotSpot，已经把原本放在永久代的字符串常量池、静态变量等移出，而到了 JDK 8，终于完全废弃了永久代的概念，改用与JRockit、J9一样在本地内存中实现的元空间（Meta- space）来代替，把JDK 7中永久代还剩余的内容（主要是类型信息）全部移到元空间中。

​ 根据《Java虚拟机规范》的规定，如果方法区无法满足新的内存分配需求时，将抛出OutOfMemoryError异常。

2.2.6 运行时常量池

​ 运行时常量池(Runtime Controller Pool)是方法区的一部分。Class文件除了有类的版本、字段、方法、接口等描述信息外，还有一项信息是常量池表（Constant Pool Table），用于存放编译期生成的各种字面量与符号引用，这部分内容将在类加载后存放到方法区的运行时常量池中。

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

2.2.7 直接内存

​ 直接内存(Direct Memory)并不是虚拟机运行时数据区的一部分，也不是《Java虚拟机规范》中定义的内存区域。但是这部分内存也被频繁使用，而且也可能导致OutOfMemoryError异常出现。

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

​ 显然，本机直接内存的分配不会受到Java堆大小的限制，但是，既然是内存，则肯定还是会受到 本机总内存（包括物理内存、SWAP分区或者分页文件）大小以及处理器寻址空间的限制，一般服务 器管理员配置虚拟机参数时，会根据实际内存去设置-Xmx等参数信息，但经常忽略掉直接内存，使得 各个内存区域总和大于物理内存限制（包括物理的和操作系统级的限制），从而导致动态扩展时出现 OutOfMemoryError异常。

2.3 HotSpot虚拟机对象探秘

​ 基于实用原则，笔者以最常用的虚拟机HotSpot和最常用的内存区域Java堆为例，深入探讨一下HotSpot虚拟机在Java堆中内存分配、布局、和访问的全过程。

2.3.1 对象的创建

Java的类加载机制为 加载 验证 准备 解析 初始化。(详细了解参照https://www.cnblogs.com/zhaodongge/p/10590457.html)

​ 当Java虚拟机遇到一条字节码new指令时，首先将去检查这个指令的参数是否能在常量池中定位到一个类的符号引用，并且检查这个符号引用代表的类是否已被加载、解析和初始化过。如果没有，那必须执行相应的类加载过程，本书第七章将探讨这部分细节。

在类加载检查通过后，接下来虚拟机将为新生对象分配内存。对象所需内存的大小在类加载完成后便可完全确定，为对象分配空间的任务实际上就是把一块确定大小的内存块从Java堆中划分出来。

分配方式基本分为两种

• 指针碰撞：Java堆中的内存绝对规整，被使用的内存放在一边，空闲的内存放在一边，中间放着一个指针作为分界点的指示器。那么分配内存时，将指针往空闲的内存区域移动与对象大小相同的距离即可。

• 空闲列表：Java中的内存并不规整，被使用的内存和空闲的内存相互交错。这时虚拟机必须维护一张表，记录哪块内存时可用的，分配内存时，从列表中找打一块足够大的内存空间划分给对象，然后更新列表的记录。

​ 选择哪种分配方式由Java堆是否规整决定，而Java堆是否规则又取决于所采用的垃圾收集器是否又空间压缩整理的能力。因此，当使用Serial、ParNew等带压缩 整理过程的收集器时，系统采用的分配算法是指针碰撞，既简单又高效；而当使用CMS这种基于清除 （Sweep）算法的收集器时，理论上[1]就只能采用较为复杂的空闲列表来分配内存。

​ 除如何划分可用空间之外，还有另外一个需要考虑的问题：对象创建在虚拟机中是非常频繁的行为，即使仅仅修改一个指针所指向的位置，在并发情况下也并不是线程安全的，可能出现正在给对象A分配内存，指针还没来得及修改，对象B又同时使用了原来的指针来分配内存的情况。解决这个问题 有两种可选方案：一种是对分配内存空间的动作进行同步处理——实际上虚拟机是采用CAS配上失败 重试的方式保证更新操作的原子性；另外一种是把内存分配的动作按照线程划分在不同的空间之中进行，即每个线程在Java堆中预先分配一小块内存，称为本地线程分配缓冲（Thread Local Allocation Buffer，TLAB），哪个线程要分配内存，就在哪个线程的本地缓冲区中分配，只有本地缓冲区用完 了，分配新的缓存区时才需要同步锁定。虚拟机是否使用TLAB，可以通过-XX：+/-UseTLAB参数来 设定。

​ 内存分配完成之后，虚拟机必须将分配到的内存空间（但不包括对象头）都初始化为零值，如果是使用了TLAB的话，这一项工作也可以提前至TLAB分配时顺便进行。这步操作保证了对象的实例字段在Java代码中可以不赋初始值就直接使用，使程序能访问到这些字段的数据类型所对应的零值。

这边我自己写了个案例

public class bean {
    
    
    int num;
}

public class testInit {
    
    
    public static void main(String[] args) {
    
    
        bean b = new bean();
        System.out.println(b.num);
    }
}

运行testInit后num没有赋值过也会输出0。

​ 接下来，Java虚拟机还要对对象进行必要的设置，例如这个对象是哪个类的实例、如何才能找到 类的元数据信息、对象的哈希码（实际上对象的哈希码会延后到真正调用Object::hashCode()方法时才 计算）、对象的GC分代年龄等信息。这些信息存放在对象的对象头（Object Header）之中。根据虚拟 机当前运行状态的不同，如是否启用偏向锁等，对象头会有不同的设置方式。关于对象头的具体内 容，稍后会详细介绍。

​ 到这里，从虚拟机得角度，一个新的对象已经产生了。但是从Java程序的角度看来，对象创建才刚刚开始——构造函数，即Class文件中的()方法还没有执行，所有的字段都 为默认的零值，对象需要的其他资源和状态信息也还没有按照预定的意图构造好。一般来说（由字节 码流中new指令后面是否跟随invokespecial指令所决定，Java编译器会在遇到new关键字的地方同时生成 这两条字节码指令，但如果直接通过其他方式产生的则不一定如此），new指令之后会接着执行 ()方法，按照程序员的意愿对对象进行初始化，这样一个真正可用的对象才算完全被构造出来。

2.3.2 对象的内存布局

​ 在HotSpot虚拟机里，对象在堆内存中的储存布局可以划分为三个部分：对象头(Header)、实例数据(Instance Data)和对齐补充(Padding)。

​ HotSpot虚拟机对象的对象头部分包括两类信息。第一类是用于存储对象自身的运行时数据，如哈 希码（HashCode）、GC分代年龄、锁状态标志、线程持有的锁、偏向线程ID、偏向时间戳等，这部 分数据的长度在32位和64位的虚拟机（未开启压缩指针）中分别为32个比特和64个比特，官方称它 为“Mark Word”。

HotSpot虚拟机对象头Mark Word

​ 对象头的另外一部分是类型指针，即对象指向它的类型元数据的指针，Java虚拟机通过这个指针来确定该对象是哪个类的实例。

​ 对象的第三部分是对齐填充，这并不是必然存在的，也没有特别的含义，它仅仅起着占位符的作 用。由于HotSpot虚拟机的自动内存管理系统要求对象起始地址必须是8字节的整数倍，换句话说就是 任何对象的大小都必须是8字节的整数倍。对象头部分已经被精心设计成正好是8字节的倍数（1倍或者 2倍），因此，如果对象实例数据部分没有对齐的话，就需要通过对齐填充来补全。

2.3.3 对象的访问定位

​ 创建对象自然是为了后续使用该对象，我们的Java程序会通过栈上的reference数据来操作堆上的具体对象。由于reference类型在《Java虚拟机规范》里面只规定了它是一个指向对象的引用，并没有定义这个引用应该通过什么方式去定位，访问到堆中对象的具体位置，所以对象访问方式也是由虚拟机实现而定的，主流的访问方式主要有使用句柄和指针两种：

• 如果使用句柄访问的话，Java堆中将可能会划分出一块内存来作为句柄池，reference中存储的就是对象的句柄地址，而句柄中包含了对象实例数据与类型数据各自具体的地址信息，其结构如图2-2所示。

• 如果使用指针直接访问的话，Java堆中对象的内存布局就必须考虑如何放置访问类型数据的相关信息，reference中存储的直接就是对象地址，如果只是访问对象本身的话，就不需要多一次间接访问开销，如图2-3所示。

​ 图2-2 通过句柄访问对象

​ 图2-3 通过直接指针访问对象

​ 这两种对象访问方式各有优势，使用句柄来访问的最大好处就是reference中存储的是稳定句柄地

址，在对象被移动（垃圾收集时移动对象是非常普遍的行为）时只会改变句柄中的实例数据指针，而

reference本身不需要被修改。

​ 使用直接指针来访问最大的好处就是速度更快，它节省了一次指针定位的时间开销，由于对象访

问在Java中非常频繁，因此这类开销积少成多也是一项极为可观的执行成本，就本书讨论的主要虚拟

机HotSpot而言，它主要使用第二种方式进行对象访问（有例外情况，如果使用了Shenandoah收集器的

话也会有一次额外的转发，具体可参见第3章），但从整个软件开发的范围来看，在各种语言、框架中

使用句柄来访问的情况也十分常见。

2.4 实战：OutOfMemoryError异常

笔者使用的是idea，idea设置虚拟机参数方法如下图

2.4.1 Java堆溢出

​ Java堆用于储存对象实例，我们只要不断地创建对象，并且保证GC Roots到对象之间有可达路径来避免垃圾回收机制清除这些对象，那么随着对象数量的增加，总容量触及最大堆的容量限制后就会产生内存溢出异常。（判断一个对象是否存活就看它到GC Roots之间是否有可达路径）

​ 代码清单2-3中限制Java堆的大小为20MB，不可扩展（将堆的最小值-Xms参数与最大值-Xmx参数设置为一样即可避免堆自动扩展），通过参数-XX：+HeapDumpOnOutOf-MemoryError可以让虚拟机在出现内存溢出异常的时候Dump出当前的内存堆转储快照以便进行事后分析[1]。

​ 处理办法后续章节展开

/**
 * VM Args：-Xms20m -Xmx20m -XX:+HeapDumpOnOutOfMemoryError
 */
public class HeapOOM {
    
    
    static class OOMObject {
    
    
    }

    public static void main(String[] args) {
    
    
        List<OOMObject> list = new ArrayList<OOMObject>();
        while (true) {
    
    
            list.add(new OOMObject());
        }
    }
}

2.4.2 虚拟机栈和本地方法栈溢出

​ 由于HotSpot虚拟机中并不区分虚拟机栈和本地方法栈，因此对于HotSpot来说，-Xoss参数（设置本地方法栈大小）虽然存在，但实际上是没有任何效果的，栈容量只能由-Xss参数来设定。关于虚拟机栈和本地方法栈，在《Java虚拟机规范》中描述了两种异常：

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

2）如果虚拟机的栈内存允许动态扩展，当扩展栈容量无法申请到足够的内存时，将抛出OutOfMemoryError异常。

2.4.3 方法区和运行时常量池溢出

​ 由于运行时常量池是方法区的一部分，所以这两个区域的溢出测试可以放到一起进行。前面曾经提到HotSpot从JDK 7开始逐步“去永久代”的计划，并在JDK 8中完全使用元空间来代替永久代的背景故事，在此我们就以测试代码来观察一下，使用“永久代”还是“元空间”来实现方法区，对程序有什么实际的影响。

​ 在此不放代码了，想详细了解可以看书。JDK 7以前的版本字符串常量池被放在永久代中，所以通过-XX:PermSize=6M -XX:MaxPermSize=6M 这两个参数限制方法区大小后可能会出现OutOfMemoryError异常。

​ 因为自JDK 7起，原本存放在永久代的字符串常量池被移至Java堆之中，所以在JDK 7及以上版本，限制方法区的容量对该测试用例来说是毫无意义的。这时候使用-Xmx参数限制最大堆到6MB会出现OutOfMemoryError异常。

​ 我们再来看看方法区的其他部分的内容，方法区的主要职责是用于存放类型的相关信息，如类名、访问修饰符、常量池、字段描述、方法描述等。对于这部分区域的测试，基本的思路是运行时产生大量的类去填满方法区，直到溢出为止。在JDK 8以后，永久代便完全退出了历史舞台，元空间作为其替代者登场。在默认设置下，前面列举的那些正常的动态创建新类型的测试用例已经很难再迫使虚拟机产生方法区的溢出异常了。

2.4.4 本机直接内存溢出

​ 直接内存（Direct Memory）的容量大小可通过-XX：MaxDirectMemorySize参数来指定，如果不去指定，则默认与Java堆最大值（由-Xmx指定）一致，代码清单2-10越过了DirectByteBuffer类直接通过反射获取Unsafe实例进行内存分配（Unsafe类的getUnsafe()方法指定只有引导类加载器才会返回实 例，体现了设计者希望只有虚拟机标准类库里面的类才能使用Unsafe的功能，在JDK 10时才将Unsafe的部分功能通过VarHandle开放给外部使用），因为虽然使用DirectByteBuffer分配内存也会抛出内存溢 出异常，但它抛出异常时并没有真正向操作系统申请分配内存，而是通过计算得知内存无法分配就会在代码里手动抛出溢出异常，真正申请分配内存的方法是Unsafe::allocateMemory()。

2.5 本章小结

​ 到此为止，我们明白了虚拟机里面的内存是如何划分的，哪部分区域、什么样的代码和操作可能导致内存溢出异常。虽然Java有垃圾收集机制，但内存溢出异常离我们并不遥远，本章只是讲解了各 个区域出现内存溢出异常的原因，下一章将详细讲解Java垃圾收集机制为了避免出现内存溢出异常都做了哪些努力。