ThreadLocal通过每个Thread实例的threadLocals（ThreadLocalMap）实现线程隔离，键为ThreadLocal弱引用、值为线程专属副本；remove()必须在finally中调用以防内存泄漏；initialValue()懒加载，set()立即执行；框架如Spring/MyBatis隐式使用它管理上下文，跨线程需TTL等方案。
ThreadLocal 为什么能实现线程间数据隔离
因为数据根本不在 ThreadLocal 对象里，而在每个 Thread 实例自己的 threadLocals 字段中——这是一个 ThreadLocalMap，键是当前 ThreadLocal 实例（弱引用），值才是你存的副本。
所以两个线程调用同一个 threadLocal.set("abc")，实际是往各自线程对象的 threadLocals 里塞了两份独立数据；调用 get() 时也只查自己线程的 Map，自然互不干扰。
- 不是 ThreadLocal “复制”了变量，而是每个线程“各自维护一份”
-
ThreadLocal本身只是个“钥匙”，真正存东西的是Thread.threadLocals - 这个设计绕开了锁和同步，但代价是内存占用随线程数线性增长
set/get/remove 必须配对使用的三个理由
remove() 不是可选项，是防止内存泄漏的刚需操作——尤其在线程复用场景（如 Tomcat 线程池、Netty EventLoop）下。
原因在于：ThreadLocalMap 的 key 是弱引用，但 value 是强引用。当 ThreadLocal 实例被回收后，key 变成 null，但 value 还卡在 Map 里，除非主动 remove() 或触发 Map 的探测清理逻辑（不保证及时）。
- 漏掉
remove()→ 线程长期存活 → value 持有大对象（如Connection、StringBuilder）→ 内存泄漏 - Web 应用中，一次请求没清掉
ThreadLocal，下次请求可能拿到上一个用户的userId - 推荐写法：在
finally块里调用threadLocal.remove()，或配合try-with-resources封装
initialValue() 和构造时 set() 的区别在哪
两者都会在首次 get() 时提供默认值，但触发时机和语义不同：
-
initialValue()是懒加载：只有第一次get()且未set()过才调用，适合初始化开销大、未必用到的对象（如SimpleDateFormat） - 直接
set()是立即执行：哪怕之后从没get()，值也已存在，适合必须预置状态的场景 - 重写
initialValue()时注意：它会被多个线程并发调用，方法体内部不能依赖共享可变状态
示例：
private static final ThreadLocal<SimpleDateFormat> sdf = new ThreadLocal<>() {
@Override
protected SimpleDateFormat initialValue() {
return new SimpleDateFormat("yyyy-MM-dd");
}
};
ThreadLocal 在 Spring 和 MyBatis 中怎么被“偷偷”用的
你没显式写 ThreadLocal，但它就在那儿——比如 Spring 的 TransactionSynchronizationManager 用它存事务资源，MyBatis 的 ErrorContext 用它存当前 SQL 错误上下文。
这些框架都遵循一个关键原则：在进入业务逻辑前（如拦截器、AOP）把上下文塞进 ThreadLocal，执行完立刻清理。一旦你手动开启新线程（比如 new Thread(...).start()），这些上下文就丢了——因为子线程没有父线程的 threadLocals。
- 异步场景（
@Async、CompletableFuture）需显式传递ThreadLocal值，否则事务/用户信息会断掉 - 父子线程传递要用
InheritableThreadLocal，但它不解决线程池复用问题（池中线程可能继承到过期上下文） - Spring 已封装
TransmittableThreadLocal（TTL）来补这个缺口，但得额外引入依赖
真正难的不是理解“每个线程一份”，而是想清楚：这个“一份”该在什么时候创建、什么时候销毁、跨线程时要不要传、传了会不会污染。边界模糊的地方，往往就是 bug 潜伏的位置。
