线程的执行，是由CPU进行调度的，一个CPU在同一时刻只会执行一个线程，我们看上去的线程A 和 线程B并发执行。
为了让用户感觉这些任务正在同时进行，操作系统利用了时间片轮转的方式，CPU给每个任务都服务一定的时间，然后把当前任务的状态保存下来，在加载下一任务的状态后，继续服务下一任务。任务的状态保存及再加载，这段过程就叫做上下文切换。
上下文切换是需要时间的
在实际工作中，我们需要根据任务类型的不同选择对应的策略。
- CPU 密集型任务
首先，我们来看 CPU 密集型任务，比如加密、解密、压缩、计算等一系列需要大量耗费 CPU 资源的任务。对于这样的任务最佳的线程数为 CPU 核心数的 1~2 倍，如果设置过多的线程数，实际上并不会起到很好的效果。此时假设我们设置的线程数量是 CPU 核心数的 2 倍以上，因为计算任务非常重，会占用大量的 CPU 资源，所以这时 CPU 的每个核心工作基本都是满负荷的，而我们又设置了过多的线程，每个线程都想去利用 CPU 资源来执行自己的任务，这就会造成不必要的上下文切换，此时线程数的增多并没有让性能提升，反而由于线程数量过多会导致性能下降。
针对这种情况，我们最好还要同时考虑在同一台机器上还有哪些其他会占用过多 CPU 资源的程序在运行，然后对资源使用做整体的平衡。
- 耗时 IO 型任务
第二种任务是耗时 IO 型，I/O 本质是对设备的读写。读取键盘的输入是 I/O，读取磁盘（SSD）的数据是 I/O。通常 CPU 在设备 I/O 的过程中会去做其他的事情，当 I/O 完成，设备会给 CPU 一个中断，告诉 CPU 响应 I/O 的结果。比如说从硬盘读取数据完成了，那么硬盘给 CPU 一个中断。如果操作对 I/O 的依赖强，比如频繁的文件操作（写日志、读写数据库等），可以看作I/O 密集型。
比如数据库、文件的读写，网络通信等任务，这种任务的特点是并不会特别消耗 CPU 资源，但是 IO 操作很耗时，总体会占用比较多的时间。对于这种任务最大线程数一般会大于 CPU 核心数很多倍，因为 IO 读写速度相比于 CPU 的速度而言是比较慢的，如果我们设置过少的线程数，就可能导致 CPU 资源的浪费。而如果我们设置更多的线程数，那么当一部分线程正在等待 IO 的时候，它们此时并不需要 CPU 来计算，那么另外的线程便可以利用 CPU 去执行其他的任务，互不影响，这样的话在任务队列中等待的任务就会减少，可以更好地利用资源。
读取硬盘数据到内存中这个过程，CPU通常不需要一个个字节处理
因为在今天的计算机中有一个叫作 Direct Memory Access（DMA）的模块，这个模块允许硬件设备直接通过 DMA 写内存，而不需要通过 CPU（占用 CPU 资源）。
我们的真实业务一般如下所示
整个过程涉及到下列计算机处理流程
- 网络请求—–>网络IO
- 解析请求—–>CPU
- 请求数据库—–>网络IO
- MySQL查询数据—–>磁盘IO
- MySQL返回数据—–>网络IO
- 数据处理—–>CPU
- 返回数据给用户—–>网络IO
在真实业务中我们不单单会涉及CPU计算，还有网络IO和磁盘IO处理，这些处理是非常耗时的。如果一个线程整个流程是上图的流程，真正涉及到CPU的只有2个节点，其他的节点都是IO处理，那么线程在做IO处理的时候，CPU就空闲出来了，CPU的利用率就不高。
所以多线程的作用就是提升CPU利用率
1. 系统性能
衡量系统性能如何，主要指标系统的（QPS/TPS）
QPS/TPS：每秒能够处理请求/事务的数量
并发数：系统同时处理的请求/事务的数量
响应时间：就是平均处理一个请求/事务需要时长
QPS/TPS = 并发数/响应时间
上面公式代表并发数越大，QPS就越大；所以很多人就会以为调大线程池，并发数就会大，也会提升QPS。但其实QPS还跟响应时间成反比，响应时间越大，QPS就会越小。虽然并发数调大了，就会提升QPS，但线程数也会影响响应时间，因为上面我们也提到了上下文切换的问题。
2. 基础常规标准
别人总结的一个基础值（还是要根据实际情况调整）
- CPU密集型：操作内存处理的业务，一般线程数设置为：
CPU核数 + 1 或者 CPU核数*2。核数为4的话，一般设置 5 或 8 - IO密集型：文件操作，网络操作，数据库操作，一般线程设置为：
cpu核数 / (1-0.9)，核数为4的话，一般设置 40
3. 线程数计算方式
最佳线程数目 = （（线程等待时间+线程CPU时间）/线程CPU时间 ）* CPU数目
比如平均每个线程CPU运行时间为0.5s，而线程等待时间（非CPU运行时间，比如IO）为1.5s，CPU核心数为8，那么根据上面这个公式估算得到：((0.5+1.5)/0.5)*8=32。
这个公式可以进一步转化为：
最佳线程数目 = （线程等待时间与线程CPU时间之比 + 1）* CPU数目
可以得出一个结论：线程等待时间所占比例越高，需要越多线程。线程CPU时间所占比例越高，需要越少线程。
一个系统最快的部分是CPU，所以决定一个系统吞吐量上限的是CPU。增强CPU处理能力，可以提高系统吞吐量上限。但根据短板效应，真实的系统吞吐量并不能单纯根据CPU来计算。那要提高系统吞吐量，就需要从“系统短板”（比如网络延迟、IO）着手：
- 尽量提高短板操作的并行化比率，比如多线程下载技术
- 增强短板能力，比如用NIO替代IO
太少的线程数会使得程序整体性能降低，而过多的线程也会消耗内存等其他资源，所以如果想要更准确的话，可以进行压测，监控 JVM 的线程情况以及 CPU 的负载情况，根据实际情况衡量应该创建的线程数，合理并充分利用资源。
4. dark magic估算法
参考下面的代码，这里就拷贝了
https://github.com/sunshanpeng/dark_magic
参考资料
https://mp.weixin.qq.com/s/-9jFy3Z0JsKihGoG1nr2rw
http://ifeve.com/how-to-calculate-threadpool-size/
