java的Reference与DirectBuffer的内存回收
这篇文章出现的原因在于自己一直困惑于java中对DirectBuffer的内存的回收，知道它是可以经由java虚拟机自动管理的，不需要我们自己去手动的释放，但是要知道DirectBuffer的内存独立于jvm，而是直接调用的malloc来分配的，那么也必定需要free来释放。。。莫非虚拟机的gc还有这功能。。。？
其实不然，最终采用的是一种折中的方法来实现的。。。。
在将具体的实现之前先要对java中的Reference比较了解了才可以。。。。
Reference主要是分为4中类型：
（1）strong reference，这个也是我们平时用到的最多的，我们平时申明一个变量，那么它默认就是这种类型，对于这种类型应用的java对象，当且只当当前的运行栈中没有它的引用之后，它就将会被gc掉。。。这也就是我们说的最多的垃圾回收。。
（2）SoftReference。。这是一种比strong reference弱一些的引用类型，当当前虚拟机内存很紧张的时候，那么gc将会将其引用的对象给回收掉。。这也就是说就算我们对对象用SoftReference引用，但是它也可能会被gc给回收了。。。所以这种引用类型非常适合用于实现高速缓存。。。。
（3）WeakReference，它比上面提到的SoftReference还要弱一些。。。只要gc运行了，它被引用的对象就会被回收。。可以用下面的例子来说明：
public void run() { if (address == 0) { // Paranoia return; } unsafe.freeMemory(address); address = 0; Bits.unreserveMemory(size, capacity); }也就是再次调用unsafe将以前申请的内存释放掉。。。。
到这里也就可以知道。当我们定义DirectBuffer类型的对象被释放之后，其底层申请的直接内存也会自动的被释放。。不过这个自动释放的过程算是比较的曲折了。。。。
不过这里有一个问题。。。不知道怎么回事。。。按照道理来说PhantomReference，只要gc启动了，那么PhantomReference类型的对象就应该被gc放到pending链表，然后再由那个后台线程来处理。。。
那么如果真是这样子的话，那么只要gc我们申请的DirectBuffer底层的内存就会被释放掉。。。
但是实际情况不是这样子的，如果我们DirectBuffer对象没有被释放。。就算是gc，底层申请的内存也不会被释放。。那么也就是说gc并没有把继承自PhantomReference的cleaner放到pending链表了。。。这个就与PhantomReference有一定的冲突了吧。。。不过也有可能Cleaner类型做了一些其余的事情吧。。。或者说gc对于Cleaner特殊的对待了。。。
不懂。。。。。