深入理解Java中的引用（三）——DirectByteBuffer与ThreadLoal的垃圾回收
上一篇文章介绍了关于Java中的四种引用类型。本文将介绍这四种类型中的弱引用与虚引用在DirectByteBuffer与ThreadLocal中的应用。
DirectByteBuffer
DirectByteBuffer是java.nio包下面的一个类，该类可以在JVM堆外分配内区域。查看DirectByteBuffer构造函数的源码：
DirectByteBuffer(int cap) { // package-private
.....
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.allocateMemory来分配内存的，而allocateMemory是一个native方法，通过把堆外内存的地址保存在address变量中，这样JVM就可以通过该变量操作堆外内存了。
由于DirectByteBuffer是一块堆外内存，JVM GC的时候如何管理他呢？在构造函数的下方可以看到，DirectByteBuffer会创建一个Cleaner实例，而
Cleaner是PhantomReference的子类，Cleaner就起到了跟踪DirectByteBuffer的垃圾回收过程的作用。在第一篇文章中说到，当Reference状态从pending到enqueue状态时，ReferenceHandler线程将其放入到队列中，在放入队列之前会调用Clean类里的clean()方法
ReferenceHandler(ThreadGroup g, String name) {
super(g, name);
}
public void run() {
for (;;) {
Reference深入clean方法可以看到，首先调用remove方法把自己从链表中删除，这样Cleaner就是一个无指向的对象，坐等被GC回收。然后是调用thunk.run()方法。
public void clean() {
if (remove(this)) {
.....
this.thunk.run();
.....
}
}
继续深入到run方法中，可以看到是用unsafe.freeMemory方法释放堆外内存
public void run() {
if (address == 0) {
// Paranoia
return;
}
unsafe.freeMemory(address);
address = 0;
Bits.unreserveMemory(size, capacity);
}
好了，DirectByteBuffer如何利用虚引用进行垃圾状态的回收先讲到这里，至于为什么要用堆外内存，他的特点和好处，大家可以参考这边文章。
ThreadLocal
看完了虚引用的应用，再看一个弱引用在ThreadLocal中的应用。
如下是ThreadLocal的get方法的源码。ThreadLocal通过ThreadLocalMap来维护线程与实例对象的映射关系。
public T get() {
Thread t = Thread.currentThread();
ThreadLocalMap map = getMap(t);
if (map != null) {
ThreadLocalMap.Entry e = map.getEntry(this);
if (e != null) {
@SuppressWarnings("unchecked")
T result = (T)e.value;
return result;
}
}
return setInitialValue();
}
继续深入到ThreadLocalMap的源码中。ThreadLocalMap通过静态内部类Entry来维护键值关系，Entry继承自WeakReference, Entry中的key是ThreadLocal实例，value就是你想在当前线程中保存的变量。
static class ThreadLocalMap {
static class Entry extends WeakReference> {
/** The value associated with this ThreadLocal. */
Object value;
Entry(ThreadLocal k, Object v) {
super(k);
value = v;
}
}
...
通过上述源代码的分析可以得到下图 （实线代表强引用,虚线代表弱引用）：
在面试的时候，面试官经常会问ThreadLocal是否存在内存泄漏的问题。从上面的图看以看到，key存在一个弱引用，当ThreadLocal的实例设置成null以后，由于没有强引用指向该实例对象，ThreadLocal实例会被回收，避免了ThreadLocal对象无法被回收的问题。但是整体Entry还是存在强引用的，所以不能被回收造成了内存泄漏的问题。
那么如何防止ThreadLocal的内存泄漏的问题呢？
有两种方法。
1、当前线程退出。Entry的强引用链断开，Entry就能被GC回收。这种方法不适合使用线程池的情况。因为线程结束是不会被销毁的，这种情况下就出现了内存泄漏问题。
2、为了减少内存泄漏的可能性，ThreadLocal会在set和get方法中对value做处理。下面以set函数为例。
private void set(ThreadLocal key, Object value) {
Entry[] tab = table;
int len = tab.length;
int i = key.threadLocalHashCode & (len-1);
for (Entry e = tab[i]; e != null; e = tab[i = nextIndex(i, len)]) {
ThreadLocal k = e.get();
if (k == key) {
e.value = value;
return;
}
if (k == null) {
replaceStaleEntry(key, value, i);
return;
}
}
tab[i] = new Entry(key, value);
int sz = ++size;
if (!cleanSomeSlots(i, sz) && sz >= threshold)
rehash();
}
如果k==null, 那么会执行replaceStaleEntry方法将Entry的值设置为null，从而使该Entry变成可回收，通过这种方式防止内存泄漏。具体Treadlocal的使用场景可以参考这篇文章。
总结
本文以DirectByteBuffer和ThreadLocal为例，通过源码分析解释了虚引用与弱引用的使用场景。可以得出这样的结论：虚引用可以跟踪对象垃圾回收的情况，弱引用不影响对象的垃圾回收，你可以通过弱引用随时拿到对象。这也印证了上一篇文章介绍的内容。