本文结合，ThreadLocal内存泄漏 和 DirectByteBuffer释放 讲解 Java 中的 Reference 。
四种引用类型
- 强引用（Strong Reference）：被强引用的对象，GC不能够收集。常见得强引用对象得方式有： 赋值
Object obj = new Object()，集合引用list.add(new Object())等等。 - 软引用（Soft Reference）：被软引用的对象，GC会在即将发生内存溢出时，只要没有对它强引用，就把它纳入GC收集对象内，进行回收，软引用通过
SoftReference来实现，它有两个构造(T reference)和(T reference,ReferenceQueue queue)，和一个get()方法，用于获取引用的对象。 - 弱引用（Weak Reference）：被弱引用得对象，下一次GC时，只要没有对它强引用就会纳入GC收集对象内，进行回收。与
SoftReference相同，有两个构造和一个获取引用对象得方法。 - 虚引用（Phantom Reference）：被虚引用得对象随时可以被GC，并且它不能通过
get()获取到引用对象，这个方法固定返回为null，存在得意义在于，可以在对象被收集时，‘得到通知’ 进而做一些其他工作，例如，DirectByteBuffer就是利用PhantomReference做直接内存得释放工作得。
Reference
强引用（Strong Reference）底层实现无法感知，其他三种（Soft/Weak/Phantom Reference）均继承于 abstract class Reference，他们的两个 构造方法 和 一个 获取引用对象 的方法也 均来自于 Reference。
// SoftReference 简单实现如下
public class SoftReference extends Reference {
public SoftReference(T referent) {
//在构造 Soft/Weak/Phantom Reference 时，一般都需要掉用父级得回调。
super(referent);
this.timestamp = clock;
}
public T get() {
T o = super.get();
if (o != null && this.timestamp != clock)
this.timestamp = clock;
return o;
}
}
Refernece 状态
- Active：最初状态，被 GC 特殊处理，当引用可达性发生变化时，状态会变为
Pending或者Inactive，具体是那个状态，依据于这个Referece在创建的时候是否，绑定了一个ReferenceQueue。 - Pending：在这个状态时，
Reference内部变量Reference会被赋值为当前的引用（这个赋值操作是 JVM 负责的） ，由内部启动得线程掉用它得enqueu方法进入另一个状态。 - Enqueue：将
Reference放入到ReferenceQueue内并唤醒，所有在这个队列上等待得线程， - Inactive：终态，到此为止，这个
Reference再也不能更改其他状态了。
GC“回调/通知”业务线程
Reference 存在一个静态代码块会启动一个线程，私有静态成员 pending 由 垃圾收集器设置，并唤醒这个线程处理相关逻辑。摘要原代码：
public abstract class Reference {
//由 collector 设置，并唤醒下面启动的线程
private static Reference ThreadLocal & WeakReference 的使用
ThreadLocal 本质上是一个门面类。通过它设置value，本质上是，在 Thread 的成员变量 ThreadLocal.ThreadLocalMap threadLocals = null; 中放入 Entry ，其中 k 为这个 ThreadLocal 对象，value 为需要存的数值。这样的话就会有内存泄漏的风险，代码描述如下：
//产生一个threadLocal对象
ThreadLocal从开发角度来说，将 threadLocal = null; => threadLocal.remove() 就可以解决这个问题。从Java语言层面其实ThreadLocal机制也存在其他操作来减少内存溢出的风险。
看一下ThreadLocalMap的实现
static class ThreadLocalMap {
//继承了 WeakRefernce ，Entry的key其实时一个弱饮用
//也就是说，当ThreadLocal没有任何强引用的时候，通过 Reference#get()方法获取key就会是 null
static class Entry extends WeakReference> {
Entry(ThreadLocal k, Object v) {
//k == ThreadLocal
//Entry 的 Key 时 WeakReference，当没有强引用时，会get到null
super(k);
value = v;
}
}
//这个方法内，会移除掉 key == null 的 Entry
//这个方法会在，put 的时候，如果 key 为 null 时调用
private void replaceStaleEntry(ThreadLocal key, Object value,
int staleSlot) {
}
}
简单来说就是，ThreadLocalMap 中 Entry
DirectByteBuffer & PhantomReference 的使用
//设置堆最大最小10m，直接内存最大使用10m
//-Xmx10m -Xms10m -XX:MaxDirectMemorySize=10m
public static void main(String[] args) throws IOException {
//分配10m directbuffer
ByteBuffer buff1 = ByteBuffer.allocateDirect(1024 * 1024 * 10);
//GC之后，在分配10m，这里并不会内存溢出
buff1 = null;
//这个显示调用去掉，其实在直接内存不足的时候，也会自动出发 FullGC
System.gc();
ByteBuffer buff2 = ByteBuffer.allocateDirect(1024 * 1024 * 10);
}
看上面的代码举例，很奇怪的一点是，GC 一般来说只会对 Java堆 以及 MateSpace（1.8 方法区实现）做回收，那为什么直接内存在运行了 System.gc() 之后也仿佛被回收了呢？
DirectByteBuffer 时怎么被释放的呢？
答案在于 DirectByteBuffer 的创建过程，代码如下：
DirectByteBuffer(int cap) { // package-private
...
//关键在于这个 Cleaner，对于 DirectByteBuffer 的虚引用，并且接受一个 Runnable，这里是 Deallocator。
cleaner = Cleaner.create(this, new Deallocator(base, size, cap));
att = null;
}
这个Cleaner其实本质上是一个对 DirectByteBuffer 对象的虚引用，并且还接受了一个 Deallocator 对象（本质上时一个Runnable，核心代码是通过unsafe释放内存）。上面讲过，再 GC 时，收集器一旦发现一个引用可达发生了变化，就会走 GC“回调/通知”业务线程 这一套逻辑（上面讲过了）。从而调用了 Cleaner#clean ，在这个例子中，这个方法，其实就是运行 Dealocator ，最终通过 unsafe.freeMemory(address) 释放内存。
总的来说就是，通过Reference(具体来说是PhantomPeference)的通知/回调机制，在回收引用对象时，运行一段用户代码，调用unsafe.freeMemory(address)释放了直接内存。
除了 ThreadLocal DirectByteBuffer 外，其他利用 Reference 在垃圾回收时，触发一些用户操作的类，还有很多。如：WeakHashMap 利用 WeakReference 防止内存溢出。
上述中，我这里将 Reference这个机制，叫做 GC“回调/通知”业务线程 并不妥当，原谅我已经词穷了，介于这个词语可以直观的反馈这个机制，还请大家见谅。