关键在于通过机制而非自觉确保ThreadLocal清理：将remove()放入finally块强制执行；线程池中重写afterExecute()或用Filter/切面统一兜底；声明为private static final并封装clear()方法。
关键不是“记不记得清理”，而是让清理这件事无法被跳过——靠机制，不靠自觉。
把 remove() 写进 finally 块，强制执行
每次调用 set() 或 get() 后，只要业务逻辑结束，就必须清空。最直接可靠的方式是包裹在 try-finally 中：
- 不管业务代码是否抛异常、是否提前 return，finally 里的 remove() 都会执行
- 不要用 set(null)，它只覆盖 value，Entry 还留在 ThreadLocalMap 里，key=null 的“僵尸条目”照旧占内存
- 示例写法：UserContext.clear() 应该封装好，业务层只管调用，不碰底层 remove()
在线程池执行完任务后统一兜底清理
单靠任务内部的 try-finally 仍可能漏：比如任务被线程池拒绝、未调度成功、或被中断。更稳妥的是在框架层拦截：
- 继承 ThreadPoolExecutor，重写 afterExecute() 方法，在里面对所有已知 ThreadLocal 显式调用 remove()
- Spring 环境下可用切面，在 @AfterReturning 或 @AfterThrowing 中统一清理当前线程绑定的 ThreadLocal
- Web 场景推荐 Filter：在 doFilter chain 执行完毕后调用 clear()，确保每个 HTTP 请求生命周期结束即释放
声明规范 + 封装工具方法，降低出错概率
从源头减少误用机会：
立即学习“Java免费学习笔记（深入）”；
- ThreadLocal 必须声明为 private static final，避免重复创建，也便于集中管理
- 提供 public static clear() 方法，隐藏 remove() 细节，业务代码只需调用这个语义明确的方法
- 禁止在 ThreadLocal 中存大对象（如 byte[]、完整上下文 Map），哪怕清了也容易在复用窗口内堆积
真正危险的不是某次忘记 remove，而是长期运行的线程反复叠加残留。机制化清理比提醒更有效。
