ThreadLocal通过为每个线程提供独立变量副本实现线程隔离，解决共享变量线程安全问题并简化上下文传递；其底层依赖Thread中私有的ThreadLocalMap，但需注意未remove导致的内存泄漏风险。
ThreadLocal 解决的核心问题是多线程环境下共享变量引发的线程安全问题，它不靠加锁，而是通过“空间换时间”的方式，为每个线程提供独立的变量副本，实现天然线程隔离。
避免共享对象状态冲突
像 SimpleDateFormat、Random、数据库连接等非线程安全对象，若被多个线程共用，内部状态容易错乱。例如：
- 10个线程同时调用同一个
SimpleDateFormat.parse()，可能抛出ParseException或返回错误日期； - 多个线程操作同一个
Random实例，可能导致生成重复或不符合分布的随机数。
用 ThreadLocal 包裹后，每个线程拿到的是自己专属的实例，互不影响。
简化同一线程内上下文传递
在 Web 请求处理链（如 Filter → Service → DAO）中，常需透传用户身份、租户 ID、请求追踪号等上下文信息。传统做法是层层显式传参，导致方法签名膨胀、耦合加重。
ThreadLocal 提供隐式传递能力：
- Filter 中解析并存入
ThreadLocal； - 后续任意深度的方法调用，直接
userContext.get()即可获取当前请求的用户； - 无需修改中间层方法参数，也无需依赖 Spring 的 RequestContextHolder 等封装。
线程隔离的底层原理
关键不在 ThreadLocal 本身，而在于每个 Thread 对象内部持有一个 ThreadLocalMap：
-
ThreadLocalMap是线程私有的哈希表，key 是 ThreadLocal 实例（弱引用），value 是该线程专属的变量副本； - 调用
set()或get()时，先获取当前线程Thread.currentThread()，再操作其内部的 map； - 不同线程即使使用同一个 ThreadLocal 对象作 key，实际访问的是各自 map 中不同的 slot，自然隔离。
注意内存泄漏风险
虽然 key 是弱引用，能防止 ThreadLocal 实例被长期持有，但 value 是
强引用。如果线程长期运行（如线程池中的线程），而忘记调用 remove()，value 就无法被回收。
- 典型场景：Web 应用中，在 Filter 中 set，在 finally 块中未 remove；
- 后果：value（比如大对象、Connection）随线程存活，越积越多，最终 OOM；
- 建议：务必配合 try-finally 或 try-with-resources 使用
remove()，尤其在线程复用场景下。
