ThreadLocalMap.Entry用弱引用是为了避免ThreadLocal实例被长期持有导致内存泄漏，而非自动清理；弱引用仅作用于key，value仍为强引用，需配合remove()或set()/get()触发的探测清理机制防止stale entry泄漏。
ThreadLocalMap.Entry 为什么用弱引用？
因为要避免 ThreadLocal 实例被长期持有，导致内存泄漏——不是为了“自动清理”，而是给 GC 一条退路。
典型场景：线程池中复用线程，ThreadLocal 变量在业务逻辑里 set 后没调用 remove()，强引用会让 Entry 的 key 永远不被回收，value（往往更大）跟着一起卡在 ThreadLocalMap 里出不去。
弱引用只作用于 key（即 ThreadLocal 实例），value 仍是强引用。所以 key 回收后，value 是否释放，取决于后续是否触发 expungeStaleEntry 清理逻辑。
- key 是弱引用 → GC 能回收无外部引用的
ThreadLocal实例 - value 不是弱引用 → 避免 value 提前被回收，造成 get() 返回 null 的误判
- 清理依赖
set()/get()/remove()时的探测扫描，不是即时的
Entry 泄漏的真实触发路径
不是“用了弱引用就安全了”，恰恰相反：弱引用让 key 先死，留下 value 悬空，这时若没走清理流程，就形成泄漏。
立即学习“Java免费学习笔记（深入）”；
常见错误现象：OutOfMemoryError: Java heap space，堆 dump 显示大量 ThreadLocalMap$Entry 的 value 占用巨量内存，而 key 为 null。
- Web 应用中，每个请求用
ThreadLocal存用户上下文，但 filter 或拦截器里忘了remove() - 使用
ExecutorService提交任务，任务内 set 了ThreadLocal，但没配 finally remove - 自定义线程池 +
InheritableThreadLocal，子线程未清理，父线程也未清理
set/get/remove 怎么触发清理？
清理不是靠 GC，而是靠 ThreadLocalMap 自己在增删查时顺手扫一遍哈希槽——但只扫“当前冲突链附近”，不是全表扫描。
set() 和 get() 在发现 key == null 的 stale entry 时，会调用 expungeStaleEntry()，往前清、往后探、重哈希；remove() 则直接从当前位置开始清理整个探测链。
-
set()：插入前先探测，遇到 null key 就启动清理，但清理范围有限 -
get()：只在命中 stale entry 时清理该位置及后续可能连带的 stale entry -
remove()：最可靠，主动清除 key 并触发完整链清理，应作为标准配套操作
为什么不能把 value 也设成弱引用？
如果 value 是弱引用，get() 可能随时返回 null，哪怕 ThreadLocal 实例还活着——这违背了 ThreadLocal “线程私有、生命周期可控”的设计契约。
更关键的是：弱 value 会让语义失控。比如你存了一个 Connection，期望它在整个请求周期内有效，结果 GC 在中间某次 pause 就把它收走了，后续 get 出来是 null，程序直接 NPE，完全不可预测。
- value 弱引用 → 行为不可控，违反 ThreadLocal 的“显式生命周期管理”原则
- 当前设计把清理责任交给开发者（调用
remove()），把兜底责任交给 map 自身探测（有限清理） - 真正健壮的做法：always pair
set()withremove()in finally block
remove()，再精巧的弱引用也救不了。 
