一、问题现象与核心矛盾

当服务日志中出现大量RejectedExecutionException时，通常表明线程池已耗尽所有资源（核心线程、最大线程、队列容量均满），无法继续接收新任务。与此同时，CPU使用率持续100%则进一步揭示系统处于过载状态，可能由以下原因引发：

线程池配置不合理：核心线程数、最大线程数或队列容量与任务类型不匹配（如IO密集型任务配置过小）。
任务提交量激增：突发流量或依赖服务故障导致重试风暴，任务堆积速度超过处理能力。
资源竞争：CPU密集型任务与IO密集型任务混用同一线程池，导致资源抢占。
死锁或阻塞：部分任务长期阻塞线程（如数据库连接池耗尽、外部API超时未释放线程）。

二、紧急处置：快速恢复服务可用性

1. 动态调整线程池参数（无需重启）

通过配置中心或管理接口实时修改线程池参数，优先缓解拒绝任务问题。需根据任务类型差异化配置：

IO密集型任务（如网络请求、文件读写）：
- 核心线程数：临时翻倍（如从8调至16），利用空闲线程快速处理突发请求。
- 最大线程数：可设为CPU核心数×4（如32），避免因线程数不足导致队列堆积。
- 队列容量：有界队列扩容至2000，但需监控队列增长趋势，防止OOM。
CPU密集型任务（如计算、图像处理）：
- 核心线程数：设为CPU核心数+2（如6核CPU设为8），减少上下文切换开销。
- 最大线程数：不超过CPU核心数×2（如12），避免线程过多导致CPU争抢。
- 队列容量：建议使用同步队列（SynchronousQueue）或极小队列（如100），迫使任务快速失败或扩容。

代码示例：动态调整线程池

public void adjustThreadPool(ThreadPoolExecutor executor) {
    int cpuCores = Runtime.getRuntime().availableProcessors();
    // 根据任务类型调整参数（示例为IO密集型）
    executor.setCorePoolSize(cpuCores * 2); 
    executor.setMaximumPoolSize(cpuCores * 4);
    if (executor.getQueue() instanceof ResizableCapacityQueue) {
        ((ResizableCapacityQueue<?>) executor.getQueue()).setCapacity(2000);
    }
    executor.allowCoreThreadTimeOut(true); // 允许核心线程超时释放
    log.warn("线程池动态调整: core={}, max={}, queue={}", 
             executor.getCorePoolSize(), executor.getMaximumPoolSize(), executor.getQueue().size());
}

2. 任务降级与限流

暂停非核心任务：如日志上报、统计分析等可延迟处理的任务，通过开关配置快速关闭。
核心任务降级：对非关键外部依赖（如非实时查询）返回缓存数据或默认值，减少耗时。
入口限流：通过网关或服务网格（如Envoy）对非核心接口实施QPS限制，保护下游服务。

3. 临时扩容机器

若CPU过载由集群整体资源不足导致，需紧急扩容1-2台机器分担流量。建议结合容器化部署（如Kubernetes）实现快速扩缩容，避免物理机采购周期过长。

三、深度定位：分析根本原因

1. 监控数据关联分析

线程池指标：通过Prometheus或自定义Metrics暴露active_threads、queued_tasks、rejected_tasks等指标，定位拒绝任务的高峰时段。
CPU使用率分解：使用top、perf或火焰图工具分析CPU消耗分布，区分用户态/内核态、进程级/线程级开销。
任务类型识别：通过线程转储（jstack）或APM工具（如SkyWalking）分析线程堆栈，识别阻塞或耗时长的任务。

2. 常见根因与解决方案

根因	解决方案
线程池配置过小	根据任务类型重新计算核心/最大线程数，参考公式：`核心线程=CPU核心数×任务类型系数`
依赖服务故障	实现熔断机制（如Hystrix），故障时快速失败并返回降级数据
数据库连接池耗尽	增加连接池大小，优化SQL查询，启用连接泄漏检测
死锁或线程阻塞	通过`jstack`分析线程堆栈，修复同步块或资源竞争问题
突发流量	实施弹性伸缩策略，结合预测算法提前扩容

四、长期优化：构建健壮性架构

1. 线程池隔离策略

按业务拆分线程池：将核心交易、异步通知、日志处理等任务分配至独立线程池，避免相互影响。
使用工作队列模式：对耗时任务采用消息队列（如Kafka、RocketMQ）异步处理，解耦生产与消费。

2. 动态资源调度

容器化部署：通过Kubernetes HPA（水平自动扩缩容）基于CPU/内存使用率动态调整Pod数量。
Serverless架构：对突发流量场景，使用函数计算（如某云厂商的FC）按需分配资源，避免长期持有。

3. 全链路监控与告警

关键指标监控：覆盖线程池拒绝率、CPU使用率、任务处理延迟、依赖服务成功率等。
智能告警：设置阈值告警（如拒绝率>5%持续5分钟）并关联自动化脚本（如自动扩容、任务降级）。

五、总结与行动清单

紧急阶段：动态调整线程池参数 → 任务降级 → 临时扩容。
定位阶段：分析监控数据 → 识别根因（配置/依赖/流量/死锁）。
优化阶段：隔离线程池 → 引入消息队列 → 实现弹性伸缩。
预防阶段：完善监控告警 → 定期压测验证容量 → 编写应急预案文档。

通过上述步骤，团队可系统化应对线程池拒绝与CPU过载问题，将生产事故转化为架构优化的契机，提升系统整体稳定性。

线上服务突发RejectedExecutionException与CPU过载：系统性应急与优化方案