线程池满导致拒绝异常的本质是任务提交速率持续超过处理能力，需分三步排查：确认是否真触发拒绝（查日志与拒绝策略）、分析运行指标定位满因（activeCount、queueSize等）、抓线程dump和堆内存找瓶颈，最后优先优化任务而非盲目调大线程池。
线程池满导致的拒绝异常（如 RejectedExecutionException）本质是任务提交速率持续超过线程池处理能力，核心排查方向是：确认是否真“满”、为什么满、以及满后是否被合理处理。
看拒绝策略和日志，确认是否真触发了拒绝
不是所有“线程池满”都会抛异常——取决于配置的 RejectedExecutionHandler：
-
AbortPolicy（默认）：直接抛
RejectedExecutionException，日志里能看到明确异常堆栈； - CallerRunsPolicy：由提交线程自己执行任务，不抛异常，但可能拖慢上游，需关注调用方 CPU 和响应时间突增；
- DiscardPolicy / DiscardOldestPolicy：静默丢弃，无异常，只能靠业务监控（如任务漏处理、下游数据缺失）反推。
所以第一步：查应用日志中是否有 RejectedExecutionException；没有的话，别急着调大线程池，先检查是否用了非默认策略且未埋点监控。
查线程池运行指标，定位“满”的真实原因
光看异常不够，要结合运行时指标判断是**瞬时尖峰**还是**持续过载**：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
立即学习“Java免费学习笔记（深入）”；
-
核心指标（可通过 JMX、Actuator 或自定义暴露）：
● activeCount：当前正在执行任务的线程数；
● queueSize：等待队列中的任务数；
● poolSize：当前线程总数（含空闲）；
● largestPoolSize：历史最大线程数；
● completedTaskCount：已完成任务总数（配合时间窗口看吞吐）。 -
典型满态特征：
— 若activeCount == corePoolSize且queueSize持续高位 → 队列积压，说明消费慢（比如 I/O 阻塞、下游响应慢）；
— 若poolSize == maxPoolSize且queueSize == 0→ 线程全忙、无排队，说明 CPU 密集或任务执行太久；
— 若largestPoolSize接近maxPoolSize且频繁波动 → 可能是线程创建/销毁开销大，或任务执行时间不稳定。
抓现场：线程 dump + 堆内存分析
异常发生时立即获取线程快照，定位瓶颈：
- 用
jstack <pid>抓线程 dump，重点看：
— 大量线程处于WAITING (parking)或BLOCKED：常见于锁竞争、数据库连接池耗尽、远程调用未超时；
— 多个线程卡在相同方法（如某次 HTTP 调用、JDBC 查询）：说明该依赖成为瓶颈；
— 线程名含pool-*且状态为RUNNABLE但 CPU 不高：可能是 I/O 等待，需结合top -H看具体线程 CPU 占用。 - 用
jmap -histo:live <pid>或 MAT 分析堆，确认是否有大量待执行Runnable对象堆积（尤其使用有界队列时），或因对象未释放导致 GC 频繁、STW 时间长，间接拖慢线程池处理速度。
验证与优化：从代码和配置双路径入手
确认问题后，避免盲目调大 corePoolSize 或 maxPoolSize，优先做减法：
-
任务本身优化：
— 检查任务是否做了不该在线程池里做的事（如同步写日志、复杂 JSON 序列化）；
— 将阻塞操作（如 DB 查询、HTTP 调用）加上合理超时，并考虑异步化或降级；
— 避免在任务中创建新线程或使用另一个线程池（易引发连锁拒绝）。 -
线程池配置校准：
— 根据任务类型选队列：LinkedBlockingQueue（无界）慎用，易 OOM；ArrayBlockingQueue（有界）+ 合理容量，配合拒绝策略更可控；
—keepAliveTime设短一点（如 60s），让空闲线程更快回收，避免资源长期占着不用；
— 为不同业务场景隔离线程池（如读/写、实时/离线），防一个慢任务拖垮全局。
