弱引用key是设计权衡而非bug，旨在显性化内存泄漏问题；真正泄漏的是强引用的value，尤其在线程池中因threadlocalmap长期存活且惰性清理不彻底而加剧；必须通过try-finally调用remove()主动清除entry。
弱引用Key不是bug，而是设计权衡
ThreadLocal把Key设为弱引用，本意是防止ThreadLocal对象本身被“卡死”在内存里。如果Key用强引用，哪怕你写了threadLocal = null，只要ThreadLocalMap还活着，GC就永远收不走它——那才是更隐蔽、更难排查的泄漏。弱引用让Key能及时释放，把问题显性化：key=null了，说明这个ThreadLocal已经失效；但value还在，且没人能访问它。
真正泄漏的是Value，不是Key
Entry结构中，Key是WeakReference包装的，Value却是普通强引用。一旦Key被GC回收，Entry变成key == null，而value仍通过这条链牢牢挂住：Thread → ThreadLocalMap → Entry → value。只要线程不死（比如线程池里的核心线程），value就始终可达，GC无法回收。尤其当value是byte[]、JSON缓存、数据库连接上下文这类大对象时，几次任务下来就可能堆积上百MB。
线程池让问题雪上加霜
- 线程长期复用，ThreadLocalMap永不销毁
- 很多任务压根不调用get/set/remove，清理机制根本没机会触发
- ThreadLocalMap的“惰性清理”只扫局部槽位，不是全表扫描，漏掉大量stale entry
- value还可能持有外部资源（如流、连接、监听器），引发连锁泄漏
remove()不是补丁，是使用契约
调用threadLocal.remove()的作用，是主动从ThreadLocalMap中移除整个Entry，切断value的强引用链。它必须放在try-finally块里，确保任务执行无论成功或异常都能清理。静态声明+封装clear方法+在任务出口统一调用，才是线上系统推荐的落地方式。依赖“等GC自动处理”或“靠set(null)代替remove”，等于把内存安全交给随机性。
