threadlocal 的值存在当前线程的 threadlocals 字段（threadlocalmap 类型）中，而非 threadlocal 实例本身；get/set 操作本质是对此 map 的 key（当前 threadlocal）查/存 value；因 entry 的 key 是弱引用而 value 是强引用，若不显式 remove()，易导致 value 内存泄漏，尤其在线程池场景下。
ThreadLocal 的值到底存在哪儿？
不在 ThreadLocal 实例里，而在当前线程（Thread 对象）的 threadLocals 字段中——这是一个 ThreadLocalMap 类型的私有成员。你 new 出 100 个 ThreadLocal 实例，只要没调用 set()，当前线程的 threadLocals 就是 null，什么都没存。
get() 的本质：从当前线程的 threadLocals 中，以当前 ThreadLocal 实例为 key 查 value；set(T) 的本质：往当前线程的 threadLocals 里执行 put(key=当前 ThreadLocal, value=传入值)。
- 误以为“
ThreadLocal存数据”是最大认知偏差，这直接导致清理遗漏 - static 声明的
ThreadLocal实例生命周期极长，key 很难变null，弱引用机制形同虚设 - 线程池中复用线程时，上一个任务 set 的值，下一个任务不 remove 就能直接 get 到——不是功能，是 bug
为什么 ThreadLocal 容易内存泄漏？
核心矛盾是：Entry 的 key 是弱引用（WeakReference<threadlocal></threadlocal>），value 是强引用。当外部不再持有该 ThreadLocal 实例（比如 Spring Bean 销毁、类卸载），GC 可回收 key，但 value 仍被线程强持有，无法释放。
更危险的是：value 若引用了大对象（如 Map、Connection、Service 实例），整条引用链都卡住不回收。
立即学习“Java免费学习笔记（深入）”；
- 泄漏高发场景：Tomcat/Netty 线程池、定时任务线程池、自定义 long-lived 线程
- 泄漏特征：heap dump 中出现大量
java.lang.ThreadLocal$ThreadLocalMap$Entry，key=null，value 指向业务对象 -
ThreadLocalMap虽在get/set/remove时触发探测式清理（rehash 清 stale entry），但 idle 线程不触发，就一直挂着
remove() 必须显式调用，且时机很关键
不调 remove()，entry 就永远留在 threadLocals 里，哪怕 ThreadLocal 实例本身已不可达。这不是可选项，是必选项。
典型安全写法：
try {
userContext.set("u123");
// ... 业务逻辑
} finally {
userContext.remove(); // 必须放 finally，防异常跳过
}
- Web 场景：在 Filter 的
doFilter()finally块中remove() - Spring 场景：用
@AfterReturning或@AfterThrowing通知统一清理 - 千万别依赖“线程结束自动清”，线程池里的线程根本不会结束
- 别用
initialValue()或withInitial()代替remove()，默认值只解决 null 问题，不解决泄漏
线程池 + ThreadLocal 的组合怎么不出错？
这是最常翻车的生产环境组合。线程复用意味着变量副本跨请求残留，轻则数据错乱（A 用户看到 B 用户的上下文），重则 OOM。
正确姿势不是“少用”，而是“闭环管理”：
- 所有使用
ThreadLocal的任务，必须保证set()和remove()成对出现在同一 try-finally 块中 - 禁止在
Runnable/Callable外部提前set()，避免污染线程池全局状态 - 若需跨方法传递上下文，优先考虑显式参数或
InheritableThreadLocal（但也要配对remove()） - 上线前用 MAT 或 JProfiler 检查 heap dump，搜索
ThreadLocalMap中 key=null 的 entry 数量
真正难的不是理解原理，是把 remove() 写进每一处业务逻辑的 finally 里——漏一处，风险就埋下一处。
