正确使用 threadlocal 的核心是每个线程独享变量副本并必须主动清理，否则引发内存泄漏；它是线程隔离容器而非线程安全工具，值存于线程的 threadlocalmap 中，需 static final 声明并在 finally 中 remove()。
正确使用 ThreadLocal 的核心是：**每个线程独享一份变量副本，避免共享状态，但必须主动清理，否则可能引发内存泄漏。** 它不是万能的“线程安全神器”，用错反而更危险。
明确 ThreadLocal 的本质：不是“线程安全的变量”，而是“线程隔离的变量容器”
ThreadLocal 本身不保证线程安全；它通过为每个线程提供独立的变量副本来规避竞争。它的值存储在当前线程对象（Thread）的一个 ThreadLocalMap 字段里，生命周期与线程绑定。
- 不同线程调用
get()或set()操作的是完全不同的内存位置，天然无竞争 - 主线程设置的值，子线程默认拿不到（除非显式继承，如使用
InheritableThreadLocal） - 它不能替代
synchronized或AtomicXXX来保护共享对象的内部状态
典型适用场景：避免频繁传参或共享对象污染
适合保存“与当前线程强绑定、生命周期短、无需跨线程共享”的上下文数据。
-
用户身份/请求上下文：如 Web 过滤器中将
UserId或RequestInfo存入ThreadLocal，后续业务层直接获取，避免层层传递参数 -
数据库连接/事务资源：某些框架（如早期 Spring 的
TransactionSynchronizationManager）用它绑定当前线程的事务状态 -
格式化工具复用：如
SimpleDateFormat非线程安全，可为每个线程持有一个实例，避免重复创建
必须遵守的关键实践：及时 remove()，尤其在线程池环境下
这是最容易出问题的地方。线程池中的线程会被反复复用，若不清理 ThreadLocal，旧值会残留，导致：
- 脏数据：后一个任务读到前一个任务遗留的值（比如上个请求的用户 ID）
- 内存泄漏：
ThreadLocalMap中的 key 是弱引用，但 value 是强引用；key 被回收后，value 若不手动清理，会一直占着内存，直到线程结束
✅ 正确做法：
- 在方法退出前调用
threadLocal.remove()—— 推荐在finally块中执行 - Web 场景下，在过滤器（Filter）或拦截器（Interceptor）的
doFilter()/afterCompletion()中统一清理 - 使用线程池时，务必确认所有路径都清理了，必要时在任务包装器中强制
remove()
进阶注意：static + final 修饰，避免误用和内存泄漏源头
ThreadLocal 实例通常应声明为 static final：
- 静态：确保全局唯一变量槽位，避免因多个实例导致管理混乱
- final：防止被意外重新赋值，丢失原有引用（否则原
ThreadLocal对象无法被 GC，其 map 中的 entry 也可能无法清理） - 错误示例：
private ThreadLocal<string> userContext = new ThreadLocal();</string>—— 每个实例都会分配新槽位，且易被覆盖
✅ 正确写法：
private static final ThreadLocal<string> USER_ID = ThreadLocal.withInitial(() -> null);</string>
