ThreadLocal的Key使用WeakReference是为了防止ThreadLocal对象因被ThreadLocalMap强引用而无法被GC回收，从而避免其本身内存泄漏；但Value仍为强引用，若未显式remove()，在复用线程（如线程池）中会导致value长期滞留。
ThreadLocal 的 Key 为什么是 WeakReference
WeakReference 不是为了“导致泄漏”，而是为了防止 ThreadLocal 对象本身被卡死在内存里。假设 ThreadLocal 的 key 是强引用：你写了 threadLocal = null，但线程还活着，ThreadLocalMap 里的 entry 仍强持有这个 ThreadLocal 实例，它就永远无法被 GC —— 这才是更隐蔽、更难排查的泄漏。弱引用让 key 能及时回收（变成 null），把问题暴露出来，而不是藏得更深。
key=null 后 value 为何还占着内存
因为 ThreadLocalMap.Entry 的 value 字段是普通强引用，不是弱引用或软引用。只要 entry 对象还在（而它属于长期存活的线程的 threadLocals map），value 就一直被强持有。此时 key 是 null，外部代码完全无法访问该 value，但它又不满足 GC 条件 —— 典型的“不可达但不可回收”状态。
- 普通线程执行完就销毁 →
ThreadLocalMap随线程一起回收 → value 自动释放 - 线程池中的核心线程永不退出 →
ThreadLocalMap持续存在 → key=null 的 entry 积累 → value 堆积
set/get/remove 时的清理是“尽力而为”，不是“保证清除”
ThreadLocal 确实会在 set()、get()（未命中时环形查找）、remove() 这些入口尝试扫描并清理 key=null 的 entry，但这些动作都依赖“是否走到那段逻辑”。比如：
- 一个任务只调用
set()一次，之后再没碰这个ThreadLocal→ 清理只发生在 set 当次，且只清理部分槽位（采样清理） - 线程空闲时什么也不做 → 零清理触发
- map 没扩容、没 rehash、没遍历 → 大量 stale entry 永远沉睡
也就是说，清理机制是被动、局部、非全覆盖的，不能当作兜底方案。
为什么线程池场景最危险
线程复用放大了所有问题：
- 每次任务执行
threadLocal.set(new byte[10 * 1024 * 1024])却不remove()，1000 次后就是 10GB 垃圾 - 这些 value 不仅自己占内存，还可能持有其他对象（如
Connection、InputStream），引发连锁泄漏 - GC 日志里看不到明显大对象，但 old gen 持续缓慢上涨，OOM 前几乎没有预警
真正容易被忽略的，不是“要不要 remove”，而是“remove 必须在 finally 或 try-with-resources 中无条件执行”——哪怕业务逻辑抛异常，也得确保清理发生。
