java线程池中队列与池大小的关系
最近需要进行scopus论文网站的数据爬取，于是尝试运用多线程的知识提高爬取效率。 本文章是关于JAVA线程中对于线程池（ThreadPoolExecutor)中队列，池大小，核心线程的关系一些知识，不涉及到爬虫内容。
线程池的参数意义
Java线程池的构造函数如下：
public ThreadPoolExecutor（
int corePoolSize,
int maximumPoolSize,
long keepAliveTime,
TimeUnit unit,
BlockingQueue<Runnable> workQueue,
ThreadFactory threadFactory,
RejectedExecutionHandler handler) {
//...
}
线程池有这么几个重要的参数：
- corePoolSize=> 线程池里的核心线程数量
- maximumPoolSize=> 线程池里允许有的最大线程数量
- keepAliveTime=> 空闲线程存活时间
- unit=> keepAliveTime的时间单位,比如分钟,小时等
- workQueue=> 缓冲队列
- threadFactory=> 线程工厂用来创建新的线程放入线程池
- handler=> 线程池拒绝任务的处理策略,比如抛出异常等策略
基本概念
- 核心线程(corePoolSize)：简单来讲就是线程池中能否允许同时并发运行的线程的数量.
- 线程池大小(maximumPoolSize)：线程池中最多能够容纳的线程的数量.
- 队列(workQueue)：对提交过来的任务的处理模式.
相互关系
对于线程池与队列的交互有个原则：
如果队列发过来的任务，发现线程池中正在运行的线程的数量workerCountOf(c)小于核心线程corePoolSize，则立即创建新的线程，无需进入队列等待。如果正在运行的线程等于或者大于核心线程，则必须参考提交的任务能否加入队列中去:
a.提交的任务能加入队列中
1）如果提交的任务能加入队列，考虑下队列的值是否有设定，如果没有设定，那么也就是不能创建新的线程，只能在队列中等待，因为理论上队列里面可以容纳无穷大的任务等待。换句话说，此时的线程池中的核心线程数就是池中能否允许的最大线程数。那么池的最大线程数就没有任何意义了。
2）如果提交的任务能加入队列，队列的值是有限定的，那么首先任务进入队列中去等待，一旦队列中满了，则新增加的任务就进入线程池中创建新的线程。一旦线程池中的最大线程数超过了，那么就会拒绝后面的任务。
b.如果提交的任务不能加入队列
1）提交的任务不能加入队列，此时就会创建新的线程加入线程池中，一旦超过线程池中最大的数量，则任务被拒绝。
队列workQueue的常用策略
SynchronousQueue
直接提交，也就是上面讲到的所有任务不进入队列去等待。此时小于核心线程就增加，多于或等于核心线程数时，还是增加线程，最大为线程池中的最大允许。
—超出就拒绝。它将任务直接提交给线程而不保持它们。在此，如果不存在可用于立即运行任务的线程，则试图把任务加入队列将失败，因此会构造一个新的线程。此策略可以避免在处理可能具有内部依赖性的请求集时出现锁。直接提交通常要求无界 maximumPoolSizes 以避免拒绝新提交的任务。当命令以超过队列所能处理的平均数连续到达时，此策略允许无界线程具有增长的可能性。
LinkedBlockingQueue
无界队列 此时超过核心线程后的任务全部加入队列等待，系统最多只能运行核心线程数量的线程。这种方法相当于控制了并发的线程数量。
—将导致在所有 corePoolSize 线程都忙时新任务在队列中等待。这样，创建的线程就不会超过 corePoolSize。（因此，maximumPoolSize的值也就无效了。）当每个任务完全独立于其他任务，即任务执行互不影响时，适合于使用无界队列；例如，在 Web页服务器中。这种排队可用于处理瞬态突发请求，当命令以超过队列所能处理的平均数连续到达时，此策略允许无界线程具有增长的可能性。
ArrayBlockingQueue
有界队列 此时超过核心线程后的任务先加入队列等待，超出队列范围后的任务就生成线程，但创建的线程最多不超过线程池的最大允许值。
—有界队列（如 ArrayBlockingQueue）有助于防止资源耗尽，但是可能较难调整和控制。队列大小和最大池大小可能需要相互折衷：使用大型队列和小型池可以最大限度地降低 CPU 使用率、操作系统资源和上下文切换开销，但是可能导致人工降低吞吐量。如果任务频繁阻塞（例如，如果它们是 I/O边界），则系统可能为超过您许可的更多线程安排时间。使用小型队列通常要求较大的池大小，CPU使用率较高，但是可能遇到不可接受的调度开销，这样也会降低吞吐量。
DelayedWorkQueue
该队列是定制的优先级队列，只能用来存储RunnableScheduledFutures任务。堆是实现优先级队列的最佳选择，而该队列正好是基于堆数据结构的实现。是无界队列, 队列的长度可以扩容到 Integer.MAX_VALUE。
四种包装好的线程池
阿里手册的描述：线程池不允许使用Executors创建，而是通过ThreadPoolExecutor的方式创建，这样的处理方式能让编写代码的工程师更加明确线程池的运行规则，规避资源耗尽的风险。 附加说明：Executors返回线程池对象的弊端如下：
1.FixedThreadPool和SingleThreadPool允许队列的长度Integer.MAX_VALUE，可能会堆积大量的请求，从而导致OOM(内存溢出)。
2.CachedThreadPool和ScheduledThreadPool允许创建的线程数量为Integer.MAX_VALUE，可能会创建大量线程，从而导致OOM(内存溢出)。
固定数量的线程池FixedThreadPool
public static ExecutorService newFixedThreadPool(int nThreads) {
return new ThreadPoolExecutor(nThreads, nThreads,
0L, TimeUnit.MILLISECONDS,
new LinkedBlockingQueue<Runnable>());
这个线程池的核心线程与最大线程为一个值，不等待，超出核心线程一定时间后的线程就被回收掉了。最多同时运行nThreads数量的线程。
单线程池SingleThreadPool
public static ExecutorService newSingleThreadExecutor() {
return new FinalizableDelegatedExecutorService
(new ThreadPoolExecutor(1, 1,
0L, TimeUnit.MILLISECONDS,
new LinkedBlockingQueue<Runnable>()));
}
可以理解为就是核心线程为1的固定线程池
可缓存线程池CachedThreadPool
public static ExecutorService newCachedThreadPool() {
return new ThreadPoolExecutor(0, Integer.MAX_VALUE,
60L, TimeUnit.SECONDS,
new SynchronousQueue<Runnable>()); 核心线程池为0，线程池的最大是无限，等待时间为60秒，队列为直接提交。
也就是说每次一个任务都直接生成一个线程，线程的无上限，但是一旦线程池中出现了空闲超过60秒的线程则被回收掉。
定时线程池ScheduledThreadPool
public ScheduledThreadPoolExecutor(int corePoolSize) {
super(corePoolSize, Integer.MAX_VALUE,
0, NANOSECONDS,
new DelayedWorkQueue());
}
用于需要多个后台线程执行周期任务，同时需要限制线程数量的场景，ScheduledThreadPool的 mamximumPoolSize 是接近无限大的；而DelayedWorkQueue 是无界队列，也是接近无限大的，更加容易会导致OOM（内存溢出）
为什么 FixedThreadPool 和 SingleThreadPool 的 corePoolSize和mamximumPoolSize 要设计成一样的?
因为线程池FixedThreadPool和SingleThreadPool 都用到的阻塞队列 LinkedBlockingQueue，LinkedBlockingQueue的源码注释中可以看到, 如果不指定队列的容量, 那么默认就是接近无限大的。 所以不管线程池FixedThreadPool和SingleThreadPool 的mamximumPoolSize 等于多少, 都是不生效的!
为什么CachedThreadPool的mamximumPoolSize要设计成接近无限大的?
因为线程池CachedThreadPool的workQueue参数为SynchronousQueue。SynchronousQueue的源码注释中说明到：同步队列没有任何内部容量，甚至容量都不是1。所以如果mamximumPoolSize不设计得很大, 就很容易导致溢出。但是设置得太大，堆积的线程任务太多，又会导致OOM（内存溢出）。
更加详细的内容可参考文章：https://blog.csdn.net/sd0902/article/details/8395677
