threadlocal 的核心是线程隔离：每个线程在其 thread 对象的 threadlocals（threadlocalmap）中存储数据，threadlocal 实例仅为 key（弱引用），value 为线程独有副本；key 回收后 value 易内存泄漏，需显式 remove；本质是“每人一份”，非“共享加锁”。
直接说核心：ThreadLocal 不是“把变量存在自己身上”，而是每个线程在自己的 Thread 对象里维护一个叫 ThreadLocalMap 的专属哈希表，你用的 ThreadLocal 实例只是这张表的 key，真正数据存在线程内部。
原理三句话讲清
• 数据不在 ThreadLocal 对象里，而在每个 Thread 对象的 threadLocals 字段中（类型是 ThreadLocal.ThreadLocalMap）；
• ThreadLocalMap 的 key 是当前 ThreadLocal 实例（弱引用），value 是你 set 的值；
• 同一个 ThreadLocal 对象，在不同线程里作为 key 查到的是各自 Map 中不同的 value，天然隔离。
为什么容易内存泄漏？关键在弱引用和线程复用
• Entry 的 key 是弱引用，GC 时 ThreadLocal 对象可能被回收，但 value 还强引用着，如果线程长期存活（比如线程池里的线程），value 就一直占着内存；
• 线程不结束，ThreadLocalMap 就不销毁，entry.value 又没被清理，就形成“key 为 null、value 还挂着”的脏 entry；
• 所以必须显式调用 remove() —— 它不只是清 value，还会主动探测并清理整条 hash 链上的脏 entry。
真实项目里怎么用才靠谱
• Web 请求场景：Filter 中 set 用户信息，Service/DAO 层随时 get，请求结束（如在拦截器或 finally 块）务必 remove；
• 工具类封装：如 SimpleDateFormat、Random、DecimalFormat 等非线程安全对象，用 withInitial 初始化，避免每次 get 都判空；
• 分布式链路追踪：MDC 或自定义 TraceContext 用 ThreadLocal 存 traceId，配合日志框架输出上下文；
• 注意别在定时任务、线程池 submit 的 Runnable 中忘了 remove，否则下一个任务会拿到上一个任务残留的值。
和 synchronized 的本质区别
• synchronized 是“抢着用同一份资源”，靠阻塞排队实现安全；
• ThreadLocal 是“每人发一份”，彻底消灭竞争，没有锁开销；
• 它不解决共享状态的协同问题，只解决“本线程内需要独有副本”的场景 —— 用错地方反而引入隐性 bug。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
