线程池中ThreadLocal更易泄漏，因线程复用导致ThreadLocalMap中弱引用key回收后强引用value滞留；必须在任务结束前用try-finally调用remove()彻底清除Entry，避免存大对象或外部引用。
在 Java 线程池中使用 ThreadLocal 时，若不主动清理，极易引发内存泄漏——根本原因是线程复用导致 ThreadLocalMap 中的 Entry（弱引用 Key + 强引用 Value）长期滞留，Value 无法被回收。
为什么线程池中 ThreadLocal 更容易泄漏？
普通线程执行完就销毁，其绑定的 ThreadLocalMap 也随之释放；但线程池中的线程会被反复复用，ThreadLocal 的 value 若未手动清除，会一直留在该线程的 ThreadLocalMap 中，尤其当 value 是大对象（如 Connection、StringBuilder 或自定义上下文）时，会持续占用堆内存，最终 OOM。
正确使用方式：set 后必须 remove
不要依赖 ThreadLocal 的自动清理机制。在线程任务结束前（尤其是 Runnable 或 Callable 执行末尾），显式调用 remove()：
- 避免只用
set(null)—— 这只是把 value 设为 null，Entry 仍存在，Key（弱引用）可能已回收，变成“stale entry”，但 value 引用还在，照样泄漏 - 务必调用
threadLocal.remove()，它会真正从ThreadLocalMap中移除整个 Entry - 推荐写法：用 try-finally 保证执行，例如：
try {
myThreadLocal.set(value);
// ... 业务逻辑
} finally {
myThreadLocal.remove(); // 关键！
}
避免在 ThreadLocal 中存大对象或外部引用
ThreadLocal 本质是“以空间换隔离”，不是缓存工具。设计时应遵循：
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
立即学习“Java免费学习笔记（深入）”；
- 只存轻量级、线程独有、生命周期与任务对齐的数据（如请求 ID、用户身份标识）
- 禁止存储数据库连接、文件句柄、大型集合等需显式释放的资源
- 避免持有外部对象（如 Service 实例、Spring Bean）的强引用，否则可能阻止整个 Spring 上下文卸载
利用 InheritableThreadLocal 要格外谨慎
子线程继承父线程的 ThreadLocal 值时，若父线程来自线程池，子线程（尤其短生命周期任务）可能让父线程的 ThreadLocal 值意外延长存活时间。除非明确需要传递上下文，否则优先用显式参数传递，或改用 TransmittableThreadLocal（阿里开源，支持线程池场景下的上下文传递并自动清理）。
不复杂但容易忽略：每次 set 就要配对 remove，这是线程池里用好 ThreadLocal 的铁律。
