threadlocal通过为每个线程提供独立变量副本，彻底规避可见性问题，因无共享故无同步需求；其核心方法包括set()、get()、remove()和initialvalue()，需特别注意线程池中未remove导致的内存泄漏风险。

直接用线程局部变量（ThreadLocal）为每个线程配一个独立的数值副本，就能绕开可见性问题——因为根本没共享，自然不存在“一个线程改了另一个线程看不到”的情况。

数值变量的可见隐患从哪来

普通成员变量或静态变量被多个线程共用时，一个线程对它的修改可能滞留在自己的 CPU 缓存里，不及时刷到主内存；其他线程读取时拿到的是旧值。比如 int count = 0; 放在类里，十个线程各执行一次 count++，最终结果很可能远小于 10。

这不是代码写错了，而是 Java 内存模型（JMM）下可见性未受保障的必然表现。

用 ThreadLocal 替代共享数值变量

把需要线程隔离的数值封装进 ThreadLocal，每个线程操作自己的副本：

• 声明带初始值的 ThreadLocal：private static final ThreadLocal localCount = ThreadLocal.withInitial(() -> 0);
• 获取当前线程的值：int val = localCount.get();
• 更新只影响本线程：localCount.set(val + 1);
• 用完及时清理：localCount.remove();（尤其在线程池场景中防止内存泄漏）

典型适用场景举例

不是所有数值都适合 ThreadLocal，关键看它是否“随线程而生、随线程而灭”：

• 请求级计数器：统计单次 HTTP 请求中某操作调用了几次
• 事务内序号生成：同一数据库事务中为子操作分配递增 ID
• 格式化过程中的临时偏移量：如解析日志时记录当前行号，仅本线程需维护
• 避免在方法间层层传参：比如一个深度调用链中都需要访问当前线程的超时毫秒数

必须注意的两个实操细节

ThreadLocal 不是银弹，用错反而埋雷：

• 别忘了 remove()：在线程复用场景（如 Tomcat 或自建线程池）中，不显式 remove 会导致上一个请求的数值残留，污染下一个请求
• 避免存储大对象或上下文全量：ThreadLocal 存的是引用，若指向一个庞大的 Map 或 DTO，容易引发堆外内存增长或 GC 压力，应只存真正轻量、线程专属的数值或简单状态