Executor中的类

Executor框架

其中ThreadPoolExecutor非常重要，通过这个类自定义线程池

public ThreadPoolExecutor(int corePoolSize, 　　　　　　　　//线程池里面的线程数量
                              int maximumPoolSize,　　　　 //线程池最大线程数量
                              long keepAliveTime,　　　　　//当线程数量大于core核心数量的时候，那么最大可以被terminate的的等待时间
                              TimeUnit unit,　　　　　　　　//上面参数的单位
                              BlockingQueue<Runnable> workQueue, //哪种阻塞队列
                              ThreadFactory threadFactory,  //线程工厂
                              RejectedExecutionHandler handler)  //拒绝策略

最常用的是Executors静态工厂创建的线程池

public static ExecutorService newFixedThreadPool(int nThreads) {
        return new ThreadPoolExecutor(nThreads, nThreads,
                                      0L, TimeUnit.MILLISECONDS,
                                      new LinkedBlockingQueue<Runnable>());
    }

public static ExecutorService newSingleThreadExecutor() {
    return new FinalizableDelegatedExecutorService
        (new ThreadPoolExecutor(1, 1,
                                0L, TimeUnit.MILLISECONDS,
                                new LinkedBlockingQueue<Runnable>()));
}

public static ExecutorService newCachedThreadPool() {
    return new ThreadPoolExecutor(0, Integer.MAX_VALUE,
                                  60L, TimeUnit.SECONDS,
                                  new SynchronousQueue<Runnable>());
}

public static ScheduledExecutorService newSingleThreadScheduledExecutor(ThreadFactory threadFactory) {
    return new DelegatedScheduledExecutorService
        (new ScheduledThreadPoolExecutor(1, threadFactory));
}

newFixedThreadExecutor中(固定大小线程池)最大线程数量和核心线程数量一致，等待时常0也就意味着如果线程无任务就关闭。用LinkedBlockingQueue。
newSingleThreadExecutor指定线程池中只有一个线程，其他和newFixedThreadExecutor一样。
newCachedThreadPool每有一个任务就创建一个线程，但是如果队列中还有任务可重用已经创建过的线程。如果队列储存的任务过多可能会造成内存不足，对于短期异步的程序可提高性能。
newScheduledThreadPool创建一个大小无限的线程池。此线程池支持定时以及周期性执行任务的需求

并发会用到两种队列：阻塞队列(BlockingQueue)和非阻塞队列(ConcurrentLinkedQueue)

常见BlockingQueue：ArrayBlockingQueue、LinkedBlockingQueue、DelayQueue、PriorityBlockingQueue、SynchronousQueue
ArrayBlockingQueue
基于数组的阻塞队列实现，在ArrayBlockingQueue内部，维护了一个定长数组，以便缓存队列中的数据对象，这是一个常用的阻塞队列，除了一个定长数组外，ArrayBlockingQueue内部还保存着两个整形变量，分别标识着队列的头部和尾部在数组中的位置。
ArrayBlockingQueue在生产者放入数据和消费者获取数据，都是共用同一个锁对象，由此也意味着两者无法真正并行运行，这点尤其不同于LinkedBlockingQueue；按照实现原理来分析，ArrayBlockingQueue完全可以采用分离锁，从而实现生产者和消费者操作的完全并行运行。Doug Lea之所以没这样去做，也许是因为ArrayBlockingQueue的数据写入和获取操作已经足够轻巧，以至于引入独立的锁机制，除了给代码带来额外的复杂性外，其在性能上完全占不到任何便宜。 ArrayBlockingQueue和LinkedBlockingQueue间还有一个明显的不同之处在于，前者在插入或删除元素时不会产生或销毁任何额外的对象实例，而后者则会生成一个额外的Node对象。这在长时间内需要高效并发地处理大批量数据的系统中，其对于GC的影响还是存在一定的区别。而在创建ArrayBlockingQueue时，我们还可以控制对象的内部锁是否采用公平锁，默认采用非公平锁。
LinkedBlockingQueue
 基于链表的阻塞队列，同ArrayListBlockingQueue类似，其内部也维持着一个数据缓冲队列（该队列由一个链表构成），当生产者往队列中放入一个数据时，队列会从生产者手中获取数据，并缓存在队列内部，而生产者立即返回；只有当队列缓冲区达到最大值缓存容量时（LinkedBlockingQueue可以通过构造函数指定该值），才会阻塞生产者队列，直到消费者从队列中消费掉一份数据，生产者线程会被唤醒，反之对于消费者这端的处理也基于同样的原理。而LinkedBlockingQueue之所以能够高效的处理并发数据，还因为其对于生产者端和消费者端分别采用了独立的锁来控制数据同步，这也意味着在高并发的情况下生产者和消费者可以并行地操作队列中的数据，以此来提高整个队列的并发性能。
作为开发者，我们需要注意的是，如果构造一个LinkedBlockingQueue对象，而没有指定其容量大小，LinkedBlockingQueue会默认一个类似无限大小的容量（Integer.MAX_VALUE），这样的话，如果生产者的速度一旦大于消费者的速度，也许还没有等到队列满阻塞产生，系统内存就有可能已被消耗殆尽了。
DelayQueue
DelayQueue中的元素只有当其指定的延迟时间到了，才能够从队列中获取到该元素。DelayQueue是一个没有大小限制的队列，因此往队列中插入数据的操作（生产者）永远不会被阻塞，而只有获取数据的操作（消费者）才会被阻塞。
使用场景：
DelayQueue使用场景较少，但都相当巧妙，常见的例子比如使用一个DelayQueue来管理一个超时未响应的连接队列

PriorityBlockingQueue
 基于优先级的阻塞队列（优先级的判断通过构造函数传入的Compator对象来决定），但需要注意的是PriorityBlockingQueue并不会阻塞数据生产者，而只会在没有可消费的数据时，阻塞数据的消费者。因此使用的时候要特别注意，生产者生产数据的速度绝对不能快于消费者消费数据的速度，否则时间一长，会最终耗尽所有的可用堆内存空间。在实现PriorityBlockingQueue时，内部控制线程同步的锁采用的是公平锁。

SynchronousQueue
一种无缓冲的等待队列，类似于无中介的直接交易，有点像原始社会中的生产者和消费者，生产者拿着产品去集市销售给产品的最终消费者，而消费者必须亲自去集市找到所要商品的直接生产者，如果一方没有找到合适的目标，那么对不起，大家都在集市等待。相对于有缓冲的BlockingQueue来说，少了一个中间经销商的环节（缓冲区），如果有经销商，生产者直接把产品批发给经销商，而无需在意经销商最终会将这些产品卖给那些消费者，由于经销商可以库存一部分商品，因此相对于直接交易模式，总体来说采用中间经销商的模式会吞吐量高一些（可以批量买卖）；但另一方面，又因为经销商的引入，使得产品从生产者到消费者中间增加了额外的交易环节，单个产品的及时响应性能可能会降低。
声明一个SynchronousQueue有两种不同的方式，它们之间有着不太一样的行为。公平模式和非公平模式的区别:
如果采用公平模式：SynchronousQueue会采用公平锁，并配合一个FIFO队列来阻塞多余的生产者和消费者，从而体系整体的公平策略；
但如果是非公平模式（SynchronousQueue默认）：SynchronousQueue采用非公平锁，同时配合一个LIFO队列来管理多余的生产者和消费者，而后一种模式，如果生产者和消费者的处理速度有差距，则很容易出现饥渴的情况，即可能有某些生产者或者是消费者的数据永远都得不到处理

BlockingQueue方法：

　　　　　　　　可能报异常　　　　返回布尔值　　　　可能阻塞　　　　　　设定等待时间

入队　　　　　　add(e)　　　　　　　offer(e)　　　　　　put(e)　　　　　　　　offer(e, timeout, unit)

出队　　　　　　remove()　　　　　　poll()　　　　　　　take()　　　　　　　　poll(timeout, unit)

查看　　　　　　element()　　　　　　peek()

add(e) remove() element() 方法不会阻塞线程。当不满足约束条件时，会抛出IllegalStateException 异常。例如：当队列被元素填满后，再调用add(e)，则会抛出异常。
offer(e) poll() peek() 方法即不会阻塞线程，也不会抛出异常。例如：当队列被元素填满后，再调用offer(e)，则不会插入元素，函数返回false。
要想要实现阻塞功能，需要调用put(e) take() 方法。当不满足约束条件时，会阻塞线程。


ConcurrentLinkedQueue
是一个基于链接节点的无界线程安全队列，它采用先进先出的规则对节点进行排序，当我们添加一个元素的时候，它会添加到队列的尾部，当我们获取一个元素时，它会返回队列头部的元素。
调用add(), take()方法是线程安全的。如果调用isEmpty()需要自己做同步。

RejectedExecutionHandler拒绝策略

就是线程池满后对新来的任务的处理

  • DiscardPolicy              这种策略和AbortPolicy几乎一样，也是丢弃任务，只不过他不抛出异常。 
    public void rejectedExecution(Runnable r, ThreadPoolExecutor e) {  
        }
  • DiscardOldestPolicy    在pool没有关闭的前提下首先丢掉缓存在队列中的最早的任务，然后重新尝试运行该任务。如果进来的任务过快，最老的任务可能永远也不执行 
    public void rejectedExecution(Runnable r, ThreadPoolExecutor e) {  
            if (!e.isShutdown()) {  
                e.getQueue().poll();  
                e.execute(r);  
            }  
        }
  • AbortPolicy　　           直接抛出异常，丢弃任务。 
    public void rejectedExecution(Runnable r, ThreadPoolExecutor e) {  
            throw new RejectedExecutionException();  
        }
  • CallerRunsPolicy        任务会调用调用者线程类处理 
    public void rejectedExecution(Runnable r, ThreadPoolExecutor e) {  
            if (!e.isShutdown()) {  
                r.run();  
            }  
        }

如果上面的策略不够可以实现RejectedExecutionHandler自定义策略。
如果没设置拒绝策略，在future.get()的时候会一直等待。

参考：
http://www.cnblogs.com/congsg2016/p/5621746.html
http://bjyzxxds.iteye.com/blog/1267833
http://wsmajunfeng.iteye.com/blog/1629354　　　　　阻塞队列
http://blog.csdn.net/madun/article/details/20313269　　阻塞/非阻塞队列
http://dongxuan.iteye.com/blog/902571　　　　　　     拒绝策略

【推广】 免费学中医，健康全家人
原文地址：https://www.cnblogs.com/badboyf/p/6607529.html