ThreadLocal不会自动销毁，必须在任务结束前显式调用remove()清理，尤其在线程池中避免数据污染和内存泄漏；应声明为static final，并配合try-finally或afterExecute兜底清理。
ThreadLocal 本身不会自动“销毁”，它的值也不会随线程结束而自动清理——尤其在线程池中，线程长期复用，不主动清理就必然导致数据污染和内存泄漏。关键不是等它“销毁”，而是在每次任务结束前显式清理。
必须在任务退出前调用 remove()
线程池里的线程会反复执行不同任务，若上一个任务通过 ThreadLocal.set() 存了用户 ID、traceId 或格式化器，下一个任务调用 get() 就可能拿到旧值，造成逻辑错乱。
- 务必在业务逻辑执行完毕的最外层 try-finally 块中调用 remove()，确保无论正常返回还是抛异常都能执行
- 不要写成 if (xxx) threadLocal.remove() —— 条件不满足时照样残留
- 避免 set(null)，它只是存了个 null 值，Entry 还在，value 引用未释放，反而加重泄漏
用 static final 声明 ThreadLocal，但更要严控生命周期
把 ThreadLocal 声明为 static final 是正确做法（保证复用性），但这恰恰放大了风险：它的生命周期几乎永久，而每个工作线程都会为它维护一份 value。
- 声明方式正确示例：private static final ThreadLocal
CONTEXT = new ThreadLocal(); - 错误做法：把 ThreadLocal 声明为实例变量（每次 new Callable 都新建一个，失去线程隔离意义）
- 配套动作：每次使用后必须 remove()，不能依赖 initialValue() 或构造逻辑自动清理
借助线程池钩子统一兜底清理
即使任务内部忘了 remove，也可以在 ThreadPoolExecutor 的生命周期回调中补救：
立即学习“Java免费学习笔记（深入）”；
- 重写 afterExecute(Runnable r, Throwable t)，在任务执行结束后强制清理
- 只清理你自己定义的 ThreadLocal，不要碰 Spring、MyBatis 等框架管理的（应走它们自身的上下文生命周期）
- 示例：在 finally 块中调用 CONTEXT.remove()，比依赖任务代码更可靠
警惕虚拟线程与 InheritableThreadLocal 的组合风险
在 Java 21+ 虚拟线程场景下，若用了 InheritableThreadLocal，父子线程间传递的上下文可能因线程池复用被意外继承或残留。
- 普通 ThreadLocal 不会跨线程传递，但 InheritableThreadLocal 会复制父线程值到子线程
- 虚拟线程调度频繁，容易让本不该关联的请求共享上下文（如误传用户身份）
- 建议：除非明确需要继承，否则一律用普通 ThreadLocal，并坚持每任务 clean
