linux查看dubbo线程池,Arthas | 定位线上 Dubbo 线程池满异常

前言

本文是 Arthas 系列文章的第二篇。

Dubbo 线程池满异常应该是大多数 Dubbo 用户都遇到过的一个问题，本文以 Arthas 3.1.7 版本为例，介绍如何针对该异常进行诊断，主要使用到 dashboard/thread 两个指令。

Dubbo 线程池满异常介绍

理解线程池满异常需要首先了解 Dubbo 线程模型，官方文档：。简单概括下 Dubbo 默认的线程模型：Dubbo 服务端每次接收到一个 Dubbo 请求，便交给一个线程池处理，该线程池默认有 200 个线程，如果 200 个线程都不处于空闲状态，则

客户端会报出如下异常：Caused by: java.util.concurrent.ExecutionException: org.apache.dubbo.remoting.RemotingException: Serverside(192.168.1.101,20880)threadpoolisexhausted...

服务端会打印 WARN 级别的日志：[DUBBO] Thread pool is EXHAUSTED!

引发该异常的原因主要有以下几点：客户端/服务端超时时间设置不合理，导致请求无限等待，耗尽了线程数

客户端请求量过大，服务端无法及时处理，耗尽了线程数

服务端由于 fullgc 等原因导致处理请求较慢，耗尽了线程数

服务端由于数据库、Redis、网络 IO 阻塞问题，耗尽了线程数

...

原因可能很多，但究其根本，都是因为业务上出了问题，导致 Dubbo 线程池资源耗尽了。所以出现该问题，首先要做的是：排查业务异常

紧接着针对自己的业务场景对 Dubbo 进行调优：调整 Provider 端的 dubbo.provider.threads 参数大小，默认 200，可以适当提高。多大算合适？至少 700 不算大；不建议调的太小，容易出现上述问题

调整 Consumer 端的 dubbo.consumer.actives 参数，控制消费者调用的速率。这个实践中很少使用，仅仅一提

客户端限流

服务端扩容

Dubbo 目前不支持给某个 service 单独配置一个隔离的线程池，用于保护服务，可能在以后的版本中会增加这个特性

另外，不止 Dubbo 如此设计线程模型，绝大多数服务治理框架、 HTTP 服务器都有业