ThreadLocal 是 Java 实现线程局部变量的工具，为每个线程提供独立变量副本以实现线程隔离；通过 set()、get()、remove() 操作本线程副本，需及时 remove() 防内存泄漏和脏数据。
ThreadLocal 是 Java 提供的用于实现线程局部变量的工具，它能让每个线程拥有自己独立的变量副本，从而天然实现线程隔离，避免共享数据带来的并发问题。
ThreadLocal 的基本用法
创建 ThreadLocal 实例后，通过 set() 存值、get() 取值、remove() 清理，每个线程操作的是自己独有的副本：
- 调用 get() 时，若当前线程未设值，会触发 initialValue() 方法（默认返回 null），可重写该方法提供默认值
- set() 和 get() 都只影响当前线程，不影响其他线程
- 务必在使用完后调用 remove()，尤其在线程复用场景（如线程池）中，防止内存泄漏和脏数据残留
典型应用场景示例
常见于需要在线程内贯穿上下文但又不想传递参数的场景：
- 用户身份信息透传：登录后将 userId 存入 ThreadLocal，在同一线程后续的 DAO、Service 层直接获取，无需层层传参
- 事务/数据库连接绑定：Spring 的事务管理底层就用 ThreadLocal 绑定当前线程的 Connection 或 TransactionStatus
- 日志链路追踪 ID：生成 traceId 后存入 ThreadLocal，各日志打印自动携带，便于分布式链路排查
注意内存泄漏风险
ThreadLocal 的 key 是弱引用，value 是强引用。如果线程长期运行（如线程池中的线程），而 ThreadLocal 实例被回收，key 为 null，但 value 仍被 Entry 持有，导致无法被 GC —— 这就是潜在的内存泄漏。
立即学习“Java免费学习笔记（深入）”；
- 解决办法是每次用完显式调用 remove()，尤其在 finally 块中确保执行
- 避免将 ThreadLocal 声明为 static 的同时又在业务代码中频繁 new 实例（应复用 static 实例）
- 不要把大对象（如 Map、List）长期放在 ThreadLocal 中，除非明确控制生命周期
结合线程池使用的正确姿势
线程池会复用线程，不清理 ThreadLocal 极易造成数据串扰或内存堆积：
- 在任务开始前 get() 或 set() 前先 remove() 上次遗留值
- 更稳妥的做法是在 Runnable/Callable 包装器中统一做初始化与清理，例如用装饰器模式封装任务逻辑
- Spring 的 RequestContextHolder 就是基于 ThreadLocal + 拦截器，在请求结束时自动 cleanup
