事件背景

系统相关使用人员反馈系统故障，日志显示从ams系统服务提示dubbo处理线程不足，具体异常信息如下：

问题定位

从上图可知，dubbo的处理线程池满了，默认200个线程，活动线程也是200个。这个现象非常不正常，我们的应用并发还没有到这个程度能同时占用200个线程处理请求。然后去读了下dubbo源码，发现dubbo也认为这种情况不正常，然后帮我们记录了应用的线程堆栈信息，这个非常赞。代码如下：

上面这段代码，在线程池不够用时，会每隔十分钟输出一份dump文件到用户目录，如：

在dump文件中，我们找到了耗尽DubboServerHandler线程池最后一个线程

通过分析得知：是我们应用程序有段代码导致的问题，在特定条件下会触发线程死锁，代码如下

代码中定义了一个线程屏障CyclicBarrier，同行数（调用await的线程数）是11，用来处理十个线程的运算，然后都计算完后拿到处理结果。本身代码没有什么问题，在没有并发的情况下，不会触发问题。但是注意中间那个箭头，执行线程的线程池是固定大小20的线程池，故当同时并发数多于2个的时候线程池的线程会不够用，导致线程等待，然后CyclicBarrier的main线程也会等待其他线程中的await。这就造成了相互等待，下一个请求过来还是继续等待，也就是死锁了。至此所有问题都以清晰明朗了。

解决问题

方案一：改CyclicBarrier为CountDownLatch，这个两个并发工具都是jdk1.5推出为了简化并发编程，CyclicBarrier的await会占用线程池中的线程不释放，导致线程不足，而CountDownLatch的count不会

方案二：改线程池类型为CachedThreadPool，不会应为线程池线程不够用，导致相互等待

文末结语

java并发包提供了丰富的api来简化多线程模型的开发，但是在针对多线程模型业务开发时，我们还需要多留心下多线程带来的坑。总之多核时代推荐大家多使用多线程开发，同时，也要对使用的工具有更多的了解