上篇我们排查了 Dubbo 直连模式调用失败的问题，根源是 URL 建立少了一个参数。这次 Dubbo 又报了另一个经典错误——线程池爆满，但这次根因不在 Dubbo 代码里。

线程池爆满，但 QPS 不高

某日下午。告警：Dubbo Provider order-service 大量请求返回 Thread pool is exhausted。

第一反应——加线程池 size。不够调到100、调到200——反正我第一想法就是"线程池配置小了"。

QPS 只有30/s。50个线程的池子，平均每个线程6秒才处理一个请求——理论负载极低。但 Dubbo 日志确实在抛：

-- :: WARN AbortPolicyWithReport: Thread pool is EXHAUSTED!
老实说，Thread Name: DubboServerHandler--thread-。Pool Size: 50,Task:,Executor status:,in dubbo://.:!java.util.concurrent.RejectedExecutionException: Thread pool is EXHAUSTED!at org.apache.dubbo.common.threadpool.support.AbortPolicyWithReport.rejectedExecution
at java.util.concurrent.ThreadPoolExecutor.reject
at java.util.concurrent.ThreadPoolExecutor.execute
...

: 日志显示所有线程都被占用且队列已空但QPS并不高

• "active = max": 全部50个工作线程都在运行状态
• "Task - completed ≈ active": 队列中没有积压任务
• "QPS=30/s × thread=50 ≈ idle": 每个线程平均6秒处理一个请求
• 矛盾点:所有线程被占用 没有积压任务 QPS很低 - 典型的非真实负载导致的假满状态!其实，

从 Dubbo 拒绝策略源码开始追踪根因方法🔍🔍🔍

: 当遇到 "Thread pool exhausted + active=max + QPS正常" 时。不要先怀疑请求量，应该 : 1. 检查 jstack 是否有阻塞/长时间运行的任务 2. 检查程序级资源限制 3. 分析其他组件对资源的占用情况

再看告诉我们，

• new Thread 调用失败时返回的是 OOM 错误而不是 RejectedExecutionException!
• 这是 JVM 层面创建内核线程失败导致的,与业务逻辑无关!
• 需要检查程序级别的资源限制!按理说，

new Thread 的底层机制⚡️⚡️⚡️

JVM 层面:
new Thread
→ JavaThread::create
→ os::create_thread

从操作程序层面来看，os::createthread → pthreadcreate

可能返回 EAGAIN 的两种情况: 1. RLIMITNPROC 达到上限 2. RLIMITMEMLOCK + RLIMIT_NPROC 达到上限

最终表现为 Java 中的 OutOfMemoryError:

三种修复方案及推荐顺序🛠️

sudo vi /etc/security/limits.d/-nproc.conf

• soft nproc *
• hard nproc *

ulimit -a | grep "max user processes" sysctl kernel.pid_max

echo *> /sys/fs/cgroup/system.slice/cpu.cfsperiodus echo *> /sys/fs/cgroup/system.slice/cpu.cfsquotaus

systemctl daemon-reload && systemctl restart service-name.service

将 ulimit 值设为服务器物理主要数×预期最大并发量×安全倍数 设置硬限制和软限制相同值避免意外降级问题。