Java 四种引用类型与 ThreadLocal 内存泄漏

TL;DR（30 秒扫完）

• 四种引用：强（默认）/ 软（内存敏感缓存）/ 弱（下次 GC 回收）/ 虚（对象死亡钩子）
• 回收优先级：虚 < 弱 < 软 < 强
• 典型场景：软→LRU 缓存；弱→ThreadLocal Key、WeakHashMap；虚→DirectByteBuffer Cleaner
• ThreadLocal 内存泄漏陷阱：Key 用弱引用可回收，但 Value 仍强引用，需手动 remove()
• PhantomReference.get() 永远返回 null——它不是"引用对象"，而是"监听对象死亡"

关键结论

完整讲解（费曼四步）

STEP 1 · 概念

STEP 2 · 大白话

类比：把对象比作"员工"，把 GC 比作"HR"。强引用像"编制内员工"，HR 不主动裁；软引用像"外包员工"，公司预算紧张就先裁；弱引用像"临时工"，只要 HR 来巡视就裁；虚引用像"离职顾问"，其实没工作，但会通知 HR 他离职了。

STEP 3 · 底层

四种引用对照

ThreadLocal 内存泄漏的真相

// 简化后的 ThreadLocalMap 结构
Entry extends WeakReference<ThreadLocal<?>> {
  Object value;   // Value 是强引用！
}

• Key 是 WeakReference：线程不死时让 Key 可回收（避免 ThreadLocal 对象本身泄漏）
• Value 是强引用：Key 被回收后，Value 依然占用内存 → "幽灵键"泄漏
• 解决：手动 try-finally 包裹 + ThreadLocal.remove()

threadLocal.set(value);
try {
  // 使用
} finally {
  threadLocal.remove();   // 关键！
}

PhantomReference 的正确用法

ReferenceQueue<Object> queue = new ReferenceQueue<>();
PhantomReference<Object> phantom = new PhantomReference<>(obj, queue);

// phantom.get() 永远返回 null
// 对象被 GC 时，phantom 会被加入 queue
// 消费 queue 得到"对象死亡通知"

// 典型场景：DirectByteBuffer Cleaner 内部实现

WeakHashMap 使用陷阱

• WeakHashMap 的 Key 用弱引用，Value 是强引用
• 单独使用仍可能泄漏（Value 一直持有）
• 依赖 GC 触发时机，不能保证立即释放

STEP 4 · 简化

一句话总结：四种引用 = 四种回收时机。虚<弱<软<强。ThreadLocal 用弱引用做 Key 但 Value 强引用，必须手动 remove()。生产环境缓存用 Caffeine/Guava。

• 强：常规对象，永不 GC
• 软：内存紧张才 GC（软引用 = 内存缓存）
• 弱：下次 GC 就 GC（弱引用 = ThreadLocal Key）
• 虚：只收通知，get 永远 null（虚引用 = DirectByteBuffer 清理）

常见误区

延伸追问

速查表

四种引用: 强（默认）> 软（缓存）> 弱（下次GC）> 虚（死亡钩子）
回收优先级: 虚 < 弱 < 软 < 强
典型场景: 软→LRU / 弱→ThreadLocal Key / 虚→DirectByteBuffer
ThreadLocal 泄漏: Key 弱引用 / Value 强引用 / 手动 remove()
生产缓存: Caffeine 或 Guava Cache（不必裸用引用类型）

Anki 候选卡片

关联题目

关联知识

• JVM 内存模型
• JVM GC 算法
• 主题地图