ThreadLocal 的 key 设为弱引用是为了避免阻断 GC 回收 ThreadLocal 实例，防止因线程长期存活导致内存泄漏；value 保持强引用以保障语义一致性，其清理依赖 ThreadLocalMap 的探测式清理机制和显式 remove() 调用。
ThreadLocal 的 key 为什么是弱引用
因为 ThreadLocal 作为 Map 的 key，必须避免阻断 GC 对它的回收——否则只要线程不结束，ThreadLocal 实例就永远无法被回收，哪怕业务代码早已不再持有它。
Java 的 ThreadLocalMap 内部使用的是自定义哈希表，其 Entry 继承自 WeakReference<ThreadLocal>，key 是弱引用，value 则是强引用。这样设计下，当外部不再持有某个 ThreadLocal 实例时，GC 可以在下次运行时回收该 key，后续通过 set/get 触发的探测式清理（expungeStaleEntry）就能顺带把对应 value 也一并清除。
- 不是为了“让 value 更快被回收”，而是为了不让 key 成为 GC 根路径上的强引用节点
- 弱引用只作用于 key，value 仍需靠
ThreadLocalMap自身的清理逻辑来释放 - 如果 key 是强引用，哪怕你把
ThreadLocal变量设为null，只要线程还活着，这个ThreadLocal就一直被 map 引用着，造成内存泄漏
为什么 value 不是弱引用
value 必须保持强引用，否则会破坏语义一致性：你调用 set(x) 后，期望后续 get() 能稳定返回 x，而不是某次 GC 后突然变成 null 或触发重新初始化。
弱引用 value 会导致不可预测的行为，比如在线程池场景中，一个被复用的线程反复执行不同任务，若 value 是弱引用，上个任务存的数据可能在中途就被回收，下个任务读到的就是空或默认值，完全违背 ThreadLocal “线程隔离存储”的契约。
立即学习“Java免费学习笔记（深入）”；
- value 弱引用 → 行为不可控，和 API 设计目标冲突
- value 强引用 + key 弱引用 → 把清理责任交给 map 自身的探测机制，既保语义又防泄漏
- 代价是：如果忘记调用
remove()，且线程长期存活（如线程池），value 会滞留，直到 map 扩容/探测时才被清理
ThreadLocal 内存泄漏的真实诱因
泄漏根源从来不是“key 是弱引用”，而是 value 在 key 被回收后没被及时清理，且线程持续复用 —— 典型于 Web 容器、线程池等长生命周期线程场景。
常见错误现象：OutOfMemoryError: Java heap space，堆 dump 显示大量 ThreadLocalMap$Entry 持有已废弃业务对象（如 UserContext、RequestInfo），而对应的 ThreadLocal 实例在堆里找不到强引用链（即已被 GC）。
- 静态
ThreadLocal变量本身不会泄漏，但它的 value 会，尤其当 value 是大对象或持有其他对象引用时 -
set(null)没用，必须调用remove()；remove()本质是清空当前线程ThreadLocalMap中该 key 对应的 entry，并向前探测清理 stale entries - 线程池中，建议在任务执行前后用 try-finally 包裹
remove()，例如：在Runnable的run()开头tl.set(...)，结尾tl.remove()
GC 可达性分析时 ThreadLocalMap 的实际行为
判断一个 ThreadLocal 是否能被回收，关键看从 GC Roots 出发是否存在强引用链。线程栈帧里的局部变量、静态字段、JNI 引用等是 Roots；而 Thread 对象持有一个 ThreadLocalMap，该 map 的每个 Entry 的 key 是弱引用，所以不构成强引用链。
也就是说：只要代码中不再有强引用指向某个 ThreadLocal 实例（比如把它赋值为 null，或所在类被卸载），那它在下一次 GC 时就满足回收条件，不管那个线程是否还活跃。
- GC 不会主动扫描
ThreadLocalMap清理 stale entries，清理动作只发生在get/set/remove等操作中 - 如果你只写不读，且从不调用
remove()，stale entry 和它的 value 可能长期驻留，直到 map rehash 或线程结束 - 不要依赖 GC 来“兜底”清理 value，
remove()是唯一可控、明确的释放时机
真正容易被忽略的，是线程复用场景下对 remove() 的调用时机和覆盖完整性——不是“用了 ThreadLocal 就要记得 remove”，而是“每次可能写入 value 的分支，都得配对 remove”，包括异常路径。
