是的，ThreadLocal通过每个Thread内部的ThreadLocalMap为各线程提供独立变量副本，实现线程隔离；但仅隔离引用，不保证其指向对象的线程安全，且需显式remove()防内存泄漏与脏数据。
ThreadLocal 是什么，它真能实现线程隔离吗？
是的，ThreadLocal 的核心作用就是为每个线程提供独立的变量副本，实现逻辑上的“线程隔离”。但它不是靠锁或同步，而是靠每个 Thread 对象内部持有一个 ThreadLocalMap，键是 ThreadLocal 实例（弱引用），值是线程私有的数据。这意味着：不同线程调用同一个 ThreadLocal 的 get() 或 set()，操作的是各自 Thread 对象里的不同 Entry。
注意：它不解决共享对象内部状态的竞争问题。比如你存了一个 ArrayList 进去，多个线程仍可能并发修改这个列表——隔离的是引用，不是引用指向的对象本身。
为什么 ThreadLocal.remove() 很容易被忽略？
如果不显式调用 remove()，在线程复用场景（如线程池）中极易发生内存泄漏和脏数据残留。因为 ThreadLocalMap 中的 key 是弱引用，GC 能回收 ThreadLocal 实例，但 value 是强引用，会一直留在 map 里，直到线程结束。
- 线程池中的工作线程长期存活 →
ThreadLocalMap不清理 → value 累积泄漏 - 前一个请求存了
userId=1001，没remove()；下一个请求复用该线程，get()可能拿到旧值 -
initialValue()只在第一次get()时触发，后续都直接返回 map 里的旧值
正确做法是在业务逻辑结束时（例如 Filter、Interceptor、try-finally 块末尾）调用 threadLocal.remove()。
立即学习“Java免费学习笔记（深入）”；
ThreadLocal 在 Web 应用中怎么安全传递用户上下文？
典型场景是把登录用户 ID、租户标识、请求 traceId 存入 ThreadLocal，供下游服务层、DAO 层无参获取。但要注意线程切换带来的失效：
- 使用
CompletableFuture异步执行时，默认用ForkJoinPool，原线程的ThreadLocal不会自动传递 - 手动提交到线程池（如
executor.submit()）时，子线程没有父线程的ThreadLocal副本 - Spring 的
@Async默认也不传递，需自定义TaskDecorator
解决方案不是放弃 ThreadLocal，而是封装一层可继承的上下文：
public class InheritableThreadLocalContext {
private static final InheritableThreadLocal<Map<String, Object>> context =
new InheritableThreadLocal<>() {
@Override
protected Map<String, Object> childValue(Map<String, Object> parentValue) {
return new HashMap<>(parentValue); // 深拷贝更稳妥
}
};
}
但注意：InheritableThreadLocal 只在 new Thread() 时复制，对线程池无效，仍需配合 wrap 提交逻辑。
ThreadLocal 和 synchronized 比较：什么时候该选哪个？
二者根本不是替代关系：synchronized 解决的是「多线程竞争同一资源」的问题；ThreadLocal 解决的是「避免共享、各用各的」问题。选择依据看数据生命周期和访问模式：
- 需要跨方法、跨类传递且只读/单线程写 →
ThreadLocal更轻量（无锁、无竞争） - 多个线程必须读写同一个实例（如计数器、缓存）→ 必须用
synchronized/AtomicInteger/ReentrantLock - 频繁创建临时对象（如
SimpleDateFormat）→ThreadLocal复用比加锁更高效 - 误用
ThreadLocal存全局配置或单例服务引用 → 不仅没必要，还增加排查复杂度
最易错的一点：以为用了 ThreadLocal 就不用考虑并发安全——只要那个 value 本身被多个地方引用并修改，就仍然要加同步控制。
