线程池ThreadPoolExecutor

为何要使用线程池?

这里写图片描述

线程是一个操做系统概念。操做系统负责这个线程的建立、挂起、运行、阻塞和终结操做。而操做系统建立线程、切换线程状态、终结线程都要进行CPU调度——这是一个耗费时间和系统资源的事情。 
另外一方面,大多数实际场景中是这样的:处理某一次请求的时间是很是短暂的,可是请求数量是巨大的。这种技术背景下,若是咱们为每个请求都单首创建一个线程,那么物理机的全部资源基本上都被操做系统建立线程、切换线程状态、销毁线程这些操做所占用,用于业务请求处理的资源反而减小了。因此最理想的处理方式是,将处理请求的线程数量控制在一个范围,既保证后续的请求不会等待太长时间,又保证物理机将足够的资源用于请求处理自己。 
另外,一些操做系统是有最大线程数量限制的。当运行的线程数量逼近这个值的时候,操做系统会变得不稳定。这也是咱们要限制线程数量的缘由。前端

线程池的基本使用方式

JAVA语言为咱们提供了两种基础线程池的选择:ScheduledThreadPoolExecutor和ThreadPoolExecutor。它们都实现了ExecutorService接口(注意,ExecutorService接口自己和“线程池”并无直接关系,它的定义更接近“执行器”,而“使用线程管理的方式进行实现”只是其中的一种实现方式)。这篇文章中,咱们主要围绕ThreadPoolExecutor类进行讲解。java

ThreadPoolExecutor类的使用方式:

public class PoolThreadSimple {     
    public static void main(String[] args) throws Throwable { 
        /* * corePoolSize:核心大小,线程池初始化的时候,就会有这么大 
         * * maximumPoolSize:线程池最大线程数 
         * * keepAliveTime:若是当前线程池中线程数大于corePoolSize。
         * * 多余的线程,在等待keepAliveTime时间后若是尚未新的线程任务指派给它,它就会被回收 
         * * unit:等待时间keepAliveTime的单位 
         * * workQueue:等待队列。这个对象的设置是本文将重点介绍的内容 
         * */ 
        ThreadPoolExecutor poolExecutor = new ThreadPoolExecutor(5, 10, 1, TimeUnit.MINUTES, new SynchronousQueue()); 
        for(int index = 0 ; index < 10 ; index ++) { 
            poolExecutor.submit(new PoolThreadSimple.TestRunnable(index)); 
        } 
    } 
    private static class TestRunnable implements Runnable { /** * 这个就是测试用的线程 */ 
        /** * 日志 */ 
        private static Log LOGGER = LogFactory.getLog(TestRunnable.class); 
        /** * 记录任务的惟一编号,这样在日志中好作识别 */ private Integer index; 
        public TestRunnable(int index) { 
            this.index = index; 
        } 
        /** * @return the index */ 
        public Integer getIndex() { 
            return index; 
        } 
        /* * 线程中,就只作一件事情: * 等待60秒钟的事件,以便模拟业务操做过程 * */
        @Override 
        public void run() {  
            Thread currentThread = Thread.currentThread(); 
            TestRunnable.LOGGER.info("线程:" + currentThread.getId() + " 中的任务(" + this.getIndex() + ")开始执行==="); 
            synchronized (currentThread) { 
                try { 
                    currentThread.wait(60000); 
                } 
                catch (InterruptedException e) { 
                    TestRunnable.LOGGER.error(e.getMessage(), e); 
                } 
            } 
            TestRunnable.LOGGER.info("线程:" + currentThread.getId() + " 中的任务(" + this.getIndex() + ")执行完成"); 
        } 
    } 
}

下文中,将对线程池中的corePoolSize、maximumPoolSize、keepAliveTime、timeUnit、workQueue、threadFactory、handler参数和一些经常使用/不经常使用的设置项进行逐一讲解。后端

ThreadPoolExecutor逻辑结构和工做方式

在上面的代码中,咱们建立线程池的时候使用了ThreadPoolExecutor中最简单的一个构造函数:数组

public ThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime, TimeUnit unit, BlockingQueue workQueue)

构造函数中须要传入的参数包括corePoolSize、maximumPoolSize、keepAliveTime、timeUnit和workQueue。要明确理解这些参数(和后续将要介绍的参数)的含义,就首先要搞清楚ThreadPoolExecutor线程池的逻辑结构。 
[图片] 
必定要注意一个概念,即存在于线程池中容器的必定是Thread对象,而不是你要求运行的任务(因此叫线程池而不叫任务池也不叫对象池);你要求运行的任务将被线程池分配给某一个空闲的Thread运行。 
从上图中,咱们能够看到构成线程池的几个重要元素: 
● 等待队列:顾名思义,就是你调用线程池对象的submit()方法或者execute()方法,要求线程池运行的任务(这些任务必须实现Runnable接口或者Callable接口)。可是出于某些缘由线程池并无立刻运行这些任务,而是送入一个队列等待执行。缓存

● 核心线程:线程池主要用于执行任务的是“核心线程”,“核心线程”的数量是你建立线程时所设置的corePoolSize参数决定的。若是不进行特别的设定,线程池中始终会保持corePoolSize数量的线程数(不包括建立阶段)。安全

● 非核心线程:一旦任务数量过多(由等待队列的特性决定),线程池将建立“非核心线程”临时帮助运行任务。你设置的大于corePoolSize参数小于maximumPoolSize参数的部分,就是线程池能够临时建立的“非核心线程”的最大数量。这种状况下若是某个线程没有运行任何任务,在等待keepAliveTime时间后,这个线程将会被销毁,直到线程池的线程数量从新达到corePoolSize。less

● maximumPoolSize参数也是当前线程池容许建立的最大线程数量。那么若是设置的corePoolSize参数和设置的maximumPoolSize参数一致时,线程池在任何状况下都不会回收空闲线程。keepAliveTime和timeUnit也就失去了意义。ide

● keepAliveTime参数和timeUnit参数也是配合使用的。keepAliveTime参数指明等待时间的量化值,timeUnit指明量化值单位。例如keepAliveTime=1,timeUnit为TimeUnit.MINUTES,表明空闲线程的回收阀值为1分钟。函数

说完了线程池的逻辑结构,下面咱们讨论一下线程池是怎样处理某一个运行任务的。 
一、首先能够经过线程池提供的submit()方法或者execute()方法,要求线程池执行某个任务。线程池收到这个要求执行的任务后,会有几种处理状况: 
1.一、若是当前线程池中运行的线程数量尚未达到corePoolSize大小时,线程池会建立一个新的线程运行你的任务,不管以前已经建立的线程是否处于空闲状态。 
1.二、若是当前线程池中运行的线程数量已经达到设置的corePoolSize大小,线程池会把你的这个任务加入到等待队列中。直到某一个的线程空闲了,线程池会根据设置的等待队列规则,从队列中取出一个新的任务执行。 
1.三、若是根据队列规则,这个任务没法加入等待队列。这时线程池就会建立一个“非核心线程”直接运行这个任务。注意,若是这种状况下任务执行成功,那么当前线程池中的线程数量必定大于corePoolSize。 
1.四、若是这个任务,没法被“核心线程”直接执行,又没法加入等待队列,又没法建立“非核心线程”直接执行,且你没有为线程池设置RejectedExecutionHandler。这时线程池会抛出RejectedExecutionException异常,即线程池拒绝接受这个任务。(实际上抛出RejectedExecutionException异常的操做,是ThreadPoolExecutor线程池中一个默认的RejectedExecutionHandler实现:AbortPolicy,这在后文会提到) 
二、一旦线程池中某个线程完成了任务的执行,它就会试图到任务等待队列中拿去下一个等待任务(全部的等待任务都实现了BlockingQueue接口,按照接口字面上的理解,这是一个可阻塞的队列接口),它会调用等待队列的poll()方法,并停留在哪里。 
三、当线程池中的线程超过你设置的corePoolSize参数,说明当前线程池中有所谓的“非核心线程”。那么当某个线程处理完任务后,若是等待keepAliveTime时间后仍然没有新的任务分配给它,那么这个线程将会被回收。线程池回收线程时,对所谓的“核心线程”和“非核心线程”是一视同仁的,直到线程池中线程的数量等于你设置的corePoolSize参数时,回收过程才会中止。工具

不经常使用的设置

在ThreadPoolExecutor线程池中,有一些不经常使用的甚至不须要的设置

allowCoreThreadTimeOut:

线程池回收线程只会发生在当前线程池中线程数量大于corePoolSize参数的时候;当线程池中线程数量小于等于corePoolSize参数的时候,回收过程就会中止。 
allowCoreThreadTimeOut设置项能够要求线程池:将包括“核心线程”在内的,没有任务分配的任何线程,在等待keepAliveTime时间后所有进行回收:

ThreadPoolExecutor poolExecutor = new ThreadPoolExecutor(5, 10, 1, TimeUnit.MINUTES, new ArrayBlockingQueue(1)); 
poolExecutor.allowCoreThreadTimeOut(true);

如下是设置前的效果: 
[图片] 
如下是设置后的效果: 
[图片]

prestartAllCoreThreads

前文咱们还讨论到,当线程池中的线程尚未达到你设置的corePoolSize参数值的时候,若是有新的任务到来,线程池将建立新的线程运行这个任务,不管以前已经建立的线程是否处于空闲状态。这个描述能够用下面的示意图表示出来: 
[图片] 
prestartAllCoreThreads设置项,能够在线程池建立,但尚未接收到任何任务的状况下,先行建立符合corePoolSize参数值的线程数:

ThreadPoolExecutor poolExecutor =new ThreadPoolExecutor(5,10,1, TimeUnit.MINUTES, new ArrayBlockingQueue<Runnable>(1));
poolExecutor.prestartAllCoreThreads();

咱们继续讨论ThreadPoolExecutor线程池。上面给出的最简单的ThreadPoolExecutor线程池的使用方式中,咱们只采用了ThreadPoolExecutor最简单的一个构造函数:

public ThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime, TimeUnit unit, BlockingQueue workQueue)

实际上ThreadPoolExecutor线程池有不少种构造函数,其中最复杂的一种构造函数是:

public ThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime, TimeUnit unit, BlockingQueue workQueue, ThreadFactory threadFactory, RejectedExecutionHandler handler)

在上文中咱们尚未介绍的workQueue、threadFactory和handler参数,将是本文讲解的重点。

一:ThreadFactory的使用

线程池最主要的一项工做,就是在知足某些条件的状况下建立线程。而在ThreadPoolExecutor线程池中,建立线程的工做交给ThreadFactory来完成。要使用线程池,就必需要指定ThreadFactory。 
相似于上文中,若是咱们使用的构造函数时并无指定使用的ThreadFactory,这个时候ThreadPoolExecutor会使用一个默认的ThreadFactory:DefaultThreadFactory。(这个类在Executors工具类中)

固然,在某些特殊业务场景下,还可使用一个自定义的ThreadFactory线程工厂,以下代码片断:

import java.util.concurrent.ThreadFactory; 
/** * 测试自定义的一个线程工厂 */ 
public class TestThreadFactory implements ThreadFactory { 
    @Override 
    public Thread newThread(Runnable r) { 
        return new Thread(r); 
    } 
}

二:线程池的等待队列

在使用ThreadPoolExecutor线程池的时候,须要指定一个实现了BlockingQueue接口的任务等待队列。在ThreadPoolExecutor线程池的API文档中,一共推荐了三种等待队列,它们是:SynchronousQueue、LinkedBlockingQueue和ArrayBlockingQueue;

队列和栈

● 队列:是一种特殊的线性结构,容许在线性结构的前端进行删除/读取操做;容许在线性结构的后端进行插入操做;这种线性结构具备“先进先出”的操做特色: 
[图片] 
可是在实际应用中,队列中的元素有可能不是以“进入的顺序”为排序依据的。例如咱们将要讲到的PriorityBlockingQueue队列。 
● 栈:栈也是一种线性结构,可是栈和队列相比只容许在线性结构的一端进行操做,入栈和出栈都是在一端完成。 
[图片]

2.1有限队列

● SynchronousQueue:

“是这样 一种阻塞队列,其中每一个 put 必须等待一个 take,反之亦然。同步队列没有任何内部容量。翻译一下:这是一个内部没有任何容量的阻塞队列,任何一次插入操做的元素都要等待相对的删除/读取操做,不然进行插入操做的线程就要一直等待,反之亦然。

SynchronousQueue<Object> queue = new SynchronousQueue<Object>(); 
// 不要使用add,由于这个队列内部没有任何容量,因此会抛出异常“IllegalStateException” 
//queue.add(new Object()); 
// 操做线程会在这里被阻塞,直到有其余操做线程取走这个对象 
queue.put(new Object());

● ArrayBlockingQueue:

一个由数组支持的有界阻塞队列。此队列按 FIFO(先进先出)原则对元素进行排序。新元素插入到队列的尾部,队列获取操做则是从队列头部开始得到元素。这是一个典型的“有界缓存区”,固定大小的数组在其中保持生产者插入的元素和使用者提取的元素。一旦建立了这样的缓存区,就不能再增长其容量。试图向已满队列中放入元素会致使操做受阻塞;试图从空队列中提取元素将致使相似阻塞。

// 咱们建立了一个ArrayBlockingQueue,而且设置队列空间为2 
ArrayBlockingQueue<Object> arrayQueue = new ArrayBlockingQueue<Object>(2); 
// 插入第一个对象 
arrayQueue.put(new Object()); 
// 插入第二个对象 
arrayQueue.put(new Object()); 
// 插入第三个对象时,这个操做线程就会被阻塞。 
arrayQueue.put(new Object()); 
// 请不要使用add操做,和SynchronousQueue的add操做同样,它们都使用了AbstractQueue中的add实现

2.2无限队列

● LinkedBlockingQueue:

LinkedBlockingQueue是咱们在ThreadPoolExecutor线程池中经常使用的等待队列。它能够指定容量也能够不指定容量。因为它具备“无限容量”的特性,因此我仍是将它纳入了无限队列的范畴(实际上任何无限容量的队列/栈都是有容量的,这个容量就是Integer.MAX_VALUE)。 
LinkedBlockingQueue的实现是基于链表结构,而不是相似ArrayBlockingQueue那样的数组。但实际使用过程当中,不须要关心它的内部实现,若是指定了LinkedBlockingQueue的容量大小,那么它反映出来的使用特性就和ArrayBlockingQueue相似了。

LinkedBlockingQueue<Object> linkedQueue = new LinkedBlockingQueue<Object>(2); 
linkedQueue.put(new Object()); 
// 插入第二个对象 
linkedQueue.put(new Object()); 
// 插入第三个对象时,这个操做线程就会被阻塞。 
linkedQueue.put(new Object());

=======================================

// 或者以下使用: 
LinkedBlockingQueue<Object> linkedQueue = new LinkedBlockingQueue<Object>(); 
linkedQueue.put(new Object()); 
// 插入第二个对象 
linkedQueue.put(new Object()); 
// 插入第N个对象时,都不会阻塞 
linkedQueue.put(new Object());

● LinkedBlockingDeque

LinkedBlockingDeque是一个基于链表的双端队列。LinkedBlockingQueue的内部结构决定了它只能从队列尾部插入,从队列头部取出元素;可是LinkedBlockingDeque既能够从尾部插入/取出元素,还能够从头部插入元素/取出元素。

LinkedBlockingDeque linkedDeque = new LinkedBlockingDeque(); 
// push ,能够从队列的头部插入元素 
linkedDeque.push(new TempObject(1)); 
linkedDeque.push(new TempObject(2)); 
linkedDeque.push(new TempObject(3)); 
// poll , 能够从队列的头部取出元素 
TempObject tempObject = linkedDeque.poll(); 
// 这里会打印 
tempObject.index = 3 
System.out.println("tempObject.index = " + tempObject.getIndex()); 
// put , 能够从队列的尾部插入元素 
linkedDeque.put(new TempObject(4)); 
linkedDeque.put(new TempObject(5)); 
// pollLast , 能够从队列尾部取出元素 
tempObject = linkedDeque.pollLast(); 
// 这里会打印 
tempObject.index = 5 
System.out.println("tempObject.index = " + tempObject.getIndex());

● PriorityBlockingQueue

PriorityBlockingQueue是一个按照优先级进行内部元素排序的无限队列。存放在PriorityBlockingQueue中的元素必须实现Comparable接口,这样才能经过实现compareTo()方法进行排序。优先级最高的元素将始终排在队列的头部;PriorityBlockingQueue不会保证优先级同样的元素的排序,也不保证当前队列中除了优先级最高的元素之外的元素,随时处于正确排序的位置。 
这是什么意思呢?PriorityBlockingQueue并不保证除了队列头部之外的元素排序必定是正确的。请看下面的示例代码:

PriorityBlockingQueue priorityQueue = new PriorityBlockingQueue(); 
priorityQueue.put(new TempObject(-5)); 
priorityQueue.put(new TempObject(5));
priorityQueue.put(new TempObject(-1)); 
priorityQueue.put(new TempObject(1)); 
// 第一个元素是5 
// 实际上在尚未执行priorityQueue.poll()语句的时候,队列中的第二个元素不必定是1 
TempObject targetTempObject = priorityQueue.poll(); 
System.out.println("tempObject.index = " + targetTempObject.getIndex()); 
// 第二个元素是1 
targetTempObject = priorityQueue.poll(); 
System.out.println("tempObject.index = " + targetTempObject.getIndex()); 
// 第三个元素是-1 
targetTempObject = priorityQueue.poll(); 
System.out.println("tempObject.index = " + targetTempObject.getIndex()); 
// 第四个元素是-5 
targetTempObject = priorityQueue.poll(); 
System.out.println("tempObject.index = " + targetTempObject.getIndex());
// 这个元素类,必须实现Comparable接口 
private static class TempObject implements Comparable<TempObject> { 
    private int index; public TempObject(int index) { 
        this.index = index;
    } 
    /** * @return the index */ 
    public int getIndex() { 
        return index; 
    } 
    /* (non-Javadoc) * @see java.lang.Comparable#compareTo(java.lang.Object) */ 
    @Override 
    public int compareTo(TempObject o) { 
        return o.getIndex() - this.index; 
    } 
}

● LinkedTransferQueue

LinkedTransferQueue也是一个无限队列,它除了具备通常队列的操做特性外(先进先出),还具备一个阻塞特性:LinkedTransferQueue能够由一对生产者/消费者线程进行操做,当消费者将一个新的元素插入队列后,消费者线程将会一直等待,直到某一个消费者线程将这个元素取走,反之亦然。 
LinkedTransferQueue的操做特性能够由下面这段代码提现。在下面的代码片断中,有两中类型的线程:生产者和消费者,这两类线程互相等待对方的操做:

/** * 生产者线程 */ 
private static class ProducerRunnable implements Runnable { 
    private LinkedTransferQueue linkedQueue; 
    public ProducerRunnable(LinkedTransferQueue linkedQueue) { 
        this.linkedQueue = linkedQueue; 
        } 
    @Override 
    public void run() { 
        for(int index = 1 ; ; index++) { 
            try { 
                // 向LinkedTransferQueue队列插入一个新的元素 
                // 而后生产者线程就会等待,直到有一个消费者将这个元素从队列中取走 
                this.linkedQueue.transfer(new TempObject(index)); 
            } catch (InterruptedException e) { 
                e.printStackTrace(System.out); 
            } 
        } 
    } 
} 
/** * 消费者线程 */ 
private static class ConsumerRunnable implements Runnable { 
    private LinkedTransferQueue linkedQueue; 
    public ConsumerRunnable(LinkedTransferQueue linkedQueue) { 
        this.linkedQueue = linkedQueue; 
    } 
    @Override 
    public void run() { 
        Thread currentThread = Thread.currentThread(); 
        while(!currentThread.isInterrupted()) { 
            try { 
                // 等待,直到从LinkedTransferQueue队列中获得一个元素 
                TempObject targetObject = this.linkedQueue.take(); 
                System.out.println("线程(" + currentThread.getId() + ")取得targetObject.index = " + targetObject.getIndex()); 
            } catch (InterruptedException e) { 
                e.printStackTrace(System.out); 
            } 
        } 
    } 
}

=====如下是启动代码:

LinkedTransferQueue<TempObject> linkedQueue = new LinkedTransferQueue<TempObject>(); 
// 这是一个生产者线程 
Thread producerThread = new Thread(new ProducerRunnable(linkedQueue)); 
// 这里有两个消费者线程 
Thread consumerRunnable1 = new Thread(new ConsumerRunnable(linkedQueue)); 
Thread consumerRunnable2 = new Thread(new ConsumerRunnable(linkedQueue)); 
// 开始运行 
producerThread.start(); 
consumerRunnable1.start(); 
consumerRunnable2.start(); 
// 这里只是为了main不退出,没有任何演示含义 
Thread currentThread = Thread.currentThread(); 
synchronized (currentThread) { 
    currentThread.wait(); 
}

三:拒绝任务(handler)

在ThreadPoolExecutor线程池中还有一个重要的接口:RejectedExecutionHandler。当提交给线程池的某一个新任务没法直接被线程池中“核心线程”直接处理,又没法加入等待队列,也没法建立新的线程执行;又或者线程池已经调用shutdown()方法中止了工做;又或者线程池不是处于正常的工做状态;这时候ThreadPoolExecutor线程池会拒绝处理这个任务,触发建立ThreadPoolExecutor线程池时定义的RejectedExecutionHandler接口的实现

在建立ThreadPoolExecutor线程池时,必定会指定RejectedExecutionHandler接口的实现。若是调用的是不须要指定RejectedExecutionHandler接口的构造函数,如:

public ThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime, TimeUnit unit, BlockingQueue workQueue); 
public ThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime, TimeUnit unit, BlockingQueue workQueue, ThreadFactory threadFactory);

那么ThreadPoolExecutor线程池在建立时,会使用一个默认的RejectedExecutionHandler接口实现,源代码片断以下:

public class ThreadPoolExecutor extends AbstractExecutorService { 
    ...... 
    /** * The default rejected execution handler */ 
    private static final RejectedExecutionHandler defaultHandler = new AbortPolicy(); 
    ...... 
    // 能够看到,ThreadPoolExecutor中的两个没有指定RejectedExecutionHandler 
    // 接口的构造函数,都是使用了一个RejectedExecutionHandler接口的默认实现:
    AbortPolicy public ThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime, TimeUnit unit, BlockingQueue workQueue) { 
        this(corePoolSize, maximumPoolSize, keepAliveTime, unit, workQueue, Executors.defaultThreadFactory(), defaultHandler); 
    } 
    ...... 
    public ThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime, TimeUnit unit, BlockingQueue workQueue, ThreadFactory threadFactory) { 
        this(corePoolSize, maximumPoolSize, keepAliveTime, unit, workQueue, threadFactory, defaultHandler); 
    } 
    ...... 
}

实际上,在ThreadPoolExecutor中已经提供了四种能够直接使用的RejectedExecutionHandler接口的实现:

● CallerRunsPolicy: 
这个拒绝处理器,将直接运行这个任务的run方法。可是,请注意并非在ThreadPoolExecutor线程池中的线程中运行,而是直接调用这个任务实现的run方法。源代码以下:

public static class CallerRunsPolicy implements RejectedExecutionHandler { 
    /** * Creates a {@code CallerRunsPolicy}. */ 
    public CallerRunsPolicy() { } 
    /** Executes task r in the caller's thread, unless the executor * has been shut down, in which case the task is discarded. 
     ** @param r the runnable task requested to be executed * @param e the executor attempting to execute this task 
     **/ 
    public void rejectedExecution(Runnable r, ThreadPoolExecutor e) { 
        if (!e.isShutdown()) { 
            r.run(); 
        } 
    } 
}

● AbortPolicy:

这个处理器,在任务被拒绝后会建立一个RejectedExecutionException异常并抛出。这个处理过程也是ThreadPoolExecutor线程池默认的RejectedExecutionHandler实现。

● DiscardPolicy: 
DiscardPolicy处理器,将会默默丢弃这个被拒绝的任务,不会抛出异常,也不会经过其余方式执行这个任务的任何一个方法,更不会出现任何的日志提示。

● DiscardOldestPolicy: 
这个处理器颇有意思。它会检查当前ThreadPoolExecutor线程池的等待队列。并调用队列的poll()方法,将当前处于等待队列列头的等待任务强行取出,而后再试图将当前被拒绝的任务提交到线程池执行:

public static class DiscardOldestPolicy implements RejectedExecutionHandler { 
    ...... 
    public void rejectedExecution(Runnable r, ThreadPoolExecutor e) { 
        if (!e.isShutdown()) { 
            e.getQueue().poll(); 
            e.execute(r); 
        } 
    } 
    ...... 
}

实际上查阅这四种ThreadPoolExecutor线程池自带的拒绝处理器实现,您能够发现CallerRunsPolicy、DiscardPolicy、DiscardOldestPolicy处理器针对被拒绝的任务并非一个很好的处理方式。  CallerRunsPolicy在非线程池之外直接调用任务的run方法,可能会形成线程安全上的问题;DiscardPolicy默默的忽略掉被拒绝任务,也没有输出日志或者提示,开发人员不会知道线程池的处理过程出现了错误;DiscardOldestPolicy中e.getQueue().poll()的方式好像是科学的,可是若是等待队列出现了容量问题,大多数状况下就是这个线程池的代码出现了BUG。最科学的的仍是AbortPolicy提供的处理方式:抛出异常,由开发人员进行处理。

相关文章
相关标签/搜索