Executors 工厂类本身不直接导致 OOM，但其默认线程池配置易引发隐性内存泄漏：newCachedThreadPool() 可能触发 unable to create new native thread；newSingleThreadExecutor()/newFixedThreadPool() 因无界队列导致任务堆积；newScheduledThreadPool() 易因引用未清理形成强引用链。
Executors 工厂类本身不直接导致 OOM，但它封装的线程池配置极易掩盖内存与线程生命周期问题——尤其在生产环境变量（如缓存、上下文、ThreadLocal）未被正确清理时，会引发隐性内存泄漏，最终触发 java.lang.OutOfMemoryError: Java heap space 或 unable to create new native thread。
Executors 默认线程池的三大高危模式
这些模式在压测或流量突增时极易暴露问题：
-
Executors.newCachedThreadPool()：核心线程数为 0，最大线程数为
Integer.MAX_VALUE。一旦任务提交速率 > 执行完成速率，线程持续创建，直至触发unable to create new native thread（系统级线程耗尽），常被误判为“内存不足” -
Executors.newSingleThreadExecutor() / newFixedThreadPool(n)：使用无界队列
LinkedBlockingQueue（容量Integer.MAX_VALUE）。若下游处理慢或阻塞，任务持续堆积，Runnable对象长期驻留堆中，Retained Heap 持续增长 -
Executors.newScheduledThreadPool(n)：若定时任务中持有外部对象引用（如 Spring Bean、HTTP 客户端、数据库连接），且未显式清除，配合
ThreadLocal使用时极易形成“线程→任务→上下文→大对象”强引用链
从 OOM 日志反推是否由 Executors 引发
看到以下线索，应立即怀疑线程池配置不当：
- 错误信息为
OutOfMemoryError: unable to create new native thread→ 检查ulimit -u和线程数监控，再用jstack -l <pid> | grep java.lang.Thread | wc -l</pid>统计实际线程数 - 堆 dump 中大量
java.util.concurrent.ThreadPoolExecutor$Worker实例，且每个 Worker 持有非空firstTask或关联的CachedThreadPool线程名（如pool-1-thread-12345） - 堆中存在巨量
FutureTask、RunnableAdapter或业务Runnable实例，其retained heap占比超 20%，且引用链指向某定时/异步服务类 - GC 日志显示老年代缓慢上涨、Full GC 后回收极少，但
jstat -gc显示年轻代 GC 频繁 —— 说明对象“活”得久，很可能是任务队列中的待执行任务
实战排查四步定位法
无需重启，快速锁定 Executors 相关泄漏点：
- 抓取实时线程快照：
jstack -l <pid> > jstack_oom.txt</pid>，搜索pool-、cached、schedule等关键词，统计各线程池活跃线程数和阻塞栈 - 检查任务队列状态：
jmap -histo <pid> | grep -E "(FutureTask|Runnable|ArrayList|LinkedList)"</pid>，重点关注实例数异常高的任务包装类 - 分析堆中线程局部变量：
jcmd <pid> VM.native_memory summary</pid>查看 internal 区是否异常高（暗示 ThreadLocal 泄漏）；再用 MAT 打开 dump，按ThreadLocalMap过滤，看 value 是否为业务对象（如 UserContext、TraceId） - 代码层交叉验证：全局搜索
Executors\.new.*ThreadPool，重点检查是否满足「三无」—— 无自定义ThreadFactory（无法设名称/捕获异常）、无拒绝策略（默认AbortPolicy不打日志）、无显式shutdown()（尤其在 Spring @PreDestroy 中缺失）
安全替代方案与加固建议
不用 Executors，改用显式构造 + 可控边界：
- 替换
newCachedThreadPool：用new ThreadPoolExecutor(0, 200, 60L, TimeUnit.SECONDS, new SynchronousQueue(), r -> new Thread(r, "biz-async-%d"))，设上限并命名线程 - 替换
newFixedThreadPool：用new ThreadPoolExecutor(4, 4, 0L, TimeUnit.MILLISECONDS, new LinkedBlockingQueue(1024), ...)，加有界队列防堆积 - 所有线程池必须配拒绝策略：
new ThreadPoolExecutor.CallerRunsPolicy()或自定义日志记录型策略 - 涉及 ThreadLocal 的异步任务，务必在 Runnable.run() 结尾调用
threadLocal.remove()；Spring 环境优先用@Async+TaskDecorator统一清理
