Java堆外内存解析：为什么Java8用元空间替代永久代及其内存管理机制

一、前言

平时编程时，在 Java 里创建对象，会在堆上划分出一块区域，而这块区域被称作堆内内存。

剖开 JVM 内存模型，来看下其堆划分：

从图中能够看出，Java8 采用了元空间来替代永久代，并且元空间是放置在堆外内存上的。这其中的缘由是什么呢？

类的元数据信息经常被用到，在进行 GC 时回收效率较低。类的元数据信息不太容易确定其大小，若指定得太小，就容易出现永久代溢出的情况；若指定得太大，就容易造成老年代溢出。

那什么是堆外内存？

堆外内存和堆内内存是相对应的。在整个机器内存当中，除去堆内内存的那部分就是堆外内存。

Java 程序通常会利用 -XX:MaxDirectMemorySize 这个参数去对最大堆外内存进行限制。

还有个问题：堆外内存属于用户空间还是内核空间？ 用户空间。

（1）为什么需要堆外内存？

使用堆外内存，有这些好处：

直接使用堆外内存能减少一次内存拷贝。在进行网络 I/O 操作以及文件读写时，堆内内存需要转换为堆外内存，之后才能与底层设备进行交互。这样可以降低 JVM GC 对应用程序的影响，因为堆外内存不受 JVM 管理。并且堆外内存能够实现进程之间以及 JVM 多实例之间的数据共享。

那我就有个问题：为什么使用堆外内存可以减少一次内存拷贝呢？

原因：在进行网络 I/O 操作或者文件读写的时候，如果运用堆内内存（HeapByteBuffer），那么 JDK 会首先创建一个堆外内存（DirectBuffer），接着去进行真正的读写操作。

具体原因在于：要调用底层系统函数，比如 write 函数和 read 函数等，就必须要求所使用的地址空间是连续的。

操作系统不会感知 JVM 的堆内存。JVM 的内存布局与操作系统所分配的不同。操作系统不会依照 JVM 的行为来读写数据。同一个对象的内存地址会因 JVM GC 的执行而随时改变，比如在 JVM GC 过程中，会通过压缩来减少内存碎片，这就涉及到对象移动的问题。

当然使用堆外内存，有这些弊端：

排查内存泄漏问题有一定难度。堆外内存需要手动释放，若不熟悉对应框架源码，稍不留意就可能导致应用程序出现内存泄漏情况。这对开发人员的基础技能要求较高。

由此可以看出，若要实现高效的 I/O 操作，堆外内存是个不错选择；若要缓存常用对象，堆外内存是个不错选择；若要降低 JVM GC 压力，堆外内存是个不错选择。

（2）如何分配堆外内存？

Java 中堆外内存的分配方式有两种：

NIO 类里的 ByteBuffer 有 allocateDirectUnsafe 方法，该方法用于 allocateMemory

首先来看 Java NIO 包中 ByteBuffer 类的分配方式，其使用方式如下：

// 分配 10M 堆外内存
使用 ByteBuffer.allocateDirect 方法分配一个容量为 10 乘以 1024 乘以 1024 的直接缓冲区，赋值给 byteBuffer 变量。
// 释放堆外内存
((DirectBuffer) byteBuffer).获取 cleaner() 方法的返回值并调用 clean() 方法；

跟进 ByteBuffer.allocateDirect 的源码，我们可以发现其中直接调用了 DirectByteBuffer 的构造函数。

DirectByteBuffer(int cap) { 
    super(-1, 0, cap, cap);
VM 的直接内存页是否对齐可以通过 boolean 类型的 pa 来表示。
    int ps = Bits.pageSize();
首先获取 1L 与 cap 加上根据 pa 条件判断的 ps 或 0 的和的较大值，将其赋值给 long size ，即 long size 等于 Math 类中的 max 方法的返回值，该返回值是 1L 与 cap 加上根据 pa 条件判断的 ps 或 0 的和的较大值。
Bits 会预留指定大小 size 和容量 cap 的内存，并且在此过程中会调用 System.gc() 方法。
    long base = 0;
    try {
        // 1\. 真正分配堆外内存
使用 unsafe 分配内存，其大小为 size，分配的内存存储在 base 中。
当捕获到 OutOfMemoryError 异常时，执行以下操作：
Bits 进行释放内存的操作，释放的内存大小为 size，同时容量为 cap 。
        throw x;
    }
unsafe 对内存进行设置操作，将指定的基地址 base 处的大小为 size 的内存区域设置为字节值 (byte) 0 。
    if (pa && (base % ps != 0)) {
        // Round up to page boundary
地址等于基值加上部分值再减去基值与部分值减 1 的结果的与运算；
    } else {
        address = base;
    }
    // 2\. 用于回收堆外内存
Cleaner 是通过调用 Cleaner.create 方法创建的，该方法的参数为 this、一个新的 Deallocator 实例，其参数为 base、size 和 cap 。
    att = null;
}

DirectByteBuffer 对象存放在堆内存中，它仅包含堆外内存的相关属性，如地址、大小等。并且会创建对应的 Cleaner 对象。由 ByteBuffer 分配的堆外内存无需手动进行回收，它能够被 JVM 自动回收。

堆内的 DirectByteBuffer 对象被 GC 回收的时候，Cleaner 会被用来回收与之对应的堆外内存。

真正分配堆外内存的逻辑是通过 unsafe.allocateMemory 来实现的，并且分配的内存大小为 size 。

Unsafe 是一个安全性极差的类，它被用于进行内存访问、分配以及修改等较为敏感的操作，能够突破 JVM 所设置的限制。Unsafe 一开始并非是为开发者而设计的，在使用它的时候，虽然能够获得对底层资源的掌控权，然而与此同时也丧失了安全性方面的保障，因此，使用 Unsafe 必须要格外谨慎。

在 Java 里无法直接去使用 Unsafe 。不过能够借助反射来获取 Unsafe 的实例，其使用的方式呈现如下：

静态私有变量 unsafe 初始值为 null 。
static {
    try {
Unsafe 类中的一个字段被获取到，这个字段名为 getUnsafe，并且通过 Unsafe.class.getDeclaredField("theUnsafe") 来获取该字段。
调用 getUnsafe 的 setAccessible 方法并将其参数设置为 true 。
unsafe 等于 (Unsafe) getUnsafe.get(null) ；获取 Unsafe 的 getUnsafe 方法并传入 null 后，将其结果转换为 Unsafe 类型赋值给 unsafe 。
如果捕获到 NoSuchFieldException 或者 IllegalAccessException 异常，就执行以下操作。
        e.printStackTrace();
    }
}

获得 Unsafe 实例之后，能够利用 allocateMemory 方法来分配堆外内存，allocateMemory 方法所返回的是内存地址，其使用方法如下所示：

// 分配 10M 堆外内存
unsafe.allocateMemory 函数被用于为 long address 分配 10 * 1024 * 1024 大小的内存。
Unsafe#allocateMemory 分配的内存需要自己手动去释放，不然就会导致内存泄漏。
// 这也是 Unsafe 不安全的体现。
unsafe.freeMemory(address);

（3）如何回收堆外内存？

堆外内存回收，有两种方式：

Full GC 时以及调用 System.gc()的情况如下：通过 JVM 参数 -XX:MaxDirectMemorySize 来指定堆外内存的上限大小。当堆外内存的大小超过这个阈值时，就会触发一次 Full GC 以进行清理回收。如果在 Full GC 之后依然无法满足堆外内存的分配，那么程序就会抛出 OOM 异常。DirectByteBuffer 在初始化时会创建一个 Cleaner 对象，这个 Cleaner 内会创建 Deallocator。可以使用 unsafe.freeMemory(address); 来回收，即调用 Deallocator#run() 来进行回收。同时，System.gc() 会触发这一回收过程。

那就有个问题，什么时候会触发 System.gc() ？

在 ByteBuffer.allocateDirect 进行分配的过程里：倘若没有足够的空间来分配堆外内存，那么在 Bits.reserveMemory 方法中，也会主动去调用 System.gc()，如此就会引发 Full GC（并非立即执行）。

ByteBuffer 调用 allocateDirect 方法后会直接去调用 DirectByteBuffer 的构造函数。
DirectByteBuffer(int cap) { 
    ... 
    Bits.reserveMemory(size, cap);  // 注意这里会调用 System.gc();
    ...
}

如果环境中设置了某个特定的参数 -XX:+DisableExplicitGC，那么 System.gc() 将不会起作用。

所以依赖 System.gc() 并不是一个好办法。

2）Cleaner对象

前面介绍了堆外内存分配方式。我们知道，DirectByteBuffer 在初始化时会创建一个 Cleaner 对象，这个 Cleaner 对象负责堆外内存的回收工作。那么，Cleaner 是怎样与 GC 关联起来的呢？

先来看下 Cleaner 的源码：

公共类 Cleaner 继承自 java.lang.ref.PhantomReference 。 {
静态私有常量引用队列。