API documentation：PhantomReference (Java SE 15 & JDK 15) (oracle.com)
Phantom reference objects, which are enqueued after the collector determines that their referents may otherwise be reclaimed. Phantom references are most often used to schedule post-mortem cleanup actions.
Suppose the garbage collector determines at a certain point in time that an object is phantom reachable. At that time it will atomically clear all phantom references to that object and all phantom references to any other phantom-reachable objects from which that object is reachable. At the same time or at some later time it will enqueue those newly-cleared phantom references that are registered with reference queues.
In order to ensure that a reclaimable object remains so, the referent of a phantom reference may not be retrieved: The
getmethod of a phantom reference always returnsnull.
如API文档所述，虚引用一般用来做事后清理。为了确保虚引用的referent成为可回收对象之后不被干扰能被顺利清理掉，PhantomReference的get方法直接返回null，而不会返回referent。
这就是虚引用与软引用、弱引用的最大区别。软引用和弱引用的referent变成弱可达之后，通过其get方法还是能够让referent恢复成强可达状态，但是PhantomReference直接堵死了这条路。
除此之外，PhantomReference只有一个构造函数，必须传入ReferenceQueue，以便在referent确定会被回收之后得到一个通知。
public class PhantomReference<T> extends Reference<T> {
/**
* Returns this reference object's referent. Because the referent of a
* phantom reference is always inaccessible, this method always returns
* {@code null}.
*
* @return {@code null}
*/
public T get() {
return null;
}
/**
* Creates a new phantom reference that refers to the given object and
* is registered with the given queue.
*
* <p> It is possible to create a phantom reference with a {@code null}
* queue, but such a reference is completely useless: Its {@code get}
* method will always return {@code null} and, since it does not have a queue,
* it will never be enqueued.
*
* @param referent the object the new phantom reference will refer to
* @param q the queue with which the reference is to be registered,
* or {@code null} if registration is not required
*/
public PhantomReference(T referent, ReferenceQueue<? super T> q) {
super(referent, q);
}
}ReferenceQueue用在什么地方？或者说怎么用ReferenceQueue。
WeakHashMap用ReferenceQueue，是因为entity是强可达的，形如WeakHashMap -> table[] -> entity。
entity extends WeakReference，key作为referent，当key弱可达时entity会被GC处理，即让entity进入创建时关联的ReferenceQueue，随后在expungeStaleEntries方法中通过ReferenceQueue拿到这个entity，然后断开其强可用，最终key被回收，随后继承弱引用的entity也会不可达被回收。
换言之，WeakHashMap使用ReferenceQueue是因为弱引用entity本身强可达，所以在referent（即key）弱可达之后继承弱引用WeakReference的entity最终被放入ReferenceQueue，随后通过ReferenceQueue拿到继承弱引用WeakReference的entity，接着到map.table[]中找到entity，然后断开map.table[] -> entity这条强引用，释放过期失效的entity。
补充：ThreadLocal没有使用ReferenceQueue，他是在get/set/remove的时候通过遍历map.table[]，查找key == null的entity，然后断开这些entity的强引用。
所以这就是ReferenceQueue的使用场景：虽然资源对象referent弱可达（Reference在被GC挂到pending-reference list上的时候还会被clear referent，变成不可达），但如果在应用场景中Reference本身一直强可达，那么当资源对象referent确定会被回收以后，就可以通过队列拿到Reference，然后断开Reference自身的强引用。
对于PhantomReference来说，如果场景中只需要断开PhantomReference的强引用，那确实是ReferenceQueue的使用姿势。但是PhantomReference的主要适用场景往往不是应对Java堆内存资源（SoftReference、WeakReference主要适用场景才是Java堆内存资源），而是什么native memory、文件句柄等。这时候你通过ReferenceQueue拿到PhantomReference是没什么用的。
在之前第二章，谈为什么要Java引用的时候，是希望有一种机制能够让你可以提前规避忘记关闭资源所造成的风险，或者以一种优雅的方式释放资源。
这种“优雅”和“提前规避风险”体现在哪里？
“我写好资源类，你直接用就行了，你不需要关注怎么关闭资源，我连close都不提供。”
回想一下，SoftReference和WeakReference就是这样的，分配给referent的Java堆内存资源，你只要把referent传入SoftReference、WeakReference，GC什么时候回收referent的Java堆内存资源，你需要关注吗？
PhantomReference不同于SoftReference、WeakReference，这俩主要的使用场景是用于回收Java堆内存资源，已经有GC来自动做这个事情。而PhantomReference的主要使用场景并不是用来回收Java堆内存资源，而是堆外的native memory、文件句柄、socket端口等，都是GC不能释放的资源，都需要你去主动close。
所以单纯的想要依靠虚引用来做事后清理是有难度的，因为关闭资源的信息在referent中，而你根本拿不到虚引用的资源对象referent，你只能通过ReferenceQueue拿到PhantomReference。但仔细想想，你拿到一堆PhantomReference有个毛用？referent被GC干掉了，但是分配给referent的native memory、socket端口、文件句柄等可都挂在JVM进程上，referent被GC回收了，这些资源释放的入口也被断掉了，这波反向操作就如同打开了资源泄露的大门。
所以，不应该、也不建议直接使用PhantomReference，而是要自己新建一个子类去继承PhantomReference（为什么这么做，请继续往下看）。出于个人朴素的情感，我觉得java.lang.ref.PhantomReference应该定义成抽象类，这样能更大程度上避免误用。
假设要释放堆外的native memory，要怎么优雅和提前规避？
在Java中，使用native memory要借助于jdk.internal.misc.Unsafe：
分配native memory：
初始化native memory：
释放native memory：
常规的做法是是抽象一个NativeMemory类，有一个属性long address，三个方法allocateMemroy、setMemroy、freeMemory。为了读写这片内存，你至少还得有一个属性long offset的偏移地址和read(size, byte[])/write(size, byte[])方法，read(size, byte[])中address+offset等于读操作的起始地址，读size个字节，读完之后offset=offset+size，write方法同理。
调用方拿到NativeMemroy，依次调用allocateMemory、setMmemory，然后read(size, byte[])/write(size, byte[])，操作完native memory之后，一定不要忘记freeMemory，否则就内存泄漏。
这样可以用，但是这不满足要求，调用方是有可能忘记调用freeMemory从而导致native memory泄露。我们希望达到的效果是调用方只管调用，不用关注怎么释放资源，不需要提供freeMemory方法。
要优雅、要提前规避，这时候你需要PhantomReference，因为Java引用机制能够让你可以提前规避忘记关闭资源所造成的风险，或者以一种优雅的方式释放资源。
同样和上例抽象一个一模一样的NativeMemory，在NativeMemory内部抽象一个Metadata extends PhantomReference，如以下示例的伪代码：
class NativeMemory {
// 内存基址
private long address;
// 当前操作的偏移地址
private long offset;
NativeMemory(int size) {
long address = allocateMemory(size);
setMemory(address, size, (byte)0);
// 这里会将继承虚引用的Metadata挂到静态链表head上，避免虚引用Metadata不可达被GC掉，从而导致Java引用的机制中断
// 其中NativeMemory作为referent
// address是释放native memory的基址指针
new Metadata(this, address);
}
allocateMemory();
setMemory();
read();
write();
// -------------------------------------
static class Metadata extends PhantomReference {
private static ReferenceQueue queue = new ReferenceQueue();
// head和next属性是为了保证虚引用Metadata不变成不可达，从而破坏Java引用机制
private static Metadata head;
private Metadata next;
private long address;
Metadata(object referent, long address){
super(referent, queue);
this.address = address;
add(this);
}
static synchronized add(Metadata md) {
if(null != head)
md.next = head;
head = md;
}
// 释放native memory
public void clean(){
Unsafe.freeMemory(address);
}
static class FreeNativeMemroyThread extends Thread {
public void run(){
while(true){
// 把Metadata从head链表上摘下来
// 然后调用其clean方法
}
}
}
// 启动FreeNativeMemroyThread
// 该线程的逻辑是拿到queue中的Metadata，并调用其clean方法释放native memory
static {
new FreeNativeMemoryThread().setDaemon(true).start();
}
}
}代码逻辑是这样的：
这样一顿操作下来，借助于Java引用机制，调用方就不再需要关注native memory的释放。
这份伪代码能满足要求，遗憾的是并不通用，因为清理资源的逻辑和引用强绑定。如果可以将清理资源的动作封装成规范，让不同调用方按照规范实现自身的清理逻辑，然后传入引用对象，让FreeNativeMemoryThread线程去调用这些自定义的清理逻辑，这就能满足多方需求。
实际上，jdk.internal.ref.Cleaner已经这样做了。
在介绍jdk.internal.ref.Cleaner之前，我们再回顾一下虚引用的处理流程。
虚引用的处理流程其实和弱引用是一样的，在JVM中不会像软引用那样需要特殊处理。当GC发生的时候，软引用在ReferenceProcessor::discover_reference中会根据配置的软引用清除策略做出是否清理的判断；而虚引用和弱引用一样，只要发生GC，在ReferenceProcessor::discover_reference中直接就往下走处理逻辑，并没有什么特殊判断。
如第二章Reference中Java引用的处理流程所述，虚引用的处理流程：
General-purpose phantom-reference-based cleaners.
Cleaners are a lightweight and more robust alternative to finalization. They are lightweight because they are not created by the VM and thus do not require a JNI upcall to be created, and because their cleanup code is invoked directly by the reference-handler thread rather than by the finalizer thread. They are more robust because they use phantom references, the weakest type of reference object, thereby avoiding the nasty ordering problems inherent to finalization.
A cleaner tracks a referent object and encapsulates a thunk of arbitrary cleanup code. Some time after the GC detects that a cleaner's referent has become phantom-reachable, the reference-handler thread will run the cleaner. Cleaners may also be invoked directly; they are thread safe and ensure that they run their thunks at most once.
Cleaners are not a replacement for finalization. They should be used only when the cleanup code is extremely simple and straightforward. Nontrivial cleaners are inadvisable since they risk blocking the reference-handler thread and delaying further cleanup and finalization.
从源码类注释可知：
jdk.internal.ref.Cleaner:
正如注释所述，dummyQueue的存在只是因为Cleaner extends PhantomReference，而PhantomReference的构造函数中要求必须传入一个ReferenceQueue，实际上dummyQueue永远是一个空队列，不会放入任何Reference节点。
回顾一下reference-handler线程处理pending-reference list的逻辑，如果节点是jdk.internal.ref.Cleaner，那么直接调用其clean方法走自定义的清理逻辑；否则走进队列的逻辑。所以，如果是jdk.internal.ref.Cleaner，那么就不会走到入队列的逻辑。因此dummyQueue只是因为PhantomReference的构造函数要求，而实际上不会有Cleaner进入队列，它始终是一个空队列。
通过first、prev、next三个属性，在Cleaner中维护了一条双向链表。
Cleaner机制可以简化成一个多生产单消费的模型，所以add、remove方法操作这条双向链表的时候需要同步。
add：头插法将新节点加入双向链表
remove：
这个过程并不复杂。但是你需要深入思考的是：为什么需要这条双向链表？
这条双向链表看似多余，实则必须，因为需要这条双向链表来保证Java引用机制的正常运行。
有两个原因：
将System.gc()换到phantomReference = null之前，通过queue.poll就能拿到phantomReference。两者的区别就是GC的时候，phantomReference是不是强可达的，不是那么会被当做垃圾清理掉，是那么就走Java引用流程。
整个jdk.internal.ref.Cleaner就两个pubic的方法，一个是create，另一个就是clean了。
create是整个Cleaner的入口。入参的object作为虚引用的referent，thunk封装了对资源对象referent的自定义清理逻辑。
在clean方法中，会调用remove将Cleaner从双向链表摘除，然后调用create传入的thunk执行自定义的清理资源代码。
而chunk是一个Runnable，关闭资源所需的元数据都需要封装在其中。
jdk.internal.ref.Cleaner的实现和使用并不复杂，看一个java.nio.DirectByteBuffer的例子基本上就能融会贯通。
整个流程很简单：
自定义释放资源的Deallocator的代码也很简单，重点关注run方法：address是释放native memory所需的元数据基址地址，size和capacity是JVM内部用于记录native memory使用情况的数值，最终会受到-XX:MaxDirectMemorySize的配置影响：
private static class Deallocator
implements Runnable
{
private long address;
private long size;
private int capacity;
private Deallocator(long address, long size, int capacity) {
assert (address != 0);
this.address = address;
this.size = size;
this.capacity = capacity;
}
public void run() {
if (address == 0) {
// Paranoia
return;
}
UNSAFE.freeMemory(address);
address = 0;
Bits.unreserveMemory(size, capacity);
}
}当你看到这里迫不及待的想要写个demo调用jdk.internal.ref.Cleaner来感受一下的时候，你发现JDK不让你调用Cleaner。就像Unsafe一样，因为JDK的安全机制，你不能直接调用。
原因有二：
因此我建议别想着像Unsafe那样通过反射调用，而是应该仿照jdk.internal.ref.Cleaner的实现，在自己的应用中写一个Cleaner出来释放应用资源。