常见线程池特点的总结
首先我们来看第一种常见的线程池 FixedTheadPool，它是线程数量固定的的线程池 。我们通过下图来理解它的特点。
![image.png]()
这种线程的特点是这样的，假设我们给它执行 1000 个任务，但是的线程已经是固定的就是 10，所以始终是0 ~ 9 这 10 个线程来反复的执行我们的任务，不会超出我们设置的固定范围。
第二种，常见的线程池是 CachedThreadPool，它是可缓存的线程池，并且还会回收。通过下图理解它的工作情况。
![image.png]()
它会把任务交给我们的线程，而且线程不够用的话，就会创建线程。如果线程过多，就会把这些线程给回收回来。
第三种非常常见的线程池是 ScheduleThreadPool，前面我们介绍过，它是支持定期和周期执行任务的，我们可以设置它每隔多长时间去执行任务。这个线程池用在我们的定时任务或者是用它来替代我们的定时器都是可以的。
第四种常见的线程池是 SingleThreadExecutor，这种线程池比较简单，它内部只有一个线程，会用唯一的工作线程来执行任务。它的原理和固定线程数量的线程池的原理是一样的，只不过这个时候它的线程数量就直接被设置为 1，也就是只有一个线程。
线程池的构造函数的参数
接下我们对 FixedTheadPool、ScheduleThreadPool、CachedThreadPool 、SingleThreadExecutor 这四种常见线程池的参数做一下总结。
| |
FixedTheadPool |
CachedThreadPool |
ScheduleThreadPool |
SingleThreadExecutor |
| corePoolSize |
constructor-arg |
0 |
constructor-arg |
1 |
| maxpoolSize |
same as corePoolSize |
Integer.MAX_VALUUE |
Integer.MAX_VALUUE |
1 |
| keepAliveTime |
0 seconds |
60 seconds |
0 seconds |
0 seconds |
FixedTheadPool 线程池的线程核心数量是我们传给它，比如我们传入 10，那么就有 10 个线程，而最大的线程数和核心线程数保持一致，所以也是 10。由于它们两个保持一致，就不可能出现线程被回收的情况，所以在 keepAliveTime 自然就是 0，所以 keepAliveTime 参数在这个时候是没有意义的。 我们再来看和 FixedTheadPool 非常像的线程池是 SingleThreadExecutor，SingleThreadExecutor 线程池的核心线程数和最大线程数都是 1，而 keepAliveTime 依然是 0。
接下来我们在来看 CachedThreadPool 线程池，CachedThreadPool 这种线程池的核心是 0，也就是它不需要存储很多的线程常驻，当需要线程的时候，临时创建即可，所以它的最大线程数就是 Integer.MAX_VALUE，也就是它可以创建几乎无限多的线程来帮助执行任务，而 60 秒之后，如果发现线程没事任务可执行了，又会把它回收回来。
最后来看一下 ScheduleThreadPool 线程池，它的特点是线程核心数量是我们传入的，所以它也有一些的核心的线程始终存活，并且它也不设置上限，它的线程数量也可以任意的增多。这个线程池它的回收时间是 0，所以这个线程池也拥有回收线程的能力。
线程池阻塞队列分析
为什么要把 FixedThreadPool 和 SingleThreadExecutor 的队列设置为 LinkedBlockingQueue 呢？这实际上都是有原因的，这个队列的选择恰恰是满足我们线程池功能的，比如 FixedThreadPool 线程池，它固定的有 10 个线程，由于线程数量已经不能再往上膨胀了，所以不得不用一个能够存储很多的，或者是无限多的队列来去存储我们的任务。新进来的任务的数量是没办法估计，所以只能在自身上来解决问题，就把这个阻塞队列的容量设置为无限，这就是选择 LinkedBlockingQueue 的原因。
CachedThreadPool 为什么要使用 SynchronousQueue 作为其队列呢？SynchronousQueue 它的特点是实际上它的内部是不存储的。那为什么还想用它呢？这是因为我们在这种线程池的情况下，根本就不需要它来存储。有任务过提交来了，直接将任务交给新的线程去执行了，新的线程的数量又是不受限制的，不需要一个队列来存储任务，有新的任务提交过来，直接让新的线程去执行新的任务任务，所以这个时候就选择了 SynchronousQueue 作为这种线程池的队列，它的效率会比较高一些，不需要在存储到队列中去中缓存。
ScheduleThreadPool 使用的是延迟队列，延迟队列具有的功能就是可以把队列里面的任务根据时间先后去做延迟，所以也是非常符合它的使用场景的。
workStealingPool
还有一种线程池是 JDK 1.8 加入的，这个线程池是 workStealingPool，这种线程池相对前面的而言使用得不是特别多，但是我们还是做一下介绍，大家可能对这种线程池不熟悉，它和之前的线程池都有很大不同。
第一个不同就是这里的任务不是普通的任务。通常而言，这个任务如果是可以产生子任务的话，那才适合于这种场景。什么叫做可以产生子任务的呢？比如树的遍历，二叉树的遍历，每一次去遍历到左子树的时候，它可能又会层层的往下。再比如处理矩阵的时候，也有可能会产生子任务，比如把一个矩阵分为四个小矩阵，四个小矩阵里面又可以分为四个小矩阵，层层的往下去分，这个就相当于是子任务。
第二个是如果我们用这个线程池，它是拥有一定的窃取能力的，这种线程池每一个线程之间是会合作的。刚才我们提到的子任务，这个子任务会被放到每一个线程自己独有的任务队列中去，而不是公共队列。比如有三个线程，第一个线程产生了很多子任务，这个子任务会放到它自己的队列中去，然后慢慢执行。而这个时候，假设后面两个线程发现自己没有任务可执行了，于是会帮助第一个线程去把第一个线程中的自己队列中的任务给取出来，这个时候第二个和第三个线程也可以帮助执行，这样一来相当于就是实现了并行执行的效果。但是也有注意点：
第一点，就是为了提高效率，我们这个任务最好是不要加锁的，因为这个任务可能会被不同的线程去执行，如果不加锁的话，就可以让多个线程去高效地执行，发挥出更好的效果。
第二点，就是不保证执行顺序。在我们之前的线程池中，比如将一些任务放到一个队列中去，有顺序将任务放到队列中去，同时就会按照顺序从队列中取出来。而在使用 workStealingPool 这种线程池情况下就不能保证其顺序性了，因为其他的线程会来到还有任务没执行完的线程中的队列中去窃取。所以它的执行顺序是不能保障的。
通常情况下，如果我们遇到的场景是递归的，每一次会产生子任务的话，我们可以采用这样的线程池。对于这个线程池，由于我们实际的开发中，满足他这种条件的任务是比较少的，所以它的适用场景是有限的。所以我们先重点掌握前面那几种线程池，在实际开发中，前面那几种线程池用得更多，当然自己定义的线程池会更好。
