java 线程池较详细文摘

最新推荐文章于 2024-09-05 11:00:53 发布

ichsonx

最新推荐文章于 2024-09-05 11:00:53 发布

阅读量4.8k

点赞数

分类专栏： JAVA 文章标签： java 任务工作 command null 服务器

JAVA 专栏收录该内容

52 篇文章 0 订阅

订阅专栏

为什么要用线程池？

诸如 Web 服务器、数据库服务器、文件服务器或邮件服务器之类的许多服务器应用程序都面向处理来自某些远程来源的大量短小的任务。请求以某种方式到达服务器，这种方式可能是通过网络协议（例如 HTTP、FTP 或 POP）、通过 JMS 队列或者可能通过轮询数据库。不管请求如何到达，服务器应用程序中经常出现的情况是：单个任务处理的时间很短而请求的数目却是巨大的。

构建服务器应用程序的一个过于简单的模型应该是：每当一个请求到达就创建一个新线程，然后在新线程中为请求服务。实际上，对于原型开发这种方法工作得很好，但如果试图部署以这种方式运行的服务器应用程序，那么这种方法的严重不足就很明显。每个请求对应一个线程（thread-per-request）方法的不足之一是：为每个请求创建一个新线程的开销很大；为每个请求创建新线程的服务器在创建和销毁线程上花费的时间和消耗的系统资源要比花在处理实际的用户请求的时间和资源更多。

除了创建和销毁线程的开销之外，活动的线程也消耗系统资源。在一个 JVM 里创建太多的线程可能会导致系统由于过度消耗内存而用完内存或“切换过度”。为了防止资源不足，服务器应用程序需要一些办法来限制任何给定时刻处理的请求数目。

线程池为线程生命周期开销问题和资源不足问题提供了解决方案。通过对多个任务重用线程，线程创建的开销被分摊到了多个任务上。其好处是，因为在请求到达时线程已经存在，所以无意中也消除了线程创建所带来的延迟。这样，就可以立即为请求服务，使应用程序响应更快。而且，通过适当地调整线程池中的线程数目，也就是当请求的数目超过某个阈值时，就强制其它任何新到的请求一直等待，直到获得一个线程来处理为止，从而可以防止资源不足。

线程池的替代方案

线程池远不是服务器应用程序内使用多线程的唯一方法。如同上面所提到的，有时，为每个新任务生成一个新线程是十分明智的。然而，如果任务创建过于频繁而任务的平均处理时间过短，那么为每个任务生成一个新线程将会导致性能问题。

另一个常见的线程模型是为某一类型的任务分配一个后台线程与任务队列。AWT 和 Swing 就使用这个模型，在这个模型中有一个 GUI 事件线程，导致用户界面发生变化的所有工作都必须在该线程中执行。然而，由于只有一个 AWT 线程，因此要在 AWT 线程中执行任务可能要花费相当长时间才能完成，这是不可取的。因此，Swing 应用程序经常需要额外的工作线程，用于运行时间很长的、同 UI 有关的任务。

每个任务对应一个线程方法和单个后台线程（single-background-thread）方法在某些情形下都工作得非常理想。每个任务一个线程方法在只有少量运行时间很长的任务时工作得十分好。而只要调度可预见性不是很重要，则单个后台线程方法就工作得十分好，如低优先级后台任务就是这种情况。然而，大多数服务器应用程序都是面向处理大量的短期任务或子任务，因此往往希望具有一种能够以低开销有效地处理这些任务的机制以及一些资源管理和定时可预见性的措施。线程池提供了这些优点。

工作队列

就线程池的实际实现方式而言，术语“线程池”有些使人误解，因为线程池“明显的”实现在大多数情形下并不一定产生我们希望的结果。术语“线程池”先于 Java 平台出现，因此它可能是较少面向对象方法的产物。然而，该术语仍继续广泛应用着。

虽然我们可以轻易地实现一个线程池类，其中客户机类等待一个可用线程、将任务传递给该线程以便执行、然后在任务完成时将线程归还给池，但这种方法却存在几个潜在的负面影响。例如在池为空时，会发生什么呢？试图向池线程传递任务的调用者都会发现池为空，在调用者等待一个可用的池线程时，它的线程将阻塞。我们之所以要使用后台线程的原因之一常常是为了防止正在提交的线程被阻塞。完全堵住调用者，如在线程池的“明显的”实现的情况，可以杜绝我们试图解决的问题的发生。

我们通常想要的是同一组固定的工作线程相结合的工作队列，它使用 wait() 和 notify() 来通知等待线程新的工作已经到达了。该工作队列通常被实现成具有相关监视器对象的某种链表。清单 1 显示了简单的合用工作队列的示例。尽管 Thread API 没有对使用 Runnable 接口强加特殊要求，但使用 Runnable 对象队列的这种模式是调度程序和工作队列的公共约定。

清单 1. 具有线程池的工作队列

public class WorkQueue

{

    private final int nThreads;

    private final PoolWorker[] threads;

    private final LinkedList queue;

    public WorkQueue(int nThreads)

    {

        this.nThreads = nThreads;

        queue = new LinkedList();

        threads = new PoolWorker[nThreads];

        for (int i=0; i<nThreads; i++) {

            threads[i] = new PoolWorker();

            threads[i].start();

        }

    }

    public void execute(Runnable r) {

        synchronized(queue) {

            queue.addLast(r);

            queue.notify();

        }

    }

    private class PoolWorker extends Thread {

        public void run() {

            Runnable r;

            while (true) {

                synchronized(queue) {

                    while (queue.isEmpty()) {

                        try

                        {

                            queue.wait();

                        }

                        catch (InterruptedException ignored)

                        {

                        }

                    }

                    r = (Runnable) queue.removeFirst();

                }

                // If we don't catch RuntimeException, 

                // the pool could leak threads

                try {

                    r.run();

                }

                catch (RuntimeException e) {

                    // You might want to log something here

                }

            }

        }

    }

}

您可能已经注意到了清单 1 中的实现使用的是 notify() 而不是 notifyAll() 。大多数专家建议使用 notifyAll() 而不是 notify() ，而且理由很充分：使用 notify() 具有难以捉摸的风险，只有在某些特定条件下使用该方法才是合适的。另一方面，如果使用得当， notify() 具有比 notifyAll() 更可取的性能特征；特别是， notify() 引起的环境切换要少得多，这一点在服务器应用程序中是很重要的。

清单 1 中的示例工作队列满足了安全使用 notify() 的需求。因此，请继续，在您的程序中使用它，但在其它情形下使用 notify() 时请格外小心。

使用线程池的风险

虽然线程池是构建多线程应用程序的强大机制，但使用它并不是没有风险的。用线程池构建的应用程序容易遭受任何其它多线程应用程序容易遭受的所有并发风险，诸如同步错误和死锁，它还容易遭受特定于线程池的少数其它风险，诸如与池有关的死锁、资源不足和线程泄漏。

死锁

任何多线程应用程序都有死锁风险。当一组进程或线程中的每一个都在等待一个只有该组中另一个进程才能引起的事件时，我们就说这组进程或线程死锁了。死锁的最简单情形是：线程 A 持有对象 X 的独占锁，并且在等待对象 Y 的锁，而线程 B 持有对象 Y 的独占锁，却在等待对象 X 的锁。除非有某种方法来打破对锁的等待（Java 锁定不支持这种方法），否则死锁的线程将永远等下去。

虽然任何多线程程序中都有死锁的风险，但线程池却引入了另一种死锁可能，在那种情况下，所有池线程都在执行已阻塞的等待队列中另一任务的执行结果的任务，但这一任务却因为没有未被占用的线程而不能运行。当线程池被用来实现涉及许多交互对象的模拟，被模拟的对象可以相互发送查询，这些查询接下来作为排队的任务执行，查询对象又同步等待着响应时，会发生这种情况。

资源不足

线程池的一个优点在于：相对于其它替代调度机制（有些我们已经讨论过）而言，它们通常执行得很好。但只有恰当地调整了线程池大小时才是这样的。线程消耗包括内存和其它系统资源在内的大量资源。除了 Thread 对象所需的内存之外，每个线程都需要两个可能很大的执行调用堆栈。除此以外，JVM 可能会为每个 Java 线程创建一个本机线程，这些本机线程将消耗额外的系统资源。最后，虽然线程之间切换的调度开销很小，但如果有很多线程，环境切换也可能严重地影响程序的性能。

如果线程池太大，那么被那些线程消耗的资源可能严重地影响系统性能。在线程之间进行切换将会浪费时间，而且使用超出比您实际需要的线程可能会引起资源匮乏问题，因为池线程正在消耗一些资源，而这些资源可能会被其它任务更有效地利用。除了线程自身所使用的资源以外，服务请求时所做的工作可能需要其它资源，例如 JDBC 连接、套接字或文件。这些也都是有限资源，有太多的并发请求也可能引起失效，例如不能分配 JDBC 连接。

并发错误

线程池和其它排队机制依靠使用 wait() 和 notify() 方法，这两个方法都难于使用。如果编码不正确，那么可能丢失通知，导致线程保持空闲状态，尽管队列中有工作要处理。使用这些方法时，必须格外小心；即便是专家也可能在它们上面出错。而最好使用现有的、已经知道能工作的实现，例如在下面的无须编写您自己的池中讨论的 util.concurrent 包。

线程泄漏

各种类型的线程池中一个严重的风险是线程泄漏，当从池中除去一个线程以执行一项任务，而在任务完成后该线程却没有返回池时，会发生这种情况。发生线程泄漏的一种情形出现在任务抛出一个 RuntimeException 或一个 Error 时。如果池类没有捕捉到它们，那么线程只会退出而线程池的大小将会永久减少一个。当这种情况发生的次数足够多时，线程池最终就为空，而且系统将停止，因为没有可用的线程来处理任务。

有些任务可能会永远等待某些资源或来自用户的输入，而这些资源又不能保证变得可用，用户可能也已经回家了，诸如此类的任务会永久停止，而这些停止的任务也会引起和线程泄漏同样的问题。如果某个线程被这样一个任务永久地消耗着，那么它实际上就被从池除去了。对于这样的任务，应该要么只给予它们自己的线程，要么只让它们等待有限的时间。

请求过载

仅仅是请求就压垮了服务器，这种情况是可能的。在这种情形下，我们可能不想将每个到来的请求都排队到我们的工作队列，因为排在队列中等待执行的任务可能会消耗太多的系统资源并引起资源缺乏。在这种情形下决定如何做取决于您自己；在某些情况下，您可以简单地抛弃请求，依靠更高级别的协议稍后重试请求，您也可以用一个指出服务器暂时很忙的响应来拒绝请求。

有效使用线程池的准则

只要您遵循几条简单的准则，线程池可以成为构建服务器应用程序的极其有效的方法：

不要对那些同步等待其它任务结果的任务排队。这可能会导致上面所描述的那种形式的死锁，在那种死锁中，所有线程都被一些任务所占用，这些任务依次等待排队任务的结果，而这些任务又无法执行，因为所有的线程都很忙。
在为时间可能很长的操作使用合用的线程时要小心。如果程序必须等待诸如 I/O 完成这样的某个资源，那么请指定最长的等待时间，以及随后是失效还是将任务重新排队以便稍后执行。这样做保证了：通过将某个线程释放给某个可能成功完成的任务，从而将最终取得某些进展。
理解任务。要有效地调整线程池大小，您需要理解正在排队的任务以及它们正在做什么。它们是 CPU 限制的（CPU-bound）吗？它们是 I/O 限制的（I/O-bound）吗？您的答案将影响您如何调整应用程序。如果您有不同的任务类，这些类有着截然不同的特征，那么为不同任务类设置多个工作队列可能会有意义，这样可以相应地调整每个池。

调整池的大小

调整线程池的大小基本上就是避免两类错误：线程太少或线程太多。幸运的是，对于大多数应用程序来说，太多和太少之间的余地相当宽。

请回忆：在应用程序中使用线程有两个主要优点，尽管在等待诸如 I/O 的慢操作，但允许继续进行处理，并且可以利用多处理器。在运行于具有 N 个处理器机器上的计算限制的应用程序中，在线程数目接近 N 时添加额外的线程可能会改善总处理能力，而在线程数目超过 N 时添加额外的线程将不起作用。事实上，太多的线程甚至会降低性能，因为它会导致额外的环境切换开销。

线程池的最佳大小取决于可用处理器的数目以及工作队列中的任务的性质。若在一个具有 N 个处理器的系统上只有一个工作队列，其中全部是计算性质的任务，在线程池具有 N 或 N+1 个线程时一般会获得最大的 CPU 利用率。

对于那些可能需要等待 I/O 完成的任务（例如，从套接字读取 HTTP 请求的任务），需要让池的大小超过可用处理器的数目，因为并不是所有线程都一直在工作。通过使用概要分析，您可以估计某个典型请求的等待时间（WT）与服务时间（ST）之间的比例。如果我们将这一比例称之为 WT/ST，那么对于一个具有 N 个处理器的系统，需要设置大约 N*(1+WT/ST) 个线程来保持处理器得到充分利用。

处理器利用率不是调整线程池大小过程中的唯一考虑事项。随着线程池的增长，您可能会碰到调度程序、可用内存方面的限制，或者其它系统资源方面的限制，例如套接字、打开的文件句柄或数据库连接等的数目。

无须编写您自己的池

Doug Lea 编写了一个优秀的并发实用程序开放源码库 util.concurrent ，它包括互斥、信号量、诸如在并发访问下执行得很好的队列和散列表之类集合类以及几个工作队列实现。该包中的 PooledExecutor 类是一种有效的、广泛使用的以工作队列为基础的线程池的正确实现。您无须尝试编写您自己的线程池，这样做容易出错，相反您可以考虑使用 util.concurrent 中的一些实用程序。参阅参考资料以获取链接和更多信息。

util.concurrent 库也激发了 JSR 166，JSR 166 是一个 Java 社区过程（Java Community Process (JCP)）工作组，他们正在打算开发一组包含在 java.util.concurrent 包下的 Java 类库中的并发实用程序，这个包应该用于 Java 开发工具箱 1.5 发行版。

ThreadPoolExecutor

一、简介

线程池类为 java.util.concurrent.ThreadPoolExecutor ，常用构造方法为：

ThreadPoolExecutor(int corePoolSize, int maximumPoolSize,

long keepAliveTime, TimeUnit unit,

BlockingQueue<Runnable> workQueue,

RejectedExecutionHandler handler)

corePoolSize ：线程池维护线程的最少数量

maximumPoolSize ：线程池维护线程的最大数量

keepAliveTime ：线程池维护线程所允许的空闲时间

unit ：线程池维护线程所允许的空闲时间的单位

workQueue ：线程池所使用的缓冲队列

handler ：线程池对拒绝任务的处理策略

一个任务通过 execute(Runnable) 方法被添加到线程池，任务就是一个 Runnable 类型的对象，任务的执行方法就是 Runnable 类型对象的run() 方法。

当一个任务通过execute(Runnable) 方法欲添加到线程池时：

l 如果此时线程池中的数量小于corePoolSize ，即使线程池中的线程都处于空闲状态，也要创建新的线程来处理被添加的任务。

l 如果此时线程池中的数量等于 corePoolSize ，但是缓冲队列 workQueue 未满，那么任务被放入缓冲队列。

l 如果此时线程池中的数量大于corePoolSize ，缓冲队列workQueue 满，并且线程池中的数量小于maximumPoolSize ，建新的线程来处理被添加的任务。

l 如果此时线程池中的数量大于corePoolSize ，缓冲队列workQueue 满，并且线程池中的数量等于maximumPoolSize ，那么通过 handler 所指定的策略来处理此任务。也就是：处理任务的优先级为：核心线程corePoolSize 、任务队列workQueue 、最大线程maximumPoolSize ，如果三者都满了，使用handler 处理被拒绝的任务。

l 当线程池中的线程数量大于 corePoolSize 时，如果某线程空闲时间超过keepAliveTime ，线程将被终止。这样，线程池可以动态的调整池中的线程数。

unit 可选的参数为java.util.concurrent.TimeUnit 中的几个静态属性：

NANOSECONDS 、

MICROSECONDS 、

MILLISECONDS 、

SECONDS 。

workQueue 常用的是：java.util.concurrent.ArrayBlockingQueue

handler 有四个选择：

ThreadPoolExecutor.AbortPolicy()

抛出java.util.concurrent.RejectedExecutionException 异常

ThreadPoolExecutor.CallerRunsPolicy()

重试添加当前的任务，他会自动重复调用execute() 方法

ThreadPoolExecutor.DiscardOldestPolicy()

抛弃旧的任务

ThreadPoolExecutor.DiscardPolicy()

抛弃当前的任务

二、相关参考

一个 ExecutorService ，它使用可能的几个池线程之一执行每个提交的任务，通常使用 Executors 工厂方法配置。

线程池可以解决两个不同问题：由于减少了每个任务调用的开销，它们通常可以在执行大量异步任务时提供增强的性能，并且还可以提供绑定和管理资源（包括执行集合任务时使用的线程）的方法。每个 ThreadPoolExecutor 还维护着一些基本的统计数据，如完成的任务数。

为了便于跨大量上下文使用，此类提供了很多可调整的参数和扩展挂钩。但是，强烈建议程序员使用较为方便的 Executors 工厂方法 Executors.newCachedThreadPool() （无界线程池，可以进行自动线程回收）、Executors.newFixedThreadPool(int) （固定大小线程池）和 Executors.newSingleThreadExecutor() （单个后台线程），它们均为大多数使用场景预定义了设置。否则，在手动配置和调整此类时，使用以下指导：

核心和最大池大小

ThreadPoolExecutor 将根据 corePoolSize （参见 getCorePoolSize() ）和 maximumPoolSize （参见 getMaximumPoolSize() ）设置的边界自动调整池大小。当新任务在方法 execute(java.lang.Runnable) 中提交时，如果运行的线程少于 corePoolSize ，则创建新线程来处理请求，即使其他辅助线程是空闲的。如果运行的线程多于 corePoolSize 而少于 maximumPoolSize ，则仅当队列满时才创建新线程。如果设置的 corePoolSize 和 maximumPoolSize 相同，则创建了固定大小的线程池。如果将 maximumPoolSize 设置为基本的无界值（如 Integer.MAX_VALUE ），则允许池适应任意数量的并发任务。在大多数情况下，核心和最大池大小仅基于构造来设置，不过也可以使用 setCorePoolSize(int) 和 setMaximumPoolSize(int) 进行动态更改。

按需构造

默认情况下，即使核心线程最初只是在新任务需要时才创建和启动的，也可以使用方法 prestartCoreThread() 或 prestartAllCoreThreads() 对其进行动态重写。

创建新线程

使用 ThreadFactory 创建新线程。如果没有另外说明，则在同一个 ThreadGroup 中一律使用 Executors.defaultThreadFactory() 创建线程，并且这些线程具有相同的 NORM_PRIORITY 优先级和非守护进程状态。通过提供不同的 ThreadFactory ，可以改变线程的名称、线程组、优先级、守护进程状态，等等。如果从 newThread 返回 null 时 ThreadFactory 未能创建线程，则执行程序将继续运行，但不能执行任何任务。

保持活动时间

如果池中当前有多于 corePoolSize 的线程，则这些多出的线程在空闲时间超过 keepAliveTime 时将会终止（参见 getKeepAliveTime(java.util.concurrent.TimeUnit) ）。这提供了当池处于非活动状态时减少资源消耗的方法。如果池后来变得更为活动，则可以创建新的线程。也可以使用方法 setKeepAliveTime(long, java.util.concurrent.TimeUnit) 动态地更改此参数。使用 Long.MAX_VALUE TimeUnit.NANOSECONDS 的值在关闭前有效地从以前的终止状态禁用空闲线程。

排队

所有 BlockingQueue 都可用于传输和保持提交的任务。可以使用此队列与池大小进行交互：

A.         如果运行的线程少于 corePoolSize ，则 Executor 始终首选添加新的线程，而不进行排队。

B.         如果运行的线程等于或多于 corePoolSize ，则 Executor 始终首选将请求加入队列，而不添加新的线程。

C.         如果无法将请求加入队列，则创建新的线程，除非创建此线程超出 maximumPoolSize ，在这种情况下，任务将被拒绝。

排队有三种通用策略：

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

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

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

被拒绝的任务

当 Executor 已经关闭，并且 Executor 将有限边界用于最大线程和工作队列容量，且已经饱和时，在方法 execute(java.lang.Runnable) 中提交的新任务将被拒绝。在以上两种情况下，execute 方法都将调用其 RejectedExecutionHandler 的 RejectedExecutionHandler.rejectedExecution(java.lang.Runnable, java.util.concurrent.ThreadPoolExecutor) 方法。下面提供了四种预定义的处理程序策略：

A.         在默认的 ThreadPoolExecutor.AbortPolicy 中，处理程序遭到拒绝将抛出运行时 RejectedExecutionException 。

B.         在 ThreadPoolExecutor.CallerRunsPolicy 中，线程调用运行该任务的 execute 本身。此策略提供简单的反馈控制机制，能够减缓新任务的提交速度。

C.         在 ThreadPoolExecutor.DiscardPolicy 中，不能执行的任务将被删除。

D.         在 ThreadPoolExecutor.DiscardOldestPolicy 中，如果执行程序尚未关闭，则位于工作队列头部的任务将被删除，然后重试执行程序（如果再次失败，则重复此过程）。

定义和使用其他种类的 RejectedExecutionHandler 类也是可能的，但这样做需要非常小心，尤其是当策略仅用于特定容量或排队策略时。

挂钩方法

此类提供 protected 可重写的 beforeExecute(java.lang.Thread, java.lang.Runnable) 和 afterExecute(java.lang.Runnable, java.lang.Throwable) 方法，这两种方法分别在执行每个任务之前和之后调用。它们可用于操纵执行环境；例如，重新初始化 ThreadLocal 、搜集统计信息或添加日志条目。此外，还可以重写方法 terminated() 来执行 Executor 完全终止后需要完成的所有特殊处理。

如果挂钩或回调方法抛出异常，则内部辅助线程将依次失败并突然终止。

队列维护

方法 getQueue() 允许出于监控和调试目的而访问工作队列。强烈反对出于其他任何目的而使用此方法。 remove(java.lang.Runnable) 和 purge() 这两种方法可用于在取消大量已排队任务时帮助进行存储回收。

一、例子

创建 TestThreadPool 类：

view plain copy to clipboard print ?

import java.util.concurrent.ArrayBlockingQueue;
import java.util.concurrent.ThreadPoolExecutor;
import java.util.concurrent.TimeUnit;

public class TestThreadPool {

    private static int produceTaskSleepTime = 2 ;

    private static int produceTaskMaxNumber = 10 ;

    public static void main(String[] args) {

        // 构造一个线程池
        ThreadPoolExecutor threadPool = new ThreadPoolExecutor( 2 , 4 , 3 ,
                TimeUnit.SECONDS, new ArrayBlockingQueue<Runnable>( 3 ),
                new ThreadPoolExecutor.DiscardOldestPolicy());

        for ( int i = 1 ; i <= produceTaskMaxNumber; i++) {
            try {
                String task = "task@ " + i;
                System.out.println("创建任务并提交到线程池中：" + task);
                threadPool.execute(new ThreadPoolTask(task));

                Thread.sleep(produceTaskSleepTime);
            } catch (Exception e) {
                e.printStackTrace();
            }
        }
    }
}

view plain copy to clipboard print ?

import java.util.concurrent.ArrayBlockingQueue;
import java.util.concurrent.ThreadPoolExecutor;
import java.util.concurrent.TimeUnit;

public class TestThreadPool {

    private static int produceTaskSleepTime = 2 ;

    private static int produceTaskMaxNumber = 10 ;

    public static void main(String[] args) {

        // 构造一个线程池
        ThreadPoolExecutor threadPool = new ThreadPoolExecutor( 2 , 4 , 3 ,
                TimeUnit.SECONDS, new ArrayBlockingQueue<Runnable>( 3 ),
                new ThreadPoolExecutor.DiscardOldestPolicy());

        for ( int i = 1 ; i <= produceTaskMaxNumber; i++) {
            try {
                String task = "task@ " + i;
                System.out.println("创建任务并提交到线程池中：" + task);
                threadPool.execute(new ThreadPoolTask(task));

                Thread.sleep(produceTaskSleepTime);
            } catch (Exception e) {
                e.printStackTrace();
            }
        }
    }
}

import java.util.concurrent.ArrayBlockingQueue; import java.util.concurrent.ThreadPoolExecutor; import java.util.concurrent.TimeUnit; public class TestThreadPool { private static int produceTaskSleepTime = 2; private static int produceTaskMaxNumber = 10; public static void main(String[] args) { // 构造一个线程池 ThreadPoolExecutor threadPool = new ThreadPoolExecutor(2, 4, 3, TimeUnit.SECONDS, new ArrayBlockingQueue<Runnable>(3), new ThreadPoolExecutor.DiscardOldestPolicy()); for (int i = 1; i <= produceTaskMaxNumber; i++) { try { String task = "task@ " + i; System.out.println("创建任务并提交到线程池中：" + task); threadPool.execute(new ThreadPoolTask(task)); Thread.sleep(produceTaskSleepTime); } catch (Exception e) { e.printStackTrace(); } } } }

创建 ThreadPoolTask 类：

view plain copy to clipboard print ?

import java.io.Serializable;

public class ThreadPoolTask implements Runnable, Serializable {

    private Object attachData;

    ThreadPoolTask(Object tasks) {
        this .attachData = tasks;
    }

    public void run() {

        System.out.println("开始执行任务：" + attachData);

        attachData = null ;
    }

    public Object getTask() {
        return this .attachData;
    }
}

view plain copy to clipboard print ?

import java.io.Serializable;

public class ThreadPoolTask implements Runnable, Serializable {

    private Object attachData;

    ThreadPoolTask(Object tasks) {
        this .attachData = tasks;
    }

    public void run() {

        System.out.println("开始执行任务：" + attachData);

        attachData = null ;
    }

    public Object getTask() {
        return this .attachData;
    }
}

import java.io.Serializable; public class ThreadPoolTask implements Runnable, Serializable { private Object attachData; ThreadPoolTask(Object tasks) { this.attachData = tasks; } public void run() { System.out.println("开始执行任务：" + attachData); attachData = null; } public Object getTask() { return this.attachData; } }

执行结果：

                创建任务并提交到线程池中： task@ 1

开始执行任务： task@ 1

创建任务并提交到线程池中： task@ 2

开始执行任务： task@ 2

创建任务并提交到线程池中： task@ 3

创建任务并提交到线程池中： task@ 4

开始执行任务： task@ 3

创建任务并提交到线程池中： task@ 5

开始执行任务： task@ 4

创建任务并提交到线程池中： task@ 6

创建任务并提交到线程池中： task@ 7

创建任务并提交到线程池中： task@ 8

开始执行任务： task@ 5

开始执行任务： task@ 6

创建任务并提交到线程池中： task@ 9

开始执行任务： task@ 7

创建任务并提交到线程池中： task@ 10

开始执行任务： task@ 8

开始执行任务： task@ 9

开始执行任务： task@ 10

ThreadPoolExecutor配置

< type="text/javascript"> < type="text/javascript">

一、ThreadPoolExcutor为一些Executor提供了基本的实现，这些Executor是由Executors中的工厂 newCahceThreadPool、newFixedThreadPool和newScheduledThreadExecutor返回的。 ThreadPoolExecutor是一个灵活的健壮的池实现，允许各种各样的用户定制。

二、线程的创建与销毁

1、核心池大小、最大池大小和存活时间共同管理着线程的创建与销毁。

2、核心池的大小是目标的大小；线程池的实现试图维护池的大小；即使没有任务执行，池的大小也等于核心池的大小，并直到工作队列充满前，池都不会创建更多的线程。如果当前池的大小超过了核心池的大小，线程池就会终止它。

3、最大池的大小是可同时活动的线程数的上限。

4、如果一个线程已经闲置的时间超过了存活时间，它将成为一个被回收的候选者。

5、newFixedThreadPool工厂为请求的池设置了核心池的大小和最大池的大小，而且池永远不会超时

6、newCacheThreadPool工厂将最大池的大小设置为Integer.MAX_VALUE，核心池的大小设置为0，超时设置为一分钟。这样创建了无限扩大的线程池，会在需求量减少的情况下减少线程数量。

三、管理

1、 ThreadPoolExecutor允许你提供一个BlockingQueue来持有等待执行的任务。任务排队有3种基本方法：无限队列、有限队列和同步移交。

2、 newFixedThreadPool和newSingleThreadExectuor默认使用的是一个无限的 LinkedBlockingQueue。如果所有的工作者线程都处于忙碌状态，任务会在队列中等候。如果任务持续快速到达，超过了它们被执行的速度，队列也会无限制地增加。稳妥的策略是使用有限队列，比如ArrayBlockingQueue或有限的LinkedBlockingQueue以及 PriorityBlockingQueue。

3、对于庞大或无限的池，可以使用SynchronousQueue，完全绕开队列，直接将任务由生产者交给工作者线程

4、可以使用PriorityBlockingQueue通过优先级安排任务

JAVA线程池(ThreadPoolExecutor)源码分析

首先,JAVA 中使用ThreadPoolExecutor的常用方式：
实例代码1

Java代码

Runnable runnable = new CountService(intArr);
ThreadPoolExecutor execute = (ThreadPoolExecutor)Executors.newFixedThreadPool(10 );
//或者使用：ThreadPoolExecutor execute = (ThreadPoolExecutor)Executors.newCachedThreadPool();
execute.submit(runnable);

Runnable runnable = new CountService(intArr);
       ThreadPoolExecutor execute = (ThreadPoolExecutor)Executors.newFixedThreadPool(10);
       //或者使用：ThreadPoolExecutor execute = (ThreadPoolExecutor)Executors.newCachedThreadPool();
       execute.submit(runnable);

    在分析ThreadPoolExecutor源码前，先了解下面两个概念：
     1.核心线程(任务)：我们定义的线程，即实现了Runnable接口的类，是我们将要放到线程池中执行的类，如实例代码中的CountService类
     2.工作线程：由线程池中创建的线程，是用来获得核心线程并执行核心线程的线程（比较拗口哦,具体看代码就知道是什么东东了）。

    Executors是一个线程池工厂，各种类型的线程池都是通过它来创建的，注意把它和Executor分开，感觉这个线程池工厂命名有点问题。
    我们主要分析下我们提交任务的处理逻辑，即’execute.submit(runnable)’的实现。
Submit()方法是在ThreadPoolExecutor继承的抽象类AbstractExecutorService中实现的，具体代码如下：

Java代码

public Future<?> submit(Runnable task) {
if (task == null ) throw new NullPointerException();
//对核心线程的一个包装，RunnableFuture还是一个Runnable
RunnableFuture<Object> ftask = newTaskFor(task, null );
//核心线程执行逻辑
execute(ftask);
return ftask;
}

public Future<?> submit(Runnable task) {
        if (task == null) throw new NullPointerException();
       //对核心线程的一个包装，RunnableFuture还是一个Runnable
        RunnableFuture<Object> ftask = newTaskFor(task, null);
       //核心线程执行逻辑
        execute(ftask);
        return ftask;
    }

    从代码中可以看出，线程的执行逻辑通过execute()完成，而 execute是在AbstractExecutorService的子类ThreadPoolExecutor中实现的。看，一个典型的模板模式！废话少说，下面看ThreadPoolExecutor中execute()方法中代码：

Java代码

public void execute(Runnable command) {
if (command == null )
throw new NullPointerException();
/*
* command线程运行的整个逻辑在 addIfUnderCorePoolSize(command)方法中实现
* 一般适用于FixedThreadPool
*/
if (poolSize >= corePoolSize || !addIfUnderCorePoolSize(command)) {
/*
* poolSize >= corePoolSize条件成立情景：当创建的为CacheThreadPool时,条件
* 就能成立
*/
if (runState == RUNNING && workQueue.offer(command)) {
if (runState != RUNNING || poolSize == 0 )
//两种情况下执行该方法:1.线程池shutdown 2.CacheThreadPool中第一个核心线程的执行
ensureQueuedTaskHandled(command);
}
//CacheThreadPool中线程的执行逻辑
else if (!addIfUnderMaximumPoolSize(command))
reject(command); // is shutdown or saturated
}
}

public void execute(Runnable command) {
        if (command == null)
            throw new NullPointerException();
        /*
         * command线程运行的整个逻辑在 addIfUnderCorePoolSize(command)方法中实现
         * 一般适用于FixedThreadPool
         */
        if (poolSize >= corePoolSize || !addIfUnderCorePoolSize(command)) {
        	/*
        	 * poolSize >= corePoolSize条件成立情景：当创建的为CacheThreadPool时,条件
        	 * 就能成立
        	 */
            if (runState == RUNNING && workQueue.offer(command)) {
                if (runState != RUNNING || poolSize == 0)
                	//两种情况下执行该方法:1.线程池shutdown  2.CacheThreadPool中第一个核心线程的执行
                    ensureQueuedTaskHandled(command);
            }
            //CacheThreadPool中线程的执行逻辑
            else if (!addIfUnderMaximumPoolSize(command))
                reject(command); // is shutdown or saturated
        }
    }

注意：CachedThreadPool和 FixedThreadPool的逻辑实现都是在ThreadPoolExecutor中实现的。它两的主要区别就是属性corePoolSize以及 workQueue的初始值的不同。具体可自己查看工程类Executors的newFixedThreadPool()和 newCachedThreadPool方法。由于这些初始值的不同，所以实现的逻辑也不同，具体的我在代码中已经注释了。
command线程运行的整个逻辑在 addIfUnderCorePoolSize(command)方法中实现的，
详细请看addIfUnderCorePoolSize(command)源码：

Java代码

private boolean addIfUnderCorePoolSize(Runnable firstTask) {
Thread t = null ;
final ReentrantLock mainLock = this .mainLock;
mainLock.lock();
try {
//poolSize < corePoolSize 即当前工作线程的数量一定要小于你设置的线程最大数量
//CachedThreadPool永远也不会进入该方法，因为它的corePoolSize初始为0
if (poolSize < corePoolSize && runState == RUNNING)
t = addThread(firstTask);
} finally {
mainLock.unlock();
}
if (t == null )
return false ;
t.start(); //线程执行了
return true ;
}

 private boolean addIfUnderCorePoolSize(Runnable firstTask) {
        Thread t = null;
        final ReentrantLock mainLock = this.mainLock;
        mainLock.lock();
        try {
        	//poolSize < corePoolSize 即当前工作线程的数量一定要小于你设置的线程最大数量
        	//CachedThreadPool永远也不会进入该方法，因为它的corePoolSize初始为0
            if (poolSize < corePoolSize && runState == RUNNING)
                t = addThread(firstTask);
        } finally {
            mainLock.unlock();
        }
        if (t == null)
            return false;
        t.start();   //线程执行了
        return true;
    }

看’t.start()’，这表示工作线程启动了，工作线程t启动的前提条件是’t = addThread(firstTask); ‘返回值t必须不为null。好了，现在想看看java线程池中工作线程是怎么样的吗？请看addThread方法：

Java代码

private Thread addThread(Runnable firstTask) {
//Worker就是典型的工作线程,所以的核心线程都在工作线程中执行
Worker w = new Worker(firstTask);
//采用默认的线程工厂生产出一线程。注意就是设置一些线程的默认属性，如优先级、是否为后台线程等
Thread t = threadFactory.newThread(w);
if (t != null ) {
w.thread = t;
workers.add(w);
//没生成一个工作线程 poolSize加1，但poolSize等于最大线程数corePoolSize时，则不能再生成工作线程
int nt = ++poolSize;
if (nt > largestPoolSize)
largestPoolSize = nt;
}
return t;
}

 private Thread addThread(Runnable firstTask) {
    	//Worker就是典型的工作线程,所以的核心线程都在工作线程中执行
        Worker w = new Worker(firstTask);
        //采用默认的线程工厂生产出一线程。注意就是设置一些线程的默认属性，如优先级、是否为后台线程等
        Thread t = threadFactory.newThread(w); 
        if (t != null) {
            w.thread = t;
            workers.add(w);
          //没生成一个工作线程 poolSize加1，但poolSize等于最大线程数corePoolSize时，则不能再生成工作线程
            int nt = ++poolSize;  
            if (nt > largestPoolSize)
                largestPoolSize = nt;
        }
        return t;
    }

看见没，Worker就是工作线程类，它是ThreadPoolExecutor中的一个内部类。下面，我们主要分析Worker类，如了解了 Worker类，那基本就了解了java线程池的整个原理了。不用怕，Worker类的逻辑很简单，它其实就是一个线程，实现了Runnable接口的，所以，我们先从run方法入手，run方法源码如下：

Java代码

public void run() {
try {
Runnable task = firstTask;
firstTask = null ;
/**
* 注意这段while循环的执行逻辑,没执行完一个核心线程后,就会去线程池
* 队列中取下一个核心线程,如取出的核心线程为null,则当前工作线程终止
*/
while (task != null || (task = getTask()) != null ) {
runTask(task); //你所提交的核心线程(任务)的运行逻辑
task = null ;
}
} finally {
workerDone(this ); // 当前工作线程退出
}
}
}

public void run() {
            try {
                Runnable task = firstTask;
                firstTask = null;
                /**
                 * 注意这段while循环的执行逻辑,没执行完一个核心线程后,就会去线程池
                 * 队列中取下一个核心线程,如取出的核心线程为null,则当前工作线程终止
                 */
                while (task != null || (task = getTask()) != null) {
                    runTask(task);  //你所提交的核心线程(任务)的运行逻辑
                    task = null;
                }
            } finally {
                workerDone(this); // 当前工作线程退出
            }
        }
    }

从源码中可看出，我们所提交的核心线程(任务)的逻辑是在 Worker中的runTask()方法中实现的。这个方法很简单，自己可以打开看看。这里要注意一点，在runTask()方法中执行核心线程时是调用核心线程的run()方法，这是一个寻常方法的调用，千万别与线程的启动(start())混合了。这里还有一个比较重要的方法，那就是上述代码中 while循环中的getTask()方法，它是一个从池队列中取的核心线程（任务）的方法。具体代码如下：

Java代码

Runnable getTask() {
for (;;) {
try {
int state = runState;
if (state > SHUTDOWN)
return null ;
Runnable r;
if (state == SHUTDOWN) //帮助清空队列
r = workQueue.poll();
/*
* 对于条件1，如果可以超时，则在等待keepAliveTime时间后，则返回一null对象,这时就
* 销毁该工作线程，这就是CachedThreadPool为什么能回收空闲线程的原因了。
* 注意以下几点:1.这种功能情况一般不可能在fixedThreadPool中出现
* 2.在使用CachedThreadPool时，条件1一般总是成立,因为CachedThreadPool的corePoolSize
* 初始为0
*/
else if (poolSize > corePoolSize || allowCoreThreadTimeOut) //------------------条件1
r = workQueue.poll(keepAliveTime, TimeUnit.NANOSECONDS);
else
r = workQueue.take(); //如果队列不存在任何元素则一直等待。 FiexedThreadPool典型模式----------条件2
if (r != null )
return r;
if (workerCanExit()) { //--------------------------条件3
if (runState >= SHUTDOWN) // Wake up others
interruptIdleWorkers();
return null ;
}
// Else retry
} catch (InterruptedException ie) {
// On interruption, re-check runState
}
}
}

Runnable getTask() {
        for (;;) {
            try {
                int state = runState;
                if (state > SHUTDOWN)  
                    return null;
                Runnable r;
                if (state == SHUTDOWN)  //帮助清空队列
                    r = workQueue.poll();
               /*
                * 对于条件1，如果可以超时，则在等待keepAliveTime时间后，则返回一null对象,这时就
                *  销毁该工作线程，这就是CachedThreadPool为什么能回收空闲线程的原因了。
                * 注意以下几点:1.这种功能情况一般不可能在fixedThreadPool中出现
                *            2.在使用CachedThreadPool时，条件1一般总是成立,因为CachedThreadPool的corePoolSize
                *              初始为0
                */
                else if (poolSize > corePoolSize || allowCoreThreadTimeOut)  //------------------条件1
                    r = workQueue.poll(keepAliveTime, TimeUnit.NANOSECONDS);  
                else
                    r = workQueue.take();       //如果队列不存在任何元素 则一直等待。 FiexedThreadPool典型模式----------条件2
                if (r != null)
                    return r;
                if (workerCanExit()) {       //--------------------------条件3
                    if (runState >= SHUTDOWN) // Wake up others
                        interruptIdleWorkers();
                    return null;
                }
                // Else retry
            } catch (InterruptedException ie) {
                // On interruption, re-check runState
            }
        }
    }

    从这个方法中，我们需要了解一下几点：
    1.CachedThreadPool获得任务逻辑是条件1 ，条件1的处理逻辑请看注释，CachedThreadPool执行条件1的原因是：CachedThreadPool的corePoolSize时刻为0。

    2.FixedThreadPool执行的逻辑为条件2 ,从’workQueue.take()’中我们就明白了为什么FixedThreadPool不会释放工作线程的原因了(除非你关闭线程池)。

    最后，我们了解下Worker(工作线程)终止时的处理吧，这个对理解CachedThreadPool有帮助，具体代码如下：

Java代码

/**
* 工作线程退出要处理的逻辑
* @param w
*/
void workerDone(Worker w) {
final ReentrantLock mainLock = this .mainLock;
mainLock.lock();
try {
completedTaskCount += w.completedTasks;
workers.remove(w); //从工作线程缓存中删除
if (--poolSize == 0 ) //poolSize减一,这时其实又可以创建工作线程了
tryTerminate(); //尝试终止
} finally {
mainLock.unlock();
}
}

 /**
     * 工作线程退出要处理的逻辑
     * @param w
     */
    void workerDone(Worker w) {
        final ReentrantLock mainLock = this.mainLock;
        mainLock.lock();
        try {
            completedTaskCount += w.completedTasks; 
            workers.remove(w);  //从工作线程缓存中删除
            if (--poolSize == 0) //poolSize减一,这时其实又可以创建工作线程了
                tryTerminate(); //尝试终止
        } finally {
            mainLock.unlock();
        }
    }

注意workDone()方法中的tyrTerminate()方法，它是你以后理解线程池中shuDown()以及CachedThreadPool原理的关键，具体代码如下：

Java代码

private void tryTerminate() {
//终止的前提条件就是线程池里已经没有工作线程(Worker)了
if (poolSize == 0 ) {
int state = runState;
/**
* 如果当前已经没有了工作线程(Worker),但是线程队列里还有等待的线程任务,则创建一个
* 工作线程来执行线程队列中等待的任务
*/
if (state < STOP && !workQueue.isEmpty()) {
state = RUNNING; // disable termination check below
Thread t = addThread(null );
if (t != null )
t.start();
}
//设置池状态为终止状态
if (state == STOP || state == SHUTDOWN) {
runState = TERMINATED;
termination.signalAll();
terminated();
}
}
}

 private void tryTerminate() {
    	//终止的前提条件就是线程池里已经没有工作线程(Worker)了
        if (poolSize == 0) {
            int state = runState;
            /**
             * 如果当前已经没有了工作线程(Worker),但是线程队列里还有等待的线程任务,则创建一个
             * 工作线程来执行线程队列中等待的任务
             */
            if (state < STOP && !workQueue.isEmpty()) {    
                state = RUNNING; // disable termination check below
                Thread t = addThread(null);
                if (t != null)
                    t.start();
            }
            //设置池状态为终止状态
            if (state == STOP || state == SHUTDOWN) {
                runState = TERMINATED;
                termination.signalAll(); 
                terminated(); 
            }
        }
    }