Java 堆外内存及调优

文章目录

直接内存简介
- 为什么DirectByteBuffer可以优化 IO 性能
直接内存的分配
直接内存的回收
直接内存跟踪与诊断

直接内存简介

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

直接内存的分配不受Java堆大小的限制，但是受限于本机总内存大小和处理器寻址空间。一般服务器运维人员会根据实际内存设置-Xmx等参数，但经常忽略直接内存，使得动态扩展时出现 OutOfMemeoryError 异常。

JDK 1.4中加入了NIO类，引入一种基于通道(Channel)与 缓冲区(Buffer)的I/O方式，它可以使用 Native 函数库直接分配堆外内存。这样在一些场景中能显著提高性能，避免在 Java 堆中和 Native 堆中来回复制数据。

为什么DirectByteBuffer可以优化 IO 性能

普通 IO 流读取磁盘中数据时，内核态需要将磁盘中的数据拷贝到系统缓冲区 Page Cache(内核地址空间)，再从内核态拷贝到用户空间中，C 程序里操作的就是用户态的内存。

JVM 启动时在用户态申请一块内存，这块内存中包含了 Java 堆，几乎所有创建的对象和数组都分配在堆上，堆上的实例受 GC 管理。除了Java堆，其余内存称为 堆外内存，如果使用JNI直接调用 C 函数申请堆外内存(直接内存)，这块堆外内存不会进行垃圾回收(例如：Direct Memory 由 malloc 分配)。

Java 程序中进行文件的读操作：

首先在内核态，将数据从磁盘中读取到系统缓存区中
再从系统缓冲区拷贝到用户态的堆外内存(JVM实现)
然后再从堆外拷贝到 Java 堆内的 byte 数组(用户地址空间)。

读操作示意图如下：

上述传统 Java IO方式，经历了两次内存拷贝，而NIO中使用 DirectByteBuffer，不需要将数据从堆外拷贝到堆内，Java程序可以直接访问堆外的 Direct Memory，减少了一次内存拷贝，也减轻了 GC 压力，降低了Java堆内存占用。示意图如下：

为什么数据不能直接从系统缓冲区拷贝到 Java 堆？
笔者认为原因主要在于 GC 会改变堆内对象的内存地址，例如：Young GC 时Eden 区存活对象会被拷贝到 Survivor 区。而内核态向用户态的数据拷贝是由内核完成的，并不受 Java 程序控制。

因此，需要先拷贝到堆外内存(这个区域不会发生 GC，地址不改变)，再从堆外内存拷贝数据到Java堆中。Java 堆内存和堆外内存同属用户地址空间，拷贝可由 Java 虚拟机完成。

Java Direct Buffer用于执行很大数据量的IO密集操作时，存在很大的性能优势。

Direct Buffer 是使用malloc进行的堆外分配，生命周期内内存地址都不会再发生更改，进而内核可以安全地对其进行访问，很多 IO 操作会很高效。
减少了堆内对象存储的可能额外维护工作(例如：垃圾回收时位置的移动)，所以访问效率可能有所提高。
Direct Buffer 的使用能提高网络和文件IO效率，因为省去了从本地堆到Java堆的拷贝，降低 Java 堆的内存占用从而减轻了GC压力。
- Direct Buffer的创建和销毁比堆内Buffer增加部分开销，通常都建议用于长期使用、数据较大的场景。

直接内存的分配

通过NIO中的DirectByteBuffer实例引用直接内存

public static void main(String[] args) {
    ByteBuffer buffer = ByteBuffer.allocateDirect(1024);
    // ...
}

allocateDircet 方法返回 DirectByteBuffer 实例：

public static ByteBuffer allocateDirect(int capacity) {
    return new DirectByteBuffer(capacity);
}

DirectByteBuffer 类的构造函数中，通过Unsafe#allocateMemory分配直接内存空间，并且创建对应的 Cleaner 实例用于回收直接内存，Cleaner 实例是一个指向 DirectByteBuffer 实例的虚引用。

DirectByteBuffer(int cap) {                   
    super(-1, 0, cap, cap);
    boolean pa = VM.isDirectMemoryPageAligned();
    int ps = Bits.pageSize();
    // 多配分一个内存页, 用于直接内存起始地址对齐
    long size = Math.max(1L, (long)cap + (pa ? ps : 0));
    // 尝试保留size大小的内存, 如果内存不够, 处理pending链表上的引用
    // 内存仍然不足，则显式GC, 将不可达的引用放入pending链表中, 再从pending回收内存
    // 内存不够, 则抛出OOM错误
    Bits.reserveMemory(size, cap);

    long base = 0;
    try {
        // base为直接内存的基址
        base = unsafe.allocateMemory(size);
    } catch (OutOfMemoryError x) {
        Bits.unreserveMemory(size, cap);
        throw x;
    }
    // 将分配到的直接内存每一个Byte设置为0
    unsafe.setMemory(base, size, (byte) 0);
    // 如果需要直接内存对齐, 且基址base不整除pageSize, 则调整起始地址为base+pageSize减去base%pageSize
    if (pa && (base % ps != 0)) {
        // address为ByteBuffer缓冲区可使用部分的起始地址
        address = base + ps - (base & (ps - 1));
    } else {
        address = base;
    }
    // CLeaner 持有 DirectByteBuffer 的幻影(虚)引用
    // Deallocator实现Runnable接口, 执行释放直接内存的操作
    cleaner = Cleaner.create(this, new Deallocator(base, size, cap));
    att = null;
}

直接内存的回收

Cleaner类继承虚引用 PhantomReference，虚引用的referent字段指向 DirectByteBuffer 实例。

虚引用：最弱的引用关系，一个对象是否有虚引用存在不对其生存时间构成影响，也无法通过虚引用获取对象实例，get 方法返回null。

为一个对象设置虚引用关联的唯一目的是能在这个对象被收集器回收时收到系统通知。

public class Cleaner extends PhantomReference<Object> {
    ...
    // Cleaner.create: var1传入DirectByteBuffer引用, var2传入Deallocator实例
    private Cleaner(Object var1, Runnable var2) {
        super(var1, dummyQueue);// DirectByteBuffer作为虚引用
        this.thunk = var2; // 
    }
    public static Cleaner create(Object var0, Runnable var1) {
        return var1 == null ? null : add(new Cleaner(var0, var1));
    }
}

当 DirectByteBuffer 实例不存在强引用后，垃圾回收时它的 PhantomReference 实例会被放入 pending 链表，等待 ReferenceHandler 线程将它从 pending 链表中取出，加入到引用队列queue中。

ReferenceHandler 线程执行逻辑实现于 tryHandlePending 方法：

从 pending 链表中取出头部的 Reference 实例，如果引用实例为 Cleaner 类型，需要调用它的 clean 方法释放直接内存。随后，将 Reference 实例加入到引用队列 queue 中。

public void run() {
    while (true) {
        tryHandlePending(true);
    }
}

static boolean tryHandlePending(boolean waitForNotify) {
    Reference<Object> r;
    Cleaner c;
    try {
        synchronized (lock) {
            if (pending != null) {
                r = pending;
                // Cleaner继承了虚引用, 需要调用clean方法, 因此特判。
                c = r instanceof Cleaner ? (Cleaner) r : null;
                // pending头节点更新为r的下一个节点
                pending = r.discovered;
                r.discovered = null;
            } else {
                // pending链表中元素为空, wait-notify等待唤醒
                if (waitForNotify) {
                    lock.wait();
                }
                // retry if waited
                return waitForNotify;
            }
        }
    }// ...
    // 如果Reference类型为Cleaner, 需要调用clean方法, 直接内存此时会被回收
    if (c != null) {
        c.clean();
        return true;
    }
    // 将Reference实例加入到引用队列中
    ReferenceQueue<? super Object> q = r.queue;
    // 注册了引用队列, 则入队, 入队后修改r.queue = ReferenceQueue.ENQUEUED, next指向队列中的后继
    if (q != ReferenceQueue.NULL) q.enqueue(r);
    return true;
}

从 pending 链表取出时，会调用 Cleaner#clean方法，clean方法会调用运行 Unsafe#freeMemory 释放直接内存。

// Cleaner
public void clean() {
    if (remove(this)) {
        try {
            this.thunk.run(); // thunk为Deallocator实例
        } // catch
    }
}

// private static class Deallocator implements Runnable
public void run() {
    if (address == 0) {
        // Paranoia
        return;
    }
    // 释放直接内存, address为直接内存基址
    unsafe.freeMemory(address);
    address = 0;
    Bits.unreserveMemory(size, capacity);
}

Direct Buffer 性能优化方面的建议：

应用程序中，System.gc() 触发Full GC，将 DirectByteBuffer 回收时调用 Cleaner#clean 方法释放直接内存。
不要开启 -XX:+DisableExplicitGC 禁用显式GC，默认不禁用；
使用 -XX:+ExplicitGCInvokesConcurrent 改变 Full GC 的行为（配合 CMS 使用）。添加该选项后，垃圾收集线程在可达性标记阶段与用户线程并发运行，减少了STW的时间。
另一种思路是，在大量使用Direct Buffer的部分框架中，框架会自己程序中显式地调用Unsafe#freeMemory方法，例如Netty。(使用反射获取 Unsafe 实例，再调用成员方法 freeMemory)
重复利用 Direct Buffer，减少它的创建和销毁。

直接内存跟踪与诊断

直接内存的容量大小可通过 -XX:MaxDirectMemorySize 参数指定，默认与 Java堆最大值一致。
使用反射越过 DirectByteBuffer 类，直接通过反射获取 Unsafe 实例(theUnsafe静态属性)，进行内存分配。

Field theUnsafe = Unsafe.class.getDeclaredField("theUnsafe");
theUnsafe.setAccessible(true);
// theUnsafe为static final字段
Unsafe unsafe = (Unsafe) theUnsafe.get(null);
// 分配直接内存
long address = unsafe.allocateMemory(1024);
unsafe.freeMemory(address);

由直接内存导致的内存溢出，在Heap Dump文件中不会看见明显的异常情况。如果发现内存溢出后，产生的Dump文件很小，而程序中直接或间接使用了Direct Memory(NIO)，就可以考虑检查直接内存溢出。

通常的垃圾收集日志等记录，并不包含 Direct Buffer 等信息。从JDK 1.8开始，可以使用 Native Memory Tracking(NMT) 特性来进行诊断，可以在程序启动时加上下面参数：

-XX:NativeMemoryTracking={summary|detail}

运行时，采用如下命令交互式对比：

// 打印NMT信息
jcmd <pid> VM.native_memory detail

// 进行baseline，以对比分配内存变化
jcmd <pid> VM.native_memory baseline

// 对比baseline, 显示出各个部分内存的变化
jcmd <pid> VM.native_memory detail.diff

下面案例中，先使用 VM.native_memory 的 baseline 命令，作为对比的参照；当打印出 Begin allocate 后，执行detail.diff，进行对比。

public class DirectMemory {
    public static void main(String[] args) {
        try {
            Thread.sleep(40000);// 进行baseline, 作为比对的参照
            System.out.println("Begin allocate: ...");
            ByteBuffer buffer = ByteBuffer.allocateDirect(1024 * 1024 * 3);    
            Thread.sleep(40000);    
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}