Dubbo线程池问题思考Thread pool is EXHAUSTED!

问题

前几天，我们的生产上突然出现了这样一个问题，调下面的查询方法报错，线程池满的问题，如下图：

问题思路

简单思考：我们都知道线程池的参数都包含什么含义！核心线程数，可建线程数，存储任务队列，拒绝策略！这块，大家不熟悉或者忘记的可以再补习补习！了解这几个参数我们不禁会问，任务处理不了，不是还有队列存储么？存储不了不是还有拒绝策略么？再者，怎么两百个线程就同时都被占用了？理论我们的场景没有这种量啊！带着这些问题，我们从源码中得到一些答案！

根据上面的问题，我找到了Dubbo相关源码，看一下生产版本2.6.5！我目前测试的版本是2.7.6，对比两个版本线程池这块的逻辑应该是差不多的，粘贴下源码：
类的位置：

源码如下：

public class AbortPolicyWithReport extends ThreadPoolExecutor.AbortPolicy {protected static final Logger logger = LoggerFactory.getLogger(AbortPolicyWithReport.class);private final String threadName;private final URL url;private static volatile long lastPrintTime = 0;private static Semaphore guard = new Semaphore(1);public AbortPolicyWithReport(String threadName, URL url) {this.threadName = threadName;this.url = url;}@Overridepublic void rejectedExecution(Runnable r, ThreadPoolExecutor e) {String msg = String.format("Thread pool is EXHAUSTED!" +" Thread Name: %s, Pool Size: %d (active: %d, core: %d, max: %d, largest: %d), Task: %d (completed: %d)," +" Executor status:(isShutdown:%s, isTerminated:%s, isTerminating:%s), in %s://%s:%d!",threadName, e.getPoolSize(), e.getActiveCount(), e.getCorePoolSize(), e.getMaximumPoolSize(), e.getLargestPoolSize(),e.getTaskCount(), e.getCompletedTaskCount(), e.isShutdown(), e.isTerminated(), e.isTerminating(),url.getProtocol(), url.getIp(), url.getPort());logger.warn(msg);dumpJStack();throw new RejectedExecutionException(msg);}private void dumpJStack() {long now = System.currentTimeMillis();//dump every 10 minutesif (now - lastPrintTime < 10 * 60 * 1000) {return;}if (!guard.tryAcquire()) {return;}Executors.newSingleThreadExecutor().execute(new Runnable() {@Overridepublic void run() {String dumpPath = url.getParameter(Constants.DUMP_DIRECTORY, System.getProperty("user.home"));SimpleDateFormat sdf;String OS = System.getProperty("os.name").toLowerCase();// window system don't support ":" in file nameif(OS.contains("win")){sdf = new SimpleDateFormat("yyyy-MM-dd_HH-mm-ss");}else {sdf = new SimpleDateFormat("yyyy-MM-dd_HH:mm:ss");}String dateStr = sdf.format(new Date());FileOutputStream jstackStream = null;try {jstackStream = new FileOutputStream(new File(dumpPath, "Dubbo_JStack.log" + "." + dateStr));JVMUtil.jstack(jstackStream);} catch (Throwable t) {logger.error("dump jstack error", t);} finally {guard.release();if (jstackStream != null) {try {jstackStream.flush();jstackStream.close();} catch (IOException e) {}}}lastPrintTime = System.currentTimeMillis();}});}}

根据上述源码，我们知道Dubbo定制了拒绝策略！从方法看，他是会把栈导出到系统文件的！Dubbo默认线程池核心线程数是200个的，可以通过参数设置！

复现问题

本地服务就可以制造个现场如下：
代码位置：码云链接
提供者代码：

@Service
public class TestApiImpl implements TestApi {private static Object lock = new Object();@Overridepublic void test(Test test) {System.out.println(Thread.currentThread().getName() + " 进入争抢资源...");synchronized (lock) {try {Thread.sleep(50000);} catch (InterruptedException e) {e.printStackTrace();}System.out.println("lock....." + Thread.currentThread().getName());}}
}

这里说一个小插曲：sleep是不会干预锁行为的！这点不同于wait方法！这个地方想要阻塞其他线程就要长期持有锁！

消费者代码：

@RestController
public class UserController {@Reference(timeout = 10000)private TestApi testApi;@GetMapping("/test")public void test(){Test test = new Test();testApi.test(test);}
}

启动服务之后，用jmeter测试一下：

开大于200个线程去调用/test的接口，就会报错：

有上面的源码可知，当出现这种情况的时候，会在系统用户的当前目录下生成出Dubbo_JStack.log.2020-05-22_11-55-23类似于这样的线程栈文件！我们可以通过这些信息查看都是为啥线程发生了阻塞等状况！

当然我们的例子我们是知道的，是因为对象锁被长期占用不释放导致的！

这里只是起到一个抛砖引玉的作用，提供大家思路去解决这样的问题！但是具体需要看一下，你们的问题到底是出在哪里？！是使用redis 无法初始化链接，连接数全部被占用！还是队列等问题，那就具体问题具体分析了，祝好！