目前按照我看过的一些开源框架，线程池中线程数量主要是根据应用的类型：IO密集型（2n +1 ），CPU密集型设置为 n + 1。
但实际情况往往复杂的多，不会按照这个进行设置，进行这种设置，通常是框架层面，例如netty,dubbo这种底层通讯框架会参考这样的标准去设置，在实际业务中往往不会这样做。
对于IO密集型网上还有一个公式：线程数 = CPU核心数/(1-阻塞系数)
这个阻塞系数一般为0.8~0.9之间，可以取0.8或者0.9。
我觉这个公式有一定的道理，考虑了阻塞的概念。
在我们的业务开发中，基本上都是IO密集型，因为往往都会去操作数据库，访问redis，es等存储型组件，涉及磁盘IO，网络IO。
那什么场景下是CPU密集型呢？纯计算类，例如计算圆周率的位数，当然我们基本接触不到。
IO密集型，可以考虑多设置一些线程，主要目的是可以增加IO的并发度，CPU密集型不宜设置过多线程，因为是会造成线程切换，浪费时间。
接下来我们以一个实际的场景来说明如何设置线程数量。
一个4C8G的机器上部署了一个MQ消费者，在RocketMQ的实现中，消费端也是用一个线程池来消费线程的，那这个线程数要怎么设置呢？
如果按照 2n + 1 的公式，线程数设置为 9个，但在我们实践过程中发现如果增大线程数量，会显著提高消息的处理能力，说明 2n + 1 对于业务场景来说，并不太合适。
如果套用 线程数 = CPU核心数/(1-阻塞系数) 阻塞系数取 0.8 ，线程数为 20 。阻塞系数取 0.9，大概线程数40，20个线程数我觉得可以。
如果我们发现数据库的操作耗时比较多，此时可以继续提高阻塞系数，从而增大线程数量。
**那我们怎么判断需要增加更多线程呢？**其实我觉得我们可以用jstack命令查看一下进程的线程栈，如果发现线程池中大部分线程都处于等待获取任务，则说明线程够用，如下图所示：
如果大部分线程都处于运行状态，可以继续适当调高线程数量。