threadlocal是java实现线程隔离的核心工具，本质为每个线程维护独立的threadlocalmap副本（键为threadlocal实例、值为线程私有数据），从而避免共享变量竞争；其key弱引用、value强引用，线程池中需显式remove防内存泄漏与脏数据。
ThreadLocal 是 Java 中实现线程隔离、避免共享变量竞争的核心工具，面试官常通过它考察你对多线程本质、内存模型和实际问题解决能力的理解——不是背定义，而是看能不能讲清“为什么需要它”“它怎么工作”“用错会怎样”。
ThreadLocal 的本质：每个线程独享一份变量副本
它不是“全局变量的线程安全版”，而是在 Thread 类内部维护了一个 ThreadLocalMap（键是 ThreadLocal 实例，值是用户存的数据），每个线程都有一份独立 map。所以 A 线程 set(x)，B 线程 get() 拿到的是 null 或自己设的值，互不干扰。
关键细节：
- ThreadLocal 本身是弱引用（key 是弱引用），防止内存泄漏——但 value 是强引用，如果线程长期运行（如线程池中的线程）且没手动 remove，value 会一直被持有
- 初始值靠 initialValue() 方法提供，默认返回 null；可重写它实现懒加载或默认上下文（如生成唯一 traceId）
- set/get/remove 都操作当前线程的 map，不涉及锁、不跨线程通信，性能高
典型应用场景：哪些问题非它不可？
面试时举出真实、有区分度的例子，比说“避免并发修改”更有说服力：
- 数据库连接/事务上下文绑定：Spring 的 TransactionSynchronizationManager 就用 ThreadLocal 存资源，确保同一线程内 DAO 复用同一个 Connection
- 用户身份/请求上下文透传：微服务中，一次请求经过多个方法调用，用 ThreadLocal 存 userId、tenantId、traceId，避免每个方法都传参
- SimpleDateFormat 等非线程安全对象复用：不用每次 new，每个线程持有一个实例，兼顾性能与安全（注意：Java 8+ 推荐用 LocalDateTime + DateTimeFormatter，它是线程安全的）
高频陷阱题：为什么线程池里用 ThreadLocal 要特别小心？
这是区分初级和中级的关键点。线程池复用线程 → ThreadLocal 的值可能残留上一次任务的数据 → 出现脏数据、NPE、越权访问等隐蔽 bug。
正确做法：
- 在业务逻辑结束前显式调用 remove()（推荐，最稳妥）
- 用 try-finally 包裹，确保异常时也能清理：try { tl.set(val); ... } finally { tl.remove(); }
- 不要依赖 initialValue() 自动初始化来“覆盖旧值”，因为 remove 后再 get 才触发 initialValue；若忘记 remove，get() 直接返回旧值
进阶追问准备：和 InheritableThreadLocal 有什么区别？
普通 ThreadLocal 的值不会被子线程继承；InheritableThreadLocal 在创建子线程时，会把父线程 map 中对应 key 的 value 复制一份给子线程（浅拷贝）。适用于异步日志跟踪、父子任务上下文传递。
但要注意：
- 仅限线程创建时复制，后续父线程修改不影响子线程
- 线程池中慎用——线程复用导致“继承”的其实是很久以前的父上下文，容易误导
- Android 中 AsyncTask 默认使用它做上下文传递，但已废弃
不复杂但容易忽略：ThreadLocal 是工具，不是银弹。真正高薪候选人能说清边界——比如“HTTP 请求生命周期内用它传上下文很自然，但跨线程调度（CompletableFuture.runAsync）、RPC 远程调用时它就失效了，得换 MDC 或透传参数”。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
