Java直接内存分配和释放方式

一. 正常分配，回收由GC负责

添加jvm启动参数:-verbose:gc -XX:+PrintGCDetails -XX:MaxDirectMemorySize=40M 循环执行以下代码，可以看到频繁fullGC.

ByteBuffer buffer = ByteBuffer.allocateDirect(10 * 1024 * 1024);

当然我也找到一种不需要GC回收由程序员自己回收的方式，不推荐使用

((DirectBuffer)buffer).cleaner().clean();

二. 偏方分配,不安全回收内存由程序员自己负责

如果循环执行下面分配内存代码而不释放会OutOfMemory
由于Unsafe是不对外开放的所有使用反射获取theUnsafe属性，第三行f.get(null)能够正确执行的原因是 theUnsafe属性是静态属性。

Field f = Unsafe.class.getDeclaredField("theUnsafe");
f.setAccessible(true);
Unsafe unsafe = (Unsafe)f.get(null);
long pointer = unsafe.allocateMemory(1024 * 1024 * 20);

//释放内存
unsafe.freeMemory(pointer);

原理分析

查看ByteBuffer 源码可知 ByteBuffer.allocateDirect()创建DirectByteBuffer实例，DirectByteBuffer通过Unsafe分配内存，下面具体看一下执行过程。
1. 调用 ByteBuffer.allocateDirect(int cap)
2. 创建DirectByteBuffer：主要分三步，第一步调用Bits.reserveMemory(long size, int cap)) 在函数内部调用System.gc() 通知GC如有必要进行垃圾回收，第一次调用一般不会触发；第二步，调用Unsafe.allocateMemory(long var )方法分配内存；第三步，调用Cleaner.create(Object var0, Runnable var1) 创建Cleaner对象，用于回收内存。
3. Cleaner类继承自PhantomReference< Object>在此处保留Cleaner对象的虚引用。此类中还包含一个静态DirectByteBuffer引用队列用于得知那些虚引用所指向的对象已回收，这是一个很棒的设计因为jvm不知道堆外内存的使用情况，通过DirectByteBuffer对象的回收来间接控制堆外内存的回收。
4. 在 2 中System.gc() 给GC一个调用建议，如果在接下来的堆外内存分配中发现空间不足就会触发fullGC 。可以通过XX:MaxDirectMemorySize=40M来模拟。GC之后，“触发”调用Cleaner.clean() 方法，进而调用Deallocator.run() 在run方法中调用unsafe.freeMemory(long var1)释放堆外内存。
5. 为验证是否因为System.gc() 可在jvm启动参数加入-XX:+DisableExplicitGC禁用该代码。

6. “触发”阶段，事实上是在Reference类中创建了一个叫Reference Handler的高优先级的守护线程监控着这些“引用”指向的对象。该线程执行Reference类的tryHandlePending方法，判断如对象是Cleaner额外调用clean方法释放内存。
c = r instanceof Cleaner ? (Cleaner) r : null;
................
if (c != null) {
c.clean();
return true;
}