核心线程长期存活导致上下文对象确定性驻留；需通过jstack查栈帧状态、mat分析threadlocalmap和闭包引用，并验证remove逻辑是否全覆盖执行。
线程池核心线程默认不销毁，长期存活的栈帧会成为 GC Roots，把本该随请求结束就丢弃的上下文对象（如 ThreadLocal 中的 value、闭包捕获的对象、临时 DTO）牢牢钉在堆里——这不是“可能泄漏”，而是确定性驻留。排查重点不在“线程是否活着”，而在“它栈上和 ThreadLocalMap 里锁住了哪些不该存在的东西”。
看线程栈：确认核心线程真实存活状态
用 jstack <pid></pid> 抓取线程快照，过滤出核心线程名（如 pool-1-thread-1、task-3），观察它们是否持续存在、状态是否长期为 WAITING 或 TIMED_WAITING。特别注意：
• 若应用已空闲 5 分钟以上，这些线程仍在线程列表中，说明未配置 allowCoreThreadTimeOut(true)
• 若线程栈顶是 getTask()（来自 ThreadPoolExecutor.Worker），说明它正空转等待任务，此时栈帧本身已是稳定 GC Root
• 同一线程处理不同 traceId 的请求，是任务残留最直接的证据
查 ThreadLocalMap：定位被强引用锁死的业务对象
ThreadLocal 的 key 是弱引用，value 是强引用；key 被 GC 后 Entry 变成“幽灵 entry”，但 value 仍挂在 Thread → threadLocals → table[i] → value 链上。用 MAT 打开 heap dump 后：
• 搜索 java.lang.ThreadLocal$ThreadLocalMap
• 展开每个 map 的 table 数组，逐个检查 Entry.value 类型
• 重点关注：UserContext、TraceContext、TenantContext、MDC、自定义 DTO 等本该一次请求一清的对象
• 若发现大量相同类实例，且所属线程 ID 与 jstack 中长期存活的核心线程一致，即确认污染源
扫闭包与栈本地变量：揪出隐式强引用
Runnable/Callable 实例常通过 lambda 或匿名内部类捕获外部变量，这些变量会作为栈帧或对象字段被线程持有：
• 在 MAT 中筛选 java.lang.Runnable 或 java.util.concurrent.Callable 子类实例
• 查看其字段，尤其是非 static、非 final 的引用类型字段（如 userId、requestId、authToken）
• 检查这些字段指向的对象是否生命周期远超单次任务（例如一个 Map 缓存了前 100 次请求的数据）
• 特别警惕日志框架（如 Logback 的 MDC）、权限校验工具类、泛型回调处理器，它们极易在闭包中意外持有所属请求的上下文
验证清理逻辑是否真正执行
很多代码写了 try ... finally { tl.remove() }，但没覆盖所有出口：
• 方法内抛出 RuntimeException 且未被捕获，finally 不执行
• 使用了 Lombok 的 @SneakyThrows，掩盖了异常传播路径
• Spring AOP 切面中拦截了方法，但切面本身未做上下文清理
• 异步回调（如 CompletableFuture.thenApply）运行在另一线程，原线程的 ThreadLocal 已失效，新线程又未初始化
建议在 remove 前加日志（如 log.debug("Removing userId from TL")），上线后观察是否每条请求都输出，缺失即代表清理未触发
