forkjoinpool_forkjoinpool源码分析_forkjoinpool 例子(2)

程数量为4时，性能最优。因为此任务的类型是计算密集型的，只有4个CPU，因此线程数量为4时，达到最优情况。

随着线程数量逐渐增加，性能下降，因为线程之间会互相争夺CPU资源，造成频繁切换线程执行上下文环境，而这些切换只会浪费CPU资源。

性能下降的速度并不明显，这也是因为任务类型是计算密集型的缘故，如果性能瓶颈不是CPU提供的计算资源，而是外部的资源，如，文件操作等，那么增加线程数量带来的性能下降也许会更加明显。

下面，从Client的角度考虑一下问题，并发Client的数量对于Server的响应时间会有什么影响呢？还是同样地环境，当并发Client数量逐渐增加时，响应时间会如下发生变化：

并发Client线程数平均响应时间(秒)基线百分比

因为任务类型是计算密集型的，当并发Client数量时1，2，4时，平均响应时间都是最优的，然而当出现多余4个Client时，性能会随着Client的增加发生显著地下降。

当Client数量增加时，你也许会想通过增加服务端线程池的线程数量来提高性能，可是在CPU密集型任务的情况下，这么做只会降低性能。因为系统的瓶颈就是CPU资源，冒然增加线程池的线程数量只会让对于这种资源的竞争更加激烈。

所以，在面对性能方面的问题时。第一步永远是了解系统的瓶颈在哪里，这样才能够有的放矢。如果冒然进行所谓的“调优”，让对瓶颈资源的竞争更加激烈，那么带来的只会是性能的进一步下降。相反，如果让对瓶颈资源的竞争变的缓和，那么性能通常则会提高。

在上面的场景中，如果从ThreadPoolExecutor的角度进行考虑，那么在任务队列中一直会有任务处于挂起(Pending)的状态(因为Client的每个请求对应的就是一个任务)，而所有的可用线程都在工作，CPU正在满负荷运转。这个时候添加线程池的线程数量，让这些添加的线程领取一些挂起的任务，会发生什么事情呢？这时带来的只会是线程之间对于CPU资源的争夺更加激烈，降低了性能。

设置最小线程数

设置了最大线程数之后，还需要设置最小线程数。对于绝大部分场景，将它设置的和最大线程数相等就可以了。

将最小线程数设置的小于最大线程数的初衷是为了节省资源，因为每多创建一个线程都会耗费一定量的资源，尤其是线程栈所需要的资源。但是在一个系统中，针对硬件资源以及任务特点选定了最大线程数之后，就表示这个系统总是会利用这些线程的，那么还不如在一开始就让线程池把需要的线程准备好。然而，把最小线程数设置的小于最大线程数所带来的影响也是非常小的，一般都不会察觉到有什么不同。

在批处理程序中，最小线程数是否等于最大线程数并不重要。因为最后线程总是需要被创建出来的，所以程序的运行时间应该几乎相同。对于服务器程序而言，影响也不大，但是一般而言，线程池中的线程在“热身”阶段就应该被创建出来，所以这也是为什么建议将最小线程数设置的等于最大线程数的原因。

在一些场景中，也需要要设置一个不同的最小线程数。比如当一个系统最大需要同时处理2000个任务，而平均任务数量只是20个情况下，就需要将最小线程数设置成20，而不是等于其最大线程数2000。此时如果还是将最小线程数设置的等于最大线程数的话，那么闲置线程(Idle Thread)占用的资源就比较可观了，尤其是当使用了ThreadLocal类型的变量时。

线程池任务数量(Thread Pool Task Sizes)

线程池有一个列表或者队列的数据结构来存放需要被执行的任务。显然，在某些情况下，任务数量的增长速度会大于其被执行的速度。如果这个任务代表的是一个来自Client的请求，那么也就意味着该Client会等待比较长的时间。显然这是不可接受的，尤其对于提供Web服务的服务器程序而言。

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-40527-2.html