©2020-2024 ioDraw All rights reserved,
Privacy Policy
线程池的作用
主要作用：避免创建过多的线程时引发的内存溢出问题。因为创建线程还是比较耗内存的，通常来说创建一个线程会默认分配1M的内存。
线程池的主要优势：
* 降低资源消耗。通过重复利用已创建的线程降低线程创建和销毁造成的消耗。
* 提高响应速度。当任务到达时，任务可以不需要等到线程创建就能立即执行。
* 提高线程的可管理性。线程是稀缺资源，如果无限制的创建，不仅会消耗系统资源，还会降低系统的稳定性，使用线程池可以进行统一的分配，调优和监控。
线程池的使用
线程池的创建方式
线程池的真正实现类是ThreadPollExecutor
，它的构造方法有以下4种重载方式。一般来说创建线程池方法是参数有7个，其中有5个是必需的，后面会对每个参数进行详细的介绍。
public ThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long
keepAliveTime, TimeUnit unit, BlockingQueue<Runnable> workQueue) {
this(corePoolSize, maximumPoolSize, keepAliveTime, unit, workQueue,
Executors.defaultThreadFactory(), defaultHandler); } public
ThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime,
TimeUnit unit, BlockingQueue<Runnable> workQueue, ThreadFactory threadFactory)
{ this(corePoolSize, maximumPoolSize, keepAliveTime, unit, workQueue,
threadFactory, defaultHandler); } public ThreadPoolExecutor(int corePoolSize,
int maximumPoolSize, long keepAliveTime, TimeUnit unit, BlockingQueue<Runnable>
workQueue, RejectedExecutionHandler handler) { this(corePoolSize,
maximumPoolSize, keepAliveTime, unit, workQueue,
Executors.defaultThreadFactory(), handler); } public ThreadPoolExecutor(int
corePoolSize, int maximumPoolSize, long keepAliveTime, TimeUnit unit,
BlockingQueue<Runnable> workQueue, ThreadFactory threadFactory,
RejectedExecutionHandler handler) { if (corePoolSize < 0 || maximumPoolSize <=
0 || maximumPoolSize < corePoolSize || keepAliveTime < 0) throw new
IllegalArgumentException(); if (workQueue == null || threadFactory == null ||
handler == null) throw new NullPointerException(); this.corePoolSize =
corePoolSize; this.maximumPoolSize = maximumPoolSize; this.workQueue =
workQueue; this.keepAliveTime = unit.toNanos(keepAliveTime); this.threadFactory
= threadFactory; this.handler = handler; }
参数介绍
创建线程池需要以下几个参数，其中有5个是必需的：
* corePoolSize（必需）：核心线程数。默认情况下，核心线程会一直存活，但是当将 allowCoreThreadTimeout 设置为 true
时，核心线程也会超时回收。
* maximumPoolSize（必需）：线程池所能容纳的最大线程数。当活跃线程数达到该数值后，后续的新任务将会阻塞。
* keepAliveTime（必需）：线程闲置超时时长。如果超过该时长，非核心线程就会被回收。如果将 allowCoreThreadTimeout
设置为 true 时，核心线程也会超时回收。
* unit（必需）：指定 keepAliveTime 参数的时间单位
。常用的有：TimeUnit.MILLISECONDS（毫秒）、TimeUnit.SECONDS（秒）、TimeUnit.MINUTES（分）。
* workQueue（必需）：任务队列。通过线程池的 execute() 方法提交的 Runnable 对象将存储在该参数中。其采用阻塞队列实现。
* threadFactory（可选）：线程工厂。用于指定为线程池创建新线程的方式。
* handler（可选）：拒绝策略。当达到最大线程数时需要执行的饱和策略。
非核心线程介绍
什么是“非核心线程”呢？是不是先创建的线程就是核心线程，后创建的就是非核心线程呢？
其实核心线程跟创建的先后没有关系，而是跟工作线程的个数有关，如果当前工作线程的个数大于核心线程数，那么所有的线程都可能是“非核心线程”，都有被回收的可能。
一个线程执行完了一个任务后，会去阻塞队列里面取新的任务，在取到任务之前它就是一个闲置的线程。
取任务的方法有两种，一种是通过 take() 方法一直阻塞直到取出任务，另一种是通过 poll(keepAliveTime，timeUnit)
方法在一定时间内取出任务或者超时，如果超时这个线程就会被回收，请注意核心线程一般不会被回收。
那么怎么保证核心线程不会被回收呢？还是跟工作线程的个数有关，每一个线程在取任务的时候，线程池会比较当前的工作线程个数与核心线程数：
*
如果工作线程数小于当前的核心线程数，则使用第一种方法取任务，也就是没有超时回收，这时所有的工作线程都是“核心线程”，他们不会被回收；
*
如果大于核心线程数，则使用第二种方法取任务，一旦超时就回收，所以并没有绝对的核心线程，只要这个线程没有在存活时间内取到任务去执行就会被回收。
所以每个线程想要保住自己“核心线程”的身份，必须充分努力，尽可能快的获取到任务去执行，这样才能逃避被回收的命运。
核心线程一般不会被回收，但是也不是绝对的，如果我们设置了允许核心线程超时被回收的话，那么就没有核心线程这种说法了，所有的线程都会通过
poll(keepAliveTime, timeUnit)
来获取任务，一旦超时获取不到任务，就会被回收，一般很少会这样来使用，除非该线程池需要处理的任务非常少，并且频率也不高，不需要将核心线程一直维持着。
非核心线程存活时间
当工作线程数达到 corePoolSize 时，线程池会将新接收到的任务存放在阻塞队列中，而阻塞队列又两种情况：一种是有界的队列，一种是无界的队列。
如果是无界队列，那么当核心线程都在忙的时候，所有新提交的任务都会被存放在该无界队列中，这时最大线程数将变得没有意义，因为阻塞队列不会存在被装满的情况。
如果是有界队列，那么当阻塞队列中装满了等待执行的任务，这时再有新任务提交时，线程池就需要创建新的“临时”线程来处理，相当于增派人手来处理任务。
但是创建的“临时”线程是有存活时间的，不可能让他们一直都存活着，当阻塞队列中的任务被执行完毕，并且又没有那么多新任务被提交时，“临时”线程就需要被回收销毁，在被回收销毁之前等待的这段时间，就是非核心线程的存活时间，也就是
keepAliveTime 属性。
任务队列(workQueue)
任务队列是基于阻塞队列实现的，即采用生产者消费者模式，在 Java 中需要实现 BlockingQueue 接口。但 Java 已经为我们提供了 7
种阻塞队列的实现：
* ArrayBlockingQueue：一个由数组结构组成的有界阻塞队列（数组结构可配合指针实现一个环形队列）。
* LinkedBlockingQueue： 一个由链表结构组成的有界阻塞队列，在未指明容量时，容量默认为 Integer.MAX_VALUE。
* PriorityBlockingQueue： 一个支持优先级排序的无界阻塞队列，对元素没有要求，可以实现 Comparable 接口也可以提供
Comparator 来对队列中的元素进行比较。跟时间没有任何关系，仅仅是按照优先级取任务。
* DelayQueue：类似于PriorityBlockingQueue，是二叉堆实现的无界优先级阻塞队列。要求元素都实现 Delayed
接口，通过执行时延从队列中提取任务，时间没到任务取不出来。
* SynchronousQueue： 一个不存储元素的阻塞队列，消费者线程调用 take()
方法的时候就会发生阻塞，直到有一个生产者线程生产了一个元素，消费者线程就可以拿到这个元素并返回；生产者线程调用 put()
方法的时候也会发生阻塞，直到有一个消费者线程消费了一个元素，生产者才会返回。
* LinkedBlockingDeque： 使用双向队列实现的有界双端阻塞队列。双端意味着可以像普通队列一样 FIFO（先进先出），也可以像栈一样
FILO（先进后出）。
* LinkedTransferQueue： 它是ConcurrentLinkedQueue、LinkedBlockingQueue 和
SynchronousQueue 的结合体，但是把它用在 ThreadPoolExecutor 中，和 LinkedBlockingQueue
行为一致，但是是无界的阻塞队列。
注意有界队列和无界队列的区别：如果使用有界队列，当队列饱和时并超过最大线程数时就会执行拒绝策略；而如果使用无界队列，因为任务队列永远都可以添加任务，所以设置
maximumPoolSize 没有任何意义。
线程工厂(threadFactory)
既然是线程池，那自然少不了线程，线程该如何来创建呢？这个任务就交给了线程工厂 ThreadFactory 来完成。线程工厂指定创建线程的方式，需要实现
ThreadFactory 接口，并实现 newThread(Runnable r) 方法。该参数可以不用指定，Executors
框架已经为我们实现了一个默认的线程工厂.
拒绝策略(handler)
虽然我们有了阻塞队列来对任务进行缓存，这从一定程度上为线程池的执行提供了缓冲期，但是如果是有界的阻塞队列，那就存在队列满的情况，也存在工作线程的数据已经达到最大线程数的时候。如果这时候再有新的任务提交时，显然线程池已经心有余而力不足了，因为既没有空余的队列空间来存放该任务，也无法创建新的线程来执行该任务了，所以这时我们就需要有一种拒绝策略，即
handler。
拒绝策略是一个 RejectedExecutionHandler
类型的变量，用户可以自行指定拒绝的策略，如果不指定的话，线程池将使用默认的拒绝策略：抛出异常。
在线程池中还为我们提供了很多其他可以选择的拒绝策略：
* AbortPolicy（默认）：丢弃任务并抛出 RejectedExecutionException 异常。
* CallerRunsPolicy：由调用线程处理该任务。
* DiscardPolicy：丢弃任务，但是不抛出异常。可以配合这种模式进行自定义的处理方式。
* DiscardOldestPolicy：丢弃队列最早的未处理任务，然后重新尝试执行任务。
线程池的原理
为了加深理解对线程池的工作原理，可以具体看一下线程池的工作流程图：
重中之重
任务数 <= 核心线程数时，线程池中工作线程 = 任务数
核心线程数 + 队列容量 < 任务数 <= 最大线程数 + 队列容量时，工作线程数 = 任务数 - 队列容量
常见的线程池
Executors已经为我们封装好了 4 种常见的功能线程池，如下：
* 定长线程池（FixedThreadPool）：只有核心线程，线程数量固定，执行完立即回收，任务队列为链表结构的有界队列。适用于控制线程最大并发数。
* 定时线程池（ScheduledThreadPool ）：核心线程数量固定，非核心线程数量无限，执行完闲置 10ms
后回收，任务队列为延时阻塞队列。适用于执行定时或周期性的任务。
* 可缓存线程池（CachedThreadPool）：无核心线程，非核心线程数量无限，执行完闲置 60s
后回收，任务队列为不存储元素的阻塞队列。适用于执行大量、耗时少的任务。
* 单线程化线程池（SingleThreadExecutor）：只有 1
个核心线程，无非核心线程，执行完立即回收，任务队列为链表结构的有界队列。不适合并发以及可能引起 IO 阻塞性及影响 UI
线程响应的操作，如数据库操作、文件操作等。
Executors 的 4 个功能线程池虽然方便，但现在已经不建议使用了，而是建议直接通过使用 ThreadPoolExecutor
的方式，这样的处理方式让写的同学更加明确线程池的运行规则，规避资源耗尽的风险。
其实 Executors 的 4 个功能线程有如下弊端：
* FixedThreadPool 和 SingleThreadExecutor：主要问题是堆积的请求处理队列均采用
LinkedBlockingQueue，可能会耗费非常大的内存，甚至 OOM。
* CachedThreadPool 和 ScheduledThreadPool：主要问题是线程数最大数是
Integer.MAX_VALUE，可能会创建数量非常多的线程，甚至 OOM。