DirectByteBuffer内存释放原理

Unsafe类的介绍

要了解DirectByteBuffer底层，我们需要了解一个Java里面的Unsafe类，这个类不能直接获取，只能通过反射的方式获取，对应代码如下：

import sun.misc.Unsafe;
import java.io.IOException;
import java.lang.reflect.Field;
public class Jvm1_27 {
    static int _1G=1020*1024*1024;
    public static void main(String[] args) throws IOException {
        Unsafe unsafe=getUnsafe();
        //分配内存
        long base=unsafe.allocateMemory(_1G); //返回直接内存分配的地址
        unsafe.setMemory(base,_1G,(byte)0);
        System.in.read();
        //释放内存
        unsafe.freeMemory(base);
        System.in.read();
    }
    public static Unsafe getUnsafe(){
        try{
            Field f=Unsafe.class.getDeclaredField("theUnsafe");
            f.setAccessible(true);
            Unsafe unsafe=(Unsafe)f.get(null);
            return unsafe;
        }catch (NoSuchFieldException |IllegalAccessException e){
            throw new RuntimeException();
        }
    }
}

代码中的unsafe.freeMemory(base);便是对内存释放。

DirectByteBuffer分配源码跟踪

我们跟踪ByteBuffer.allocateDirect(_2G);的具体实现，在ByteBuffer中有如下代码：

 public static ByteBuffer allocateDirect(int capacity) {
        return new DirectByteBuffer(capacity);
    }```
进一步跟踪我们的DirectByteBuffer构造方法：

```java
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来分配内存：

base = unsafe.allocateMemory(size);

内存的释放跟踪

我们找到了分配内存的地方，但是还是没有找到释放的地方，我们看最后一行代码：

        cleaner = Cleaner.create(this, new Deallocator(base, size, cap));

进一步跟踪Cleaner的实现：

public class Cleaner extends PhantomReference<Object> {
    private static final ReferenceQueue<Object> dummyQueue = new ReferenceQueue();
    private static Cleaner first = null;
    private Cleaner next = null;
    private Cleaner prev = null;
    private final Runnable thunk;

我们发现Cleaner是一个虚引用的方法，Cleaner.create方法中注册了一个Deallocator的类，我们查看一下Deallocator中的关键部分：

 public void run() {
            if (address == 0) {
                // Paranoia
                return;
            }
            unsafe.freeMemory(address);
            address = 0;
            Bits.unreserveMemory(size, capacity);
        }

我们看到了真正释放内存的方法，这里需要一个知识，就是虚引用。Cleaner类继承了PhantomReference，这个在Java叫做虚引用，这个在后面讲四种引用类型的时候专门讨论，我们现在需要知道的是当jvm执行gc的时候，run方法会被触发，也就是会执行我们的释放内存的方法 unsafe.freeMemory(address)，这个就是内存释放的原因。

内存释放的风险

System.gc();在jvm中其实是fullgc，是一次很耗时的操作，一般在实际应用中会增加-XX:+DisableExplicitGC 指令禁用显示回收内存。这种时候DirectByteBuffer的内存回收将会不被控制了。但是我们把System.gc打开的话，显然也不现实的。
可以想到的办法就是，我们还是需要会到最本质的操作上面，利用unfase的api主动进释放，那么我们就可以控制这部分内存了。