ThreadLocal 通过为每个线程提供独立副本实现数据隔离，避免多线程间变量串扰；但需主动调用 remove() 防内存泄漏，尤其在线程池场景下必须配对使用 set() 与 remove()。
ThreadLocal 为什么能防数据串扰
多个线程共用同一个对象时，实例变量容易被覆盖或读到别人写入的值。而 ThreadLocal 本质是给每个线程配一个独立的“抽屉”，get() 拿的是当前线程专属副本，set() 也只改自己抽屉里的东西。
- 线程 A 调用
tl.set("A")，线程 B 同时调用tl.set("B")，两者互不影响 - 即使共享同一个
ThreadLocal实例，底层靠Thread.threadLocals（一个ThreadLocalMap）按线程隔离 - 注意：不是“线程安全的容器”，而是“每个线程一份拷贝”，所以天然无竞争
不 cleanup 就会内存泄漏
ThreadLocalMap 的 key 是 WeakReference<threadlocal></threadlocal>，value 却是强引用。如果线程长期存活（比如线程池里的线程），而你忘了调用 remove()，value 就一直卡在 map 里，哪怕 ThreadLocal 实例本身已被回收，value 也无法被 GC。
- 常见场景：Web 应用中用
ThreadLocal存用户上下文，但 Filter 或 Interceptor 没调tl.remove() - 泄漏表现：堆内存持续增长，MAT 分析能看到大量 value 对象被
ThreadLocalMap持有 - 正确姿势：必须和
set()配对使用remove()，尤其在线程复用环境（如 Tomcat、Dubbo 线程池）
ThreadLocal 与线程池一起用的坑
线程池复用线程，意味着前一次请求留下的 ThreadLocal 值，可能被下一次请求无意中读到。
- 错误写法：
tl.set(user)后没remove()，下一个任务执行tl.get()拿到上个用户的User对象 - 更隐蔽的问题：如果
set(null)替代remove()，value 变成null，但 entry 还在 map 里，仍占内存，且可能触发ThreadLocalMap的探测式清理逻辑，带来额外开销 - 推荐做法：在任务结束前（比如
try-finally或 Spring 的@AfterReturning）强制tl.remove() - 示例：
try { tl.set(user); doWork(); } finally { tl.remove(); // 不是 set(null)，也不是可选 }
ThreadLocal 初始化值的两种写法差异
ThreadLocal 提供了 initialValue() 和 withInitial(Supplier) 两种初始化方式，行为一致，但后者更函数式、适合链式构造。
立即学习“Java免费学习笔记（深入）”；
-
new ThreadLocal<String>() { @Override protected String initialValue() { return "default"; } } -
ThreadLocal.withInitial(() -> "default")—— 推荐，避免匿名内部类带来的类加载/序列化问题 - 注意：初始化只在第一次
get()时触发；如果先set()再get()，不会走初始化逻辑 - 如果初始化逻辑较重（比如创建连接、解析配置），要确认是否真的每次都需要，否则可能掩盖本该显式管理生命周期的问题
ThreadLocal 的难点不在用，而在“什么时候清”和“谁来清”。线程生命周期和业务逻辑边界一旦错位，泄漏和脏数据就藏在看似正常的日志背后。
