threadlocal 防泄漏靠自身 threadlocalmap 的弱引用 key 设计 + 显式 remove()，而非 weakhashmap；weakhashmap 无法实现线程隔离，且其弱引用机制对 threadlocal 泄漏无帮助。
WeakHashMap 本身不直接用于 ThreadLocal 缓存清洗，它和 ThreadLocal 是两个独立机制，不能混用。真正防止 ThreadLocal 内存泄漏的核心不是 WeakHashMap，而是 ThreadLocal 自身的 ThreadLocalMap 中 key 的弱引用设计 + 显式 remove() 配合。
ThreadLocal 的“弱引用 key”不是 WeakHashMap
很多人误以为 ThreadLocal 内部用了 WeakHashMap，其实不然：
- ThreadLocalMap 是自定义哈希表，不是 HashMap 或 WeakHashMap 的子类
- 它的 Entry 继承自
WeakReference<threadlocal></threadlocal>，仅对 key（即 ThreadLocal 实例） 使用弱引用 - value 始终是强引用 —— 这正是泄漏根源：key 可被回收，value 却卡住不放
- WeakHashMap 的 key 是弱引用、value 也是强引用，且它清理依赖 GC 后的 expungeStaleEntries() 主动扫描，而 ThreadLocalMap 的类似清理只在 set/get/remove 时「局部触发」，不保证彻底
为什么不能用 WeakHashMap 替代 ThreadLocal 做线程本地缓存
WeakHashMap 无法实现线程隔离：
- 它是全局共享的 Map，所有线程读写同一份数据，完全违背 ThreadLocal “每线程一份副本” 的设计目标
- 即使把 WeakHashMap 放进 ThreadLocal 里（如
ThreadLocal<weakhashmap>></weakhashmap>），也只是把 WeakHashMap 当作 value 存储——此时 WeakHashMap 自身的弱引用 key 机制对防止 ThreadLocal 泄漏毫无帮助 - 反而增加复杂度：WeakHashMap 的 entry 清理时机不可控，还可能因 GC 延迟导致缓存意外失效
真正起作用的清洗机制只有三个动作
ThreadLocal 缓存的可靠清洗，靠的是开发者主动干预，而非依赖任何自动回收机制：
- 声明为 static final：确保 ThreadLocal 实例本身不会被提前回收，避免 key==null 的脏 entry 出现
- 每次使用后调用 remove()：在 finally 块或 try-with-resources 结尾执行，立即切断 value 的强引用链
- 避免存大对象：只存 ID、token、轻量标识等，而不是 UserContext、Connection、DTO 等持有长生命周期引用的对象
Spring 等框架的实践也印证这一点
比如 Spring 的 @RequestScope Bean，底层就是 ThreadLocal，但它并不依赖 WeakHashMap：
- 靠 Servlet 容器在请求结束时回调
RequestContextHolder.resetRequestAttributes() - 该方法内部调用
threadLocal.remove()，完成显式清理 - 若你自定义 Filter 或 Interceptor，也必须手动做同样操作，否则泄漏必然发生
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
