threadlocal本质是线程私有副本，非线程安全容器；需显式set()、及时remove()防内存泄漏；inheritablethreadlocal仅支持子线程创建时继承；web/异步场景优先用框架提供的上下文传递机制。
ThreadLocal 的基本用法：new 之后 set/get 就完事？
ThreadLocal 不是“线程安全的容器”，它本质是每个线程持有一份独立副本。调用 set() 是往当前线程的私有 map 里存值，get() 是从当前线程的 map 里取——不同线程之间完全不共享。
- 必须在每个线程内显式调用
set()，否则get()返回的是initialValue()（默认null） - 不要复用同一个
ThreadLocal实例跨线程传值，它不支持 - 避免在
Runnable或Callable外部提前set()，因为子线程看不到父线程的ThreadLocal值
ThreadLocal<string> holder = ThreadLocal.withInitial(() -> "default");
holder.set("thread-1-value"); // 当前线程写入
System.out.println(holder.get()); // 输出 thread-1-value
</string>
为什么线程池里用 ThreadLocal 容易内存泄漏？
线程池复用线程，但 ThreadLocal 的 key 是弱引用，value 是强引用。如果忘记 remove()，线程长期存活时，value 无法被 GC，且 key 被回收后变成“脏 entry”，可能引发泄漏。
- 每次使用完必须调用
remove()，尤其在try-finally中 - 不要用
set(null)替代remove()，这只会把 value 设为null，entry 还在 - 如果
ThreadLocal是 static 的（常见），泄漏风险更高，因为类加载器卸载前它一直存在
try {
holder.set("work");
doSomething();
} finally {
holder.remove(); // 关键！不能省
}
ThreadLocal 与 InheritableThreadLocal 的区别在哪？
InheritableThreadLocal 是 ThreadLocal 的子类，仅在创建子线程时把父线程的值拷贝一份过去；它不传播给线程池里的线程，也不支持异步回调（如 CompletableFuture）。
- 子线程启动瞬间继承，后续父线程修改不影响子线程，子线程修改也不影响父线程
- 线程池中提交的任务不会自动继承，除非你手动包装
Runnable并在执行前set() -
ForkJoinPool和虚拟线程（Loom）对继承行为支持不一致，别依赖
ThreadLocal<string> tl = new InheritableThreadLocal
tl.set("from-parent");
new Thread(() -> System.out.println(tl.get())).start(); // 输出 from-parent
</string>
替代方案：什么时候不该用 ThreadLocal？
ThreadLocal 是隐式上下文传递，调试困难、测试难 mock、容易和框架生命周期冲突（比如 Spring 的 request scope 已经封装了类似逻辑）。
- Web 应用中优先用
RequestContextHolder（Spring）或ServletRequestAttributes，而不是自己套ThreadLocal - 异步链路（如 Dubbo filter、Sleuth traceId）应走显式透传或框架拦截机制，避免靠
ThreadLocal“侥幸”传递 - 单元测试中若用到
ThreadLocal，必须在@After或finally清理，否则污染其他测试用例
真正麻烦的不是怎么写，是清理时机和作用域边界的判断——一个没 remove() 的 ThreadLocal，可能在某个凌晨三点的线程池满载日志里才暴露出来。
