一. 正常分配,回收由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;
}