threadlocal未remove导致内存泄漏：因key为弱引用而value为强引用，线程池中线程复用时“幽灵条目”堆积，需在finally、filter/interceptor末尾或通过装饰器/aop自动清理。
核心问题在于：ThreadLocal 变量没被 remove，值对象长期滞留在 Thread 的 ThreadLocalMap 中，尤其在线程池场景下，线程不销毁，这些“残留值”越积越多，最终撑爆堆内存。
为什么未移除会导致堆积
每个线程内部有个 ThreadLocalMap，其中 Entry 的 key 是 ThreadLocal 实例（弱引用），value 是你存的数据（强引用）。一旦 ThreadLocal 实例本身被回收（比如局部变量置为 null），key 就变成 null，但 value 仍被 map 强引用着——它既无法被访问，又无法被 GC 回收，成了“幽灵条目”。线程不死，这些条目就一直占着内存。
典型堆积场景与对应解法
- 线程池任务中忘记清理：提交到 ExecutorService 的 Runnable/Callable 里用了 ThreadLocal，但没调 remove。解决方式是在 finally 块中强制 remove，哪怕业务逻辑抛异常也要保证执行。
- Web 请求链路未兜底清除：Filter 或 Interceptor 中 set 了用户上下文，但响应返回后没 clear。建议在 Filter 的 doFilter 方法末尾或 Spring 的 HandlerInterceptor.afterCompletion 中统一调用 remove。
- 静态 ThreadLocal + 长生命周期线程：static final ThreadLocal 看似安全，但若 value 是大对象（如 byte[]、Map），且线程反复复用，不清理照样堆积。必须配合 remove，不能依赖“static 就不会泄漏”的误解。
让清理自动化，减少人为遗漏
手动写 try-finally 容易漏，更可靠的方式是封装或拦截：
- 用装饰器包装 Runnable：提交前自动 wrap，执行前后分别做 set 和 remove；
- Spring 环境下可结合 @Aspect，在 @Transactional 或自定义注解方法执行完后自动清理指定 ThreadLocal；
- 使用 Netty 的 FastThreadLocal —— 它重写了 ThreadLocalMap 清理逻辑，支持自动探测并回收无效 entry，降低泄漏风险。
验证是否还有堆积残留
可通过 JVM 堆转储（heap dump）分析 ThreadLocalMap 中的 Entry 数量和 value 大小。重点关注 key == null 但 value 非空的条目数量。开发阶段可在关键 ThreadLocal 上加日志，统计每次 set/remove 的配对情况，快速定位漏清理点。
