Java自定义线程池应用

自定义线程池的核心：ThreadPoolExecutor

为了更好的控制多线程，JDK提供了一套线程框架Executor，帮助开发人员有效的进行线程控制，其中在java.util.concurrent包下，是JDK并发包的核心，比如我们熟知的Executors。Executors扮演着线程工厂的角色，我们通过它可以创建特定功能的线程池，而这些线程池背后的就是：ThreadPoolExecutor。那么下面我们来具体分析下它。

构造ThreadPoolExecutor

    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;
    }

参数说明

• corePoolSize:核心线程数
• maximumPoolSize:最大线程数
• keepAliveTime + unit:线程回收时间
• workQueue:任务较多时暂存到队列
• threadFactory:执行程序创建新线程时使用的工厂
• handler:超出线程池容量以及队列长度后拒绝任务的策略

线程池拒绝策略

当线程池的任务缓存队列已满并且线程池中的线程数目达到maximumPoolSize时，如果还有任务到来就会采取任务拒绝策略，通常有以下四种策略：

• ThreadPoolExecutor.AbortPolicy: 丢弃任务并抛出RejectedExecutionException异常。
• ThreadPoolExecutor.DiscardPolicy: 丢弃任务，但是不抛出异常。
• ThreadPoolExecutor.DiscardOldestPolicy: 丢弃队列最前面的任务，然后重新提交被拒绝的任务。
• ThreadPoolExecutor.CallerRunsPolicy: 由调用线程（提交任务的线程）处理该任务。

线程池默认的拒绝策略

既然有四种拒绝策略可以选择，那么线程池的默认拒绝策略是什么呢？
查看java.util.concurrent.ThreadPoolExecutor类的源码，我们可以看到：

/**
 * The default rejected execution handler
 */
private static final RejectedExecutionHandler defaultHandler = new AbortPolicy();

线程池的默认拒绝策略为AbortPolicy，即丢弃任务并抛出RejectedExecutionException异常。

常用的几种队列

• ArrayBlockingQueue: 规定大小的BlockingQueue，其构造必须指定大小。其所含的对象是FIFO顺序排序的。
• LinkedBlockingQueue: 大小不固定的BlockingQueue，若其构造时指定大小，生成的BlockingQueue有大小限制，不指定大小，其大小有Integer.MAX_VALUE来决定。其所含的对象是FIFO顺序排序的。
• PriorityBlockingQueue: 类似于LinkedBlockingQueue，但是其所含对象的排序不是FIFO，而是依据对象的自然顺序或者构造函数的Comparator决定。
• SynchronizedQueue: 特殊的BlockingQueue，对其的操作必须是放和取交替完成。

排队策略

排队有三种通用策略：

直接提交。工作队列的默认选项是 SynchronousQueue，它将任务直接提交给线程而不保持它们。在此，如果不存在可用于立即运行任务的线程，则试图把任务加入队列将失败，因此会构造一个新的线程。此策略可以避免在处理可能具有内部依赖性的请求集时出现锁。直接提交通常要求无界 maximumPoolSizes 以避免拒绝新提交的任务。当命令以超过队列所能处理的平均数连续到达时，此策略允许无界线程具有增长的可能性。

无界队列。使用无界队列（例如，不具有预定义容量的 LinkedBlockingQueue）将导致在所有 corePoolSize 线程都忙时新任务在队列中等待。这样，创建的线程就不会超过 corePoolSize。（因此，maximumPoolSize的值也就无效了。）当每个任务完全独立于其他任务，即任务执行互不影响时，适合于使用无界队列；例如，在 Web页服务器中。这种排队可用于处理瞬态突发请求，当命令以超过队列所能处理的平均数连续到达时，此策略允许无界线程具有增长的可能性。

有界队列。当使用有限的 maximumPoolSizes时，有界队列（如 ArrayBlockingQueue）有助于防止资源耗尽，但是可能较难调整和控制。队列大小和最大池大小可能需要相互折衷：使用大型队列和小型池可以最大限度地降低 CPU 使用率、操作系统资源和上下文切换开销，但是可能导致人工降低吞吐量。如果任务频繁阻塞（例如，如果它们是 I/O边界），则系统可能为超过您许可的更多线程安排时间。使用小型队列通常要求较大的池大小，CPU使用率较高，但是可能遇到不可接受的调度开销，这样也会降低吞吐量。

我们选其中的LinkedBlockingQueue队列来解析在上述Java自带的创建线程池的方法中，newFixedThreadPool使用的队列就是LinkedBlockingQueue

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

如果需要执行的工作任务少于核心线程数，那么直接使用线程池的空闲线程执行任务，如果任务不断增加，超过核心线程数，那么任务将被放进队列中，而且是没有限制的，线程池中的线程也不会增加。其他线程池的工作队列也是根据排队的通用策略来进行工作，看客们可以自己分析。