多线程场景下的OOM特征：线程数量膨胀、ThreadLocal泄漏、线程池未回收

现象识别

多媒体应用中多线程场景的OOM通常不像大对象分配那样突然触发 Full GC 后立即崩溃。线程相关的OOM前期表现为应用响应迟钝、接口超时率上升、CPU 使用率持续走高但吞吐量下降。运维或监控告警中常见以下三种表象：

• 线程数量膨胀：通过 jstack 或 top -H 观察到的活跃线程数远超预期基线（如基线 200，实际达到 2000+），线程栈中大量线程停留在 RUNNABLE 或 WAITING 状态。
• ThreadLocal 泄漏导致元空间或堆外内存耗尽：堆转储中 java.lang.ref.Finalizer 或 java.lang.ThreadLocal$ThreadLocalMap$Entry 实例数量异常，且 GC Root 链指向长时间存活的线程。
• 线程池未回收（任务堆积）：工作队列（如 LinkedBlockingQueue）中待处理任务数持续增长，堆内存中 Runnable/Callable 对象占用了堆的大部分空间。

数据采集

在决定介入排查前，必须收集三组数据：

原因定位

定位阶段的核心是交叉验证线程快照与堆转储，按以下故障树逐层分解：

线程相关OOM
├─ 线程数量膨胀
│  ├─ 无限制创建线程（new Thread() 未池化）
│  └─ 线程池核心线程数设置过大 + 任务持续涌入
├─ ThreadLocal 泄漏
│  ├─ 线程池内线程复用，ThreadLocal 未 remove()
│  └─ 自定义线程未正确清理 InheritableThreadLocal
└─ 线程池未回收（任务堆积）
   ├─ 任务处理耗时过长（IO 阻塞 / 死锁）
   ├─ 拒绝策略设为 CallerRunsPolicy 导致调用线程被占
   └─ 队列无界，生产速度 > 消费速度

判断规则：检查 jstack.log 中是否有大量相同栈模式的线程（如 "pool-1-thread-*" 或 "http-nio-*"），若线程名称连续编号达数千且状态为 WAITING (parking)，则基本判定为线程池膨胀。若线程名称包含 "Thread-" 且无池名前缀，多为裸线程泄漏。

堆转储中看 ThreadLocalMap$Entry 的 referent 是否已被清除但 Entry 仍未释放（key=null 但 value 非空），以及 java.util.concurrent.ThreadPoolExecutor 的 workers 集合大小与线程快照是否一致。

修复动作

根据定位到的具体原因，采用针对性修复：

1. 裸线程泄漏：将 new Thread(runnable).start() 替换为线程池提交。对于必须使用线程的遗留代码，应在 finally 块中显式调用线程的 interrupt() 或确保任务结束后线程自然退出。
2. ThreadLocal 泄漏：在 ThreadPoolExecutor 的 beforeExecute/afterExecute 回调中清理 ThreadLocal，或在每个任务结束后使用 try-finally 执行 threadLocal.remove()。特别关注自定义 InheritableThreadLocal 的使用点。
3. 线程池参数不当：设置合理的 corePoolSize、maximumPoolSize 和有界工作队列（如 ArrayBlockingQueue），并配置拒绝策略（推荐 AbortPolicy 或 DiscardOldestPolicy，避免 CallerRunsPolicy）。

// 修改前：无界队列 + 无限最大线程（危险）
ThreadPoolExecutor executor = new ThreadPoolExecutor(
    10, Integer.MAX_VALUE,
    60L, TimeUnit.SECONDS,
    new LinkedBlockingQueue<Runnable>());

// 修改后：有界队列 + 上限 + 自定义拒绝
ThreadPoolExecutor executor = new ThreadPoolExecutor(
    10, 50,
    60L, TimeUnit.SECONDS,
    new ArrayBlockingQueue<>(100),
    new ThreadPoolExecutor.AbortPolicy());

复测

修复后必须经过以下验证步骤：

• 压测场景复现：使用与之前相同的并发压力（如 500 并发请求），持续运行 30 分钟以上。
• 线程稳定快照：间隔 1 分钟采集 3 次 jstack，确认线程总数稳定在预期值（如核心线程数 + 少量额外线程），且无大量 WAITING 堆积。
• 堆转储对比：比较修复前后堆中 ThreadLocalMap$Entry 实例数，应下降 90% 以上。LinkedBlockingQueue 或 ArrayBlockingQueue 的 size 若为 0 或极小值，则判定队列已排空。

预防

将以下检查点融入研发规范和监控体系中：