ThreadLocal通过每个Thread实例内部的ThreadLocalMap实现线程隔离，key为ThreadLocal自身（弱引用），value为线程私有值；因value强引用且key可能被回收，未调用remove易致内存泄漏。
ThreadLocal 是怎么做到线程间数据隔离的
它不靠锁，也不靠复制对象，核心是每个 Thread 实例内部持有一个 ThreadLocalMap 字段（类型为 ThreadLocal.ThreadLocalMap），而这个 map 的 key 是 ThreadLocal 实例本身，value 才是你要存的线程私有值。也就是说：不是“ThreadLocal 管着所有线程的数据”，而是“每个线程自己管自己的 ThreadLocalMap”。
关键点在于：ThreadLocal.set() 和 ThreadLocal.get() 都会先通过 Thread.currentThread() 拿到当前线程，再操作该线程专属的 map —— 自然就不存在跨线程读写。
为什么 ThreadLocal 可能导致内存泄漏
因为 ThreadLocalMap 中的 key 是 ThreadLocal 的弱引用（WeakReference），但 value 是强引用。当外部不再持有 ThreadLocal 实例（比如被 gc），key 变成 null，但 value 还卡在 map 里，且没主动清理的话，就会一直占着内存。
- 线程长期运行（如线程池中的 worker 线程）时风险最大
-
ThreadLocal.remove()必须显式调用，尤其在使用完后或 finally 块中 - 不要把大对象（如
byte[]、Connection）直接塞进ThreadLocal，除非你确定生命周期可控
set() / get() / remove() 的实际行为差异
这三个方法看着简单，但行为细节影响很大：
立即学习“Java免费学习笔记（深入）”；
-
set(T value)：如果当前线程的ThreadLocalMap为空，会先初始化；否则直接插入或替换对应 key 的 entry -
get()：若 map 为空或没找到 key，会调用initialValue()（默认返回null），并把结果 put 进去 —— 所以首次get()也可能触发写入 -
remove()：只清除当前线程 map 中该ThreadLocal对应的 entry，不会影响其他线程，也不会清空整个 map
示例：
ThreadLocal<String> tl = ThreadLocal.withInitial(() -> "default"); System.out.println(tl.get()); // 输出 "default"，且已写入当前线程的 map
在线程池中使用 ThreadLocal 的典型陷阱
线程复用导致数据残留是最常见问题。一个请求 set 的值，可能被下一个请求的 get() 拿到 —— 因为用的是同一个线程实例。
- 务必在业务逻辑结束前调用
tl.remove()，不能只依赖set(null) - 避免在过滤器、拦截器、AOP 切面中只做
set()而忘记remove() - 如果必须传递上下文（如 traceId），建议封装成工具类，在入口 set、出口 remove，并配合 try-finally 或 try-with-resources（需包装）
真正难处理的不是“怎么用”，而是“什么时候 clean”——尤其在异步调用、CompletableFuture、或嵌套线程场景下，ThreadLocal 不会自动传递，也容易漏掉清理点。
