threadlocalmap 的 entry 用弱引用包裹 key 是为防止 key 泄漏，因强引用会阻碍 threadlocal 被回收；但 value 仍为强引用，若不调用 remove()，key 为 null 的脏 entry 中的 value 将长期驻留内存，导致内存泄漏。
ThreadLocalMap 的 Entry 为什么用弱引用包裹 key
因为 ThreadLocal 实例本身常作为栈上局部变量存在，一旦方法结束、引用消失，若 Entry 持有强引用，这个 ThreadLocal 就无法被回收——哪怕它再也不会被访问。JVM 线程不退出时，ThreadLocalMap 又长期存活，就会导致 ThreadLocal 对象堆积，即“key 泄漏”。用弱引用让 GC 能及时回收 key，是止损的第一道设计。
但注意：这只是解决 key 的泄漏，value 仍是强引用——这才是真正踩坑的起点。
为什么 remove() 不调用就大概率内存泄漏
弱引用 key 被回收后，Entry 变成 key == null 的“脏 entry”，但 value 还牢牢挂着。只要线程不结束、ThreadLocalMap 不触发清理逻辑（比如后续调用 set() 或 get()），这些 value 就一直占着堆内存。
常见错误场景：
- 在线程池中复用线程，且业务代码没显式调用
remove() - 使用
try-finally但忘了在finally里调tl.remove() - 异步回调中持有
ThreadLocal，但回调完成路径未清理
示例：
ThreadLocal<String> tl = new ThreadLocal<>();
tl.set("big-object");
// 忘了 tl.remove() —— 这个字符串对象会随线程池线程一起“苟活”
set() 和 get() 会自动清理脏 entry 吗
会，但只清理“当前哈希槽附近”的脏 entry，不是全表扫描。这是性能权衡：避免每次操作都遍历整个 map。
关键点：
-
set()在探测到哈希冲突并向前探查时，会顺手清理遇到的key == null的 entry -
get()在找不到目标 key 但发现脏 entry 时，也会触发一次小范围探测清理 - 但如果线程只调用一次
set()就再也不碰这个ThreadLocal，那脏 entry 就永远不清理
也就是说：依赖自动清理是靠不住的，尤其在低频使用的 ThreadLocal 上。
如何安全使用 ThreadLocal 避免泄漏
核心原则：谁 set，谁 remove；线程复用场景下，remove 是必选项，不是可选项。
实操建议：
- 总是配对使用：
tl.set(x); ...; tl.remove();，别信“反正 GC 会收” - 在线程池 +
ThreadLocal场景下，在任务执行完的统一出口（如Runnable的结尾、过滤器的 finally）调用remove() - 避免在
static字段里直接 newThreadLocal并长期持有——这会让类卸载困难，间接加剧泄漏 - 排查时看 heap dump：搜索
java.lang.ThreadLocal$ThreadLocalMap$Entry，检查大量key == null但value非空的实例
真正难的不是理解弱引用，而是把 remove() 写进每一条可能的退出路径——尤其是异常分支和早期 return。
