一 . 系统说明：
A系统阿里云平台，5台集群，每台：1-2核，内存6G，带宽上限2M,磁盘1G。
基于tomcat容器，主要业务消费rocketmq，再pegion（服务治理工具）调用第三方服务。
同时接入20个左右topic的mq，并每一次mq都会调用一次第三方服务，第三方服务有B，C，D等系统，单台mq的qps 有几个（4个）比较大，一小时几十万。其他的比较小。
二. 问题：
5台集群一台的线程数量达到2500+，触发公司线程报警。其他四台也很高（2000+），但是还没到阀值。
三 .初步分析：
1. 调用链
看到线程数量大的这台a机器，调用B系统有多个请求时间到15S（调用超时时间是5S），并有10个左右调用失败，正常的都是1S以下，但是B系统的日志显示所有请求都是1S以下返回的。目前没有思路。
2. threaddump
2.1 活跃线程：
226个running Threads，194 个 "New I/O worker": running, holding...",活跃线程大部分是在epoolwait，应该是等着接收mq消息。
2.2 全部线程：
1900+个线程都在线程池里空闲着，等待任务来执行。
大致是：ConsumeMessageThread_X 有275个，NettyClientPublicExecutor_X 1024个，600+ 个线程池模样线程（pool-XX-thread-XXX）。
分析下 ：
（1）ConsumeMessageThread_X 是rocketmq的消费线程，epoolwait中，所以ConsumeMessageThread_X 也在等待。
数量上参考下rocketmq源码，在：
有20个客户端，所以基本也是这个数量，这里最小需要20个线程吗？有些mq真的qps超级小。包装消费类时可以在start方法前面，set这两个值。并对外提供配置方式。
（2）NettyClientPublicExecutor_X,NettyRemoteingClient.java ：这个线程是client做回调用的。
private int clientCallbackExecutorThreads = Runtime.getRuntime().availableProcessors();
所以应该是 可用processor有64个
这部分应该是云服务器的 物理服务器可用核太多，导致新建了很多无用的线程，其实这部分线程只做callback使用，数量应该也可以开发可配置。
（3）pool-XX-thread-XXX
有5（7，21，22，15，28）个线程池，每个线程池100+个线程，都是线程池里的线程空闲。
这部分需要看下pegion的代码，惊奇地发现pegion这部分跟dubbo一样，近似看下开源的dubbo的代码
大意就是各种threadpool用这个factory来生成线程，线程越来越多。没有源码很难看懂，从数量看也不是特别多，
如果猜测下应该是调用外系统超时导致多起了一些线程来处理，后续线程未释放掉。
遗留问题：
rocketmq不常用线程数量可以配置等方式减少下
dubbo pegion线程池数量等有场景再分析下
dubbo个别服务调用时间长，这个目前还没有思路。
https://www.cnblogs.com/thinkqin/p/11794028.html