runnable线程持有大对象导致内存泄漏，本质是对象生命周期被意外延长；需通过jstat观察old gen单向增长、jstack分析runnable线程堆栈、jmap+mat定位隐式引用链（如this$0、threadlocal、静态缓存等）并修复清理逻辑。
Runnable 线程持有大对象引发内存泄漏，本质是对象生命周期被意外延长——尤其在线程池复用场景下，Runnable 实例及其隐式引用的对象（比如外部类、缓存数据、IO 缓冲区等）会长期驻留堆中，GC 无法回收。排查关键不在“Runnable 本身”，而在它背后持有的强引用链。
看线程状态和堆内存趋势是否匹配
先确认这不是假警报：用 jstat -gc
- 用 jps 找到 Java 进程 ID
- 用 jstack
> threaddump.log 抓快照，重点搜 java.lang.Thread.State: RUNNABLE 和对应堆栈中的业务类名（如 YourService$$Lambda、YourTask、InnerRunnable） - 对比多个时间点的 dump，看同一批线程是否反复出现在相同方法里，且未退出
定位 Runnable 持有的大对象来源
非静态内部类或 Lambda 是最常见“隐形推手”。编译后，它们会隐式持有外部类实例（this 非静态内部类或 Lambda 是最常见“隐形推手”。编译后，它们会隐式持有外部类实例（this$0），而外部类又可能持有很多资源：数据库连接池、缓存 Map、字节数组、HTTP 响应体等。
- 用 jmap -dump:format=b,file=heap.hprof
生成堆快照 - 在 Eclipse MAT 中打开，运行 Leak Suspects Report，看 top 占用是否指向某类 Runnable 或其封闭类
- 用 OQL 查询：SELECT * FROM instanceof java.lang.Runnable WHERE toString().contains("YourTask")，再右键 → Path to GC Roots → with all references，逐层展开，找到 value 字段里实际占内存的大对象（如 byte[]、HashMap、Protobuf 对象）
- 特别检查 OuterClass$1 这类匿名类名，它大概率就是问题 Runnable；若看到 this$0 引用了一个 Service 实例，再点开该 Service 的字段，常能发现未清理的 List、Cache 或 ThreadLocal
检查线程池任务是否遗漏清理动作
Runnable 提交到线程池后，线程不会销毁，只会归还给池。如果 Runnable 内部用了 ThreadLocal、静态缓存、或注册了监听器但没注销，这些都会随线程一起“沉淀”下来。
- 搜索代码中所有 executor.submit(new MyRunnable()) 或 CompletableFuture.runAsync() 调用点
- 确认每个 Runnable 的 run() 方法末尾是否有 try-finally { ... threadLocal.remove(); }
- 检查是否在 initialValue() 中直接 new 了大对象（如 new byte[1024*1024]），应改为懒加载 + 显式 set
- 查 Spring 环境下是否用了 @Async，对应方法里是否调用了 ThreadLocal 或持有 RequestContextHolder、LocaleContext 等 Web 上下文对象
验证与修复后的观测要点
改完代码后别急着上线，先做两件事验证效果：
- 重启服务后，用 jstat 连续监控 1 小时，Old Gen 波谷是否不再逐日抬高
- 触发几次人工请求，再抓一次 threaddump 和 heapdump，对比 Runnable 实例数是否稳定（MAT 中 Histogram 查 YourRunnable 类实例数）、ThreadLocalMap 中 Entry 数量是否不随请求数线性增长
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
