threadlocal 是 java 中为每个线程提供独立变量副本的机制，通过线程内部的 threadlocalmap 实现隔离，需手动初始化、使用和 remove 以防内存泄漏。
ThreadLocal 是 Java 中为每个线程提供独立变量副本的核心机制，它不解决共享资源竞争问题，而是通过“空间换时间”的思路，让每个线程拥有自己的变量实例，从而避免同步开销和数据干扰。
ThreadLocal 的本质是线程级的 Map
每个 Thread 对象内部都持有一个 ThreadLocalMap（弱引用 key + 强引用 value），key 是 ThreadLocal 实例本身，value 才是你存的变量副本。调用 set() 或 get() 时，JVM 实际操作的是当前线程的这个 Map，因此天然隔离。
- 不同线程调用同一个 ThreadLocal 的
get()，返回的是各自线程中独立存储的值 - 主线程设置的值，子线程默认拿不到（除非显式继承，见下文）
- ThreadLocal 变量不会自动清理，线程复用（如线程池）时可能引发内存泄漏，务必配合
remove()
正确使用：初始化、使用、清理三步不能少
典型模式是声明 static final ThreadLocal，并在 get() 中提供初始化逻辑，避免 null 判断；在线程任务结束前主动 remove()。
- 推荐写法：
private static final ThreadLocal<simpledateformat> sdf = ThreadLocal.withInitial(() -> new SimpleDateFormat("yyyy-MM-dd"));</simpledateformat> - 若需复杂初始化或捕获异常，可重写
initialValue()方法 - 在 try-finally 或 try-with-resources 中调用
sdf.remove()，尤其在线程池场景下必须执行
注意父子线程间的数据传递（InheritableThreadLocal）
普通 ThreadLocal 的值不会自动传递给子线程。如果需要继承，应使用 InheritableThreadLocal —— 它在子线程创建时会拷贝父线程 ThreadLocalMap 中的对应 entry。
- 适用于日志 traceId、用户上下文等需透传的场景
- 但要注意：子线程修改不会影响父线程，且仍需手动 remove 防泄漏
- Spring 的
RequestContextHolder底层就基于 InheritableThreadLocal 实现请求上下文传播
常见误用与风险点
ThreadLocal 看似简单，但几个细节处理不当容易引发隐蔽 bug。
- 把 ThreadLocal 当全局单例用：误以为 set 后所有线程都能 get 到，实际只有当前线程可见
- 在线程池中忘记 remove：旧值残留导致业务逻辑错乱（比如上一个请求的 userId 被下一个请求误读）
- 存储大对象或未关闭资源（如 Connection、InputStream）：加剧内存泄漏风险
- static ThreadLocal 被多个类共用却未加命名区分：易造成语义混淆和覆盖
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
