ThreadLocal 如何使用？

核心回答

Java 的 ThreadLocal 为同一个变量提供按线程隔离的存取位置，适合保存与当前线程执行过程关联的状态，例如同步请求调用链中的请求 ID、租户信息。它不通过加锁让多个线程共同修改一份值。

常见用法是：

1. 定义一个可复用的 ThreadLocal 入口；需要默认值时可用 withInitial 提供初始化函数。
2. 在请求或任务入口用 set() 设置当前线程的值，调用链中用 get() 读取。
3. 在负责该上下文生命周期的边界，用 finally 中的 remove() 清理，保证异常退出也执行。若只是临时覆盖外层已有上下文，退出时应恢复原值。

底层由每个 Thread 持有自己的 ThreadLocalMap；同一个 ThreadLocal 对象在不同线程的 Map 中对应不同条目。线程局部不等于请求局部或任务局部：线程池会复用线程，跨线程执行也不会自动取得调用方的普通 ThreadLocal 值。

一次请求中如何使用？

假设入口解析出请求 ID req-A，将它设置到当前线程的上下文；后续服务、DAO 和日志组件在同一线程中读取这个值，便可把日志关联到本次请求，避免每一层都增加相同的上下文参数。

请求结束时清理很重要。线程池随后可能让同一工作线程处理请求 B；若 A 没清理，而 B 又没有设置自己的值，B 就可能读到 req-A。这不仅是内存占用问题，也可能造成日志混淆或租户上下文串用。

普通 ThreadLocal 未设置时，get() 会触发当前线程的初始值逻辑，默认返回 null；withInitial 可改变初始值。remove() 删除当前线程的条目，后续再次 get() 可以重新初始化，不是每调用一次 get() 就新建一份值。

为什么弱引用仍可能造成内存滞留？

以 OpenJDK 25 实现为例，引用关系是：线程持有 ThreadLocalMap，Map 持有 Entry，Entry 弱引用 ThreadLocal 键、强引用 value。

当 ThreadLocal 本身不再被外部强引用，GC 可能清除弱引用键；但 Entry 里的 value 不会因为键被清除就同步消失。长寿命线程仍可能通过 Map 保留这份 value，直到条目被后续操作清理，或者线程及相关对象不再可达。部分 get、set、remove 路径会顺带清理失效条目，但不能依赖它们及时清空全部残留。

即使 ThreadLocal 被 static final 持有，键没有失效，任务已结束的 value 仍可能被工作线程继续保留。因此，关键是明确值的生命周期，及时清理，而不是只讨论弱引用是否被 GC。

线程池和 Spring 异步任务怎样传上下文？

InheritableThreadLocal 主要在线程创建时继承父线程的值。线程池中的工作线程通常早已创建，还会执行多个提交方的任务，所以它不能自然表示“这一次提交时的上下文”。

跨线程时，可优先把必要数据作为任务参数；需要隐式上下文时，则按任务进行捕获、安装、执行、恢复：提交时捕获所需值，执行前设置到工作线程，退出时恢复原有状态或清理。也有 TTL 这类组件封装任务传播，但仍需明确传播哪些值、捕获时机和执行器接入方式。

Spring 的 @Async 通常通过执行器切换线程，仅添加注解不保证任意 ThreadLocal 自动传播。可以在所用执行器上配置 TaskDecorator，或使用适配的上下文传播设施实现上述过程；如果某个执行器没有接入这套机制，任务仍可能取不到值或读到残留值。传递请求 ID，也不意味着把事务、数据库连接等线程绑定资源一起移交给异步任务。

常见追问

ThreadLocal 中的对象一定线程安全吗？ 不一定。隔离的是存取条目，不是自动深拷贝对象。如果两个线程各自 set() 的仍是同一个可变对象引用，后续依然在共享它，需要额外的并发控制。

set(null) 和 remove() 一样吗？ 不一样。前者保留一个值为 null 的条目，后者删除当前线程的条目；删除后再 get() 可以重新走初始化逻辑。因此任务结束时通常用 remove() 表达生命周期结束。

对应教程

参考资料