-
ThreadPoolExecutor线程池顶级父类Executor
interface Executor extends interface ExecutorService implements abstract AbstractExecutorService extends ThreadPoolExecutor -
ThreadPoolExecutor参数
| 参数名 | 解释 |
|---|---|
| corePoolSize | 核心线程数量 |
| maximumPoolSize | 线程池维护线程的最大数量 |
| keepAliveTime | 线程池维护线程所允许的空闲时间 |
| TimeUnit | 时间单位 |
| workQueue | 线程池所使用的缓冲队列 |
| handler | 线程池对拒绝任务的处理策略 |
| ThreadFactory | 线程工厂 自定义线程管理 |
-
线程池运行基本原理
新来线程 1 线程池线程数量没有达到核心线程数量，则新建线程，直至达到核心线程数量 2 线程池线程数量达到核心线程数量，有空闲线程，则直接执行 3 线程池线程数量达到核心线程数量，没有空闲线程，则放入队列 4 线程池线程数量达到核心线程数量，没有空闲线程，队列已满，则线程数量增加至Max线程数量 5 线程池线程数量达到核心线程数量，没有空闲线程，队列已满，线程数量已增加至Max线程数量，则调用丢弃策略 1 丢弃任务有4种方式 实现RejectedExecutionHandler接口（是ThreadPoolExecutor内部类） 提供了四种方式来处理任务拒绝策略 1、直接丢弃（DiscardPolicy） 2、丢弃队列中最老的任务(DiscardOldestPolicy)。 3、抛异常(AbortPolicy) 4、将任务分给调用线程来执行(CallerRunsPolicy)。 -
ThreadPoolExecutor#execute方法
1 基本判断步骤 //ThreadPoolExecutor#execute public void execute(Runnable command) { if (command == null) throw new NullPointerException(); int c = ctl.get(); //由它可以获取到当前有效的线程数和线程池的状态 /*1.获取当前正在运行线程数是否小于核心线程池，是则新创建一个线程执行任务，否则将任务放到任务队列中*/ if (workerCountOf(c) < corePoolSize){ if (addWorker(command, tre)) //在addWorker中创建工作线程执行任务 return ; c = ctl.get(); } /*2.当前核心线程池中全部线程都在运行workerCountOf(c) >= corePoolSize，所以此时将线程放到任务队列中*/ if (isRunning(c) && workQueue.offer(command)) { //线程池是否处于运行状态，且是否任务插入任务队列成功 int recheck = ctl.get(); if (!isRunning(recheck) && remove(command)) //线程池是否处于运行状态，如果不是则使刚刚的任务出队 reject(command); //抛出RejectedExceptionException异常 else if (workerCountOf(recheck) == 0) addWorker(null, false); } /*3.插入队列不成功，且当前线程数数量小于最大线程池数量，此时则创建新线程执行任务，创建失败抛出异常*/ else if (!addWorker(command, false)){ reject(command); //抛出RejectedExceptionException异常 } } 2 四个步骤 1 线程池线程数量没有达到核心线程数量，则新建线程 2 线程池线程数量达到核心线程数量，没有空闲线程，则放入队列 3 线程池线程数量达到核心线程数量，没有空闲线程，队列已满，则线程数量增加至Max线程数量 4 线程池线程数量达到核心线程数量，没有空闲线程，队列已满，线程数量已增加至Max线程数量，则调用丢弃策略 创建失败抛出异常 -
BlockingQueue队列
1 常用的队列主要有以下两种：（当然通过不同的实现方式，还可以延伸出很多不同类型的队列，DelayQueue就是其中的一种） 先进先出（FIFO）：先插入的队列的元素也最先出队列，类似于排队的功能。从某种程度上来说这种队列也体现了一种公平性。 后进先出（LIFO）：后插入队列的元素最先出队列，这种队列优先处理最近发生的事件。 2 BlockingQueue的核心方法： 1.多线程环境下为什么需要BlockingQueue的原因？ 作为BlockingQueue的使用者，我们再也不需要关心什么时候需要阻塞线程，什么时候需要唤醒线程， 因为这一切BlockingQueue都给你一手包办了。既然BlockingQueue如此神通广大，让我们一起来见识下它的常用方法： 2.放入数据 （1）offer(anObject):表示如果可能的话,将anObject加到BlockingQueue里,即如果BlockingQueue可以容纳,则返回true,否则返回false.（本方法不阻塞当前执行方法 的线程）； （2）offer(E o, long timeout, TimeUnit unit)：可以设定等待的时间，如果在指定的时间内，还不能往队列中加入BlockingQueue，则返回失败。 （3）put(anObject):把anObject加到BlockingQueue里,如果BlockQueue没有空间,则调用此方法的线程被阻断直到BlockingQueue里面有空间再继续. 3. 获取数据 （1）poll(time):取走BlockingQueue里排在首位的对象,若不能立即取出,则可以等time参数规定的时间,取不到时返回null; （2）poll(long timeout, TimeUnit unit)：从BlockingQueue取出一个队首的对象，如果在指定时间内，队列一旦有数据可取，则立即返回队列中的数据。否则知道时间 超时还没有数据可取，返回失败。 （3）take():取走BlockingQueue里排在首位的对象,若BlockingQueue为空,阻断进入等待状态直到BlockingQueue有新的数据被加入; （4）drainTo():一次性从BlockingQueue获取所有可用的数据对象（还可以指定获取数据的个数），通过该方法，可以提升获取数据效率；不需要多次分批加锁或释放锁。 4.常用队列 1. ArrayBlockingQueue 基于数组的阻塞队列实现，在ArrayBlockingQueue内部，维护了一个定长数组，以便缓存队列中的数据对象，这是一个常用的阻塞队列，除了一个定长数组外， ArrayBlockingQueue内部还保存着两个整形变量，分别标识着队列的头部和尾部在数组中的位置。 ArrayBlockingQueue在生产者放入数据和消费者获取数据，都是共用同一个锁对象，由此也意味着两者无法真正并行运行，这点尤其不同于LinkedBlockingQueue； 按照实现原理来分析，ArrayBlockingQueue完全可以采用分离锁，从而实现生产者和消费者操作的完全并行运行。Doug Lea之所以没这样去做，也许是因为ArrayBlockingQueue的数据写入和获取操作已经足够轻巧， 以至于引入独立的锁机制，除了给代码带来额外的复杂性外，其在性能上完全占不到任何便宜。 ArrayBlockingQueue和LinkedBlockingQueue间还有一个明显的不同之处在于， 前者在插入或删除元素时不会产生或销毁任何额外的对象实例，而后者则会生成一个额外的Node对象。这在长时间内需要高效并发地处理大批量数据的系统中， 其对于GC的影响还是存在一定的区别。而在创建ArrayBlockingQueue时，我们还可以控制对象的内部锁是否采用公平锁，默认采用非公平锁。 2.LinkedBlockingQueue 基于链表的阻塞队列，同ArrayListBlockingQueue类似，其内部也维持着一个数据缓冲队列（该队列由一个链表构成），当生产者往队列中放入一个数据时， 队列会从生产者手中获取数据，并缓存在队列内部，而生产者立即返回；只有当队列缓冲区达到最大值缓存容量时（LinkedBlockingQueue可以通过构造函数指定该值），才会阻塞生产者队列， 直到消费者从队列中消费掉一份数据，生产者线程会被唤醒，反之对于消费者这端的处理也基于同样的原理。而LinkedBlockingQueue之所以能够高效的处理并发数据， 还因为其对于生产者端和消费者端分别采用了独立的锁来控制数据同步，这也意味着在高并发的情况下生产者和消费者可以并行地操作队列中的数据，以此来提高整个队列的并发性能。 作为开发者，我们需要注意的是，如果构造一个LinkedBlockingQueue对象，而没有指定其容量大小，LinkedBlockingQueue会默认一个类似无限大小的容量（Integer.MAX_VALUE）， 这样的话，如果生产者的速度一旦大于消费者的速度，也许还没有等到队列满阻塞产生，系统内存就有可能已被消耗殆尽了。 ArrayBlockingQueue和LinkedBlockingQueue是两个最普通也是最常用的阻塞队列，一般情况下，在处理多线程间的生产者消费者问题，使用这两个类足以。 3. DelayQueue DelayQueue中的元素只有当其指定的延迟时间到了，才能够从队列中获取到该元素。DelayQueue是一个没有大小限制的队列，因此往队列中插入数据的操作（生产者）永远不会被阻塞， 而只有获取数据的操作（消费者）才会被阻塞。 使用场景： DelayQueue使用场景较少，但都相当巧妙，常见的例子比如使用一个DelayQueue来管理一个超时未响应的连接队列。 4. PriorityBlockingQueue 基于优先级的阻塞队列（优先级的判断通过构造函数传入的Compator对象来决定），但需要注意的是PriorityBlockingQueue并不会阻塞数据生产者，而只会在没有可消费的数据时， 阻塞数据的消费者。因此使用的时候要特别注意，生产者生产数据的速度绝对不能快于消费者消费数据的速度，否则时间一长，会最终耗尽所有的可用堆内存空间。在实现PriorityBlockingQueue时 ，内部控制线程同步的锁采用的是公平锁。 5. SynchronousQueue 一种无缓冲的等待队列，类似于无中介的直接交易，有点像原始社会中的生产者和消费者，生产者拿着产品去集市销售给产品的最终消费者，而消费者必须亲自去集市找到所要商品的直接生产者， 如果一方没有找到合适的目标，那么对不起，大家都在集市等待。相对于有缓冲的BlockingQueue来说，少了一个中间经销商的环节（缓冲区），如果有经销商，生产者直接把产品批发给经销商， 而无需在意经销商最终会将这些产品卖给那些消费者，由于经销商可以库存一部分商品，因此相对于直接交易模式，总体来说采用中间经销商的模式会吞吐量高一些（可以批量买卖）；但另一方面， 又因为经销商的引入，使得产品从生产者到消费者中间增加了额外的交易环节，单个产品的及时响应性能可能会降低。 声明一个SynchronousQueue有两种不同的方式，它们之间有着不太一样的行为。公平模式和非公平模式的区别: 如果采用公平模式：SynchronousQueue会采用公平锁，并配合一个FIFO队列来阻塞多余的生产者和消费者，从而体系整体的公平策略； 但如果是非公平模式（SynchronousQueue默认）：SynchronousQueue采用非公平锁，同时配合一个LIFO队列来管理多余的生产者和消费者，而后一种模式，如果生产者和消费者的处理速度有差距， 则很容易出现饥渴的情况，即可能有某些生产者或者是消费者的数据永远都得不到处理。
