ThreadLocal 是线程局部变量机制，每个线程持有独立副本，值实际存储在 Thread 对象的 ThreadLocalMap 中，key 为弱引用的 ThreadLocal 实例，value 为强引用对象；必须遵循初始化、使用、清理三步，尤其在线程池中需手动 remove 防止内存泄漏和脏数据。
ThreadLocal 是 Java 提供的一种线程局部变量机制，它为每个使用该变量的线程都创建一个独立副本，从而天然避免共享变量带来的并发竞争问题。关键不在于“怎么设值”，而在于“谁来初始化、何时清理、是否泄漏”。
理解 ThreadLocal 的本质：不是“绑定线程”，而是“线程持有副本”
ThreadLocal 本身不存储值；真正存值的是每个 Thread 对象内部的 ThreadLocalMap。当你调用 threadLocal.set(value)，实际是把 value 写入当前线程对象的 map 中，key 是这个 ThreadLocal 实例（弱引用），value 是你传入的对象。因此：
- 不同线程调用同一个 ThreadLocal 的 get/set，互不影响
- 主线程设的值，子线程不会自动继承（除非显式使用 InheritableThreadLocal）
- 若未手动 remove，线程复用（如线程池中）时旧值可能残留，引发脏数据或内存泄漏
正确使用模式：初始化 + 使用 + 清理三步不可少
尤其在 Web 应用或线程池场景下，必须按顺序操作：
-
初始化：推荐使用
ThreadLocal.withInitial(() -> new Xxx())，避免每次 get 都判空 -
使用：直接调用
get()或set()，无需同步 -
清理：在业务逻辑结束前（如 Filter 的 finally 块、Runnable 结束前）务必调用
remove()
示例（Spring Web 中拦截用户上下文）：
立即学习“Java免费学习笔记（深入）”；
private static final ThreadLocal<UserContext> CONTEXT = ThreadLocal.withInitial(UserContext::new);
public void handleRequest() {
try {
CONTEXT.get().setUserId("u123");
doBusiness();
} finally {
CONTEXT.remove(); // 必须！否则线程池中下次可能拿到旧用户
}
}
警惕常见陷阱
- 静态 ThreadLocal + 线程池 = 潜在内存泄漏：ThreadLocal 被静态持有时生命周期极长，而它的 key 是弱引用，value 却是强引用。若忘记 remove，value 无法被回收，map 中的 Entry 会堆积（虽 key 可被回收，但 value 滞留）
-
父子线程不共享：普通 ThreadLocal 子线程 get 到的是 null，需改用
InheritableThreadLocal并注意其同样需要 remove - 不要把它当全局缓存用：ThreadLocal 不解决跨线程通信，也不替代 ConcurrentHashMap
替代方案思考：什么时候不该用 ThreadLocal？
如果变量需在线程间传递（如异步回调、CompletableFuture 链）、或需统一管理生命周期（如事务上下文），优先考虑：
- 显式传参（最清晰、易测）
- 基于 AOP 或框架上下文（如 Spring 的 RequestContext、TransactionSynchronizationManager）
- 短生命周期的局部变量（能不用就不用）
ThreadLocal 是利器，但不是银弹。用对了省心，用错了难排查。
