ThreadLocal的key是弱引用、value是强引用，因此GC仅回收key，而value仍被线程强引用链持有，若不调用remove()主动清理，易在线程池场景中导致内存泄漏。
ThreadLocal 的 Key 是弱引用，但 Value 是强引用
ThreadLocalMap 中的 Entry 继承自 WeakReference<ThreadLocal>，所以 key（即 ThreadLocal 实例）是弱引用；而 value 字段是普通对象引用，属于强引用。这意味着：GC 发生时，只要没有其他强引用指向该 ThreadLocal 对象，它就会被回收，Entry.key 变成 null；但 Entry.value 仍通过 Thread → ThreadLocalMap → Entry → value 这条强引用链牢牢挂在内存里。
线程长期存活时，失效 Entry 不会自动清理
ThreadLocalMap 确实有惰性清理机制，会在 get()、set()、remove() 时顺手扫描并清理 key == null 的 Entry，但这不是实时、全覆盖的：
- 如果线程执行完任务后不再调用任何 ThreadLocal 方法，就不会触发清理
- 清理只扫哈希桶附近几个位置，不是全表遍历
- 一个 Entry 被标记为“key == null”后，其
value可能永远卡在内存里，直到线程结束
在线程池场景中，线程复用频繁，但很多任务根本不碰 ThreadLocal，这就导致大量“幽灵 value”持续堆积。
为什么不能只靠 GC 回收 ThreadLocal 就万事大吉？
常见误解是：“我把 ThreadLocal 变量设为 null 或让它出作用域，GC 一收，整个 Entry 就没了”。错在忽略了引用链：
-
ThreadLocal对象本身被 GC 后，只是让Entry.key == null - 但
Thread对象还活着 →Thread.threadLocals（即ThreadLocalMap）还存在 →Entry实例还在 →Entry.value仍被强引用 - 除非手动调用
threadLocal.remove()，否则这条链不会断
尤其当 value 是大对象（如 byte[]、StringBuilder、缓存数据）时，泄漏几 MB 很快就累积成 OOM。
remove() 不是可选项，是线程生命周期管理的一部分
调用 remove() 的本质，是主动切断 ThreadLocalMap → Entry → value 这一环。它比 set(null) 更彻底，直接从哈希表中移除整个 Entry。
- 必须放在
try-finally块里，确保异常时也能清理 - 在线程池任务中，应在任务末尾（而非方法末尾）调用，因为方法可能早于线程任务结束
- 不要依赖
ThreadLocal.withInitial()的懒加载来规避 —— 初始化后的 value 一样需要清理
真正危险的不是“用了 ThreadLocal”，而是“用了却不告诉线程：这段数据我已经不需要了”。
