ThreadLocal 通过 ThreadLocalMap 实现线程局部变量隔离，但因 key 弱引用、value 强引用，未及时 remove 易致内存泄漏；安全使用需坚持 static final 声明、配套 try-finally remove、线程池中显式清理。
ThreadLocal 是 Java 中实现线程局部变量的核心工具，它能让每个线程拥有独立的变量副本，天然避免并发读写冲突。但若使用不当，极易引发内存泄漏——尤其在使用线程池时。关键在于理解其底层结构（ThreadLocalMap）、正确生命周期管理，以及主动清理。
ThreadLocal 的隔离原理：每个线程独享副本
ThreadLocal 并不直接存储值，而是作为 key 在当前线程的 ThreadLocalMap 中查找或设置对应 value。每个 Thread 对象内部持有一个 ThreadLocalMap（弱引用 key + 强引用 value），因此不同线程调用 get()/set() 操作的是各自 Map 中的条目，互不影响。
- set() 时：以当前 ThreadLocal 实例为 key，存入当前线程的 ThreadLocalMap
- get() 时：从当前线程的 ThreadLocalMap 中按该 ThreadLocal 实例查找 value
- remove() 时：显式删除当前线程 Map 中该 key 对应的 entry，释放 value 引用
内存泄漏的根本原因：value 强引用 + key 弱引用失效
ThreadLocalMap 的 key 是 WeakReference 类型，当 ThreadLocal 实例被回收（如局部变量超出作用域且无强引用），key 变为 null，但 value 仍被 Map 的 Entry 强引用着。若线程长期运行（如线程池中的 worker 线程），这些“脏 entry”无法被自动清理，value 所引用的大对象（如上下文、数据库连接、缓存数据）就持续占用堆内存。
- 泄露典型场景：在 Servlet 过滤器或 Spring AOP 中用 ThreadLocal 存放请求上下文，但未在 finally 或 afterCompletion 中 remove()
- 验证方式：Heap dump 中搜索 java.lang.ThreadLocal$ThreadLocalMap$Entry，观察 value 非空但 key == null 的条目数量是否持续增长
安全使用的三原则：及时 remove + 使用 static + 避免在线程池中裸用
防范泄漏不是靠“尽量少用”，而是建立规范用法：
立即学习“Java免费学习笔记（深入）”；
-
总是配套 remove()：尤其在 try-finally 或 try-with-resources 中确保执行，例如：
try { threadLocal.set(value); ... } finally { threadLocal.remove(); } - ThreadLocal 声明为 static final：防止因 ThreadLocal 实例本身被回收导致 key 提前失效；static 保证全局唯一 key，final 防止误重赋值
- 线程池场景必须显式清理：不要依赖线程结束自动回收（线程复用不会销毁 ThreadLocalMap）；可在任务执行前后统一 wrap 或借助框架钩子（如 Spring 的 RequestContextHolder.reset()）
进阶建议：用 InheritableThreadLocal？慎用！
InheritableThreadLocal 允许子线程继承父线程的值，但仅在 new Thread() 时复制一次，对线程池无效（worker 线程早已存在）。且同样存在泄漏风险，继承来的 value 也需要手动 remove。除非明确需要 fork 场景（如异步日志追踪链路 ID），否则优先用普通 ThreadLocal + 显式透传参数更可控。
