生产环境必须禁用Executors工厂方法，手动构造有界队列、显式参数、命名线程工厂和CallerRunsPolicy的可监控线程池，以防止任务积压OOM。

Java线程池用不好，不是性能上不去，而是直接OOM。关键不在“多开线程”，而在“任务积压失控”和“资源不可见”。生产环境必须绕过Executors工厂方法，手动构造可监控、有边界的线程池。

禁用Executors默认方法，显式控制三大核心参数

所有Executors静态工厂方法（如newFixedThreadPool、newCachedThreadPool）在生产中都应禁用。它们隐藏了关键配置，且默认使用无界队列或无限线程数：

• newFixedThreadPool底层是LinkedBlockingQueue(Integer.MAX_VALUE)，任务持续提交会把大量Runnable对象（含HTTP请求体、DTO、数据库参数等）堆积在堆内存中，几百个就可能吃掉数百MB
• newCachedThreadPool最大线程数为Integer.MAX_VALUE，高并发下线程疯涨，易触发栈溢出或CPU打满
• newSingleThreadExecutor同样基于无界队列，且被封装成不可转型、不可调参的FinalizableDelegatedExecutorService，异常后线程静默死亡

用有界队列替代无界队列，设置合理容量

队列不是越大越好，而是要“上限可见”：

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

• 选用ArrayBlockingQueue而非LinkedBlockingQueue，并明确指定容量（例如new ArrayBlockingQueue<Runnable>(256)）
• 队列容量需与线程数匹配：若核心/最大线程数设为8，队列设256，则系统最多缓冲256个待执行任务；超出即触发拒绝策略，不会静默堆积
• 避免将队列容量设为10000甚至更大——这等于把OOM延后，而非规避

选择合适的拒绝策略与线程工厂

拒绝策略是反压的第一道防线，线程工厂是可观测性的基础：

立即学习“Java免费学习笔记（深入）”；

• 推荐CallerRunsPolicy：当队列满时，由提交任务的线程自己执行该任务，天然实现背压，防止任务无节制涌入
• 务必传入命名的ThreadFactory，例如用ThreadFactoryBuilder生成格式为"biz-notify-%d"的线程名，便于日志追踪与监控定位
• 避免使用AbortPolicy（直接抛异常）在关键路径，除非业务能容忍任务丢失；必要时可自定义策略，记录日志+降级处理

接入运行时监控，让线程池“看得见、管得住”

手动构造后才能获取真实指标，这是规避OOM的闭环保障：

• 调用getQueue().size()实时查看积压量，超过阈值（如队列容量的80%）立即告警
• 用getActiveCount()观察当前活跃线程数，判断是否已打满，结合CPU使用率判断是否需扩容
• 通过Micrometer或Prometheus暴露pool.activeThreads、pool.queueSize等指标，纳入统一监控告警体系