ThreadLocal的key用弱引用，是为了让ThreadLocal实例在无外部强引用时能被GC及时回收；value用强引用确保数据稳定可见，但需显式调用remove()切断引用链以防内存泄漏。
ThreadLocal 的 key 用弱引用，不是为了“自动防泄漏”，而是为了让 ThreadLocal 实例本身能被及时回收——前提是线程还活着但你已经不再需要它了。真正决定内存是否泄漏的，是 value 的强引用链有没有被主动打断。
弱引用在 ThreadLocal 里管什么
ThreadLocalMap 的 Entry 继承 WeakReference
这一步只解决一个问题：避免 ThreadLocal 对象自己卡在内存里出不去。它不碰 value，也不删 Entry，更不释放 value 占的堆空间。
key 变 null 后会发生什么
Entry 还在 ThreadLocalMap 的数组里，只是 key 是 null；value 仍是强引用，路径是：
Thread → threadLocals（ThreadLocalMap）→ table[i]（Entry）→ value
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
这条链只要线程没结束，就一直有效。GC 看得见 value，但绕不开它——因为它是被强引用着的。
- 普通线程执行完就销毁 → 整个 ThreadLocalMap 被回收 → value 自动释放
- 线程池里的核心线程长期存活 → ThreadLocalMap 持续存在 → key=null 的 Entry 积累 → value 堆积
- get() 和 set() 方法内部会顺带清理附近 key==null 的 Entry，但只是探测式扫描，不保证清干净
怎么配合弱引用真正防泄漏
弱引用只是暴露问题的“探针”，不是兜底方案。要让 value 真正释放，必须显式切断强引用链：
- 每次用完 ThreadLocal，必须调用 remove() —— 它会把 value 设为 null，同时把 key（referent）也设为 null，并触发一次局部清理
- Web 场景推荐在 Filter 或 Interceptor 的 finally 块里 remove()
- 线程池任务中，务必在任务结尾 remove()，不能依赖 lambda 表达式自动结束
- 避免把 ThreadLocal 声明为非 static 的实例字段或匿名内部类，否则容易因对象生命周期短于线程而提前丢失引用
为什么 value 不用弱引用
如果 value 也是弱引用，那它可能在任意一次 GC 时就被回收，导致 get() 返回 null，违背 ThreadLocal “线程内数据稳定可见” 的设计目标。
比如存了一个 UserContext 对象，刚 set 完还没 get，GC 一来就清掉了——业务逻辑直接断裂。所以 value 必须是强引用，可用性优先于自动回收。
