ThreadLocal实现线程隔离的根本原因是每个Thread对象持有独立的ThreadLocalMap，get()/set()操作的是当前线程自身的map，键为ThreadLocal实例、值为变量副本，故各线程互不干扰。
ThreadLocal 为什么能实现线程隔离
根本原因在于 Thread 类内部持有一个 ThreadLocalMap 实例（字段名是 threadLocals），而不是在 ThreadLocal 对象里存数据。每次调用 get() 或 set()，实际是操作当前线程自己的 threadLocals 这个哈希表——键是 ThreadLocal 实例本身，值才是你存的变量副本。
这意味着：不同线程调用同一个 ThreadLocal 的 get()，查的是各自线程对象里的不同哈希表，自然互不干扰。
注意点：
-
ThreadLocalMap的 key 是弱引用（WeakReference<ThreadLocal>），这是为避免内存泄漏做的设计，但反而容易导致“key 被回收后 value 滞留”的问题 - 主线程和子线程之间不共享
ThreadLocal值，子线程需手动继承（比如用InheritableThreadLocal） - 线程池中复用线程时，若忘记
remove()，上一个任务留下的值可能污染下一个任务
ThreadLocal.set() 和 get() 的真实行为
看似简单，但底层有隐式初始化逻辑。首次调用 get() 时，如果当前线程的 threadLocals 为 null，会自动创建一个空的 ThreadLocalMap；而 set() 会先尝试查找已有 entry，不存在则新建。
立即学习“Java免费学习笔记（深入）”；
关键细节：
-
set(null)是合法的，会把对应 key 的 value 设为null，但 entry 本身仍存在 -
get()永远不会返回null（除非你显式设了null），它只负责取值，不校验业务逻辑意义 - 若重写了
initialValue()，首次get()会触发它；但若先set()再get()，initialValue()根本不会执行
线程池场景下 ThreadLocal 的典型泄漏与修复
最常见的误用：在 Tomcat 或 Spring Boot 的请求线程池中，用 ThreadLocal<Connection> 存数据库连接，却没在 filter 或 finally 块里调用 remove()。结果是连接对象长期滞留在线程的 ThreadLocalMap 中，GC 无法回收。
真正安全的做法：
- 总是配对使用
set()/remove()，尤其在try-finally中确保remove()执行 - 避免在
ThreadLocal中存大对象（如byte[]、ArrayList），否则即使 key 被回收，value 仍占内存 - 排查泄漏时，可 dump 线程堆栈 +
ThreadLocalMap内容，重点关注 value 类型和引用链
示例修复模式：
try {
threadLocal.set(value);
// ... 业务逻辑
} finally {
threadLocal.remove(); // 不要用 set(null)，remove 才清 entry
}
InheritableThreadLocal 能否跨线程传递值
可以，但仅限于「子线程创建时」这一瞬间。父线程中已设置的 InheritableThreadLocal 值，会在子线程构造函数中被复制进其 inheritableThreadLocals（另一个 ThreadLocalMap）。之后父线程再修改，子线程完全感知不到。
限制很明确：
- 仅支持单向、一次性继承；不支持运行时动态同步
- ForkJoinPool、CompletableFuture 默认不继承（需显式配置
ForkJoinWorkerThreadFactory或用copy()方法） - 如果子线程又创建孙子线程，不会继续传递——继承链只有一层
所以别把它当“线程间通信”工具，它只是初始化时的便利机制。
真正难处理的是异步调用链（比如 WebFlux + Reactor），那种场景得靠 MDC、Scope 或显式透传上下文对象，ThreadLocal 体系天然不适用。
