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;

}