ThreadLocal 本质是“每个线程配一个独立变量副本”
它不解决共享资源的同步问题，而是绕开共享——让变量压根就不共享。你声明一个 ThreadLocal<string></string>，10 个线程访问它，背后其实是 10 个互不相干的 String 实例，各自读写、互不影响。
所以别把它当锁用，也别指望它能在线程间传数据。它的价值在于：避免为非线程安全对象（比如 SimpleDateFormat）加锁，或在异步调用链里透传上下文而不靠层层传参。
- 常见错误现象：
get()返回null却没重写initialValue()，导致 NPE - 使用场景：Web 请求中存
userId、事务 ID；线程池中复用DecimalFormat等有状态工具类 - 性能影响：开销很小，但若长期不
remove()，在线程复用场景（如 Tomcat 线程池）下会引发内存泄漏
为什么必须显式调用 remove()？
因为线程池里的线程不会销毁，而 ThreadLocal 的底层是 Thread 对象内部的 ThreadLocalMap，key 是弱引用，value 是强引用。key 被 GC 后，value 若没被手动清理，就变成“不可达却无法回收”的孤魂野鬼。
这不是理论风险——线上服务跑几天后 OOM，堆 dump 里常能看到成百上千个残留的 UserContext 实例，根源就是忘了 remove()。
立即学习“Java免费学习笔记（深入）”；
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 实操建议：在过滤器（Filter）、拦截器（Interceptor）或
try-finally块末尾强制threadLocal.remove() - 别依赖“线程结束自动清理”：线程池线程永不结束，
remove()必须由业务代码兜底 - 如果用 Spring，可配合
@PreDestroy或RequestContextHolder.resetRequestAttributes()类似机制
set(null) 和 remove() 完全不是一回事
set(null) 是把当前线程副本设为 null 值，entry 还在 ThreadLocalMap 里，key 没变，value 变成 null —— 内存没释放，entry 仍占位，甚至可能干扰后续 get 逻辑（比如你判断 get() == null 就初始化，结果反复初始化）。
remove() 才是真正删除 entry，清空 key-value 关系，是唯一正确的清理动作。
- 错误写法：
ctx.set(null)，以为“清空了”，实际埋雷 - 正确写法：
ctx.remove()，哪怕只调一次也要写上 - 注意：
remove()是无害操作，重复调用不会报错，适合放在 finally 块里无脑执行
Spring 的 RequestContextHolder 底层就是 ThreadLocal
你用 RequestContextHolder.getRequestAttributes() 拿到当前请求的 ServletRequestAttributes，背后就是 ThreadLocal<requestattributes></requestattributes>。这意味着：只要没跨线程，它天然支持 Controller → Service → Dao 全链路透传请求上下文。
但一旦用了 CompletableFuture.supplyAsync() 或手动起新线程，这个链就断了——子线程没有父线程的 ThreadLocal 副本。
- 跨线程传递方案：用
TransmittableThreadLocal（阿里 TTL 库），或手动get()+set()透传 - 别误以为 Spring 自动帮你“继承”了：默认不继承，这是设计使然，不是 bug
- 异步日志、链路追踪 ID 透传等场景，必须额外处理，否则 MDC、traceId 都会丢失
remove() 就像往内存里悄悄钉钉子，短时间看不出，压测或上线几天后才扎手。 
