为何Java的Cleaner采用双向链表而非ConcurrentHashSet？

Java底层的Cleaner使用双向链表存储PhantomReference，直到其引用对象变为虚可达状态。当Cleaner的守护线程从ReferenceQueue中取出并移除一个PhantomReference，同时从链表中删除它时，整个链表必须被锁定（移除代码在链表上使用@synchronized修饰）。

相比之下，ConcurrentHashMap不仅能提供对PhantomReference的O(1)访问，还支持多个清理线程同时从映射中移除作为键的PhantomReference，实现并发修改。

那么Java选择双向链表方案的原因是什么？具体可以从这几点分析：

• 单线程场景下的极简实现
  Cleaner从设计之初就只依赖单个守护线程处理清理逻辑，不存在多线程并发修改链表的需求。双向链表的实现极其简单，不需要引入ConcurrentHashMap这类复杂并发容器的额外开销——比如哈希计算、分段锁或CAS操作的成本，对于轻量级的清理任务来说，这种极简实现反而更高效。

• 避免哈希冲突与额外内存开销
  若将PhantomReference作为键存入ConcurrentHashMap，需要处理哈希冲突问题，这会引入链表或红黑树的额外结构，反而增加了内存占用。而双向链表本身就是线性存储，对于Cleaner这种需要跟踪所有待清理引用的场景，线性结构的内存开销更低，也不需要维护哈希表的额外元数据。

• 与引用处理逻辑的天然适配
  Cleaner的清理流程是：当对象变为虚可达时，PhantomReference会被自动入队ReferenceQueue，守护线程只需从队列取出引用，再到链表中找到并删除它。由于守护线程是单线程操作，遍历链表的成本在实际场景中可以忽略——毕竟大多数应用中Cleaner的待清理引用数量并不会特别大，线性遍历的性能完全够用。

• 历史设计的兼容性考量
  Cleaner是JDK早期就存在的机制，而ConcurrentHashMap是在JDK 1.5才引入的。早期JDK设计时，优先选择了更成熟、更简单的双向链表方案，后续也没有必要为了单线程场景替换成更复杂的并发容器，保持原有实现可以避免兼容性问题。

内容的提问来源于stack exchange，提问作者IronWidget