ThreadLocal内存泄漏是怎么回事

导致原因

ThreadLocalMap 的 Key 是 弱引用，但 Value 是强引用。

如果一个线程一直在运行，并且 value 一直指向某个强引用对象，那么这个对象就不会被回收，从而导致内存泄漏。

怎么解决

很简单，使用完 ThreadLocal 后，及时调用 remove() 方法释放内存空间。

那为什么 key 要设计成弱引用？

弱引用的好处是，当内存不足的时候，JVM 能够及时回收掉弱引用的对象。

比如说：

WeakReference key = new WeakReference(new ThreadLocal());

key 是弱引用，new WeakReference(new ThreadLocal()) 是弱引用对象，当 JVM 进行垃圾回收时，只要发现了弱引用对象，就会将其回收。

一旦 key 被回收，ThreadLocalMap 在进行 set、get 的时候就会对 key 为 null 的 Entry 进行清理。

加深理解

这是一个非常经典且容易误解的问题，涉及到 ThreadLocal 的实现机制和 JVM 的垃圾回收行为。我们逐步解析你提出的问题：

---

一、你的理解是对的部分

是的，ThreadLocalMap 中的 key 是弱引用（WeakReference<ThreadLocal>），目的是为了避免因为强引用导致的内存泄漏。

static class Entry extends WeakReference<ThreadLocal<?>> {
    Object value;
}

这意味着：

• 当某个 ThreadLocal 实例没有强引用指向它时，它的弱引用 key 会被 GC 回收。
• 一旦 key 被 GC 回收，其对应的 Entry 就成了 key 为 null，value 还存在的 Entry。

---

二、问题关键：value 是强引用，不会被 GC 自动回收

虽然 key 是弱引用会被 GC 回收，但 value 是正常的强引用。

这就意味着：

• 即使 key（即 ThreadLocal 实例）被 GC 了，value 依然强引用存在。
• 如果你没有调用 ThreadLocal.remove()，value 对应的对象（比如大对象、线程绑定资源等）就一直挂在线程的 ThreadLocalMap 中。

这块内存就永远无法释放，只要线程活着，它就存在。

---

三、ThreadLocal 为什么容易导致 OOM？

原因就在于线程生命周期和 value 的强引用：

1. 线程是长生命周期的（如线程池中的线程）
2. ThreadLocal 的 key 被 GC 了，但 value 没有手动 remove
3. value 引用着大对象或资源（如 DB 连接、Buffer、Map 等）
4. JVM 无法自动清理 value，导致内存泄漏，最终 OOM

---

四、实际情况举例

ThreadLocal<byte[]> threadLocal = new ThreadLocal<>();
threadLocal.set(new byte[1024 * 1024 * 10]); // 10MB

// 不调用 remove，也没有外部引用 threadLocal
threadLocal = null;

即使你把 threadLocal 设为 null（key 会被 GC 回收），但 value（10MB 的数组）依旧挂在线程的 ThreadLocalMap 中，无法被回收。

---

五、如何避免这种 OOM 风险？

1. 手动调用 ThreadLocal.remove()，在使用完 ThreadLocal 后清理它：

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

2. 使用阿里巴巴 Java 开发手册推荐的做法，必须 remove。

3. 避免在 线程池线程 中随意使用 ThreadLocal，除非你确保每次任务之后都清除。

---

六、总结

元素	引用类型	GC后会怎样
key (ThreadLocal)	弱引用	没有外部强引用会被 GC
value	强引用	不会自动 GC，需手动 remove

即使 key 被 GC，value 仍然存在，只要线程没销毁，value 就不会释放，造成内存泄漏，最终可能 OOM。

---

你要继续深入看 ThreadLocalMap 的 expungeStaleEntries() 机制吗？