ThreadLocal 的 key 设为弱引用是为了避免阻断 GC 回收 ThreadLocal 实例，防止因线程长期存活导致内存泄漏；value 保持强引用以保障语义一致性，其清理依赖 ThreadLocalMap 的探测式清理机制和显式 remove() 调用。
ThreadLocal 的 key 为什么是弱引用
因为 ThreadLocal 作为 Map 的 key，必须避免阻断 GC 对它的回收——否则只要线程不结束，ThreadLocal 实例就永远无法被回收，哪怕业务代码早已不再持有它。
Java 的 ThreadLocalMap 内部使用的是自定义哈希表，其 Entry 继承自 WeakReference<threadlocal></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免费学习笔记（深入）”；
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 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”，包括异常路径。
