ThreadLocal 是每个线程持有独立副本的容器，非线程共享变量，天然线程安全；误用作跨线程传值或未及时 remove 会导致内存泄漏，尤其在线程池中。
ThreadLocal 是什么，为什么不能直接用普通变量
ThreadLocal 不是“线程变量”，而是每个线程持有独立副本的容器。普通变量（比如 static 或实例字段）被所有线程共享，容易引发竞态；而 ThreadLocal 让每个线程读写的是自己专属的那一份，天然线程安全。
常见误用：把 ThreadLocal 当成全局缓存或跨线程传值工具——它不传递数据，只隔离数据。一旦在线程池中复用线程（如 ExecutorService），未清理的 ThreadLocal 值可能残留并污染后续任务。
怎么正确初始化和使用 ThreadLocal
推荐用 static final 声明 + 匿名内部类重写 initialValue()，避免每次 get() 都触发 null 判断和同步开销：
private static final ThreadLocal<SimpleDateFormat> DATE_FORMAT = ThreadLocal.withInitial(() -> new SimpleDateFormat("yyyy-MM-dd"));
或者更简洁的 lambda 形式（Java 8+）：
立即学习“Java免费学习笔记（深入）”；
-
get()返回当前线程绑定的值，首次调用自动触发初始化 -
set(T value)绑定/覆盖当前线程的值 -
remove()必须显式调用，尤其在线程池场景下防止内存泄漏
哪些场景适合用 ThreadLocal
核心原则：需要「线程内贯穿、跨方法传递、且无需共享」的上下文数据。
- 用户身份信息（如 Web 请求中的
userId）：Filter 中解析并 set，Service 层直接 get，避免层层透传参数 - 数据库连接或事务状态：某些 ORM 框架（如早期 Hibernate）用它绑定 session
- 日志 MDC（Mapped Diagnostic Context）：Logback/Log4j2 依赖
ThreadLocal实现 traceId 等字段自动注入日志行 - 临时缓冲对象：如
SimpleDateFormat、ByteBuffer，避免重复创建开销
反例：试图用它在父子线程间传参（子线程不会继承父线程的 ThreadLocal 值，要用 InheritableThreadLocal，但仍有局限）
ThreadLocal 内存泄漏是怎么发生的
根本原因不是 ThreadLocal 本身，而是它的静态引用 + 线程长期存活 + 忘记 remove()。
ThreadLocalMap 的 key 是弱引用（WeakReference<ThreadLocal>），value 是强引用。当 ThreadLocal 变量被回收后，key 变为 null，但 value 还挂在 map 里，直到线程结束或 map 触发探测式清理——这不可控。
- 线程池中线程复用，value 可能长期驻留
- Web 应用中，一次请求对应一个线程，若 Filter 中 set 却没在 finally 里 remove，下次该线程处理新请求时可能拿到旧值
- 最佳实践：总是配对使用
try-finally——set()后在 finally 调用remove()
真正难排查的，是那些没被显式引用、却因生命周期错配悄悄堆积的 value 对象。
