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主動進釋放，那麼我們就可以控制這部分內存了。