多线程程序在较低的层次上扩展了多任务的概念：一个程序同时执行多个任务。通常， 每一个任务称为一个线程（thread), 它是线程控制的简称。可以同时运行一个以上线程的程序称为多线程程序（multithreaded)。 多进程与多线程有哪些区别呢？ 本质的区别在于每个进程拥有自己的一整套变量， 而线程则共享数据（有风险）。然而，共享变量使线程之间的通信比进程之间的通信更有效、更容易。此外， 在有 些操作系统中，与进程相比较， 线程更“ 轻量级”， 创建、撤销一个线程比启动新进程的开销要小得多。 在实际应用中， 多线程非常有用。例如， 一个浏览器可以同时下载几幅图片。一个 Web 服务器需要同时处理几个并发的请求。
●使用多线程，让球在弹跳的同时，也能接收stop指令，终止弹跳。 ●下面是在一个单独的线程中执行一个任务的简单过程： 1 ) 将任务代码移到实现了 Runnable 接口的类的 run方法中。这个接口非常简单，只有 一个方法： public interface Runnable { void run()； } 由于 Runnable 是一个函数式接口，可以用 lambda 表达式建立一个实例： Runnable r = () -> { taskcode}; 2 ) 由 Runnable 创建一个 Thread 对象： Thread t = new Thread®; 3 ) 启动线程： t.start()； ●要想将弹跳球代码放在一个独立的线程中， 只需要实现一个类 BallRunnable， 然后，将动画代码放在run方法中，如同下面这段代码： Runnable r = () -> { try { for (int i = 1 ; i <=STEPS; i++) { ball.move(comp.getBounds()); comp.repaint(); Thread.sleep(DELAY); } } catch (InterruptedException e) { } } ； Thread t = new Thread®; t.startO； 需要捕获 sleep方法可能抛出的异常 InterruptedException。在 一般情况下, 线程在中断时被终止。因此，当发生 InterruptedException异常时， run方法将结束执行. ●也可以通过构建一个 Thread 类的子类定义一个线程 class MyThread extends Thread { public void run() { taskcode } } 然后， 构造一个子类的对象， 并调用 start 方法。 不过， 这种方法已不再推荐。应该将要并行运行的任务与运行机制解耦合。如果有很多任务， 要为每个任务创建一个独立的线程所付出的代价太大了。可以使用线程池来解决这个问题， 有关内容请参看第 10.9 节。 ● 不要调用 Thread 类或 Runnable 对象的 run 方法。直接调用 run 方法， 只会执行同 一个线程中的任务， 而不会启动新线程。应该调用 Thread.start 方法。这个方法将创建一个执行 run 方法的新线程。
●当线程的 run 方法执行方法体中最后一条语句后， 并经由执行 return 语句返冋时， 或者出现了在方法中没有捕获的异常时，线程将终止。在 Java 的早期版本中， 还有一个 stop方法， 其他线程可以调用它终止线程（已弃用） ●没有可以强制线程终止的方法。然而，interrupt 方法可以用来请求终止线程。 当对一个线程调用 interrupt 方法时，线程的中断状态将被置位。这是每一个线程都具有的 boolean 标志。每个线程都应该不时地检査这个标志， 以判断线程是否被中断。 ●要想弄清中断状态是否被置位，首先调用静态的 Thread.currentThread方法获得当前线程，然后调用 islnterrupted方法。但是， 如果线程被阻塞， 就无法检测中断状态。这是产生 InterruptedException 异常的地 方。当在一个被阻塞的线程（调用 sleep 或 wait) 上调用 interrupt方法时，阻塞调用将会被 InterruptedException 异常中断。（存在不能被中断的阻塞 I/O 调用， 应该考虑选择可中断的调用。有关细节请参看卷2的第 1 章和第 3 章 ）
没有任何语言方面的需求要求一个被中断的线程应该终止。中断一个线程不过是引起它的注意。被中断的线程可以决定如何响应中断。某些线程是如此重要以至于应该处理完异常后， 继续执行，而不理会中断。但是，更普遍的情况是，线程将简单地将中断作为一个终止的请求
如果在每次工作迭代之后都调用 sleep方法（或者其他的可中断方法)，islnterrupted 检测既没有必要也没有用处。如果在中断状态被置位时调用 sleep方法，它不会休眠。相反，它 将清除这一状态（!）并拋出 InterruptedException。 ●方法比较
interrupt 方法：向线程发送中断请求。线程的中断状态将被设置为 true。如果目前该线程被一个 sleep 调用阻塞，那么，InterruptedException 异常被抛出。interrupted 方法：是一个静态方法， 测试当前线程（即正在执行这一命令的线程）是否被中断。注意， 这一调用会产生副作用— —它将当前线程的中断状态重置为 false，可用于清除中断状态。islnterrupted方法：是一个实例方法， 返回目标线程的中断状态。可用来检验是否有线程被中断。调用这个方法不会改变中断状态。●不要将 InterruptedException 异常抑制在很低的层次上，如果不认为在 catch 子句中做这一处理有什么好处的话，仍然有两种合理的选择： ①在 catch 子句中调用 Thread.currentThread().interrupt() 来设置中断状态。这样，调用者可以对其进行检测。 ②或者，更好的选择是，throws InterruptedException，调用者（或者，最终的 run 方法）可以捕获这一异常。
线程可以有如下 6 种状态： •New (新创建） •Runnable (可运行） •Blocked (被阻塞） •Waiting (等待） •Timed waiting (计时等待） •Terminated (被终止） 要确定一个线程的当前状态， 可调用 getState 方法。
当用 new 操作符创建一个新线程时，如 newThread®，该线程还没有开始运行。它的状态是 new。当一个线程处于新创建状态时，程序还没有开始运行线程中的代码。在线程运行之前还有一些基础工作要做。
●可运行线程 一旦调用 start 方法，线程处于 runnable 状态。一个可运行的线程可能正在运行也可能没有运行， 这取决于操作系统给线程提供运行的时间。（这是为什么将这个状态称为可运行而不是运行)。
一旦一个线程开始运行，它不必始终保持运行。事实上，运行中的线程被中断，目的是为了让其他线程获得运行机会。线程调度的细节依赖于操作系统提供的服务。抢占式调度系统给每一个可运行线程一个时间片来执行任务。当时间片用完，操作系统剥夺该线程的运行权， 并给另一个线程运行机会。当选择下一个线程时， 操作系统考虑线程的优先级。
现在所有的桌面以及服务器操作系统都使用抢占式调度。但是，像手机这样的小型设备可能使用协作式调度在，这样的设备中，一个线程只有在调用 yield方法、或者被阻塞或等待时，线程才失去控制权。 在具有多个处理器的机器上，每一个处理器运行一个线程， 可以有多个线程并行运行。 当然，如果线程的数目多于处理器的数目， 调度器依然采用时间片机制。
当线程处于被阻塞或等待状态时，它暂时不活动。它不运行任何代码且消耗最少的资源。直到线程调度器重新激活它。
●当一个线程试图获取一个内部的对象锁（而不是java.util.Concurrent 库中的锁)，而该锁被其他线程持有， 则该线程进人阻塞状态。当所有其他线程释放该锁，并且线程调度器允许本线程持有它的时候，该线程将变成非阻塞状态。 ●当线程等待另一个线程通知调度器一个条件时，它自己进入等待状态。在调用Object.wait方法或 Thread.join方法， 或者是等待 java, util.concurrent 库中的 Lock 或 Condition 时， 就会出现这种情况。实际上，被阻塞状态与等待状态是有很大不同的。 ●有几个方法有一个超时参数。调用它们导致线程进人计时等待（timed waiting) 状态。这一状态将一直保持到超时期满或者接收到适当的通知。带有超时参数的方法有 Thread.sleep 和 Object.wait、Thread.join、Lock,tryLock 以及 Condition.await 的计时版。 上图展示了线程可以具有的状态以及从一个状态到另一个状态可能的转换。当一个线程被阻塞或等待时（或终止时)，另一个线程被调度为运行状态。当一个线程被重新激活（例如， 因为超时期满或成功地获得了一个锁)，调度器检查它是否具有比当前运行线程更高的优先级。如果是这样，调度器从当前运行线程中挑选一个， 剥夺其运行权，选择一个新的线程运行。
线程因如下两个原因之一而被终止： •因为run方法正常退出而自然死亡。 •因为一个没有捕获的异常终止了 run方法而意外死亡。
下面将讨论线程的各种属性，其中包括：线程优先级、守护线程、线程组以及处理未捕获异常的处理器。
●在 Java 程序设计语言中，每一个线程有一个优先级。默认情况下，一个线程继承它的父线程的优先级。可以用 setPriority 方法提高或降低任何一个线程的优先级。可以将优先级设置为在 MIN_PRIORITY (在Thread类中定义为 1 ) 与 MAX_PRIORITY (定义为10 ) 之间的任何值。NORM_PRIORITY 被定义为 5。 ● 不要将程序构建为功能的正确性依赖于优先级 每当线程调度器有机会选择新线程时， 它首先选择具有较高优先级的线程。但是，线程优先级是高度依赖于系统的。当虚拟机依赖于宿主机平台的线程实现机制时， Java 线程的优先级被映射到宿主机平台的优先级上，优先级个数也许更多，也许更少。 例如，Windows 有 7 个优先级别。一些 Java 优先级将映射到相同的操作系统优先级。在 Oracle 为 Linux 提供的 Java 虚拟机中，线程的优先级被忽略——所有线程具有相同的优先级。 初级程序员常常过度使用线程优先级。
如果确实要使用优先级， 应该避免初学者常犯的一个错误。如果有几个高优先级的线程没有进入非活动状态， 低优先级的线程可能永远也不能执行。每当调度器决定运行一个新线程时，首先会在具有高优先级的线程中进行选择， 尽管这样会使低优先级的线程完全饿死。
可以通过调用 t.setDaemon(true); 将线程转换为守护线程（daemon thread)。 守护线程的唯一用途是为其他线程提供服务。计时线程就是一个例子，它定时地发送“ 计时器嘀嗒” 信号给其他线程或清空过时的高速缓存项的线程。 当只剩下守护线程时， 虚拟机就退出了。 守护线程有时会被初学者错误地使用， 他们不打算考虑关机（shutdown) 动作。但是， 这是很危险的。守护线程应该永远不去访问固有资源， 如文件、 数据库，因为它会在任何时候甚至在一个操作的中间发生中断。
●线程的 run方法不能抛出任何受查异常（https://blog.csdn.net/qq_26106607/article/details/79145882）。 ●非受査异常会导致线程终止，就在线程死亡之前， 异常被传递到一个用于未捕获异常的处理器。 该处理器必须属于一个实现 Thread.UncaughtExceptionHandler 接口的类。这个接口只有— 个方法： void uncaughtException(Thread t, Throwable e)
可以用 setUncaughtExceptionHandler方法为任何线程安装一个处理器。也可以用 Thread 类的静态方法 setDefaultUncaughtExceptionHandler 为所有线程安装一个默认的处理器。替换处理器可以使用日志 API 发送未捕获异常的报告到日志文件。 如果不安装默认的处理器， 默认的处理器为空。但是， 如果不为独立的线程安装处理器，此时的处理器就是该线程的 ThreadGroup 对象。 ●线程组是一个可以统一管理的线程集合。默认情况下，创建的所有线程属于相同的线程组， 但是， 也可能会建立其他的组。现在引入了更好的特性用于线程集合的操作， 所以建议不要在自己的程序中使用线程组。
ThreadGroup 类实现 Thread.UncaughtExceptionHandler 接口。它的 uncaughtException方法做如下操作： 如果有父线程组， 调用父线程组的这一方法; 或者， 如果 Thread类有默认处理器，调用该处理器， 否则， 输出栈轨迹到标准错误流上（但是， 如果 e 是一个 ThreadDeath 对象， 栈轨迹是被禁用的。ThreadDeath 对象由 stop方法产生，而该方法已经过时)。 参考：https://www.cnblogs.com/jwen1994/p/10632372.html https://blog.csdn.net/weixin_38106322/article/details/107397095
两个或两个以上的线程需要共享对同一数据的存取，如果两个线程存取相同的对象， 并且每一个线程都调用了一个修改该对象状态的方法。这样一个情况通常称为竞争条件（race condition)
为了避免多线程引起的对共享数据的错误，必须学习如何同步存取。 银行账户相互转钱，不控制同步存取，会出现问题
当两个线程试图同时更新同一个账户的时候， 这个问题就出现了。假定两个线程同时执行指令 accounts[to] += amount; 问题在于这不是原子操作。该指令可能被处理如下： 1 ) 将 accounts[to] 加载到寄存器。 2 ) 增加 amount。 3 ) 将结果写回 accounts[to]。 现在，假定第 1 个线程执行步骤 1 和 2, 然后， 它被剥夺了运行权。假定第 2 个线程被唤醒并修改了 accounts 数组中的同一项。然后，第 1 个线程被唤醒并完成其第 3 步。 这样， 这一动作擦去了第二个线程所做的更新。于是， 总金额不再正确，如下图。 真正的问题是 transfer方法的执行过程中可能会被中断。如果能够确保线程在失去控制之前方法运行完成，那么银行账户对象的状态永远不会出现讹误。
有两种机制防止代码块受并发访问的干扰。Java语言提供一个 synchronized关键字达到这一目的，并且 Java SE 5.0引入了 ReentrantLock 类。 ●synchronized 关键字自动提供一个锁以及相关的“ 条件”， 对于大多数需要显式锁的情况， 这是很便利的。 ●用 ReentrantLock 保护代码块的基本结构如下： 这一结构确保任何时刻只有一个线程进人临界区。一旦一个线程封锁了锁对象， 其他任何线程都无法通过 lock语句。当其他线程调用 lock 时，它们被阻塞，直到第一个线程释放锁对象。
●让我们使用一个锁来保护 Bank类的 transfer 方法。假定一个线程调用 transfer, 在执行结束前被剥夺了运行权。假定第二个线程也调用 transfer, 由于第二个线程不能获得锁，将在调用 lock 方法时被阻塞。它必须等待第一个线程完成 transfer 方法的执行之后才能再度被激活。当第一个线程释放锁时， 那么第二个线程才能开始运行 。如下图 ●注意每一个 Bank 对象有自己的 ReentrantLock 对象。如果两个线程试图访问同一个 Bank 对象， 那么锁以串行方式提供服务。但是， 如果两个线程访问不同的 Bank 对象， 每 一个线程得到不同的锁对象， 两个线程都不会发生阻塞。本该如此，因为线程在操纵不同的 Bank 实例的时候，线程之间不会相互影响。 ●锁是可重入的， 因为线程可以重复地获得已经持有的锁。锁保持一个持有计数（hold count) 来跟踪对 lock 方法的嵌套调用。线程在每一次调用 lock 都要调用 unlock 来释放锁。 由于这一特性， 被一个锁保护的代码可以调用另一个使用相同的锁的方法。
例如，transfer 方法调用 getTotalBalance方法， 这也会封锁 bankLock 对象，此时 bankLock 对象的持有计数为 2。当 getTotalBalance方法退出的时候， 持有计数变回 1。当 transfer方法退出的时候， 持有计数变为 0。线程释放锁。 通常， 可能想要保护需若干个操作来更新或检查共享对象的代码块。要确保这些操作完成后， 另一个线程才能使用相同对象。
●通常， 线程进人临界区，却发现在某一条件满足之后它才能执行。要使用一个条件对象来管理那些已经获得了一个锁但是却不能做有用工作的线程。在这一节里， 我们介绍 Java 库中条件对象的实现。（由于历史的原因， 条件对象经常被称为条件变量（conditional variable)）。
●现在来细化银行的模拟程序。我们避免选择没有足够资金的账户作为转出账户。注意不能使用下面这样的代码： if (bank.getBalance(fron) >= amount) // thread night be deactivated at this point bank.transfer(from, to, amount); 必须确保没有其他线程在检査余额与转账活动之间修改余额。通过使用锁来保护检査与转账动作来做到这一点。如下图 现在，当账户中没有足够的余额时， 要等待直到另一个线程向账户中注入了资金。但是，这一线程刚刚获得了对 bankLock 的排它性访问， 因此别的线程没有进行存款操作的机会。这就是为什么我们需要条件对象的原因。
●一个锁对象可以有一个或多个相关的条件对象。你可以用 newCondition 方法获得一个条件对象。习惯上给每一个条件对象命名为可以反映它所表达的条件的名字。 如果transfer方法发现余额不足，它调用 sufficientFunds.await(); 当前线程现在被阻塞了，并放弃了锁，使得另一个线程可以进行增加账户余额的操作。
等待获得锁的线程和调用 await 方法的线程存在本质上的不同。一旦一个线程调用 await 方法，它进入该条件的等待集。当锁可用时，该线程不能马上解除阻塞。相反，它处于阻塞状态，直到另一个线程调用同一条件上的 signalAll 方法时为止。
●当另一个线程转账时， 它应该调用 sufficientFunds.signalAll(); 这一调用重新激活因为这一条件而等待的所有线程。当这些线程从等待集中移出时， 它们再次成为可运行的，调度器将再次激活它们。同时，它们将试图重新进人该对象。一旦锁成为可用的，它们中的某个将从 await 调用返回， 获得该锁并从被阻塞的地方继续执行。 此时， 线程应该再次测试该条件。由于无法确保该条件被满足— —signalAll 方法仅仅是通知正在等待的线程，需要再次去检测该条件。
● 通常， 对 await 的调用应该在如下形式的循环体中 while (!(ok to proceed)) condition.await(); 至关重要的是最终需要某个其他线程调用 signalAll 方法。当一个线程调用 await 时，它没有办法重新激活自身。它寄希望于其他线程。如果没有其他线程来重新激活等待的线程， 它就永远不再运行了。这将导致死锁（deadlock) 现象。如果所有其他线程被阻塞， 最后一个活动线程在解除其他线程的阻塞状态之前就调用 await 方法，那么它也被阻塞。 没有任何线程可以解除其他线程的阻塞，那么该程序就挂起了。
●何时调用 signalAll： 经验上讲， 在对象的状态有利于等待线程的方向改变时调用 signalAll。例如， 当一个账户余额发生改变时，等待的线程会应该有机会检查余额。在例子中， 当完成了转账时， 调用 signalAll 方法。 注意调用 signalAll 不会立即激活一个等待线程。它仅仅解除等待线程的阻塞， 以便这些线程可以在当前线程退出同步方法之后，通过竞争实现对对象的访问。 另一个方法 signal, 则是随机解除等待集中某个线程的阻塞状态。这比解除所有线程的阻塞更加有效，但也存在危险。如果随机选择的线程发现自己仍然不能运行， 那么它再次被阻塞。如果没有其他线程再次调用 signal, 那么系统就死锁了。
●当一个线程拥有某个条件的锁时， 它仅仅可以在该条件上调用 await、signalAll 或 signal 方法。
●在进一步深人之前，总结一下有关锁和条件的关键之处： •锁用来保护代码片段， 任何时刻只能有一个线程执行被保护的代码。 •锁可以管理试图进入被保护代码段的线程。 •锁可以拥有一个或多个相关的条件对象。 •每个条件对象管理那些已经进入被保护的代码段但还不能运行的线程。
●Lock 和 Condition接口为程序设计人员提供了高度的锁定控制。然而， 大多数情况下， 并不需要那样的控制。从 1.0 版开始，Java 中的每一个对象都有一个内部锁。如果一个方法用 synchronized关键字声明，那么对象的锁将保护整个方法。也就是说，要调用该方法，线程必须获得内部的对象锁。 换句话说， 例如， 可以简单地声明 Bank类的 transfer方法为synchronized, 而不是使用一个显式的锁。 内部对象锁只有一个相关条件。wait 方法添加一个线程到等待集中，notifyAll /notify方法解除等待线程的阻塞状态。换句话说，调用 wait 或 notityAll 等价于 intrinsicCondition.await(); intrinsicCondition.signalAIl();
●可以看到， 使用 synchronized关键字来编写代码要简洁得多。你必须了解每一个对象有一个内部锁， 并且该锁有一个内部条件。由锁来管理那些试图进入 synchronized 方法的线程，由条件来管理那些调用 wait 的线程。
●将静态方法声明为synchronized也是合法的。如果调用这种方法，该方法获得相关的类对象的内部锁。例如，如果 Bank类有一个静态同步的方法，那么当该方法被调用时，Bank.class 对象的锁被锁住。因此，没有其他线程可以调用同一个类的这个或任何其他的同步静态方法。 内部锁和条件存在一些局限。包括： •不能中断一个正在试图获得锁的线程。 •试图获得锁时不能设定超时。 •每个锁仅有单一的条件， 可能是不够的。
●在代码中应该使用哪一种？ Lock 和 Condition 对象还是同步方法？下面是一些建议： •最好既不使用 Lock/Condition 也不使用 synchronized 关键字。可以使用java.util.concurrent 包中的一种机制，它会为你处理所有的加锁。 •如果 synchronized 关键字适合你的程序，那么请尽量使用它，这样可以减少编写的代码数量，减少出错的几率。 •如果特别需要 Lock/Condition结构提供的独有特性时，才使用Lock/Condition。 参考： https://blog.csdn.net/xiao__gui/article/details/8188833 https://blog.csdn.net/weixin_34357267/article/details/93208577 https://www.cnblogs.com/codebj/p/10994748.html
●正如刚刚讨论的，每一个 Java 对象有一个锁。线程可以通过调用同步方法获得锁。还有另一种机制可以获得锁，通过进入一个同步阻塞。当线程进入如下形式的阻塞： synchronized (obj) // this is the syntax for a synchronized block { critical section } 于是它获得 obj 的锁。
●有时程序员使用一个对象的锁来实现额外的原子操作， 实际上称为客户端锁定（clientside locking) 。客户端锁定是非常脆弱的，通常不推荐使用。 参考： https://www.cnblogs.com/yaowen/p/5983136.html https://segmentfault.com/q/1010000021724843
●多年来，研究人员努力寻找一种方法，可以在不需要程序员考虑如何加锁的情况下，就可以保证多线程的安全性。最成功的解决方案之一是监视器（monitor), 这一概念最早是由 PerBrinchHansen 和 TonyHoare 在 20世纪 70 年代提出的。用 Java 的术语来讲，监视器具有如下特性： •监视器是只包含私有域的类。 •每个监视器类的对象有一个相关的锁。 •使用该锁对所有的方法进行加锁。换句话说，如果客户端调用 obj.method(), 那么 obj 对象的锁是在方法调用开始时自动获得，并且当方法返回时自动释放该锁。因为所有的域是私有的，这样的安排可以确保一个线程在对对象操作时， 没有其他线程能访问该域。 •该锁可以有任意多个相关条件。
●Java设计者以不是很精确的方式采用了监视器概念， Java 中的每一个对象有一个内部的锁和内部的条件。如果一个方法用 synchronized 关键字声明，那么，它表现的就像是一个监视器方法。通过调用 wait/notifyAll/notify来访问条件变量。 然而， 在下述的 3 个方面 Java 对象不同于监视器， 从而使得线程的安全性下降： •域不要求必须是 private。 •方法不要求必须是 synchronized。 •内部锁对客户是可用的。 参考：https://www.cnblogs.com/keeplearnning/p/7020287.html
●有时，仅仅为了读写一个或两个实例域就使用同步， 显得开销过大了。遗憾的是， 使用现代的处理器与编译器， 不使用同步机制，出错的可能性很大。 •多处理器的计算机能够暂时在寄存器或本地内存缓冲区中保存内存中的值。结果是， 运行在不同处理器上的线程可能在同一个内存位置取到不同的值。 •编译器可以改变指令执行的顺序以使吞吐量最大化。这种顺序上的变化不会改变代码语义，但是编译器假定内存的值仅仅在代码中有显式的修改指令时才会改变。然而， 内存的值可以被另一个线程改变！
●Brian Goetz 给出了下述 “ 同步格言”：“ 如果向一个变量写入值， 而这个变量接下来可能会被另一个线程读取， 或者，从一个变量读值， 而这个变量可能是之前被另一个线程写入的， 此时必须使用同步”。 ●volatile关键字为实例域的同步访问提供了一种免锁机制。如果声明一个域为 volatile, 那么编译器和虚拟机就知道该域是可能被另一个线程并发更新的。
例如， 假定一个对象有一个布尔标记 done, 它的值被一个线程设置却被另一个线程査询，如同我们讨论过的那样，你可以使用锁： 在这种情况下，将域声明为 volatile 是合理的： 但是，要注意，volatile 变量可以提供可见性和有序性，不能提供原子性。不能确保翻转域中的值。不能保证读取、翻转和写入不被中断。 参考：https://www.jianshu.com/p/3a7c7a54ed0b
上一节已经了解到， 除非使用锁或 volatile 修饰符，否则无法从多个线程安全地读取一个域。 还有一种情况可以安全地访问一个共享域， 即这个域声明为 final 时。考虑以下声明： final Map<String, Double〉accounts = new HashKap<>()； 其他线程会在构造函数完成构造之后才看到这个 accounts 变量。 如果不使用 final，就不能保证其他线程看到的是 accounts 更新后的值，它们可能都只是看到 null, 而不是新构造的 HashMap。 当然，对这个映射表的操作并不是线程安全的。如果多个线程在读写这个映射表，仍然需要进行同步。 day36
假设对共享变量除了赋值之外并不完成其他操作，那么可以将这些共享变量声明为 volatile.
●java.util.concurrent.atomic 包中有很多类使用了很高效的机器级指令（而不是使用锁）来保证其他操作的原子性。 例如， Atomiclnteger 类提供了方法 incrementAndGet 和 decrementAndGet, 它们分别以原子方式将一个整数自增或自减。例如，可以安全地生成一个数值序列，如下所示： public static AtomicLong nextNumber = new AtomicLong(); // In some thread… long id = nextNumber.increinentAndGet(); incrementAndGet 方法以原子方式将 AtomicLong 自增， 并返回自增后的值。也就是说， 获得值、增 1 并设置然后生成新值的操作不会中断。
●有很多方法可以以原子方式设置和增减值， 不过， 如果希望完成更复杂的更新，就必须使用 compareAndSet方法。例如， 假设希望跟踪不同线程观察的最大值，应当在一个循环中计算新值和使用compareAndSet: 如果另一个线程也在更新 largest，就可能阻止这个线程更新。这样一来，compareAndSet 会返回 false, 而不会设置新值。在这种情况下，循环会更次尝试，读取更新后的值，并尝试修改。最终， 它会成功地用新值替换原来的值。这听上去有些麻烦， 不过 compareAndSet方法会映射到一个处理器操作， 比使用锁速度更快。
●在 Java SE 8中，不再需要编写这样的循环样板代码。实际上，可以提供一个 lambda 表 达式更新变量，它会为你完成更新。对于这个例子，我们可以调用： largest.updateAndGet(x -> Math.max(x, observed)); 或 largest.accumulateAndGet(observed, Math::max); accumulateAndGet方法利用一个二元操作符来合并原子值和所提供的参数。 还有 getAndUpdate 和 getAndAccumulate 方法可以返回原值。
●如果有大量线程要访问相同的原子值，性能会大幅下降，因为乐观更新需要太多次重试。Java SE 8 提供了 LongAdder 和 LongAccumulator类来解决这个问题。LongAdder包括多 个变量（加数)，其总和为当前值。可以有多个线程更新不同的加数，线程个数增加时会自动提供新的加数。通常情况下， 只有当所有工作都完成之后才需要总和的值， 对于这种情况， 这种方法会很高效。性能会有显著的提升。 参考：https://blog.csdn.net/qq_29373285/article/details/88566435
锁和条件不能解决多线程中的所有问题。考虑下面的情况： 账户 1: $200 账户 2: $300 线程 1: 从账户 1 转移 $300 到账户 2 线程 2: 从账户 2 转移 $400 到账户 1 线程 1 和线程 2 都被阻塞了。因为余额都不足以进行转账，两个线程都无法执行下去。 有可能会因为每一个线程要等待更多的钱款存入而导致所有线程都被阻塞。这样的状态称为死锁（deadlock)。 ●在这个程序里，死锁不会发生， 原因很简单。每一次转账至多 $1000。因为有 100 个账 户，而且所有账户的总金额是 $1000, 在任意时刻， 至少有一个账户的余额髙于 $1 000。 从该账户取钱的线程可以继续运行。 但是， 如果修改 run方法，把每次转账至多 $1 000 的限制去掉，死锁很快就会发生。 ● 当程序挂起时， 键入 CTRL+, 将得到一个所有线程的列表。每一个线程有一个栈踪迹， 告诉你线程被阻塞的位置。 Java 编程语言中没有任何东西可以避免或打破这种死锁现象。必须仔细设计程序，以确保不会出现死锁。
●在线程间共享变量有风险。有时可能要避免共享变量， 使用 ThreadLocal 辅助类为各个线程提供各自的实例。 例如，SimpleDateFormat 类不是线程安全的。 假设有一个静态变量： public static final SimpleDateFormat dateFormat = new SimpleDateForniat(“yyyy-MM-dd”)；
如果两个线程都执行以下操作： String dateStamp = dateFormat.format(new Date()); 结果可能很混乱，因为 dateFormat 使用的内部数据结构可能会被并发的访问所破坏。当 然可以使用同步，但开销很大； 或者也可以在需要时构造一个局部 SimpleDateFormat 对象， 不过这也太浪费了。
要为每个线程构造一个实例，可以使用以下代码： public static final ThreadLocal< SimpleDateFormat> dateFormat = ThreadLocal.withInitial(() -> new SimpleDateFormat(“yyyy-MM-dd”)); 要访问具体的格式化方法，可以调用： String dateStamp = dateFormat.get().format(new Date()); 在一个给定线程中首次调用 get 时， 会调用 initialValue方法。在此之后，get方法会返回属于当前线程的那个实例。 ●在多个线程中生成随机数也存在类似的问题。java.util.Random 类是线程安全的。但是如果多个线程需要等待一个共享的随机数生成器， 这会很低效。可以使用 ThreadLocal 辅助类为各个线程提供一个单独的生成器
线程在调用 lock 方法来获得另一个线程所持有的锁的时候，很可能发生阻塞。应该更加谨慎地申请锁。tryLock方法试图申请一个锁， 在成功获得锁后返回 true, 否则， 立即返回 false, 而且线程可以立即离开去做其他事情。 可以调用 tryLock 时，使用超时参数，像这样： if (myLock.tryLock(100, TineUnit.MILLISECONDS)) … TimeUnit 是一 枚举类型，可以取的值包括 SECONDS、MILLISECONDS, MICROSECONDS 和 NANOSECONDS。 ●lock 方法不能被中断。如果一个线程在等待获得一个锁时被中断，中断线程在获得锁之前一直处于阻塞状态。如果出现死锁，那么，lock 方法就无法终止。 然而， 如果调用带有用超时参数的 tryLock, 那么如果线程在等待期间被中断，将抛出 InterruptedException 异常。这是一个非常有用的特性，因为允许程序打破死锁。 ●也可以调用 locklnterruptibly方法。它就相当于一个超时设为无限的 tryLock 方法。 ●在等待一个条件时， 也可以提供一个超时： myCondition.await(100, TineUnit.MILLISECONDS)) 如果一个线程被另一个线程通过调用 signalAll 或 signal 激活， 或者超时时限已达到，或者线程被中断， 那么 await 方法将返回。 如果等待的线程被中断， await 方法将抛出一个 InterruptedException 异常。在你希望出现这种情况时线程继续等待（可能不太合理)， 可以使用awaitUninterruptibly方法代替 await。 参考：https://segmentfault.com/a/1190000020541622?utm_source=tag-newest
java.util.concurrent.locks 包定义了两个锁类， ReentrantLock类和 ReentrantReadWriteLock 类。 如果很多线程从一个数据结构读取数据而很少有线程修改其中数据的话， 后者是十分有用的。在这种情况下， 允许对读者线程共享访问是合适的。当然，写者线程依然必须是互斥访问的。 下面是使用读 / 写锁的必要步骤： 1 ) 构造一个 ReentrantReadWriteLock 对象： private ReentrantReadWriteLock rwl = new ReentrantReadWriteLock(); 2 ) 抽取读锁和写锁： private Lock readLock = rwl.readLock(); private Lock writeLock = rwl.writeLock(); 3 ) 对所有的获取方法加读锁： public double getTotalBalance() { readLock.lock()； try { . . . } finally { readLock.unlock(); } } 4 ) 对所有的修改方法加写锁： public void transfer(. . .) { writeLock.lock(); try { . . . } finally { writeLock.unlock(); } }
初始的 Java 版本定义了一个 stop方法用来终止一个线程， 以及一个 suspend方法用来阻塞一个线程直至另一个线程调用 resume。stop 和 suspend方法有一些共同点：都试图控制一个给定线程的行为。 stop、 suspend 和 resume方法已经弃用。stop方法天生就不安全，经验证明 suspend方法会经常导致死锁。 ●首先来看看 stop方法，该方法终止所有未结束的方法， 包括 run方法。 当线程被终止，立即释放被它锁住的所有对象的锁。这会导致对象处于不一致的状态。例如，假定 TransferThread 在从一个账户向另一个账户转账的过程中被终止，钱款已经转出，却没有转入目标账户，现在银行对象就被破坏了。因为锁已经被释放，这种破坏会被其他尚未停止的线程观察到。 当线程要终止另一个线程时， 无法知道什么时候调用stop方法是安全的， 什么时候导致对象被破坏。因此，该方法被弃用了。在希望停止线程的时候应该中断线程， 被中断的线程会在安全的时候停止。 ●与 stop不同，suspend不会破坏对象。但是， 如果用 suspend 挂起一个持有一个锁的线程， 那么，该锁在恢复之前是不可用的。如果调用 suspend方法的线程试图获得同一个锁， 那么程序死锁： 被挂起的线程等着被恢复，而将其挂起的线程等待获得锁。 如果想安全地挂起线程，引人一个变量 suspendRequested 并在 run方法的某个安全的地方测试它，安全的地方是指该线程没有封锁其他线程需要的对象的地方。当该线程发现 suspendRequested 变量已经设置，将会保持等待状态直到它再次获得为止。 java同步器AQS:参考 https://www.jianshu.com/p/d8eeb31bee5c
现在，读者已经看到了形成 Java并发程序设计基础的底层构建块。然而，对于实际编程来说，应该尽可能远离底层结构。使用由并发处理的专业人士实现的较高层次的结构要方便得多、要安全得多。 ●对于许多线程问题， 可以通过使用一个或多个队列以优雅且安全的方式将其形式化。生产者线程向队列插人元素， 消费者线程则取出它们。使用队列，可以安全地从一个线程向另一个线程传递数据。例如，考虑银行转账程序， 转账线程将转账指令对象插入一个队列中， 而不是直接访问银行对象。另一个线程从队列中取出指令执行转账。只有该线程可以访问该银行对象的内部。因此不需要同步。（当然， 线程安全的队列类的实现者需要考虑锁和条件，但是这不归我管）
●当试图向队列添加元素而队列已满， 或是想从队列移出元素而队列为空的时候， 阻塞队列（blocking queue) 导致线程阻塞。在协调多个线程之间的合作时，阻塞队列是一个有用的 工具。工作者线程可以周期性地将中间结果存储在阻塞队列中。其他的工作者线程移出中间结果并进一步加以修改。队列会自动地平衡负载。如果第一个线程集运行得比第二个慢， 第 二个线程集在等待结果时会阻塞。如果第一个线程集运行得快， 它将等待第二个队列集赶上来。下表给出了阻塞队列的方法 ●阻塞队列方法分为以下 3类， 这取决于当队列满或空时它们的响应方式。如果将队列当作线程管理工具来使用， 将要用到 put 和 take 方法。当试图向满的队列中添加或从空的队列中移出元素时，add、 remove 和 element 操作抛出异常。当然，在一个多线程程序中， 队列会在任何时候空或满， 因此，一定要使用 offer、poll 和 peek方法作为替代。这些方法如果不能完成任务，只是给出一个错误提示而不会抛出异常。 还有带有超时的 offer方法和 poll 方法的变体。例如，下面的调用： boolean success = q.offer(x, 100, TimeUnit.MILLISECONDS); ●java.util.concurrent 包提供了阻塞队列的几个变种 默认情况下，LinkedBlockingQueue 的容量是没有上边界的，但是，也可以选择指定最大容量。LinkedBlockingDeque 是一个双端的版本。 ArrayBlockingQueue 在构造时需要指定容量，并且有一个可选的参数来指定是否需要公平性。若设置了公平参数， 则那么等待了最长时间的线程会优先得到处理。通常，公平性会降低性能，只有在确实非常需要时才使用它。 PriorityBlockingQueue 是一个带优先级的队列， 而不是先进先出队列。元素按照它们的优先级顺序被移出。该队列是没有容量上限，但是，如果队列是空的， 取元素的操作会阻塞。 DelayQueue 包含实现 Delayed接口的对象。getDelay方法返回对象的残留延迟。负值表示延迟已经结束。元素只有在延迟用完的情况下才能从 DelayQueue 移除。 JavaSE 7增加了一个 TransferQueue 接口，允许生产者线程等待， 直到消费者准备就绪可以接收一个元素。如果生产者调用 q.transfer(item); 这个调用会阻塞， 直到另一个线程将元素（item) 删除。LinkedTransferQueue 类实现了这个接口.
如果多线程要并发地修改一个数据结构， 例如散列表， 那么很容易会破坏这个数据结构 。例如， 一个线程向表中插入一个新元素,在调整散列表各个桶之间的链接关系的过程中， 被剥夺了控制权。如果另一个线程也开始遍历同一个链表，可能使用无效的链接并造成混乱， 会抛出异常或者陷入死循环。
可以通过提供锁来保护共享数据结构， 但是选择线程安全的实现作为替代可能更容易。前一节讨论的阻塞队列就是线程安全的集合。在下面各小节中，将讨论 Java类库提供的另外一些线程安全的集合。
●java.util.concurrent 包提供了映射、 有序集和队列的高效实现：ConcurrentHashMap、 ConcurrentSkipListMap 、ConcurrentSkipListSet 和 ConcurrentLinkedQueue。 这些集合使用复杂的算法，通过允许并发地访问数据结构的不同部分来使竞争极小化。
●与大多数集合不同，size方法不必在常量时间内操作。确定这样的集合当前的大小通常需要遍历。 有些应用使用庞大的并发散列映射， 以至于无法用 size 方法 得到它的大小， 因为这个方法只能返回 int。为此JavaSE 8 引入了一个 mappingCount 方法可以把大小作为 long 返回。
●集合返回弱一致性（weakly consistent) 的迭代器。这意味着迭代器不一定能反映出它们被构造之后的所有的修改，但是，它们不会将同一个值返回两次，也不会拋出 Concurrent ModificationException 异常。 与之形成对照的是， 集合如果在迭代器构造之后发生改变，java.util 包中的迭代器 将抛出一个 ConcurrentModificationException 异常。 参考：https://segmentfault.com/a/1190000000377057 ●并发的散列映射表， 可高效地支持大量的读者和一定数量的写者。默认情况下，假定 可以有多达 16 个写者线程同时执行。可以有更多的写者线程，但是， 如果同一时间多于 16 个，其他线程将暂时被阻塞。可以指定更大数目的构造器，然而，恐怕没有这种必要。
假设多个线程会遇到单词，我们想统计它们的频率。 使用 ConcurrentHashMap<String, Long> ●显然这段代码是不安全的。有些程序员很奇怪为什么原本线程安全的数据结构会允许非线程安全的操作。需要注意，如果多个线程修改一个普通的 HashMap，它们会破坏内部结构（一个链表数组） 。有些链接可能丢失， 或者甚至会构成循环，使得这个数据结构不再可用。对于 ConcurrentHashMap 绝对不会发生这种情况。在上面的例子中，get 和 put 代码不会破坏数据结构。不过，由于操作序列不是原子的，所以结果不可预知。 ●传统的做法是使用 replace 操作，它会以原子方式用一个新值替换原值，前提是之前没有其他线程把原值替换为其他值。必须一直这么做， 直到 replace 成功： do { oldValue = map.get(word); newValue = oldValue = null ? 1 : oldValue + 1; } while (!map.replace(word, oldValue, newValue));
●或者可以使用一个 ConcurrentHashMap<String，AtomicLong>， 或者在 Java SE 8中， 还可以使用 ConcurrentHashMap<String，LongAdder>。更新代码如下： map.putlfAbsent(word, new LongAdder())； map.get(word).increment(); 第一个语句确保有一个 LongAdder 可以完成原子自增。由于putlfAbsent 返回映射的的值（可能是原来的值， 或者是新设置的值)， 所以可以组合这两个语句： map.putlfAbsent(word, new LongAdder()).increment() ● Java SE 8 提供了一些可以更方便地完成原子更新的方法。调用 compute方法时可以提供一个键和一个计算新值的函数。这个函数接收键和相关联的值（如果没有值，则为 null), 它 会计算新值。例如，可以如下更新一个整数计数器的映射： map.compute(word, (k, v) -> v = null ? 1: v +1); 另外还有 computelfPresent 和 computelfAbsent方法，它们分别只在已经有原值的情况下计 算新值，或者只有没有原值的情况下计算新值。可以如下更新一个 LongAdder计数器映射： map.computelfAbsent(word, k -> new LongAdder())_increment(); ●首次增加一个键时通常需要做些特殊的处理。利用 merge 方法可以非常方便地做到这一 点。这个方法有一个参数表示键不存在时使用的初始值。否则， 就会调用你提供的函数来结合原值与初始值。（与 compute 不同，这个函数不处理键。 ） map.merge(word, 1L, (existingValue, newValue) -> existingValue + newValue); 或者map.merge(word, 1L, Long::sum);
ConcurrentHashMap 中不允许有 null 值。有很多方法都使用 null 值来指示映射中某个给定的键不存在。
Java SE 8 为并发散列映射提供了批操作，即使有其他线程在处理映射，这些操作也能安全地执行。批操作会遍历映射，处理遍历过程中找到的元素。无须冻结当前映射的快照。除非你恰好知道批操作运行时映射不会被修改，否则就要把结果看作是映射状态的一个近似。
●有 3 种不同的操作： •搜索（search) 为每个键或值提供一个函数，直到函数生成一个非 null 的结果。然后搜索终止，返回这个函数的结果。 •归约（reduce) 组合所有键或值， 这里要使用所提供的一个累加函数。 •forEach 为所有键或值提供一个函数。 ●每个操作都有 4 个版本： •operationKeys: 处理键。 •operationValues: 处理值。 •operation: 处理键和值。 •operationEntries: 处理 Map.Entry对象。 对于上述各个操作， 需要指定一个参数化阈值（parallel threshold)。如果映射包含的元素多于这个阈值， 就会并行完成批操作。如果希望批操作在一个线程中运行，可以使用阈值 Long.MAX_VALUE。如果希望用尽可能多的线程运行批操作，可以使用阈值 1。
●使用示例 1、search 例如， 假设我们希望找出第一个出现次数超过 1000 次的单词。需要搜索键和值： String result = map.search(threshold, (k, v) -> v > 1000 ? k : null); result 会设置为第一个匹配的单词，如果搜索函数对所有输人都返回 null, 则返回 null。 2、forEach方法有两种形式。 第一个只为各个映射条目提供一个消费者函数， 例如： map.forEach(threshold, (k, v) -> System.out.println(k + "-> " + v)); 第二种形式还有一个转换器函数， 这个函数要先提供，其结果会传递到消费者： map.forEach(threshold, (k, v)-> k + " -> " + v，// Transformer System.out::println); // Consumer 转换器可以用作为一个过滤器。只要转换器返回 null, 这个值就会被悄无声息地跳过。 例如，下面只打印有大值的条目： map.forEach(threshold, (k, v) -> v > 1000 ? k + "-> " + v : null, // Filter and transformer System.out::println); // The nulls are not passed to the consumer 3、reduce 操作用一个累加函数组合其输入。例如，可以如下计算所有值的总和： Long sum = map.reduceValues(threshold, Long::sum); 与 forEach类似，也可以提供一个转换器函数。可以如下计算最长的键的长度： Integer maxlength = map.reduceKeys(threshold, String::length, // Transformer Integer::max); // Accumulator 转换器可以作为一个过滤器，通过返回 null 来排除不想要的输入。 在这里，我们要统计多少个条目的值 > 1000: Long count = map.reduceValues(threshold, v -> v > 1000 ? 1L : null, Long::sum);
●对于 int、 long 和 double 输出还有相应的特殊化操作， 分别有后缀 Tolnt、ToLong和 ToDouble。需要把输入转换为一个基本类型值，并指定一个默认值和一个累加器函数。映射为空时返回默认值。 long sum = map. reduceValuesToLong(threshold, Long::longValue, // Transformer to primitive type 0, // Default value for empty map Long::sum); // Primitive type accumulator
●假设你想要的是一个大的线程安全的集而不是映射。并没有一个 ConcurrentHashSet 类， 而且你肯定不想自己创建这样一个类。当然，可以使用 ConcurrentHashMap (包含“ 假” 值), 不过这会得到一个映射而不是集， 而且不能应用 Set 接口的操作。 静态 newKeySet方法会生成一个 Set< K>, 这实际上是 ConcurrentHashMap<K, Boolean> 的一个包装器。（所有映射值都为 Boolean.TRUE, 不过因为只是要把它用作一个集，所以并不关心具体的值。 ） Set< String> words = ConcurrentHashMap.< String>newKeySet(); ● 如果原来有一个映射，keySet 方法可以生成这个映射的键集。这个集是可变的。 如果删除这个集的元素，这个键（以及相应的值）会从映射中删除。不过，不能向键集增加元素，因为没有相应的值可以增加。Java SE8为 ConcurrentHashMap增加了第二个 keySet方 法，包含一个默认值，可以在为集增加元素时使用： Set< String> words = map.keySet(1L); words.add("Java”）； 如果 "Java”在 words 中不存在，现在它会有一个值 1。
CopyOnWriteArrayList 和 CopyOnWriteArraySet 是线程安全的集合，其中所有的修改线程对底层数组进行复制。如果在集合上进行迭代的线程数超过修改线程数， 这样的安排是很有用的。当构建一个迭代器的时候， 它包含一个对当前数组的引用。如果数组后来被修改 了，迭代器仍然引用旧数组， 但是，集合的数组已经被替换了。因而，旧的迭代器拥有一致的（可能过时的）视图，访问它无须任何同步开销。 参考：https://www.jianshu.com/p/9b6a4d0b94ac
在 Java SE 8中， Arrays类提供了大量并行化操作。静态 Arrays.parallelSort 方法可以对 一个基本类型值或对象的数组排序。需要避免使用有副作用的比较器。
parallelSetAll 方法会用由一个函数计算得到的值填充一个数组。这个函数接收元素索引， 然后计算相应位置上的值。 Arrays.parallelSetAll(values,i ->i % 10); // Fills values with 0 12 3 4 5 6 7 8 9 0 12 …
parallelPrefix 方法，它会用对应一个给定结合操作的前缀的累加结果替换各个数组元素。这里给出一个例子。考虑数组 [1，2, 3, 4, . . .] 和 x 操作。执行 Arrays.parallelPrefix(values, (x, y)-> x * y) 之后，数组将包含： [1 , 1x 2, 1x 2 x 3, 1x 2 x 3 x 4, . . .]
●从 Java 的初始版本开始，Vector 和 Hashtable类就提供了线程安全的动态数组和散列表的实现。现在这些类被弃用了， 取而代之的是 ArrayList 和 HashMap类。这些类不是线程安全的，而集合库中提供了不同的机制。任何集合类都可以通过使用同步包装器（synchronization wrapper) 变成线程安全的： List< E> synchArrayList = Collections.synchronizedList(new ArrayList< E>()); Map<K, V> synchHashMap = Collections.synchronizedMap(new HashMap<K, V>())； 集合的方法使用锁加以保护，提供了线程安全访问。
●应该确保没有任何线程通过原始的非同步方法访问数据结构。最便利的方法是确保不保存任何指向原始对象的引用， 简单地构造一个集合并立即传递给包装器，像我们的例子中所做的那样。
●如果在另一个线程可能进行修改时要对集合进行迭代，仍然需要使用“ 客户端” 锁定： synchronized (synchHashMap) { Iterator< K> iter = synchHashMap.keySet().iterator(); while (iter.hasNext()) . . . } 如果使用“ foreach” 循环必须使用同样的代码， 因为循环使用了迭代器。注意：如果在迭代过程中，别的线程修改集合，迭代器会失效，抛出 ConcurrentModificationException异常。同步仍然是需要的， 因此并发的修改可以被可靠地检测出来。
最好使用java.util.Concurrent 包中定义的集合， 不使用同步包装器中的。特别是， 假如它们访问的是不同的桶， 由于 ConcurrentHashMap 已经精心地实现了，多线程可以访问它而且不会彼此阻塞。有一个例外是经常被修改的数组列表,在那种情况下，同步的 ArrayList 可以胜过 CopyOnWriteArrayList
●Runnable 封装一个异步运行的任务，可以把它想象成为一个没有参数和返回值的异步方法。Callable 与 Runnable 类似，但是有返回值。Callable 接口是一个参数化的类型， 只有一 个方法 call。 public interface Callable< V> { V call() throws Exception; } 类型参数是返回值的类型。例如， Callable< Integer> 表示一个最终返回Integer对象的异步计算。 ●Future 保存异步计算的结果。可以启动一个计算，将Future对象交给某个线程，Future 对象的所有者在结果计算好之后就可以获得它。 Future 接口具有下面的方法： public interface Future< V> { V get() throws … V get(long timeout, TimeUnit unit) throws … void cancel(boolean maylnterrupt); boolean isCancelled(); boolean isDone(); } 第一个 get 方法的调用被阻塞， 直到计算完成。如果在计算完成之前， 第二个方法的调用超时，拋出一个 TimeoutException 异常。如果运行该计算的线程被中断，两个方法都将拋出 InterruptedException。如果计算已经完成， 那么 get 方法立即返回。 如果计算还在进行，isDone方法返回 false; 如果完成了， 则返回 true。 可以用 cancel 方法取消该计算。如果计算还没有开始，它被取消且不再开始。如果计算处于运行之中，那么如果 maylnterrupt 参数为 true, 它就被中断。 ●FutureTask 包装器是一种非常便利的机制， 可将 Callable转换成 Future 和 Runnable, 它同时实现二者的接口。例如： Callable< Integer> myComputation =…; FutureTask< Integer> task = new FutureTask< Integer>(myComputation); Thread t = new Thread(task); //it’s a Runnable t.start()； Integer result = task.get()；//it’s a Future
构建一个新的线程是有一定代价的， 如果程序中创建了大量的生命期很短的线程，应该使用线程池（thread pool)。一个线程池中包含许多准备运行的空闲线程。将 Runnable 对象交给线程池， 就会有一个线程调用 run方法。当 run 方法退出时，线程不会死亡，而是在池中准备为下一个请求提供服务。
另一个使用线程池的理由是减少并发线程的数目。创建大量线程会大大降低性能甚至使虚拟机崩溃。如果有一个会创建许多线程的算法， 应该使用一个线程数“ 固定的” 线程池以限制并发线程的总数。
执行器（Executor) 类有许多静态工厂方法用来构建线程池， 表 中对这些方法进行 了汇总。
newCachedThreadPool方法构建了一个线程池， 对于每个任务， 如果有空闲线程可用，立即让它执行任务，如果没有可用的空闲线程， 则创建一个新线程。 newFixedThreadPool 方法构建一个具 有固定大小的线程池。如果提交的任务数多于空闲的线程数， 那么把得不到服务的任务放置到队列中。当其他任务完成以后再运行它们。 newSingleThreadExecutor 是一个退化了的大小为 1 的线程池： 由一个线程执行提交的任务，一个接着一个. 这 3 个方法返回实现了 ExecutorService 接口的 ThreadPoolExecutor 类的对象。
可用下面的方法之一将一个 Runnable 对象或 Callable 对象提交给 ExecutorService: Future<?> submit(Runnable task) Future< T > submit(Runnable task, T result) Future< T> submit(Callable< T> task) 该池会在方便的时候尽早执行提交的任务。调用 submit 时，会得到一个 Future 对象， 可用来查询该任务的状态。 第一个 submit 方法返回一个奇怪样子的 Future<?>。可以使用这样一个对象来调用 isDone、cancel 或 isCancelled。但是，get 方法在完成的时候只是简单地返回 null。 第二个版本的 submit 也提交一个 Runnable，并且 Future 的 get 方法在完成的时候返回指定的 result 对象。 第三个版本的 submit 提交一个Callable, 并且返回的 Future 对象将在计算结果准备好的时候得到它。
当用完一个线程池的时候， 调用 shutdown。该方法启动该池的关闭序列。被关闭的执行器不再接受新的任务。当所有任务都完成以后，线程池中的线程死亡。 另一种方法是调用 shutdownNow。该池取消尚未开始的所有任务并试图中断正在运行的线程。
下面总结了在使用连接池时应该做的事：
调用 Executors 类中静态的方法 newCachedThreadPool 或 newFixedThreadPool。调用 submit 提交 Runnable 或 Callable对象。 3 ) 如果想要取消一个任务， 或如果提交 Callable 对象， 那就要保存好返回的 Future 对象。 4 ) 当不再提交任何任务时，调用 shutdownScheduledExecutorService 接口具有为预定执行（Scheduled Execution) 或重复执行任务而设计的方法。它是一种允许使用线程池机制的java.util.Timer 的泛化。 Executors 类的 newScheduledThreadPool 和 newSingleThreadScheduledExecutor方法将返回实现了 ScheduledExecutorService 接口的对象。 可以预定 Runnable 或 Callable在初始的延迟之后只运行一次。也可以预定一个 Runnable 对象周期性地运行。
invokeAny方法提交所有对象到一个 Callable 对象的集合中，并返回某个已经完成了的任务的结果。无法知道返回的究竟是哪个任务的结果。 对于搜索问题， 如果你愿意接受任何一种解决方案的话，可以使用这个方法。
invokeAll 方法提交所有对象到一个 Callable 对象的集合中，并返回一个 Future 对象的列表，代表所有任务的解决方案。 这个方法的缺点是如果第一个任务恰巧花去了很多时间，则可能不得不进行等待。将结果按可获得的顺序保存起来更有实际意义。可以用 ExecutorCompletionService 来进行排列。
有些应用使用了大量线程， 但其中大多数都是空闲的。 将任务划分成子任务，分别并行求解，再综合
CompletableFuture 是一个简单 API, 不过有很多不同方法来组合可完成 future 利用可完成 future，可以指定你希望做什么，以及希望以什么顺序执行这些工作。
java.util.concurrent 包中有几个能帮助人们管理相互合作的线程集的类见下表。这 些机制具有为线程之间的共用集结点模式（common rendezvous patterns) 提供的“ 预置功能” ( canned functionality)。如果有一个相互合作的线程集满足这些行为模式之一， 那么应该直接重用合适的库类而不要试图提供手工的锁与条件的集合。 参考：https://www.cnblogs.com/doit8791/p/8052339.html 多线程面试：https://segmentfault.com/a/1190000020313421?utm_source=sf-related
