ThreadLocal 用于线程隔离而非线程通信，核心是为每个线程提供独立变量副本，避免共享变量的线程安全问题；需注意及时 remove() 防内存泄漏，异步场景需配合 TransmittableThreadLocal。
ThreadLocal 主要用于为每个线程提供独立的变量副本，避免共享变量带来的线程安全问题，而不是用来“传递”数据或替代参数传递。 它的核心价值在于“线程隔离”，不是“线程通信”。
数据库连接或事务上下文管理
在 Web 应用中，一个请求通常由一个线程处理。使用 ThreadLocal 可以绑定当前线程的 Connection、SqlSession 或 TransactionStatus，确保同一线程内多次 DAO 调用复用同一连接，且不会被其他线程干扰。
- MyBatis 的 SqlSession 默认就是基于 ThreadLocal 实现的“线程内单例”
- Spring 的 DataSourceTransactionManager 内部用 ThreadLocal 存储 TransactionSynchronizationManager 的资源绑定信息
- 手动管理时需注意：务必在请求结束（如 Filter 的 finally 块）中调用 remove()，防止连接泄漏或内存泄漏
用户认证与上下文透传
在无参调用链中（如日志打印、权限校验、灰度标识），避免层层手动传参，可将当前登录用户、租户 ID、请求 traceId 等放入 ThreadLocal。
- 例如：在拦截器中解析 Token 后存入 ThreadLocal
，后续 Service 层直接获取，无需修改方法签名 - 注意：异步调用（如 new Thread、线程池、CompletableFuture）会丢失该上下文，需显式传递或使用 TransmittableThreadLocal（阿里开源）
- 敏感信息（如 token、密码）不应长期驻留，应在业务逻辑结束后及时 remove()
SimpleDateFormat 等非线程安全对象的复用
像 SimpleDateFormat、DecimalFormat 这类类内部维护状态，不能全局共享。用 ThreadLocal 包装后，每个线程持有一个实例，兼顾安全与性能。
立即学习“Java免费学习笔记（深入）”；
- 替代方案：Java 8+ 推荐使用线程安全的 LocalDate/LocalDateTime + DateTimeFormatter（不可变、无状态）
- 若仍需使用旧 API，可定义 static final ThreadLocal
，初始化时创建新实例 - 避免在 ThreadLocal 中存大对象或缓存大量数据，否则易引发内存泄漏（尤其在线程池场景下）
避免内存泄漏的关键实践
ThreadLocal 的 key 是弱引用，但 value 是强引用。线程长期存活（如 Tomcat 线程池）时，若忘记 remove()，value 无法被回收，导致内存堆积。
- 每次 set() 后，尽量在作用域结束时调用 remove()；推荐 try-finally 或 try-with-resources 封装
- 不要依赖 ThreadLocal 的 get() 返回 null 来判断是否初始化——它可能只是还没 set，应主动初始化或使用 initialValue() 方法
- 子线程不会自动继承父线程的 ThreadLocal 值，除非显式调用 childValue() 或使用 InheritableThreadLocal（有额外开销，慎用）
