1、CPU 密集型程序
一个完整请求，I/O操作可以在很短时间内完成， CPU还有很多运算要处理，也就是说 CPU 计算的比例占很大一部分。
假如我们要计算 1+2+....100亿 的总和，很明显，这就是一个 CPU 密集型程序
在【单核】CPU下，如果我们创建 4 个线程来分段计算，即：
1、线程1计算 [1,25亿）
2、...... 以此类推
3、线程4计算 [75亿，100亿]
我们来看下图他们会发生什么？
由于是单核 CPU，所有线程都在等待 CPU 时间片。按照理想情况来看，四个线程执行的时间总和与一个线程5独自完成是相等的，实际上我们还忽略了四个线程上下文切换的开销
所以，单核CPU处理CPU密集型程序，这种情况并不太适合使用多线程
此时如果在 4 核CPU下，同样创建四个线程来分段计算，看看会发生什么？
每个线程都有 CPU 来运行，并不会发生等待 CPU 时间片的情况，也没有线程切换的开销。理论情况来看效率提升了 4 倍
所以，如果是多核CPU 处理 CPU 密集型程序，我们完全可以最大化的利用 CPU 核心数，应用并发编程来提高效率。
2、I/O密集型程序
与 CPU 密集型程序相对，一个完整请求，CPU运算操作完成之后还有很多 I/O 操作要做，也就是说 I/O 操作占比很大部分。
我们都知道在进行 I/O 操作时，CPU是空闲状态，所以我们要最大化的利用 CPU，不能让其是空闲状态
同样在单核 CPU 的情况下：
从上图中可以看出，每个线程都执行了相同长度的 CPU 耗时和 I/O 耗时，如果你将上面的图多画几个周期，CPU操作耗时固定，将 I/O 操作耗时变为 CPU 耗时的 3 倍，你会发现，CPU又有空闲了，这时你就可以新建线程 4，来继续最大化的利用 CPU。
综上两种情况我们可以做出这样的总结：
线程等待时间所占比例越高，需要越多线程；线程CPU时间所占比例越高，需要越少线程。
3、创建多少个线程合适？
从上面知道，我们有 CPU 密集型和 I/O 密集型两个场景，不同的场景当然需要的线程数也就不一样了
3.1、CPU 密集型程序创建多少个线程合适？
有些同学早已经发现，对于 CPU 密集型来说，理论上 线程数量 = CPU 核数（逻辑） 就可以了，但是实际上，数量一般会设置为 CPU 核数（逻辑）+ 1， 为什么呢？
《Java并发编程实战》这么说：
计算(CPU)密集型的线程恰好在某时因为发生一个页错误或者因其他原因而暂停，刚好有一个“额外”的线程，可以确保在这种情况下CPU周期不会中断工作。
所以对于CPU密集型程序， CPU 核数（逻辑）+ 1 个线程数是比较好的经验值的原因了
3.2、I/O密集型程序创建多少个线程合适？
上面已经让大家按照图多画几个周期（你可以动手将I/O耗时与CPU耗时比例调大，比如6倍或7倍），这样你就会得到一个结论，对于 I/O 密集型程序：
最佳线程数 = (1/CPU利用率) = 1 + (I/O耗时/CPU耗时)
这是一个CPU核心的最佳线程数，如果多个核心，那么 I/O 密集型程序的最佳线程数就是：
最佳线程数 = CPU核心数 * (1/CPU利用率) = CPU核心数 * (1 + (I/O耗时/CPU耗时))
说到这，有些同学可能有疑问了，要计算 I/O 密集型程序，是要知道 CPU 利用率的，如果我不知道这些，那要怎样给出一个初始值呢？
按照上面公式，假如几乎全是 I/O耗时，所以纯理论你就可以说是 2N（N=CPU核数），当然也有说 2N + 1的，（我猜这个 1 也是 backup），没有找到具体的推倒过程，在【并发编程实战-8.2章节】截图在此，大家有兴趣的可以自己看看
理论上来说，这样就能达到 CPU 100% 的利用率
如果理论都好用，那就用不着实践了，也就更不会有调优的事出现了。不过在初始阶段，我们确实可以按照这个理论之作为伪标准， 毕竟差也可能不会差太多，这样调优也会更好一些
。