NIO详解（六）：Java堆外内存

1. 前言

最近研究ByteBuffer和DirectByteBuffer。堆外内存是相对于堆内内存的一个概念。堆内内存是由JVM所管控的Java进程内存，我们平时在Java中创建的对象都处于堆内内存中，并且它们遵循JVM的内存管理机制，JVM会采用垃圾回收机制统一管理它们的内存。那么堆外内存就是存在于JVM管控之外的一块内存区域，因此它是不受JVM的管控。下面本博客就来详细介绍以下Java NIO 中的DirectByteBuffer。

2. Linux 内核态和用户态

• 内核态：控制计算机的硬件资源，并提供上层应用程序运行的环境。比如socket I/0操作或者文件的读写操作等
• 用户态：上层应用程序的活动空间，应用程序的执行必须依托于内核提供的资源
• 系统调用：为了使上层应用能够访问到这些资源，内核为上层应用提供访问的接口

内核态由操作系统控制计算机的硬件资源，用户态的程序可以通过一些系统调用，通过上下文切换，由用户态切换到内核态，然后进行相应的操作系统底层系统调用。因此我们可以得知当我们通过JNI调用的native方法实际上就是从用户态切换到了内核态的一种方式。并且通过该系统调用使用操作系统所提供的功能。

2.DirectByteBuffer ———— 直接缓冲

堆内内存存在的问题：由于HeapByteBuffer是存储在JVM 堆中的，所以我们在使用ByteBufffer的时候，如果创建了一个很大的ByteBuffer的时候，那么过大的内存Buffer对于垃圾回收来说造成的影响会很大，JVM新生带会频繁进行Minor GC，进而对程序的性能造成影响。在某些I/O操作下，FilChannelImpl需要通过堆外内存进行数据传输，如果使用HeapByteBuffer的话，FilChannelImpl需要通过将HeapByteBuffer复制到堆外内存，然后进行数据传输。

DirectByteBuffer解决了上述产生的问题：

• 垃圾回收停顿改善：由于DirectByteBuffer是堆外内存，不受垃圾回收机制控制，它直接受操作系统管理。所以减少了大内存Buffer在新生代中，造成JVM新生代进行频繁的垃圾回收。
• 在某些场景下可以提升程序I/O操纵的性能。少去了将数据从堆内内存拷贝到堆外内存的步骤。

DirectByteBuffer是Java用于实现堆外内存的一个重要类，我们可以通过该类实现堆外内存的创建、使用和销毁。

DirectByteBuffer该类本身还是位于Java内存模型的堆中。堆内内存是JVM可以直接管控、操纵。 而DirectByteBuffer中的unsafe.allocateMemory(size);是个一个native方法，这个方法分配的是堆外内存，通过C的malloc来进行分配的。分配的内存是系统本地的内存，并不在Java的内存中，也不属于JVM管控范围，所以在DirectByteBuffer一定会存在某种方式来操纵堆外内存。 下面我们就来分析DirectByteBuffer的创建过程和回收过程。

2. 源码分析 DirectByteBuffer内存分配和回收

2.1 DirectByteBuffer内存分配

在DirectByteBuffer的父类Buffer中有个address属性，address只会被Directbuffer给使用到。之所以将address属性升级放在Buffer中，是为了在JNI调用GetDirectBufferAddress时提升它调用的速率。

 DirectByteBuffer(int cap) {                   // package-private

        super(-1, 0, cap, cap);
        boolean pa = VM.isDirectMemoryPageAligned();
        int ps = Bits.pageSize();
        long size = Math.max(1L, (long)cap + (pa ? ps : 0));
        Bits.reserveMemory(size, cap);

        long base = 0;
        try {
            base = unsafe.allocateMemory(size);
        } catch (OutOfMemoryError x) {
            Bits.unreserveMemory(size, cap);
            throw x;
        }
        unsafe.setMemory(base, size, (byte) 0);
        if (pa && (base % ps != 0)) {
            // Round up to page boundary
            address = base + ps - (base & (ps - 1));
        } else {
            address = base;
        }
        cleaner = Cleaner.create(this, new Deallocator(base, size, cap));
        att = null;



    }

unsafe.allocateMemory(size);分配完堆外内存后就会返回分配的堆外内存基地址，并将这个地址赋值给了address属性。这样我们后面通过JNI对这个堆外内存操作时都是通过这个address来实现的了。

2.2 DirectByteBuffer回收

前面我们说到了DirectByteBuffer是堆外内存，它不由JVM 垃圾回收机制控制。所以JVM 垃圾回收不了DirectByteBuffer分配的内存，那么DirectByteBuffer是如何进行回收的呢？
DirectBuffer内存回收主要有两种方式，一种是通过System.gc来回收，另一种是通过构造函数里创建的Cleaner对象来回收。

System.gc回收

在DirectBuffer的构造函数中，用到了Bit.reserveMemory这个方法，该方法如下

static void reserveMemory(long size, int cap) {
        ······
        if (tryReserveMemory(size, cap)) {
            return;
        }
        ······
        while (jlra.tryHandlePendingReference()) {
            if (tryReserveMemory(size, cap)) {
                return;
            }
        }
        System.gc();

        // a retry loop with exponential back-off delays
        // (this gives VM some time to do it's job)
        boolean interrupted = false;
        try {
            long sleepTime = 1;
            int sleeps = 0;
            while (true) {
                if (tryReserveMemory(size, cap)) {
                    return;
                }
                if (sleeps >= MAX_SLEEPS) {
                    break;
                }

                if (!jlra.tryHandlePendingReference()) {
                    try {
                        Thread.sleep(sleepTime);
                        sleepTime <<= 1;
                        sleeps++;
                    } catch (InterruptedException e) {
                        interrupted = true;
                    }
                }
            }
            // no luck
            throw new OutOfMemoryError("Direct buffer memory");
        } finally {
            if (interrupted) {
                // don't swallow interrupts
                Thread.currentThread().interrupt();
            }
        }
    }

reserveMemory方法首先尝试分配内存，如果分配成功的话，那么就直接退出。如果分配失败那么就通过调用tryHandlePendingReference来尝试清理堆外内存(最终调用的是Cleaner的clean方法，其实就是unsafe.freeMemory然后释放内存)，清理完内存之后再尝试分配内存。如果还是失败，调用System.gc()来触发一次FullGC进行回收(前提是没有加-XX:-+DisableExplicitGC参数)。

Cleaner对象回收

另个触发堆外内存回收的时机是通过Cleaner对象的clean方法进行回收。在每次新建一个DirectBuffer对象的时候，会同时创建一个Cleaner对象，同一个进程创建的所有的DirectBuffer对象跟Cleaner对象的个数是一样的，并且所有的Cleaner对象会组成一个链表，前后相连。

3. 源码分析 FilChannelImpl的read调用

下面我们来看一下为什么在某些I/O操作下，使用DirectBuffer对比HeapByteBuffer的性能会更好。在FileChannelImpl的read方法中进行read操作的时候，会调用IOUtil.read(this.fd, var1, -1L, this.nd) 的read 方法。

public class FileChannelImpl{
    public int read(ByteBuffer var1) throws IOException {
        this.ensureOpen();
        if (!this.readable) {
            throw new NonReadableChannelException();
        } else {
            Object var2 = this.positionLock;
            synchronized(this.positionLock) {
                int var3 = 0;
                int var4 = -1;

                byte var5;
                try {
                    this.begin();
                    var4 = this.threads.add();
                    if (this.isOpen()) {
                        do {
                            var3 = IOUtil.read(this.fd, var1, -1L, this.nd);
                        } while(var3 == -3 && this.isOpen());

                        int var12 = IOStatus.normalize(var3);
                        return var12;
                    }

                    var5 = 0;
                } finally {
                    this.threads.remove(var4);
                    this.end(var3 > 0);

                    assert IOStatus.check(var3);

                }

                return var5;
            }
        }
    }
}

接下来我们继续跟踪源码，找到为什么I/O操作下，使用DirectBuffer对比HeapByteBuffer的性能会更好。

public class IOUtil{

static int read(FileDescriptor var0, ByteBuffer var1, long var2, NativeDispatcher var4) throws IOException {
        if (var1.isReadOnly()) {
            throw new IllegalArgumentException("Read-only buffer");
        } else if (var1 instanceof DirectBuffer) {
            return readIntoNativeBuffer(var0, var1, var2, var4);
        } else {
            ByteBuffer var5 = Util.getTemporaryDirectBuffer(var1.remaining());

            int var7;
            try {
                int var6 = readIntoNativeBuffer(var0, var5, var2, var4);
                var5.flip();
                if (var6 > 0) {
                    var1.put(var5);
                }

                var7 = var6;
            } finally {
                Util.offerFirstTemporaryDirectBuffer(var5);
            }

            return var7;
        }
    }
}

从这段代码中，我们可以看出来如果FileDescriptor操作的ByteBuffer是堆外内存的话，我们直接调用readIntoNativeBuffer将文件从内核缓冲区直接读取到DirectBuffer中。但是如果我们操作的是HeapBytebuffer的话，我们首先构造一个新的DirectBuffer，然后调用readIntoNativeBuffer将文件从内核缓冲区直接读取到DirectBuffer中，最后将这个DirectBuffer复制到HeapByteBuffer之中。所以说，如果我们直接使用DirectBuffer，在进行数据读取的话，就不用将构造出来新的DirectBuffer复制到HeapByteBuffer之中。所以对于大文件来说，我们使用DirectBuffer性能更好。

Q：小伙伴可能回文，那为什么操作系统不直接访问Java堆内的内存区域了？

A：这是因为JNI方法访问的内存区域是一个已经确定了的内存区域地址，那么该内存地址指向的是Java堆内内存的话，那么如果在操作系统正在访问这个内存地址的时候，Java在这个时候进行了GC操作，而GC操作会涉及到数据的移动操作[GC经常会进行先标志-整理算法的操作。即，将可回收的空间做标志，然后清空标志位置的内存，然后会进行一个整理，整理就会涉及到对象的移动，移动的目的是为了腾出一块更加完整、连续的内存空间，以容纳更大的新对象]，数据的移动会使JNI调用的数据错乱。所以JNI调用的内存是不能进行GC操作的。

Q：如上面所说，JNI调用的内存是不能进行GC操作的，那该如何解决了？

A：①堆内内存与堆外内存之间数据拷贝的方式(并且在将堆内内存拷贝到堆外内存的过程JVM会保证不会进行GC操作)：比如我们要完成一个从文件中读数据到堆内内存的操作，即FileChannelImpl.read(HeapByteBuffer)。这里实际上File I/O会将数据读到堆外内存中，然后堆外内存再讲数据拷贝到堆内内存，这样我们就读到了文件中的内存。