ThreadLocal通过每个Thread持有独立ThreadLocalMap实现线程隔离，key为ThreadLocal弱引用，value为实际数据；set/get操作均作用于当前线程map，remove必须显式调用以防内存泄漏。
ThreadLocal 为什么能实现线程隔离
因为每个 Thread 对象内部都持有一个 ThreadLocalMap 实例，而这个 map 的 key 是 ThreadLocal 实例本身（弱引用），value 才是真正要隔离的数据。不同线程操作的是各自独立的 ThreadLocalMap，自然互不干扰。
注意：不是 ThreadLocal 自己存数据，而是它作为“钥匙”去访问当前线程专属的 map —— 这个设计决定了它天然线程安全，无需加锁。
set() 和 get() 背后发生了什么
set() 会先获取当前线程的 threadLocals 字段（即 ThreadLocalMap），如果为空则初始化；get() 同样先查当前线程的 map，找不到 key 就调用 initialValue() 初始化。
- 第一次
get()且未set()时，会触发initialValue()（默认返回null） - 若重写了
initialValue()，它只在当前线程首次get()时执行一次 -
remove()必须显式调用，否则可能引发内存泄漏（key 是弱引用，但 value 是强引用）
Web 应用中 ThreadLocal 泄漏的典型场景
在 Tomcat 等容器中，线程常被复用（线程池），如果在 Filter 或 Interceptor 中用了 ThreadLocal 却没调用 remove()，上一个请求存的 value 可能被下一个请求读到，或长期滞留导致 OOM。
立即学习“Java免费学习笔记（深入）”；
常见错误模式：
- 只在
try块里set()，却没在finally里remove() - 用
static final ThreadLocal<simpledateformat></simpledateformat>缓存非线程安全对象，看似省事，但忘了清理时机 - Spring 的
RequestContextHolder底层就是ThreadLocal，若异步线程（如@Async）未手动传播上下文，会拿不到值
替代方案与使用边界
ThreadLocal 不是万能线程私有存储，它解决的是「同一线程内跨方法传递状态」的问题，不是为了解耦或替代参数传递。
- 若只是临时变量，优先用局部变量，更轻量、无泄漏风险
- 需要跨线程传递上下文时，考虑
InheritableThreadLocal（注意子线程继承后仍需自行remove()）或显式透传（如MDC配合日志框架） - JDK9+ 可考虑
ScopedValue（预览特性），语义更清晰、自动清理，但目前生产环境慎用
真正容易被忽略的，是「谁负责清理」—— 它永远不该依赖线程销毁，而必须由业务代码在明确的作用域结束点调用 remove()。
