ThreadLocal 使用不当会导致数据串号、内存泄漏和OOM，关键是要明确其生命周期：线程池中必须在 finally 块调用 remove()；static 声明仅影响 ThreadLocal 实例，不保证 value 安全；弱引用 key 无法防止 value 泄漏；跨线程需用 TransmittableThreadLocal。
ThreadLocal 用起来简单，但生产环境里出问题往往悄无声息——数据串号、内存持续上涨、GC 频繁、服务半夜 OOM。避开这些坑，关键不是“少用”，而是清楚每个操作背后的真实行为和生命周期约束。
线程池场景下不 remove 就等于埋雷
线程池复用线程，ThreadLocalMap 中的 Entry 不会随请求结束自动清空。前一个请求 set 的值，可能被下一个请求 get 到，造成用户上下文污染（比如 A 用户看到 B 用户的订单）。更严重的是，value 是强引用，只要线程不销毁，value 就一直可达，长期累积大对象（如 Map、StringBuilder、DTO）直接拖垮堆内存。
- 所有在过滤器、拦截器、AOP 或任务提交处 set 的 ThreadLocal，必须配对调用 remove()
- 不要依赖“线程执行完就自动清理”——线程池里的线程根本不会销毁
- remove() 要放在 finally 块里，确保异常时也能执行，例如：
try { context.set(userId); doWork(); } finally { context.remove(); }
static + ThreadLocal 组合容易误判生命周期
ThreadLocal 实例通常声明为 private static final，这是正确的；但很多人误以为“static 就代表全局唯一且安全”，却忽略了它只是 key 的句柄。真正存储数据的位置是每个 Thread 对象内部的 ThreadLocalMap，而这个 map 的生命周期绑定在线程上。一旦线程长期存活（如 Tomcat 工作线程、Netty EventLoop 线程），map 里的 Entry 就一直存在。
- 静态声明只影响 ThreadLocal 对象本身是否可被回收，不影响它写入的 value
- 如果 value 是大对象或持有外部引用（如 Service、Mapper、Connection），不 remove 就会导致这些对象无法 GC
- 可通过 MAT 分析 threadLocals 字段，确认是否存在大量未清理的 Entry
弱引用 key 并不能防止 value 泄漏
ThreadLocalMap 的 Entry 继承自 WeakReference
立即学习“Java免费学习笔记（深入）”；
- 线程空闲、不触发 ThreadLocal 操作时，脏 entry 和它的 value 会长期驻留
- 仅靠弱引用设计，无法解决线程池中“set 后再无任何 ThreadLocal 调用”的泄漏场景
- 必须主动 remove，不能寄希望于“弱引用能兜底”
父子线程间数据不传递，InheritableThreadLocal 也非万能
普通 ThreadLocal 在 new Thread() 场景下，子线程完全拿不到父线程的值。InheritableThreadLocal 虽可继承，但在使用线程池时依然失效——因为线程池中的线程是预先创建好的，不是由当前线程 new 出来的，inheritableThreadLocals 不会被复制。
- 若业务需要跨线程传递上下文（如异步日志、消息投递），应改用 TransmittableThreadLocal（TTTL）
- TTTL 通过重写 Executor、ThreadFactory 等方式，在 submit/run 时主动拷贝上下文，适配线程池
- 避免自己手动在父子线程间传参或用 static Map 模拟，极易出错且不可维护
