避免线程池OOM需控制任务堆积和线程膨胀：禁用Executors，显式创建ThreadPoolExecutor并配置有界队列、合理线程数、拒绝策略及配套监控与资源清理措施。
避免线程池引发内存溢出（OOM），关键在于控制任务堆积和线程膨胀这两个核心风险点。Java 中绝大多数 OOM 事故都源于线程池配置失当，而不是代码逻辑本身。
禁用 Executors 工具类创建线程池
Executors 提供的 newFixedThreadPool、newCachedThreadPool 等方法底层使用无界队列或 Integer.MAX_VALUE 线程上限，极易失控：
- FixedThreadPool：内部用 LinkedBlockingQueue(无参构造)，队列容量为 Integer.MAX_VALUE → 任务持续提交时内存持续增长，最终 OOM
- CachedThreadPool：maximumPoolSize = Integer.MAX_VALUE → 高并发下疯狂创建线程，耗尽 CPU 和栈内存
- 阿里《Java开发手册》与主流规范均强制禁止使用 Executors 创建生产环境线程池
显式使用 ThreadPoolExecutor 并配置有界队列
必须手动传入全部 7 个参数，尤其要约束队列容量和拒绝策略：
Java 接口排错助手
下载
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
- 选用 有界阻塞队列，如
new LinkedBlockingQueue(100)或ArrayBlockingQueue(200)，明确任务缓冲上限 - 搭配合适的拒绝策略：CallerRunsPolicy（由提交线程自己执行）可自然降速；AbortPolicy（抛异常）便于快速暴露压力瓶颈
- 避免使用 SynchronousQueue（实际无缓冲）或无界队列，除非你已精确压测并确认吞吐与延迟边界
合理设置核心与最大线程数
线程数量不是越多越好，需匹配业务类型与机器负载：
- CPU 密集型任务（如加解密、图像处理）：corePoolSize ≈ CPU 核数 + 1，maximumPoolSize 可略高但不宜超过核数 × 2
- IO 密集型任务（如数据库调用、HTTP 请求）：corePoolSize 可设为 CPU 核数 × 2 ~ × 4，但 maximumPoolSize 仍需设上限（如 50~100），防止线程过多引发上下文切换风暴
- keepAliveTime 建议设为 30~60 秒，既保障突发流量弹性，又避免空闲线程长期驻留
配套防护措施不能少
光靠参数配置还不够，运行期管控同样重要：
- 任务中务必捕获并处理异常，否则未捕获异常会导致工作线程终止，线程池逐渐“残缺”且难以发现
- 使用完毕后调用 shutdown()（平滑关闭）或 shutdownNow()（立即中断），避免线程池长期持有资源不释放
- 接入监控：定期采集
getActiveCount()、getQueue().size()、getCompletedTaskCount()等指标，设置队列积压告警 - 若任务内使用 ThreadLocal，必须在 finally 块中调用 remove()，防止线程复用导致内存泄漏累积
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
