20220424 Java核心技术卷1 基础知识 14

并发

操作系统中的 多任务（multitasking) ：在同一刻运行多个程序的能力

多线程程序在较低的层次上扩展了多任务的概念：一个程序同时执行多个任务。通常，每一个任务称为一个 线程（thread) , 它是线程控制的简称。可以同时运行一个以上线程的程序称为 多线程程序（multithreaded)

多进程与多线程有哪些区别呢？本质的区别在于每个进程拥有自己的一整套变量，而线程则共享数据。 共享变量使线程之间的通信比进程之间的通信更有效、更容易。此外，在有些操作系统中，与进程相比较，线程更 “轻量级”，创建、撤销一个线程比启动新进程的开
销要小得多

什么是线程

Runnable 接口的类的 run 方法

@FunctionalInterface
public interface Runnable {
    public abstract void run();
}

由于 Runnable 是一个函数式接口，可以用 lambda 表达式建立一个实例：

Runnable r = () -> {
    // task code
};

Thread thread = new Thread(r);
thread.start();

也可以通过构建一个 Thread 类的子类定义一个线程

class MyThread extends Thread {
    @Override
    public void run() {
        // task code
    }
}

这种方法已不再推荐。应该将要并行运行的任务与运行机制解耦合。如果有很多任务，要为每个任务创建一个独立的线程所付出的代价太大了。可以使用 线程池 来解决这个问题

警告：不要调用 Thread 类或 Runnable 对象的 run 方法。直接调用 run 方法，只会执行同一个线程中的任务，而不会启动新线程。应该调用 Thread.start 方法。这个方法将创建一个执行 run 方法的新线程。

`java.lang.Thread` 方法名称	方法声明	描述
构造器	`Thread(Runnable target)`	构造一个新线程，用于调用给定目标的 `run` 方法
`start`	`synchronized void start()`	启动这个线程，将引发调用 `run` 方法。这个方法将立即返回，并且新线程将并发运行
`run`	`void run()`	调用关联 `Runnable` 的 `run` 方法
`sleep`	`static native void sleep(long millis) throws InterruptedException`	休眠给定的毫秒数

`java.lang.Runnable` 方法名称	方法声明	描述
`run`	`void run()`	必须覆盖这个方法，并在这个方法中提供所要执行的任务指令

中断线程

当线程的 run 方法执行方法体中最后一条语句后，并经由执行 return 语句返冋时，或者出现了在方法中没有捕获的异常时，线程将终止。在 Java 的早期版本中，还有一个 stop 方法，其他线程可以调用它终止线程。但是，这个方法现在已经被弃用了。

没有可以强制线程终止的方法。然而， interrupt 方法可以用来请求终止线程。当对一个线程调用 interrupt 方法时，线程的中断状态将被置位。这是每一个线程都具有的 boolean 标志。每个线程都应该不时地检査这个标志，以判断线程是否被中断。

要想弄清中断状态是否被置位，首先调用静态的 Thread.currentThread 方法获得当前线程，然后调用 isInterrupted 方法：

Thread.currentThread().isInterrupted()

但是，如果线程被阻塞，就无法检测中断状态。这是产生 InterruptedException 异常的地方。当在一个被阻塞的线程（调用 sleep 或 wait ) 上调用 interrupt 方法时，阻塞调用将会被 InterruptedException 异常中断。（存在不能被中断的阻塞 I/O 调用，应该考虑选择可中断的调用）

没有任何语言方面的需求要求一个被中断的线程应该终止。中断一个线程不过是引起它的注意。被中断的线程可以决定如何响应中断。某些线程是如此重要以至于应该处理完异常后，继续执行，而不理会中断。但是，更普遍的情况是，线程将简单地将中断作为一个终止的请求。这种线程的 run 方法具有如下形式：

Runnable r = () -> {
    try {
        while (!Thread.currentThread().isInterrupted() && more work to do) {
            // do more work
        }
    } catch(InterruptedException e) {
        // thread was interruted during sleep or wait
    } finally {
        // cleanup, if required
    }
    // exiting the run method terminates the thread
};

如果在每次工作迭代之后都调用 sleep 方法（或者其他的可中断方法)， islnterrupted 检测既没有必要也没有用处。如果在中断状态被置位时调用 sleep 方法，它不会休眠。相反，它将清除这一状态（！！！）并拋出 InterruptedException 。因此，如果你的循环调用 sleep ，不会检测中断状态。相反，要如下所示捕获 InterruptedException 异常：

Runnable r = () -> {
    try {
        while ( more work to do ? ) {
            // do more work
            Thread.sleep(delay);
        }
    } catch (InterruptedException e) {
        // thread was interrupted during sleep
    } finally {
        // cleanup,if required
    }
    // exiting the run method terminates the thread
};

有两个非常类似的方法，interrupted 和 isInterrupted 。interrupted 方法是一个静态方法，它检测当前的线程是否被中断。而且，调用 interrupted 方法会清除该线程的中断状态。另一方面， isInterrupted 方法是一个实例方法，可用来检验是否有线程被中断。调用这个方法不会改变中断状态。

在很多发布的代码中会发现 InterruptedException 异常被抑制在很低的层次上，像这样：

void mySubTask() {
    try {
        sleep(delay);
    } catch (InterruptedException e) {
        // Don't ignore!
    } 
}

不要这样做！如果不认为在 catch 子句中做这一处理有什么好处的话，仍然有两种合理的选择：

在 catch 子句中调用 Thread.currentThread().interrupt() 来设置中断状态。于是，调用者可以对其进行检测

void mySubTask() {
    try {
        sleep(delay);
    } catch (InterruptedException e) {
        Thread.currentThread().interrupt();
    }
}

或者，更好的选择是，用 throws InterruptedException 标记你的方法，不采用 try 语句块捕获异常。于是，调用者（或者，最终的 run 方法）可以捕获这一异常
```
void mySubTask() throws InterruptedException {
    sleep(delay);
}
```

`java.lang.Thread` 方法名称	方法声明	描述
`interrupt`	`void interrupt()`	向线程发送中断请求。线程的中断状态将被设置为 `true` 。如果目前该线程被一个 `sleep` 调用阻塞，那么，`InterruptedException` 异常被抛出
`interrupted`	`static boolean interrupted()`	测试当前线程（即正在执行这一命令的线程）是否被中断。注意，这是一个静态方法。这一调用会产生副作用——它将当前线程的中断状态重置为 `false`
`isInterrupted`	`boolean isInterrupted()`	测试线程是否被终止。不像静态的中断方法，这一调用不改变线程的中断状态
`currentThread`	`static native Thread currentThread()`	返回代表当前执行线程的 `Thread` 对象
`isAlive`	`final native boolean isAlive()`	测试此线程是否处于活动状态。如果线程已启动但尚未死亡，则该线程是活动的

JavaDoc：

java.lang.Thread#interrupt

允许当前线程中断自身，如果不是自身中断，将检查权限，可能会导致抛出 SecurityException
wait 、join 、sleep 阻塞时中断，中断状态会被清除，并抛出 InterruptedException
如果线程被 InterruptibleChannel 上的 IO 操作阻塞，那么通道将被关闭，并设置中断状态，抛出 ClosedByInterruptException
如果线程被 Selector 阻塞，它将立即从选择操作返回，可能带有非零值，就像调用了选择器的唤醒方法一样；并设置中断状态
如果前面的条件都不成立，那么将设置该线程的中断状态
中断一个非活动线程不需要有任何效果

java.lang.Thread#isInterrupted

如果此线程已中断，则为 true ；否则 false
测试此线程是否已中断。线程的中断状态不受此方法的影响
由于线程在中断时不处于活动状态而被忽略的线程中断将通过返回false的方法反映出来

java.lang.Thread#interrupted

如果此线程已中断，则为 true ；否则 false
测试当前线程是否已中断。此方法清除线程的中断状态，换句话说，如果连续调用两次此方法，则第二次调用将返回 false（除非当前线程在第一次调用清除其中断状态之后，第二次调用检查之前再次中断）
由于线程在中断时不处于活动状态而被忽略的线程中断将通过返回 false 的方法反映出来

@Slf4j
class MyThread extends Thread {
    @Override
    public void run() {
        log.info("MyThread started!");
        for (int i = 1; ; i++) {
            log.info("loop i=" + i);
            if (this.isInterrupted()) {
                // 当前为中断状态
                log.info("检测到当前为中断状态!");
                log.info("第一次1 isInterrupted() :: " + isInterrupted());     // 中断状态为 true
                log.info("第一次 interrupted() :: " + interrupted());          // 中断状态为 true，返回 true，清除线程的中断状态
                log.info("第一次2 isInterrupted() :: " + isInterrupted());     // 中断状态已被清除，返回 false
                log.info("isAlive :: " + this.isAlive());
                //清除中断状态
                // this.interrupt();  再次中断后，下面三条语句分别返回 true、true、false
                log.info("第二次1 isInterrupted() :: " + isInterrupted());     // 中断状态已被清除，返回 false
                log.info("第二次 interrupted() :: " + interrupted());          // 中断状态已被清除，返回 false
                log.info("第二次2 isInterrupted() :: " + isInterrupted());     // 中断状态已被清除，返回 false
                break;
            }
        }
        log.info("MyThread stopped!");
    }
}

@Slf4j
public class TestInterrupt {
    public static void main(String[] args) {
        log.info("Main Thread started!");
        MyThread thread = new MyThread();
        thread.start();
        //中断线程
        thread.interrupt();
        log.info("thread是否存活：" + thread.isAlive());     // true
        log.info("中断后，立刻查看中断状态 thread.isInterrupted：" + thread.isInterrupted()); // true
        try {
            Thread.sleep(1000);//主线程等待两秒，等待MyThread线程运行结束
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        log.info("thread是否存活：" + thread.isAlive());     // false
        log.info("中断 1s 后，立刻查看中断状态 thread.isInterrupted：" + thread.isInterrupted()); // false
        log.info("Main Thread stopped!");
    }
}

@Slf4j
public class InterruptTest2 {

    @SneakyThrows
    public static void main(String[] args) {
        InterruptTest2 interruptTest2 = new InterruptTest2();
        log.info("=============== test6 =======================");
        // interruptTest2.test6();
        // Thread.sleep(2000);
        log.info("=============== test7 =======================");
        // interruptTest2.test7();
        // Thread.sleep(2000);
        log.info("=============== test8 =======================");
        // interruptTest2.test8();
        // Thread.sleep(2000);
        log.info("=============== test9 =======================");
        // interruptTest2.test9();

        for (int i = 0; i < 5; i++) {
            log.info("=============== test =======================");
            interruptTest2.test9();
            Thread.sleep(2000);
        }
    }

    /**
     * 中断异常
     */
    public void test6() {
        Thread thread = new Thread(() -> {
            Thread thread1 = Thread.currentThread();
            try {
                log.info("1.1. {}", thread1.isInterrupted());   // false
                Thread.sleep(2000);
                log.info("1.2. {}", thread1.isInterrupted());   // 不会经过这句
            } catch (InterruptedException e) {
                log.info("1.3. {}", thread1.isInterrupted());   // false ，这里中断了 sleep 方法，中断状态会被重置
            } finally {
                log.info("1.4. {}", thread1.isInterrupted());   // false
            }
        });
        thread.start();

        try {
            Thread.sleep(1000);     // 保证 thread 线程已经启动
            log.info("2.1. {}", thread.isInterrupted());   // false
            thread.interrupt();
            log.info("2.2. {}, {}", thread.isAlive(), thread.isInterrupted());   // true, true ，这里会受线程是否 alive 的影响

            Thread.sleep(2000);
            log.info("2.3. {}, {}", thread.isAlive(), thread.isInterrupted());   // false, false ，这里会受线程是否 alive 的影响
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

    }

    /**
     * 中断异常
     */
    public void test7() {
        Thread thread = new Thread(() -> {
            Thread thread1 = Thread.currentThread();
            try {
                log.info("1.1. {}", thread1.isInterrupted());   // false
                Thread.sleep(2000);
                log.info("1.2. {}", thread1.isInterrupted());   // 不会经过这句
            } catch (InterruptedException e) {
                log.info("1.3. {}", Thread.interrupted());   // false ，这里中断了 sleep 方法，中断状态会被重置
            } finally {
                log.info("1.4. {}", thread1.isInterrupted());   // false
            }
        });
        thread.start();

        try {
            Thread.sleep(1000);     // 保证 thread 线程已经启动
            log.info("2.1. {}", thread.isInterrupted());   // false
            thread.interrupt();
            log.info("2.2. {}, {}", thread.isAlive(), thread.isInterrupted());   // true, true ，这里会受线程是否 alive 的影响

            Thread.sleep(2000);
            log.info("2.3. {}, {}", thread.isAlive(), thread.isInterrupted());   // false, false ，这里会受线程是否 alive 的影响
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }

    /**
     * 循环，并根据中断状态作为判断条件终止循环，不涉及中断异常
     */
    public void test8() {
        Thread thread = new Thread(() -> {
            Thread thread1 = Thread.currentThread();
            try {
                log.info("1.1. {}", thread1.isInterrupted());   // false
                while (!thread1.isInterrupted()) {

                }
                log.info("1.2. {}", thread1.isInterrupted());   // true
            } finally {
                log.info("1.4. {}", thread1.isInterrupted());   // true
            }
        });
        thread.start();

        try {
            Thread.sleep(1000);     // 保证 thread 线程已经启动
            log.info("2.1. {}", thread.isInterrupted());   // false
            thread.interrupt();
            log.info("2.2. {}, {}", thread.isAlive(), thread.isInterrupted());   // true, true ，这里会受线程是否 alive 的影响

            Thread.sleep(1000);
            log.info("2.3. {}, {}", thread.isAlive(), thread.isInterrupted());   // false, false ，这里会受线程是否 alive 的影响
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }


    /**
     * 循环，并根据中断状态作为判断条件终止循环，不涉及中断异常
     */
    public void test9() {
        Thread thread = new Thread(() -> {
            Thread thread1 = Thread.currentThread();
            try {
                log.info("1.1. {}", thread1.isInterrupted());   // false
                while (!thread1.isInterrupted()) {

                }
                log.info("1.2. {}", Thread.interrupted());   // true，重置中断状态
            } finally {
                log.info("1.4. {}", thread1.isInterrupted());   // false
            }
        });
        thread.start();

        try {
            Thread.sleep(1000);     // 保证 thread 线程已经启动
            log.info("2.1. {}", thread.isInterrupted());   // false
            thread.interrupt();
            log.info("2.2. {}, {}", thread.isAlive(), thread.isInterrupted());   // true, true ，这里会受线程是否 alive 的影响

            Thread.sleep(1000);
            log.info("2.3. {}, {}", thread.isAlive(), thread.isInterrupted());   // false, false ，这里会受线程是否 alive 的影响
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }

}

线程状态

线程可以有如下 6 种状态（ java.lang.Thread.State ）：

New (新创建）
Runnable (可运行）
Blocked (被阻塞）
Waiting (等待）
Timed waiting (计时等待）
Terminated (被终止）

要确定一个线程的当前状态，可调用 getState 方法。

新创建线程（ `NEW` ）

当用 new 操作符创建一个新线程时，如 new Thread(r) ，该线程还没有开始运行。这意味着它的状态是 NEW 。当一个线程处于新创建状态时，程序还没有开始运行线程中的代码。在线程运行之前还有一些基础工作要做。

可运行线程（ `RUNNABLE` ）

一旦调用 start 方法，线程处于 RUNNABLE 状态。一个可运行状态的线程可能正在运行也可能没有运行，这取决于操作系统给线程提供运行的时间。（ Java 的规范说明没有将它作为一个单独状态。一个正在运行中的线程仍然处于可运行状态）

一旦一个线程开始运行，它不必始终保持运行。事实上，运行中的线程被中断，目的是为了让其他线程获得运行机会。线程调度的细节依赖于操作系统提供的服务。抢占式调度系统给每一个可运行线程一个时间片来执行任务。当时间片用完，操作系统剥夺该线程的运行权，并给另一个线程运行机会。当选择下一个线程时，操作系统考虑线程的优先级。

现在所有的桌面以及服务器操作系统都使用 抢占式调度 。但是，像手机这样的小型设备可能使用 协作式调度 。在这样的设备中，一个线程只有在调用 yield 方法、或者被阻塞或等待时，线程才失去控制权。

在具有多个处理器的机器上，每一个处理器运行一个线程，可以有多个线程并行运行。当然，如果线程的数目多于处理器的数目，调度器依然采用时间片机制。

记住，在任何给定时刻，一个可运行的线程可能正在运行也可能没有运行（这就是为什么将这个状态称为可运行而不是运行) 。

被阻塞线程（ `BLOCKED` ）和等待线程（ `WAITING` 、`TIMED_WAITING` ）

当线程处于被阻塞或等待状态时，它暂时不活动。它不运行任何代码且消耗最少的资源。直到线程调度器重新激活它。 细节取决于它是怎样达到非活动状态的。

当一个线程试图获取一个内部的对象锁（而不是 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 方法而意外死亡

特别是，可以调用线程的 stop 方法杀死一个线程。该方法抛出 ThreadDeath 错误对象，由此杀死线程。但是，stop 方法已过时，不要在自己的代码中调用这个方法。

`java.lang.Thread` 方法名称	方法声明	描述
`join`	`final void join() throws InterruptedException` `final synchronized void join(long millis) throws InterruptedException`	等待指定的线程死亡或者经过指定的毫秒数
`getState`	`State getState()`	得到这一线程的状态；枚举值 `java.lang.Thread.State`
`stop`	~~`final void stop()`~~	停止该线程。这一方法已过时
`suspend`	~~`final void suspend()`~~	暂停这一线程的执行。这一方法已过时
`resume`	~~`final void resume()`~~	恢复线程。这一方法仅仅在调用 `suspend` 之后调用。这一方法已过时

线程属性

线程的各种属性，其中包括：线程优先级、守护线程、线程组以及处理未捕获异常的处理器

线程优先级

在 Java 程序设计语言中，每一个线程有一个 优先级 。默认情况下，一个线程继承它的父线程的优先级。可以用 setPriority 方法提高或降低任何一个线程的优先级。可以将优先级设置为在 MIN_PRIORITY (在 Thread 类中定义为 1 ) 与 MAX_PRIORITY (定义为 10 ) 之间的任何值。NORM_PRIORITY 被定义为 5 。

每当线程调度器有机会选择新线程时，它首先选择具有较高优先级的线程。但是，线程优先级是高度依赖于系统的。当虚拟机依赖于宿主机平台的线程实现机制时， Java 线程的优先级被映射到宿主机平台的优先级上，优先级个数也许更多，也许更少。

例如， Windows 有 7 个优先级别。一些 Java 优先级将映射到相同的操作系统优先级。在 Oracle 为 Linux 提供的 Java 虚拟机中，线程的优先级被忽略——所有线程具有相同的优先级。

初级程序员常常过度使用线程优先级。为优先级而烦恼是事出有因的。不要将程序构建为功能的正确性依赖于优先级。

警告：如果确实要使用优先级，应该避免初学者常犯的一个错误。如果有几个高优先级的线程没有进入非活动状态，低优先级的线程可能永远也不能执行。每当调度器决定运行一个新线程时，首先会在具有高优先级的线程中进行选择，尽管这样会使低优先级的线程完全饿死

`java.lang.Thread` 方法名称	方法声明	描述
`setPriority`	`final void setPriority(int newPriority)`	设置线程的优先级。优先级必须在 `Thread.MIN_PRIORITY` 与 `Thread.MAX_PRIORITY` 之间（ `1-10` ）。一般使用 `Thread.NORM_PRIORITY` 优先级
`yield`	`static native void yield()`	导致当前执行线程处于让步状态。如果有其他的可运行线程具有至少与此线程同样高的优先级，那么这些线程接下来会被调度。注意，这是一个静态方法

守护线程

可以通过调用

t.setDaemon(true);

将线程转换为 守护线程（daemon thread ) 。这样一个线程没有什么神奇。守护线程的唯一用途是为其他线程提供服务。当只剩下守护线程时，虚拟机就退出了，由于如果只剩下守护线程，就没必要继续运行程序了。

守护线程有时会被初学者错误地使用，他们不打算考虑关机（shutdown ) 动作。但是，这是很危险的。守护线程应该永远不去访问固有资源，如文件、数据库，因为它会在任何时候甚至在一个操作的中间发生中断。

`java.lang.Thread` 方法名称	方法声明	描述
`setDaemon`	`final void setDaemon(boolean on)`	标识该线程为守护线程或用户线程。这一方法必须在线程启动之前调用

未捕获异常处理器

线程的 run 方法不能抛出任何受查异常，但是，非受査异常会导致线程终止。在这种情况下，线程就死亡了。

但是，不需要任何 catch 子句来处理可以被传播的异常。相反，就在线程死亡之前，异常被传递到一个用于未捕获异常的处理器。
该处理器必须属于一个实现 Thread.UncaughtExceptionHandler 接口的类。这个接口只有—个方法。

void uncaughtException(Thread t, Throwable e);

可以用 setUncaughtExceptionHandler 方法为任何线程设置一个处理器。也可以用 Thread 类的静态方法 setDefaultUncaughtExceptionHandler 为所有设置设置一个默认的处理器。替换处理器可以使用日志 API 发送未捕获异常的报告到日志文件。

**uncaughtException 在被设置的线程中执行。**

如果不设置默认的处理器，默认的处理器为空。但是，如果不为独立的线程设置处理器，此时的处理器就是该线程的 ThreadGroup 对象。

线程组（ ThreadGroup ）是一个可以统一管理的线程集合。默认情况下，创建的所有线程属于相同的线程组，但是，也可能会建立其他的组。现在引入了更好的特性用于线程集合的操作，所以 建议不要在自己的程序中使用线程组 。

ThreadGroup 类实现 Thread.UncaughtExceptionHandler 接口。它的 uncaughtException 方法做如下操作（ java.lang.ThreadGroup#uncaughtException ）：

如果该线程组有父线程组，那么父线程组的 uncaughtException 方法被调用
如果该线程组没有父线程组：
1. 如果 Thread.getDefaultUncaughtExceptionHandler 方法返回一个非空的处理器，则调用该处理器
2. 如果返回 null ：
  1. 如果 Throwable 是 ThreadDeath 的一个实例，什么都不做
  2. 如果不是，线程的名字以及 Throwable 的栈轨迹被输出到 System.err 上

`java.lang.Thread` 方法名称	方法声明	描述
`setDefaultUncaughtExceptionHandler` `getDefaultUncaughtExceptionHandler`	`static void setDefaultUncaughtExceptionHandler(UncaughtExceptionHandler eh)` `static UncaughtExceptionHandler getDefaultUncaughtExceptionHandler()`	设置或获取未捕获异常的默认处理器
`setUncaughtExceptionHandler` `getUncaughtExceptionHandler`	`void setUncaughtExceptionHandler(UncaughtExceptionHandler eh)` `UncaughtExceptionHandler getUncaughtExceptionHandler()`	设置或获取未捕获异常的处理器。如果没有设置处理器，则将线程组对象作为处理器

`java.lang.Thread.UncaughtExceptionHandler` 方法名称	方法声明	描述
`uncaughtException`	`void uncaughtException(Thread t, Throwable e);`	当一个线程因未捕获异常而终止，按规定要将客户报告记录到日志中

`java.lang.ThreadGroup` 方法名称	方法声明	描述
`uncaughtException`	`void uncaughtException(Thread t, Throwable e)`	如果有父线程组，调用父线程组的这一方法；或者，如果 `Thread` 类有默认处理器，调用该处理器，否则，输出栈轨迹到标准错误流上（但是，如果 `e` 是一个 `ThreadDeath` 对象，栈轨迹是被禁用的。`ThreadDeath` 对象由 `stop` 方法产生，而该方法已经过时)

同步

在大多数实际的多线程应用中，两个或两个以上的线程需要共享对同一数据的存取。如果两个线程存取相同的对象，并且每一个线程都调用了一个修改该对象状态的方法，将会发生什么呢？可以想象，线程彼此踩了对方的脚。根据各线程访问数据的次序，可能会产生错误的对象。这样一个情况通常称为 竞争条件（ race condition ）。

竞争条件的一个例子

我们有具有 transfer 方法的 Bank 类。该方法从一个账户转移一定数目的钱款到另一个账户（还没有考虑负的账户余额)。如下是 Bank 类的 transfer 方法的代码。

public void transfer(int from, int to, double amount) {
    if (accounts[from] < amount) {
        return;
    }
    log.info("Thread.currentThread :: {}", Thread.currentThread());
    accounts[from] -= amount;
    System.out.printf(" %10.2f from %d to %d", amount, from, to);
    accounts[to] += amount;
    System.out.printf(" Total Balance: %10.2f%n", getTotalBalance());
}

这里是 Runnable 类的代码。它的 run 方法不断地从一个固定的银行账户取出钱款。在每一次迭代中，run 方法随机选择一个目标账户和一个随机账户，调用 bank 对象的 transfer 方法，然后睡眠。

Runnable r = () -> {
    try {
        while (true) {
            int toAccount = (int) (bank.size() * Math.random());
            double amount = MAX_AMOUNT * Math.random();
            bank.transfer(fromAccount, toAccount, amount);
            Thread.sleep((int) (DELAY * Math.random()));
        }
    } catch (InterruptedException e) {
    }
};

在最初的交易中，银行的余额保持在 $100000, 这是正确的，因为共 100 个账户，每个账户 $1000 。但是，过一段时间，余额总量有轻微的变化。当运行这个程序的时候，会发现有时很快就出错了，有时很长的时间后余额发生混乱。

竞争条件详解

当两个线程试图同时更新同一个账户的时候，这个问题就出现了。假定两个线程同时执行指令

accounts[to] += amount;

问题在于这不是原子操作。该指令可能被处理如下：

将 accounts[to] 加载到寄存器
增加 amount
将结果写回 accounts[to]

可以具体看一下执行我们的类中的每一个语句的虚拟机的字节码。运行命令 javap -c -v Bank 对 Bank.class 文件进行反编译，代码行 accounts[to] += amount; 被转换成以下的字节码：

69: aload_0
70: getfield      #2                  // Field accounts:[D
73: iload_2
74: dup2
75: daload
76: dload_3
77: dadd
78: dastore

可以看出，增值命令是由几条指令组成的，执行它们的线程可以在任何一条指令点上被中断。

出现这一错误的可能性有多大呢？这里通过将打印语句和更新余额的语句交织在一起执行，增加了发生这种情况的机会。

如果删除打印语句，错误的风险会降低一点，因为每个线程在再次睡眠之前所做的工作很少，调度器在计算过程中剥夺线程的运行权可能性很小。但是，错误的风险并没有完全消失。如果在负载很重的机器上运行许多线程，那么，即使删除了打印语句，程序依然会出
错。这种错误可能会几分钟、几小时或几天出现一次。坦白地说，对程序员而言，很少有比无规律出现错误更糟的事情了。

真正的问题是 transfer 方法的执行过程中可能会被中断。如果能够确保线程在失去控制之前方法运行完成，那么银行账户对象的状态永远不会出现讹误。

锁对象

有两种机制防止代码块受并发访问的干扰。Java语言提供一个 synchronized 关键字达到这一目的，并且 Java SE 5.0 引入了 ReentrantLock 类。

synchronized 关键字自动提供一个锁以及相关的 “条件”，对于大多数需要显式锁的情况，这是很便利的。java.util.concurrent 框架为这些基础机制提供独立的类。

用 ReentrantLock 保护代码块的基本结构如下：

myLock.lock(); // ReentrantLock 对象获得锁
try {
    // 临界区
} finally {
    myLock.unlock(); // ReentrantLock 对象释放锁
}

这一结构确保任何时刻只有一个线程进人临界区。一旦一个线程封锁了锁对象，其他任何线程都无法通过 lock 语句。当其他线程调用 lock 时，它们被阻塞，直到第一个线程释放锁对象。

警告：把解锁操作括在 finally 子句之内是至关重要的。如果在临界区的代码抛出异常，锁必须被释放。否则，其他线程将永远阻塞。

如果使用锁，就不能使用带资源的 try 语句。首先，解锁方法名不是 close 。不过，即使将它重命名，带资源的 try 语句也无法正常工作。它的首部希望声明一个新变量。但是如果使用一个锁，你可能想使用多个线程共享的那个变量（而不是新变量）

为 Bank 类添加锁：

private Lock bankLock = new ReentrantLock();

注意每一个 Bank 对象有自己的 ReentrantLock 对象。如果两个线程试图访问同一个Bank 对象，那么锁以串行方式提供服务。但是，如果两个线程访问不同的 Bank 对象，每一个线程得到不同的锁对象，两个线程都不会发生阻塞。本该如此，因为线程在操纵不同的 Bank 实例的时候，线程之间不会相互影响。

锁是 可重入 的，因为线程可以重复地获得已经持有的锁。锁保持一个 持有计数（ hold count ) 来跟踪对 lock 方法的嵌套调用。线程在每一次调用 lock 都要调用 unlock 来释放锁。由于这一特性，被一个锁保护的代码可以调用另一个使用相同的锁的方法。

例如，transfer 方法调用 getTotalBalance 方法，这也会封锁 bankLock 对象，此时 bankLock 对象的持有计数为 2 。当 getTotalBalance 方法退出的时候，持有计数变回 1。当 transfer 方法退出的时候，持有计数变为 0。线程释放锁。

通常，可能想要保护需若干个操作来更新或检查共享对象的代码块。要确保这些操作完成后，另一个线程才能使用相同对象。

警告：要留心临界区中的代码，不要因为异常的抛出而跳出临界区。如果在临界区代码结束之前抛出了异常， finally 子句将释放锁，但会使对象可能处于一种受损状态。

`java.util.concurrent.locks.Lock` 方法名称	方法声明	描述
`lock`	`void lock();`	获取这个锁；如果锁同时被另一个线程拥有则发生阻塞
`unlock`	`void unlock();`	释放这个锁

`java.util.concurrent.locks.ReentrantLock` 方法名称	方法声明	描述
构造器	`ReentrantLock()`	构建一个可以被用来保护临界区的可重入锁
构造器	`ReentrantLock(boolean fair)`	构建一个带有公平策略的锁。一个公平锁偏爱等待时间最长的线程。但是，这一公平的保证将大大降低性能。所以，默认情况下，锁没有被强制为公平的

警告：听起来公平锁更合理一些，但是使用公平锁比使用常规锁要慢很多。只有当你确实了解自己要做什么并且对于你要解决的问题有一个特定的理由必须使用公平锁的时候，才可以使用公平锁。即使使用公平锁，也无法确保线程调度器是公平的。如果线程调度器选择忽略一个线程，而该线程为了这个锁已经等待了很长时间，那么就没有机会公平地处理这个锁了。

条件对象

通常，线程进入临界区，却发现在某一条件满足之后它才能执行。要使用一个条件对象来管理那些已经获得了一个锁但是却不能做有用工作的线程。

由于历史的原因， 条件对象 经常被称为 条件变量（ conditional variable )

一个锁对象可以有一个或多个相关的条件对象。你可以用 newCondition 方法获得一个条件对象。习惯上给每一个条件对象命名为可以反映它所表达的条件的名字。例如，转账前，设置一个条件对象来表达 “余额充足” 条件。

private Lock bankLock = new ReentrantLock();
private Condition sufficientFunds = bankLock.newCondition();

private void lockTransfer(int from, int to, BigDecimal amount) {
    bankLock.lock();
    try {
        while (accounts[from].compareTo(amount) < 0) {
            sufficientFunds.await();
        }

        accounts[from] = accounts[from].subtract(amount);
        accounts[to] = accounts[to].add(amount);
        BigDecimal totalBalance = getTotalBalance(true);
        if (Double.compare(totalBalance.doubleValue(), 100000D) != 0) {
            log.info("Thread.currentThread :: {}", Thread.currentThread());
            log.info("amount {} ,from {} ,to {}", amount, from, to);
            log.error("Total Balance :: {}", totalBalance);
        } else {
            log.info("Total Balance ok ! transfer amount {} ,from {} ,to {}", amount, from, to);
        }

        sufficientFunds.signalAll();
    } catch (InterruptedException e) {
        log.error("转账异常", e);
    } finally {
        bankLock.unlock();
    }
}

如果 transfer 方法发现余额不足，它调用 await 方法阻塞当前线程，并放弃锁。我们希望这样可以使得另一个线程可以进行增加账户余额的操作

等待获得锁的线程和调用 await 方法的线程存在本质上的不同。一旦一个线程调用 await 方法，它进入该条件的等待集。当锁可用时，该线程不能马上解除阻塞。相反，它处于阻塞状态，直到另一个线程调用同一条件上的 signalAll 方法时为止。

signalAll 方法重新激活因为这一条件而等待的所有线程。当这些线程从等待集当中移出时，它们再次成为可运行的，调度器将再次激活它们。同时，它们将试图重新进入该对象。一旦锁成为可用的，它们中的某个将从 await 调用返回，获得该锁并从被阻塞的地方继续执行。

此时，线程应该再次测试该条件。由于无法确保该条件被满足，signalAll 方法仅仅是通知正在等待的线程：此时有可能已经满足条件，值得再次去检测该条件。

通常，对 await 的调用应该在如下形式的循环体中：

while (accounts[from].compareTo(amount) < 0) {
    sufficientFunds.await();
}

至关重要的是最终需要某个其他线程调用 signalAll 方法。当一个线程调用 await 时，它没有办法重新激活自身。它寄希望于其他线程。如果没有其他线程来重新激活等待的线程，它就永远不再运行了。这将导致令人不快的 死锁（deadlock) 现象 。如果所有其他线程被阻塞，最后一个活动线程在解除其他线程的阻塞状态之前就调用 await 方法，那么它也被阻塞。没有任何线程可以解除其他线程的阻塞，那么该程序就挂起了。

应该何时调用 signalAll 呢？经验上讲，在对象的状态有利于等待线程的方向改变时调用 signalAll 。例如，当一个账户余额发生改变时，等待的线程会应该有机会检查余额。

注意调用 signalAll 不会立即激活一个等待线程。它仅仅解除等待线程的阻塞，以便这些线程可以在当前线程退出同步方法之后，通过竞争实现对对象的访问。

另一个方法 signal , 则是随机解除等待集中某个线程的阻塞状态。这比解除所有线程的阻塞更加有效，但也存在危险。如果随机选择的线程发现自己仍然不能运行，那么它再次被阻塞。如果没有其他线程再次调用 signal , 那么系统就死锁了。

警告：当一个线程拥有某个条件的锁时，它仅仅可以在该条件上调用 await 、signalAll 或 signal 方法。

`java.util.concurrent.locks.Lock` 方法名称	方法声明	描述
`newCondition`	`Condition newCondition();`	返回一个与该锁相关的条件对象

`java.util.concurrent.locks.Condition` 方法名称	方法声明	描述
`await`	`void await() throws InterruptedException;`	将该线程放到条件的等待集中
`signalAll`	`void signalAll();`	解除该条件的等待集中的所有线程的阻塞状态
`signal`	`void signal();`	从该条件的等待集中随机地选择一个线程，解除其阻塞状态

`synchronized` 关键字

总结一下有关锁和条件的关键之处：

锁用来保护代码片段，任何时刻只能有一个线程执行被保护的代码
锁可以管理试图进入被保护代码段的线程
锁可以拥有一个或多个相关的条件对象
每个条件对象管理那些已经进入被保护的代码段但还不能运行的线程

Lock 和 Condition 接口为程序设计人员提供了高度的锁定控制。然而，大多数情况下，并不需要那样的控制，并且可以使用一种嵌入到 Java 语言内部的机制。从 1.0 版开始，Java 中的每一个对象都有一个内部锁。如果一个方法用 synchronized 关键字声明，那么对象的锁将保护整个方法。也就是说，要调用该方法，线程必须获得内部的对象锁。

public synchronized void method() {
    // method body
}

等价于

public void method() {
    this.intrinsicLock.lock();
    try {
        // method body
    } finally {
        this.intrinsicLock.unlock();
    }
}

内部对象锁只有一个相关条件。wait 方法添加一个线程到等待集中，notifyAll / notify 方法解除等待线程的阻塞状态。换句话说，调用 wait 或 notityAll 等价于

intrinsicCondition.await();
intrinsicCondition.signalAll();

wait、notifyAll 以及 notify 方法是 Object 类的 final 方法。Condition 方法必须被命名为 await、signalAll 和 signal 以便它们不会与那些方法发生冲突。

可以看到，使用 synchronized 关键字来编写代码要简洁得多。当然，要理解 synchronized 关键字，必须了解每一个对象有一个内部锁，并且该锁有一个内部条件。由锁来管理那些试图进入 synchronized 方法的线程，由条件来管理那些调用 wait 的线程。

将静态方法声明为 synchronized 也是合法的。如果调用这种方法，该方法获得相关的类对象的内部锁。此时，没有其他线程可以调用同一个类的这个或任何其他的同步静态方法。

内部锁和条件存在一些局限。包括：

不能中断一个正在试图获得锁的线程
试图获得锁时不能设定超时
每个锁仅有单一的条件，可能是不够的

在代码中应该使用哪一种？ Lock 和 Condition 对象还是同步方法？下面是一些建议：

最好既不使用 Lock / Condition 也不使用 synchronized 关键字。在许多情况下你可以使用 java.util.concurrent 包中的一种机制，它会为你处理所有的加锁
如果 synchronized 关键字适合你的程序，那么请尽量使用它，这样可以减少编写的代码数量，减少出错的几率
如果特别需要 Lock / Condition 结构提供的独有特性时，才使用 Lock / Condition

`java.lang.Object` 方法名称	方法声明	描述
`notifyAll`	`public final native void notifyAll();`	解除那些在该对象上调用 `wait` 方法的线程的阻塞状态。该方法只能在同步方法或同步块内部调用。如果当前线程不是对象锁的持有者，该方法拋出一个 `IllegalMonitorStateException` 异常
`notify`	`public final native void notify();`	随机选择一个在该对象上调用 `wait` 方法的线程，解除其阻塞状态。该方法只能在一个同步方法或同步块中调用。如果当前线程不是对象锁的持有者，该方法抛出一个 `IllegalMonitorStateException` 异常
`wait`	`public final void wait() throws InterruptedException`	导致线程进入等待状态直到它被通知。该方法只能在一个同步方法中调用。如果当前线程不是对象锁的持有者，该方法拋出一个 `IllegalMonitorStateException` 异常
`wait`	`public final native void wait(long timeout) throws InterruptedException;` `public final void wait(long timeout, int nanos) throws InterruptedException`	导致线程进入等待状态直到它被通知或者经过指定的时间。这些方法只能在一个同步方法中调用。如果当前线程不是对象锁的持有者该方法拋出一个 `IllegalMonitorStateException` 异常 `nanos` - 纳秒数，< 1000000

同步阻塞

每一个 Java 对象有一个锁。线程可以通过调用同步方法获得锁。还有另一种机制可以获得锁，通过进入一个同步阻塞。当线程进入如下形式的阻塞：

synchronized (obj) {
    // 临界区
}

有时会发现 “特殊的” 锁，例如：

private Object lock = new Object();

synchronized (lock) {
    // 临界区
}

在此，lock 对象被创建仅仅是用来使用每个 Java 对象持有的锁。

有时程序员使用一个对象的锁来实现额外的原子操作，实际上称为 客户端锁定（clientside locking)

public void transfer(Vector<Double> accounts, int from, int to, int amount) {
    accounts.set(from, accounts.get(from) - amount);
    accounts.set(to, accounts.get(to) + amount);
}

Vector 类的 get 和 set 方法是同步的，但是，这对于我们并没有什么帮助。在第一次对 get 的调用已经完成之后，一个线程完全可能在 transfer 方法中被剥夺运行权。于是，另一个线程可能在相同的存储位置存入不同的值。但是，我们可以截获这个锁：

public void transfer(Vector<Double> accounts, int from, int to, int amount) {
    synchronized (accounts) {
        accounts.set(from, accounts.get(from) - amount);
        accounts.set(to, accounts.get(to) + amount);
    }
}

这个方法可以工作，但是它完全依赖于这样一个事实， Vector 类对自己的所有可修改方法都使用内部锁。然而，这是真的吗？ Vector 类的文档没有给出这样的承诺。不得不仔细研究源代码并希望将来的版本能介绍非同步的可修改方法。如你所见， 客户端锁定是非常脆弱的，通常不推荐使用

监视器概念

锁和条件是线程同步的强大工具，但是，严格地讲，它们不是面向对象的。多年来，研究人员努力寻找一种方法，可以在不需要程序员考虑如何加锁的情况下，就可以保证多线程的安全性。最成功的解决方案之一是 监视器（monitor)，这一概念最早是由 PerBrinchHansen
和 Tony Hoare 在 20 世纪 70 年代提出的。用 Java 的术语来讲，监视器具有如下特性：

监视器是只包含私有域的类
每个监视器类的对象有一个相关的锁
使用该锁对所有的方法进行加锁。换句话说，如果客户端调用 obj.method() , 那么 obj 对象的锁是在方法调用开始时自动获得，并且当方法返回时自动释放该锁。因为所有的域是私有的，这样的安排可以确保一个线程在对对象操作时，没有其他线程能访问该域
该锁可以有任意多个相关条件

监视器的早期版本只有单一的条件，使用一种很优雅的句法。可以简单地调用 await accounts[from] >= balance 而不使用任何显式的条件变量。然而，研究表明盲目地重新测试条件是低效的。显式的条件变量解决了这一问题。每一个条件变量管理一个独立的线程集

Java 设计者以不是很精确的方式采用了监视器概念， Java 中的每一个对象有一个内部的锁和内部的条件。如果一个方法用 synchronized 关键字声明，那么，它表现的就像是一个监视器方法。通过调用 wait / notifyAll /notify 来访问条件变量。
然而，在下述的 3 个方面 Java 对象不同于监视器，从而使得线程的安全性下降：

域不要求必须是 private
方法不要求必须是 synchronized
内部锁对客户是可用的

`volatile` 域

使用现代的处理器与编译器，出错的可能性很大：

多处理器的计算机能够暂时在寄存器或本地内存缓冲区中保存内存中的值。结果是，运行在不同处理器上的线程可能在同一个内存位置取到不同的值
编译器可以改变指令执行的顺序以使吞吐量最大化。这种顺序上的变化不会改变代码语义，但是编译器假定内存的值仅仅在代码中有显式的修改指令时才会改变。然而，内存的值可以被另一个线程改变

如果你使用锁来保护可以被多个线程访问的代码，那么可以不考虑这种问题。 编译器被要求通过在必要的时候刷新本地缓存来保持锁的效应，并且不能不正当地重新排序指令。

Brian Goetz 给出了下述 “同步格言”： “ 如果向一个变量写入值，而这个变量接下来可能会被另一个线程读取；或者，从一个变量读值，而这个变量可能是之前被另一个线程写入的，此时必须使用同步”。

volatile 关键字为实例域的同步访问提供了一种免锁机制。如果声明一个域为 volatile , 那么编译器和虚拟机就知道该域是可能被另一个线程并发更新的。

警告： volatile 变量不能提供原子性。例如，方法

private volatile boolean done;

public void flipDone() {
    done = !done;
}

不能确保翻转域中的值。不能保证读取、翻转和写入不被中断。

`final` 变置

还有一种情况可以安全地访问一个共享域，即这个域声明为 final 时。

final Map<String, Double> accounts = new HashMap<>();

其他线程会在构造函数完成构造之后才看到这个 accounts 变量。

如果不使用 final ，就不能保证其他线程看到的是 accounts 更新后的值，它们可能都只是看到 null , 而不是新构造的 HashMap 。

当然，对这个映射表的操作并不是线程安全的。如果多个线程在读写这个映射表，仍然需要进行同步。

原子性

假设对共享变量除了赋值之外并不完成其他操作，那么可以将这些共享变量声明为 volatile

java.util.concurrent.atomic 包中有很多类使用了很高效的机器级指令（而不是使用锁）来保证其他操作的原子性。例如， AtomicInteger 类提供了方法 incrementAndGet 和 decrementAndGet , 它们分别以原子方式将一个整数自增或自减。

有很多方法可以以原子方式设置和增减值，不过，如果希望完成更复杂的更新，就必须使用 compareAndSet 方法。例如，假设希望跟踪不同线程观察的最大值。下面的代码是不可行的：

public static AtomicLong largest = new AtomicLong();

// 在线程中
largest.set(Math.max(largest.get(), observed));

这个更新不是原子的。实际上，应当在一个循环中计算新值和使用 compareAndSet :

do {
    oldValue = largest.get();
    newValue = Math.max(oldValue, observed);
} while (largest.compareAndSet(oldValue, newValue));

如果另一个线程也在更新 largest ，就可能阻止这个线程更新。这样一来， compareAndSet 会返回 false , 而不会设置新值。在这种情况下，循环会更次尝试，读取更新后的值，并尝试修改。最终，它会成功地用新值替换原来的值。这听上去有些麻烦，不过 compareAndSet 方法会映射到一个处理器操作，比使用锁速度更快。

在 Java SE 8 中，不再需要编写这样的循环样板代码。实际上，可以提供一个 lambda 表达式更新变量，它会为你完成更新。对于这个例子，我们可以调用：

largest.updateAndGet(x -> Math.max(x, observed));
// 或者
largest.accumulateAndGet(observed, Math::max);

accumulateAndGet 方法利用一个二元操作符来合并原子值和所提供的参数。

getAndUpdate 和 getAndAccumulate 方法可以返回原值。

类 AtomicInteger 、AtomicIntegerArray、AtomicIntegerFieldUpdater、AtomicLongArray、AtomicLongFieldUpdater、AtomicReference、 AtomicReferenceArray 和 AtomicReferenceFieldUpdater 也提供了这些方法。

如果有大量线程要访问相同的原子值，性能会大幅下降，因为乐观更新需要太多次重试。 Java SE 8 提供了 LongAdder 和 LongAccumulator 类来解决这个问题。LongAdder 包括多个变量（加数，) 其总和为当前值。可以有多个线程更新不同的加数，线程个数增加时会自动提供新的加数。通常情况下，只有当所有工作都完成之后才需要总和的值，对于这种情况，这种方法会很高效。性能会有显著的提升。

如果认为可能存在大量竞争，只需要使用 LongAdder 而不是 AtomicLong 。方法名稍有区别。调用 increment 让计数器自增，或者调用 add 来增加一个量，或者调用 sum 来获取总和。

increment 方法不会返回原值。这样做会消除将求和分解到多个加数所带来的性能提升。

LongAccumulator 将这种思想推广到任意的累加操作。在构造器中，可以提供这个操作以及它的零元素。要加人新的值，可以调用 accumulate 。调用 get 来获得当前值。下面的代码可以得到与 LongAdder 同样的效果：

LongAccumulator adder = new LongAccumulator(Long::sum, 0);
adder.accumulate(value);

在内部，这个累加器包含变量 a1, a2， … an 。每个变量初始化为零元素（这个例子中零元素为 0 )

如果选择一个不同的操作，可以计算最小值或最大值。一般地，这个操作必须满足结合律和交换律。这说明，最终结果必须独立于所结合的中间值的顺序。

另外 DoubleAdder 和 DoubleAccumulator 也采用同样的方式，只不过处理的是 double 值。

死锁

有可能会因为每一个线程要等待而导致所有线程都被阻塞。这样的状态称为 死锁（deadlock )

遗憾的是，Java 编程语言中没有任何东西可以避免或打破这种死锁现象。必须仔细设计程序，以确保不会出现死锁。

线程局部变量（ `ThreadLocal` ）

有时可能要避免共享变量，使用 ThreadLocal 辅助类为各个线程提供各自的实例。例如，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 辅助类为各个线程提供一个单独的生成器，不过 Java SE 7 还另外提供了一个便利类。只需要做以下调用：

int random = ThreadLocalRandom.current().nextInt(upperBound);

ThreadLocalRandom.current() 调用会返回特定于当前线程的 Random 类实例。

`java.lang.ThreadLocal<T>` 方法名称	方法声明	描述
`get`	`public T get()`	得到这个线程的当前值。如果是首次调用 `get` , 会调用 `initialValue` 来得到这个值
`initialValue`	`protected T initialValue()`	应覆盖这个方法来提供一个初始值。默认情况下，这个方法返回 `null`
`set`	`public void set(T value)`	为这个线程设置一个新值
`remove`	`public void remove()`	删除对应这个线程的值
`withInitial`	`public static <S> ThreadLocal<S> withInitial(Supplier<? extends S> supplier)`	创建一个线程局部变量，其初始值通过调用给定的 `supplier` 生成

`java.util.concurrent.ThreadLocalRandom` 方法名称	方法声明	描述
`current`	`public static ThreadLocalRandom current()`	返回特定于当前线程的 `Random` 类实例

锁测试与超时

线程在调用 lock 方法来获得另一个线程所持有的锁的时候，很可能发生阻塞。应该更加谨慎地申请锁。tryLock 方法试图申请一个锁，在成功获得锁后返回 true , 否则，立即返回 false , 而且线程可以立即离开去做其他事情。

if (myLock.tryLock()) {
    // 线程获取到锁
    try {
        // do something
    } finally {
        myLock.unlock();
    }
} else {
    
}

调用 tryLock 时，使用超时参数

if (myLock.tryLock(100, TimeUnit.MILLISECONDS)) {

}

lock 方法不能被中断。如果一个线程在等待获得一个锁时被中断，中断线程在获得锁之前一直处于阻塞状态。如果出现死锁，那么，lock 方法就无法终止。

如果调用带有用超时参数的 tryLock , 那么如果线程在等待期间被中断，将抛出 InterruptedException 异常。这是一个非常有用的特性，因为允许程序打破死锁。

也可以调用 lockInterruptibly 方法。它就相当于一个超时设为无限的 tryLock 方法。

在等待一个条件时，也可以提供一个超时：

myCondition.await(100, TimeUnit.MILLISECONDS);

如果一个线程被另一个线程通过调用 signalAll 或 signal 激活，或者超时时限已达到，或者线程被中断，那么 await 方法将返回。

如果等待的线程被中断， await 方法将抛出一个 InterruptedException 异常。在你希望出现这种情况时线程继续等待（可能不太合理) ，可以使用 awaitUninterruptibly 方法代替 await 。

`java.util.concurrent.locks.Lock` 方法名称	方法声明	描述
`tryLock`	`boolean tryLock();`	尝试获得锁而没有发生阻塞；如果成功返回 `true` 。这个方法会抢夺可用的锁，即使该锁有公平加锁策略，即便其他线程已经等待很久也是如此
`tryLock`	`boolean tryLock(long time, TimeUnit unit) throws InterruptedException;`	尝试获得锁，阻塞时间不会超过给定的值；如果成功返回 `true`
`lockInterruptibly`	`void lockInterruptibly() throws InterruptedException;`	获得锁，但是会不确定地发生阻塞。如果线程被中断，抛出一个 `InterruptedException` 异常

`java.util.concurrent.locks.Condition` 方法名称	方法声明	描述
`await`	`boolean await(long time, TimeUnit unit) throws InterruptedException;`	进入该条件的等待集，直到线程从等待集中移出或等待了指定的时间之后才解除阻塞。如果因为等待时间到了而返回就返回 `false` , 否则返回 `true`
`awaitUninterruptibly`	`void awaitUninterruptibly();`	进入该条件的等待集，直到线程从等待集移出才解除阻塞。如果线程被中断，该方法不会抛出 `InterruptedException` 异常

读 / 写锁（ `ReentrantReadWriteLock` ）

java.util.concurrent.locks 包定义了两个锁类，我们已经讨论的 ReentrantLock 类和 ReentrantReadWriteLock 类。如果很多线程从一个数据结构读取数据而很少线程修改其中数据的话，读写锁是十分有用的。在这种情况下，允许对读线程共享访问是合适的。当然，写线程依然必须是互斥访问的。

使用读 / 写锁的必要步骤：

构造一个 ReentrantReadWriteLock 对象

private ReentrantReadWriteLock rwl = new ReentrantReadWriteLock();

抽取读锁和写锁

private Lock readLock = rwl.readLock();
private Lock writeLock = rwl.writeLock();

对所有的读方法加读锁

public double getTotalBalance() {
    readLock.lock();
    try {
        // ...
    } finally {
        readLock.unlock();
    }
    // ...
}

对所有的写方法加写锁

public void transfer(int from, int to, BigDecimal amount) {
    writeLock.lock();
    try {
        // ...
    } finally {
        writeLock.unlock();
    }
}

`java.util.concurrent.locks.ReentrantReadWriteLock` 方法名称	方法声明	描述
`readLock`	`public ReentrantReadWriteLock.ReadLock readLock()`	得到一个可以被多个读操作共用的读锁，但会排斥所有写操作
`writeLock`	`public ReentrantReadWriteLock.WriteLock writeLock()`	得到一个写锁，排斥所有其他的读操作和写操作

为什么弃用 `stop` 和 `suspend` 方法

初始的 Java 版本定义了一个 stop 方法用来终止一个线程，以及一个 suspend 方法用来阻塞一个线程直至另一个线程调用 resume 。stop 和 suspend 方法有一些共同点：都试图控制一个给定线程的行为。

stop、 suspend 和 resume 方法已经弃用。stop 方法天生就不安全，经验证明 suspend 方法会经常导致死锁。

当线程要终止另一个线程时，无法知道什么时候调用 stop 方法是安全的，什么时候导致对象被破坏。因此，该方法被弃用了。在希望停止线程的时候应该中断线程，被中断的线程会在安全的时候停止。

如果想安全地挂起线程，引人一个变量 suspendRequested 并在 run 方法的某个安全的地方测试它，安全的地方是指该线程没有封锁其他线程需要的对象的地方。当该线程发现 suspendRequested 变量已经设置，将会保持等待状态直到它再次获得为止。

阻塞队列（ `BlockingQueue` ）

上面已经看到了形成 Java 并发程序设计基础的底层构建块。对于实际编程来说，应该尽可能远离底层结构。使用由并发处理的专业人士实现的较高层次的结构要方便得多、要安全得多

对于许多线程问题，可以通过使用一个或多个队列以优雅且安全的方式将其形式化。生产者线程向队列插人元素，消费者线程则取出它们。使用队列，可以安全地从一个线程向另一个线程传递数据。

当试图向队列添加元素而队列已满，或是想从队列移出元素而队列为空的时候， 阻塞队列（ blocking queue ) 导致线程阻塞。在协调多个线程之间的合作时，阻塞队列是一个有用的工具。工作者线程可以周期性地将中间结果存储在阻塞队列中。其他的工作者线程移出中间结果并进一步加以修改。队列会自动地平衡负载。如果第一个线程集运行得比第二个慢，第二个线程集在等待结果时会阻塞。如果第一个线程集运行得快，它将等待第二个队列集赶上来。

阻塞队列方法：

方法	正常行为	特殊情况下的行为
`add`	添加一个元素	如果队列满，则抛出 `IllegalStateException` 异常
`element`	返回队列的头元素	如果队列空，抛出 `NoSuchElementException` 异常
`offer`	添加一个元素并返回 `true`	如果队列满，返回 `false`
`peek`	返回队列的头元素	如果队列空，则返回 `null`
`poll`	移出并返回队列的头元素	如果队列空，则返回 `null`
`put`	添加一个元素	如果队列满，则阻塞
`remove`	移出并返回头元素	如果队列空，抛出 `NoSuchElementException` 异常
`take`	移出并返回头元素	如果队列空，则阻塞

阻塞队列方法分为以下 3 类，这取决于当队列满或空时它们的响应方式。如果将队列当作线程管理工具来使用，将要用到 put 和 take 方法。当试图向满的队列中添加或从空的队列中移出元素时，add、 remove 和 element 操作抛出异常。当然，在一个多线程程序中，队列会在任何时候空或满，因此，一定要使用 offer、 poll 和 peek 方法作为替代。这些方法如果不能完成任务，只是给出一个错误提示而不会抛出异常

poll 和 peek 方法返回空来指示失败。因此，向这些队列中插入 null 值是非法的

java.util.concurrent 包提供了阻塞队列的几个变种。默认情况下，LinkedBlockingQueue 的容量是没有上边界的，但是，也可以选择指定最大容量。LinkedBlockingDeque 是一个双端的版本。ArrayBlockingQueue 在构造时需要指定容量，并且有一个可选的参数来指定是否需要公平性。若设置了公平参数，则那么等待了最长时间的线程会优先得到处理。通常，公平性会降低性能，只有在确实非常需要时才使用它。

PriorityBlockingQueue 是一个带优先级的队列，而不是先进先出队列。元素按照它们的优先级顺序被移出。该队列是没有容量上限，但是，如果队列是空的，取元素的操作会阻塞。

DelayQueue 包含实现 Delayed 接口的对象

public class DelayQueue<E extends Delayed> extends AbstractQueue<E> implements BlockingQueue<E>

public interface Delayed extends Comparable<Delayed> {
    long getDelay(TimeUnit unit);
}

getDelay 方法返回对象的残留延迟。负值表示延迟已经结束。元素只有在延迟用完的情况下才能从 DelayQueue 移除。还必须实现 compareTo 方法。DelayQueue 使用该方法对元素进行排序。

JavaSE 7 增加了一个 TransferQueue 接口，允许生产者线程等待，直到消费者准备就绪可以接收一个元素。如果生产者调用 q.transfer(item); 这个调用会阻塞，直到另一个线程将元素（item) 删除。LinkedTransferQueue 类实现了这个接口。

`java.util.concurrent.ArrayBlockingQueue<E>` 方法名称	方法声明	描述
构造器	`public ArrayBlockingQueue(int capacity)` `public ArrayBlockingQueue(int capacity, boolean fair)`	构造一个带有指定的容量和公平性设置的阻塞队列。该队列用循环数组实现

`java.util.concurrent.LinkedBlockingQueue<E>` 方法名称	方法声明	描述
构造器	`public LinkedBlockingQueue()` `public LinkedBlockingQueue(int capacity)`	根据指定容量（默认为 `Integer.MAX_VALUE` ）构建一个有限的阻塞队列，用链表实现

`java.util.concurrent.LinkedBlockingDeque<E>` 方法名称	方法声明	描述
构造器	`public LinkedBlockingDeque()` `public LinkedBlockingDeque(int capacity)`	根据指定容量（默认为 `Integer.MAX_VALUE` ）构建一个有限的双向阻塞队列，用链表实现

`java.util.concurrent.DelayQueue<E extends Delayed> extends AbstractQueue<E>` 方法名称	方法声明	描述
构造器	`public DelayQueue()`	构造一个包含 `Delayed` 元素的无界的阻塞时间有限的阻塞队列。只有那些延迟已经超过时间的元素可以从队列中移出

`java.util.concurrent.Delayed` 方法名称	方法声明	描述
`getDelay`	`long getDelay(TimeUnit unit);`	得到该对象的延迟，用给定的时间单位进行度量

`java.util.concurrent.PriorityBlockingQueue<E> extends AbstractQueue<E>` 方法名称	方法声明	描述
构造器	`public PriorityBlockingQueue()` `public PriorityBlockingQueue(int capacity)` `public PriorityBlockingQueue(int initialCapacity, Comparator<? super E> comparator)`	构造一个无边界阻塞优先队列，用堆实现 `initialCapacity` ：优先队列的初始容量。默认值是 `11` `comparator` ：用来对元素进行比较的比较器，如果没有指定，则元素必须实现 `Comparable` 接口

`java.util.concurrent.BlockingQueue<E>` 方法名称	方法声明	描述
`put`	`void put(E e) throws InterruptedException;`	添加元素，在必要时阻塞
`take`	`E take() throws InterruptedException;`	移除并返回头元素，必要时阻塞
`offer`	`boolean offer(E e, long timeout, TimeUnit unit) throws InterruptedException;`	添加给定的元素，如果成功返回 true，如果必要时阻塞，直至元素已经被添加或超时
`poll`	`E poll(long timeout, TimeUnit unit) throws InterruptedException;`	移除并返回头元素，必要时阻塞，直至元素可用或超时用完。失败时返回 null

`java.util.concurrent.BlockingDeque<E>` 方法名称	方法声明	描述
`putFirst` `putLast`	`void putFirst(E e) throws InterruptedException;` `void putLast(E e) throws InterruptedException;`	添加元素，必要时阻塞
`takeFirst` `takeLast`	`E takeFirst() throws InterruptedException;` `E takeLast() throws InterruptedException;`	移除并返回头元素或尾元素，必要时阻塞
`offerFirst` `offerLast`	`boolean offerFirst(E e);` `boolean offerLast(E e);`	添加给定的元素，成功时返回 `true` ，必要时阻塞直至元素被添加或超时
`pollFirst` `pollLast`	`E pollFirst(long timeout, TimeUnit unit) throws InterruptedException;` `E pollLast(long timeout, TimeUnit unit) throws InterruptedException;`	移动并返回头元素或尾元素，必要时阻塞，直至元素可用或超时。失败时返回 `null`

`java.util.concurrent.TransferQueue<E>` 方法名称	方法声明	描述
`tryTransfer` `transfer`	`boolean tryTransfer(E e);` `void transfer(E e) throws InterruptedException;`	传输一个值，或者尝试在给定的超时时间内传输这个值，这个调用将阻塞，直到另一个线程将元素删除。第二个方法会在调用成功时返回 `true`

线程安全的集合

可以通过提供锁来保护共享数据结构，但是选择线程安全的实现作为替代可能更容易些。

阻塞队列就是线程安全的集合。

高效的映射、集和队列

java.util.concurrent 包提供了映射、有序集和队列的高效实现：ConcurrentHashMap、ConcurrentSkipListMap、ConcurrentSkipListSet 和 ConcurrentLinkedQueue。

这些集合使用复杂的算法，通过允许并发地访问数据结构的不同部分来使竞争极小化。

请注意，与大多数集合不同，size 方法不是恒定时间操作。由于这些队列的异步特性，确定当前元素的数量需要 O(n) 遍历。此外，如果在此方法执行期间添加或删除元素，则返回的结果可能不准确。因此，这种方法在并发应用程序中通常不是很有用。

有些应用使用庞大的并发散列映射，这些映射太过庞大，以至于无法用 size 方法得到它的大小，因为这个方法只能返回 int 。JavaSE 8 引入了一个 mappingCount 方法可以把大小作为 long 返回。

集合返回 弱一致性（ weakly consistent ) 的迭代器。这意味着迭代器不一定能反映出它们被构造之后的所有的修改，但是，它们不会将同一个值返回两次，也不会拋出 ConcurrentModificationException 异常。

与之形成对照的是，集合如果在迭代器构造之后发生改变，java.util 包中的迭代器（非并发的）将抛出一个 ConcurrentModificationException 异常。

并发的散列映射表，可高效地支持大量的读和一定数量的写。默认情况下，假定可以有多达 16 个写线程同时执行。可以有更多的写线程，但是，如果同一时间多于 16个，其他线程将暂时被阻塞。可以指定更大数目的构造器

散列映射将有相同散列码的所有条目放在同一个 “桶” 中。有些应用使用的散列函数不当，以至于所有条目最后都放在很少的桶中，这会严重降低性能。即使是一般意义上还算合理的散列函数，如 String 类的散列函数，也可能存在问题。例如，攻击者可能会制造大量有相同散列值的字符串，让程序速度减慢。在 JavaSE 8 中，并发散列映射将桶组织为树，而不是列表，键类型实现了 Comparable , 从而可以保证性能为 O(log(n)) 。

`java.util.concurrent.ConcurrentLinkedQueue<E>` 方法名称	方法声明	描述
构造器	`public ConcurrentLinkedQueue()`	构造一个可以被多线程安全访问的无边界非阻塞的队列

`java.util.concurrent.ConcurrentSkipListSet<E>` 方法名称	方法声明	描述
构造器	`public ConcurrentSkipListSet()` `public ConcurrentSkipListSet(Comparator<? super E> comparator)`	构造一个可以被多线程安全访问的有序集。第一个构造器要求元素实现 `Comparable` 接口

`java.util.concurrent.ConcurrentHashMap<K,V>` 方法名称	方法声明	描述
构造器	`public ConcurrentHashMap()` `public ConcurrentHashMap(int initialCapacity)` `public ConcurrentHashMap(int initialCapacity, float loadFactor, int concurrencyLevel)`	构造一个可以被多线程安全访问的散列映射表。 `initialCapacity` ：集合的初始容量。默认值为 16 `loadFactor` ：控制调整：如果每一个桶的平均负载超过这个因子，表的大小会被重新调整。默认值为 0.75 `concurrencyLevel` ：并发写者线程的估计数目

`java.util.concurrent.ConcurrentSkipListMap<K,V>` 方法名称	方法声明	描述
构造器	`public ConcurrentSkipListMap()` `public ConcurrentSkipListMap(Comparator<? super E> comparator)`	构造一个可以被多线程安全访问的有序的映像表。第一个构造器要求键实现`Comparable` 接口

SkipList （跳表） 这种数据结构的设计初衷是作为替换平衡树的一种选择。AVL树有着严格的 O(logN) 的查询效率，但是由于插入过程中可能需要多次旋转，导致插入效率较低，因而才有了在工程界更加实用的红黑树。

但是红黑树有一个问题就是在并发环境下使用不方便，比如需要更新数据时，SkipList 需要更新的部分比较少，锁的东西也更少，而红黑树有个平衡的过程，在这个过程中会涉及到较多的节点，需要锁住更多的节点，从而降低了并发性能。

SkipList 还有一个优势就是实现简单

映射条目的原子更新

作为一个简单的例子，假设多个线程会遇到单词，我们想统计它们的频率。

下面的代码不是线程安全的，可能会有另一个线程在同时更新同一个计数。

ConcurrentHashMap<String, Long> map = new ConcurrentHashMap<>();
String word = "";
Long oldValue = map.get(word);
Long newValue = oldValue == null ? 1 : oldValue + 1;
map.put(word, newValue);

有些程序员很奇怪为什么原本线程安全的数据结构会允许非线程安全的操作。不过有两种完全不同的情况。如果多个线程修改一个普通的 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> 。更新代码如下：

ConcurrentHashMap<String, LongAdder> map = new ConcurrentHashMap<>();
String word = "";

map.putIfAbsent(word, new LongAdder());
map.get(word).increment();

可以组合成：

map.putIfAbsent(word, new LongAdder()).increment();

Java SE 8 提供了一些可以更方便地完成原子更新的方法。调用 compute 方法时可以提供一个键和一个计算新值的函数。这个函数接收键和相关联的值（如果没有值，则为 null ), 它会计算新值。例如，可以如下更新一个整数计数器的映射：

map.compute(word, (k, v) -> v == null ? 1 : v + 1);

ConcurrentHashMap 中不允许有 null 值。有很多方法都使用 null 值来指示映射中某个给定的键不存在

另外还有 computelfPresent 和 computelf bsent 方法，它们分别只在已经有原值的情况下计算新值，或者只有没有原值的情况下计算新值。可以如下更新一个 LongAdder 计数器映射：

map.computeIfAbsent(word, k -> new LongAdder()).increment();

首次增加一个键时通常需要做些特殊的处理。利用 merge 方法可以非常方便地做到这一点。这个方法有一个参数表示键不存在时使用的初始值。否则，就会调用你提供的函数来结合原值与初始值。（与 compute 不同，这个函数不处理键）

map.merge(word, 1L, Long::sum);

如果传入 compute 或 merge 的函数返回 null , 将从映射中删除现有的条目

使用 compute 或 merge 时，要记住你提供的函数不能做太多工作。这个函数运行时，可能会阻塞对映射的其他更新。当然，这个函数也不能更新映射的其他部分。

对并发散列映射的批操作

Java SE 8 为并发散列映射提供了批操作，即使有其他线程在处理映射，这些操作也能安全地执行。批操作会遍历映射，处理遍历过程中找到的元素。无须冻结当前映射的快照。除非你恰好知道批操作运行时映射不会被修改，否则就要把结果看作是映射状态的一个近似

有 3 种不同的操作（ operation ）：

搜索（ search ) 为每个键或值提供一个函数，直到函数生成一个非 null 的结果。然后搜索终止，返回这个函数的结果
归约（ reduce ) 组合所有键或值，这里要使用所提供的一个累加函数
forEach 为所有键或值提供一个函数

每个操作都有 4 个版本：

operationKeys ：处理键
operationValues ：处理值
operation ：处理键和值
operationEntries ：处理 Map.Entry 对象

对于上述各个操作，需要指定一个参数化阈值（ parallelism threshold )。如果映射包含的元素多于这个阈值，就会并行完成批操作。如果希望批操作在一个线程中运行，可以使用阈值 Long.MAX_VALUE 。如果希望用尽可能多的线程运行批操作，可以使用阈值 1 。

以 search 方法为例，ConcurrentHashMap 有以下方法：

public <U> U searchKeys(long parallelismThreshold, Function<? super K, ? extends U> searchFunction)
public <U> U searchValues(long parallelismThreshold, Function<? super V, ? extends U> searchFunction)
public <U> U search(long parallelismThreshold, BiFunction<? super K, ? super V, ? extends U> searchFunction)
public <U> U searchEntries(long parallelismThreshold, Function<Map.Entry<K,V>, ? extends U> searchFunction)

例如，假设我们希望找出第一个出现次数超过 1000 次的单词。需要搜索键和值：

String result = map.search(threshold, (k, v) -> v > 1000 ? k : null);

result 会设置为第一个匹配的单词，如果搜索函数对所有输人都返回 null , 则返回 null 。

forEach 方法有两种形式。第一个只为各个映射条目提供一个消费者函数；第二种形式还有一个转换器函数，这个函数要先提供，其结果会传递到消费者；

map.forEach(threshold, (k, v) -> System.out.println(k + " -> " + v));

map.forEach(threshold, (k, v) -> k + " -> " + v, System.out::println);

转换器可以用作为一个过滤器。只要转换器返回 null , 这个值就会被悄无声息地跳过。例如，下面只打印有大值的条目：

map.forEach(threshold, (k, v) -> v > 1000 ? k + " -> " + v : null, System.out::println);

reduce 操作用一个累加函数组合其输入。例如，可以如下计算所有值的总和：

Long sum = map.reduceValues(threshold, Long::sum);

与 forEach 类似，也可以提供一个转换器函数。可以如下计算最长的键的长度：

Integer maxlength = map.reduceKeys(threshold, String::length, Integer::max);

转换器可以作为一个过滤器，通过返回 null 来排除不想要的输入。

在这里，我们要统计多少个条目的值 > 1000 :

Long count = map.reduceValues(threshold, v -> v > 1000 ? 1L : null, Long::sum);

如果映射为空，或者所有条目都被过滤掉， reduce 操作会返回 null 。如果只有一个元素，则返回其转换结果，不会应用累加器。

对于 int 、 long 和 double 输出还有相应的特殊化操作，分别有后缀 ToInt 、 ToLong 和 ToDouble 。需要把输入转换为一个基本类型值，并指定一个默认值和一个累加器函数。映射为空时返回默认值。

long sum = map.reduceValuesToLong(threshold, Long::longValue, 0, Long::sum);

警告：这些特殊化操作与对象版本的操作有所不同，对于对象版本的操作，只需要考虑一个元素。这里不是返回转换得到的元素，而是将与默认值累加。因此，默认值必须是累加器的零元素。

并发集视图

并没有一个 ConcurrentHashSet 类

静态 newKeySet 方法会生成一个 Set<K> , 这实际上是 ConcurrentHashMap<K, Boolean> 的一个包装器。（所有映射值都为 Boolean.TRUE , 不过因为只是要把它用作一个集，所以并不关心具体的值）

ConcurrentHashMap.KeySetView<String, Boolean> keySetView = ConcurrentHashMap.<String>newKeySet();
Set<String> set1 = ConcurrentHashMap.<String>newKeySet();
Set<String> set2 = ConcurrentHashMap.newKeySet();

如果原来有一个映射，keySet 方法可以生成这个映射的键集。这个集是可变的。如果删除这个集的元素，这个键（以及相应的值）会从映射中删除。不过，不能向键集增加元素，因为没有相应的值可以增加。

Java SE 8 为 ConcurrentHashMap 增加了第二个 keySet 方法，包含一个默认值，可以在为集增加元素时使用：

Set<String> keySet = map.keySet(999L);
boolean add = keySet.add("9999999");
System.out.println(map.get("9999999"));	// 999

写数组的拷贝

CopyOnWriteArrayList 和 CopyOnWriteArraySet 是线程安全的集合， 其中所有的修改线程对底层数组进行复制 。如果在集合上进行迭代的线程数超过修改线程数，这样的安排是很有用的。当构建一个迭代器的时候，它包含一个对当前数组的引用。如果数组后来被修改了，迭代器仍然引用旧数组，但是，集合的数组已经被替换了。因而，旧的迭代器拥有一致的（可能过时的）视图，访问它无须任何同步开销。

并行数组算法

在 Java SE 8中， Arrays 类提供了大量并行化操作。静态 Arrays.parallelSort 方法可以对一个基本类型值或对象的数组排序。

String contents = "Hello World Alice";
String[] words = contents.split("[\\P{L}]+"); // Split along nonletters
Arrays.parallelSort(words);
System.out.println(Arrays.toString(words));     // [Alice, Hello, World]

对对象排序时，可以提供一个 Comparator

Arrays.parallelSort(words, Comparator.comparing(String::length));

对于所有方法都可以提供一个范围的边界，如：

Arrays.parallelSort(values, values.length / 2, values.length);

乍一看，这些方法名中的 parallel 可能有些奇怪，因为用户不用关心排序具体怎样完成。不过，API 设计者希望清楚地指出排序是并行化的。这样一来，用户就会注意避免使用有副作用的比较器。

int[] values = new int[30];
Arrays.parallelSetAll(values, i ->i % 10);
System.out.println(Arrays.toString(values));    // [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9]

还有一个 parallelPrefix 方法，它会用对应一个给定结合操作的前缀的累加结果替换各个数组元素。

int[] values = new int[10];
Arrays.parallelSetAll(values, i -> i % 10 + 1);
System.out.println(Arrays.toString(values));    // [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]

Arrays.parallelPrefix(values, (x, y) -> x * y);

System.out.println(Arrays.toString(values));    // [1, 2, 6, 24, 120, 720, 5040, 40320, 362880, 3628800]

较早的线程安全集合

从 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()) {
        // do something
    }
}

如果使用 “foreach” 循环必须使用同样的代码，因为循环使用了迭代器。注意：如果在迭代过程中，别的线程修改集合，迭代器会失效，抛出 ConcurrentModificationException 异常。同步仍然是需要的，因此并发的修改可以被可靠地检测出来。

最好使用 java.util.concurrent 包中定义的集合，不使用同步包装器中的。特别是，假如它们访问的是不同的桶，由于 ConcurrentHashMap 已经精心地实现了，多线程可以访问它而且不会彼此阻塞。有一个例外是经常被修改的数组列表。在那种情况下，同步的 ArrayList 可以胜过 CopyOnWriteArrayList

`java.util.Collections` 方法名称	方法声明	描述
`synchronizedCollection` `synchronizedList` `synchronizedSet` `synchronizedSortedSet` `synchronizedMap` `synchronizedSortedMap`	`public static <T> Collection<T> synchronizedCollection(Collection<T> c)` `public static <T> List<T> synchronizedList(List<T> list)` `public static <T> Set<T> synchronizedSet(Set<T> s)` `public static <T> SortedSet<T> synchronizedSortedSet(SortedSet<T> s)` `public static <K,V> Map<K,V> synchronizedMap(Map<K,V> m)` `public static <K,V> SortedMap<K,V> synchronizedSortedMap(SortedMap<K,V> m)`	构建集合视图，该集合的方法是同步的

`Callable` 与 `Future`

Runnable 封装一个异步运行的任务，可以把它想象成为一个没有参数和返回值的异步方法。Callable 与 Runnable 类似，但是有返回值。Callable 接口是一个参数化的类型，只有一个方法 call

@FunctionalInterface
public interface Runnable {
    public abstract void run();
}

@FunctionalInterface
public interface Callable<V> {
	V call() throws Exception;
}

类型参数是返回值的类型。例如， Callable<Integer> 表示一个最终返回 Integer 对象的异步计算

Future 保存异步计算的结果。可以启动一个计算，将 Future 对象交给某个线程，然后忘掉它。Future 对象的所有者在结果计算好之后就可以获得它。

public interface Future<V> {
    V get() throws InterruptedException, ExecutionException;
	V get(long timeout, TimeUnit unit) throws InterruptedException, ExecutionException, TimeoutException;
    boolean cancel(boolean mayInterruptIfRunning);
    boolean isCancelled();
    boolean isDone();
}

第一个 get 方法的调用被阻塞，直到计算完成。如果在计算完成之前，第二个方法的调用超时，拋出一个 TimeoutException 异常。如果运行该计算的线程被中断，两个方法都将拋出 InterruptedException 。如果计算已经完成，那么 get 方法立即返回。

如果计算还在进行，isDone 方法返回 false ; 如果完成了，则返回 true

可以用 cancel 方法取消该计算。如果计算还没有开始，它被取消且不再开始。如果计算处于运行之中，那么如果 mayInterruptIfRunning 参数为 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

`java.util.concurrent.Callable<V>` 方法名称	方法声明	描述
`call`	`V call() throws Exception;`	运行一个将产生结果的任务

`java.util.concurrent.Future<V>` 方法名称	方法声明	描述
`get`	`V get() throws InterruptedException, ExecutionException;` `V get(long timeout, TimeUnit unit) throws InterruptedException, ExecutionExcept`	获取结果，如果没有结果可用，则阻塞直到真正得到结果超过指定的时间为止。如果不成功，第二个方法会拋出 `TimeoutException` 异常
`cancel`	`boolean cancel(boolean mayInterruptIfRunning);`	尝试取消这一任务的运行。如果任务已经开始，并且 `mayInterruptIfRunning` 参数值为 `true` ，它就会被中断。如果成功执行了取消操作，返回 `true`
`isCancelled`	`boolean isCancelled();`	如果任务在完成前被取消了，则返回 `true`
`isDone`	`boolean isDone();`	如果任务结束，无论是正常结束、中途取消或发生异常，都返回 `true`

`java.util.concurrent.FutureTask<V>` 方法名称	方法声明	描述
构造器	`public FutureTask(Callable<V> callable)` `public FutureTask(Runnable runnable, V result)`	构造一个既是 `Future<V>` 又是 `Runnable` 的对象

执行器

构建一个新的线程是有一定代价的，因为涉及与操作系统的交互。如果程序中创建了大量的生命期很短的线程，应该使用 线程池（ thread pool ) 。一个线程池中包含许多准备运行的空闲线程。将 Runnable 对象交给线程池，就会有一个线程调用 run 方法。当 run 方法退出时，线程不会死亡，而是在池中准备为下一个请求提供服务。

另一个使用线程池的理由是减少并发线程的数目。创建大量线程会大大降低性能甚至使虚拟机崩溃。如果有一个会创建许多线程的算法，应该使用一个线程数 “固定的” 线程池以限制并发线程的总数。

执行器（ Executors ) 类有许多静态工厂方法用来构建线程池，表中对这些方法进行了汇总

方法	描述
`newCachedThreadPool`	必要时创建新线程；空闲线程会被保留 60 秒
`newFixedThreadPool`	该池包含固定数量的线程；空闲线程会一直被保留
`newSingleThreadExecutor`	只有一个线程的 “池”，该线程顺序执行每一个提交的任务
`newScheduledThreadPool`	用于预定执行而构建的固定线程池，替代 `java.util.Timer`
`newSingleThreadScheduledExecutor`	用于预定执行而构建的单线程 “池”

线程池（ `ThreadPoolExecutor` ）

newCachedThreadPool 方法构建了一个线程池，对于每个任务，如果有空闲线程可用，立即让它执行任务，如果没有可用的空闲线程，则创建一个新线程
newFixedThreadPool 方法构建一个具有固定大小的线程池。如果提交的任务数多于空闲的线程数，那么把得不到服务的任务放置到队列中。当其他任务完成以后再运行它们
newSingleThreadExecutor 是一个退化了的大小为 1 的线程池：由一个线程执行提交的任务，一个接着一个

这 3 个方法返回实现了 ExecutorService 接口的 ThreadPoolExecutor 类的对象。

可用下面的方法之一将一个 Runnable 对象或 Callable 对象提交给 ExecutorService :

public Future<?> submit(Runnable task)
public <T> Future<T> submit(Runnable task, T result)
public <T> 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 对象
如果想要取消一个任务，或如果提交 Callable 对象，那就要保存好返回的 Future 对象
当不再提交任何任务时，调用 shutdown

`java.util.concurrent.Executors` 方法名称	方法声明	描述
`newCachedThreadPool`	`public static ExecutorService newCachedThreadPool()`	返回一个带缓存的线程池，该池在必要的时候创建线程，在线程空闲 60 秒之后终止线程
`newFixedThreadPool`	`public static ExecutorService newFixedThreadPool(int nThreads)`	返回一个线程池，该池中的线程数由参数指定
`newSingleThreadExecutor`	`public static ExecutorService newSingleThreadExecutor()`	返回一个执行器，它在一个单个的线程中依次执行各个任务

`java.util.concurrent.ExecutorService` 方法名称	方法声明	描述
`submit`	`<T> Future<T> submit(Callable<T> task);` `<T> Future<T> submit(Callable<T> task);` `<T> Future<T> submit(Runnable task, T result);`	提交指定的任务去执行
`shutdown`	`void shutdown();`	关闭服务，会先完成已经提交的任务而不再接收新的任务

`java.util.concurrent.ThreadPoolExecutor` 方法名称	方法声明	描述
`getLargestPoolSize`	`public int getLargestPoolSize()`	返回线程池在该执行器生命周期中的最大尺寸

预定执行（ `ScheduledExecutorService` ）

ScheduledExecutorService 接口具有为预定执行（Scheduled Execution ) 或重复执行任务而设计的方法。它是一种允许使用线程池机制的 java.util.Timer 的泛化。Executors 类的 newScheduledThreadPool 和 newSingleThreadScheduledExecutor 方法将返回实现了 ScheduledExecutorService 接口的对象。

可以预定 Runnable 或 Callable 在初始的延迟之后只运行一次。也可以预定一个 Runnable 对象周期性地运行。

`java.util.concurrent.Executors` 方法名称	方法声明	描述
`newScheduledThreadPool`	`public static ScheduledExecutorService newScheduledThreadPool(int corePoolSize)`	返回一个线程池，它使用给定的线程数来调度任务
`newSingleThreadScheduledExecutor`	`public static ScheduledExecutorService newSingleThreadScheduledExecutor()`	返回一个执行器，它在一个单独线程中调度任务

`java.util.concurrent.Executors` 方法名称	方法声明	描述
`schedule`	`public <V> ScheduledFuture<V> schedule(Callable<V> callable, long delay, TimeUnit unit);` `public ScheduledFuture<?> schedule(Runnable command, long delay, TimeUnit unit);`	预定在指定的时间之后执行任务
`scheduleAtFixedRate`	`public ScheduledFuture<?> scheduleAtFixedRate(Runnable command, long initialDelay, long period, TimeUnit unit);`	预定在初始的延迟结束后，周期性地运行给定的任务，周期长度是 `period`
`scheduleWithFixedDelay`	`public ScheduledFuture<?> scheduleWithFixedDelay(Runnable command, long initialDelay, long delay, TimeUnit unit);`	预定在初始的延迟结束后周期性地运行给定的任务，在一次调用完成和下一次调用开始之间有长度为 `delay` 的延迟

scheduleAtFixedRate 和 scheduleWithFixedDelay 的区别：

如果执行耗时小于或等于调度周期，那么两者的效果是一样的
如果执行耗时大于调度周期
- scheduleWithFixedDelay 的下次执行时间是上次执行完毕之后再加 delay 后再执行
- scheduleAtFixedRate 的下次执行时间是上次执行完毕之后立即执行

控制任务组（ `ExecutorCompletionService` ）

将一个执行器服务作为线程池使用，可以提高执行任务的效率。有时，使用执行器有更有实际意义的原因，控制一组相关任务。例如，可以在执行器中使用 shutdownNow 方法取消所有的任务。

invokeAny 方法提交所有对象到一个 Callable 对象的集合中，并返回某个已经完成了的任务的结果。无法知道返回的究竟是哪个任务的结果，也许是最先完成的那个任务的结果。对于搜索问题，如果你愿意接受任何一种解决方案的话，你就可以使用这个方法。例如，假定你需要对一个大整数进行因数分解计算来解码 RSA 密码。可以提交很多任务，每一个任务使用不同范围内的数来进行分解。只要其中一个任务得到了答案，计算就可以停止了。

invokeAll 方法提交所有对象到一个 Callable 对象的集合中，并返回一个 Future 对象的列表，代表所有任务的解决方案。

@SneakyThrows
public static void test1() {
    ExecutorService executorService = Executors.newFixedThreadPool(5);
    List<Callable<Integer>> tasks = new ArrayList<>();
    for (int i = 0; i < 5; i++) {
        final int x = i;
        tasks.add(() -> x);
    }

    Integer result = executorService.invokeAny(tasks);
    System.out.println(result);     // 可能返回 [0, 5)

    executorService.shutdown();
}

@SneakyThrows
public static void test2() {
    ExecutorService executorService = Executors.newFixedThreadPool(5);
    List<Callable<Integer>> tasks = new ArrayList<>();
    for (int i = 0; i < 5; i++) {
        final int x = i;
        tasks.add(() -> x);
    }

    List<Future<Integer>> results = executorService.invokeAll(tasks);
    for (Future<Integer> result : results) {
        System.out.println(result.get());
    }

    executorService.shutdown();
}

使用 for 循环去获取 List<Future> 的缺点是如果第一个任务恰巧花去了很多时间，则可能不得不进行等待。将结果按可获得的顺序保存起来更有实际意义。可以用 ExecutorCompletionService 来进行排列。

用常规的方法获得一个执行器。然后，构建一个 ExecutorCompletionService ，提交任务给完成服务（completion service) 。该服务管理 Future 对象的阻塞队列，其中包含已经提交的任务的执行结果（当这些结果成为可用时) 。

@SneakyThrows
public static void test3() {
    ExecutorService executorService = Executors.newFixedThreadPool(5);
    List<Callable<Integer>> tasks = new ArrayList<>();
    for (int i = 0; i < 5; i++) {
        final int x = 5 - i;
        tasks.add(() -> {
            TimeUnit.SECONDS.sleep(x);
            return x;
        });
    }

    List<Future<Integer>> results = executorService.invokeAll(tasks);
    log.info("get begin");
    for (Future<Integer> result : results) {
        log.info("result :: {}", result.get());
    }
    log.info("get end");

    executorService.shutdown();
}

@SneakyThrows
public static void test4() {
    ExecutorService executorService = Executors.newFixedThreadPool(5);
    ExecutorCompletionService<Integer> executorCompletionService = new ExecutorCompletionService(executorService);

    for (int i = 0; i < 5; i++) {
        final int x = 5 - i;
        executorCompletionService.submit(() -> {
            TimeUnit.SECONDS.sleep(x);
            return x;
        });
    }

    log.info("get begin");
    for (int i = 0; i < 5; i++) {
        log.info("task result :: {}", executorCompletionService.take().get());
    }
    log.info("get end");

    executorService.shutdown();
}

输出结果：

11:52:36.683 [main] INFO v1ch14.ExecutorTest - ====================test3
11:52:41.742 [main] INFO v1ch14.ExecutorTest - get begin
11:52:41.742 [main] INFO v1ch14.ExecutorTest - result :: 5
11:52:41.744 [main] INFO v1ch14.ExecutorTest - result :: 4
11:52:41.744 [main] INFO v1ch14.ExecutorTest - result :: 3
11:52:41.744 [main] INFO v1ch14.ExecutorTest - result :: 2
11:52:41.744 [main] INFO v1ch14.ExecutorTest - result :: 1
11:52:41.744 [main] INFO v1ch14.ExecutorTest - get end
11:52:41.744 [main] INFO v1ch14.ExecutorTest - ====================test4
11:52:41.745 [main] INFO v1ch14.ExecutorTest - get begin
11:52:42.759 [main] INFO v1ch14.ExecutorTest - task result :: 1
11:52:43.760 [main] INFO v1ch14.ExecutorTest - task result :: 2
11:52:44.745 [main] INFO v1ch14.ExecutorTest - task result :: 3
11:52:45.748 [main] INFO v1ch14.ExecutorTest - task result :: 4
11:52:46.749 [main] INFO v1ch14.ExecutorTest - task result :: 5
11:52:46.749 [main] INFO v1ch14.ExecutorTest - get end

从结果中可以看出，ExecutorCompletionService 可以按照任务完成时间来获取。

`java.util.concurrent.ExecutorService` 方法名称	方法声明	描述
`invokeAny`	`<T> T invokeAny(Collection<? extends Callable<T>> tasks) throws InterruptedException, ExecutionException;` `<T> T invokeAny(Collection<? extends Callable<T>> tasks, long timeout, TimeUnit unit) throws InterruptedException, ExecutionException, TimeoutException;`	执行给定的任务，返回其中一个任务的结果。第二个方法若发生超时，抛出一个 `TimeoutException` 异常
`invokeAll`	`<T> List<Future<T>> invokeAll(Collection<? extends Callable<T>> tasks) throws InterruptedException;` `<T> List<Future<T>> invokeAll(Collection<? extends Callable<T>> tasks, long timeout, TimeUnit unit) throws InterruptedException;`	执行给定的任务，返回所有任务的结果。第二个方法若发生超时，拋出一个 `TimeoutException` 异常

`java.util.concurrent.ExecutorCompletionService<V>` 方法名称	方法声明	描述
构造器	`public ExecutorCompletionService(Executor executor)`	构建一个执行器完成服务来收集给定执行器的结果
`submit`	`public Future<V> submit(Callable<V> task)` `public Future<V> submit(Runnable task, V result)`	提交一个任务给底层的执行器
`take`	`public Future<V> take() throws InterruptedException`	移除下一个已完成的结果，如果没有任何已完成的结果可用则阻塞
`poll`	`public Future<V> poll()` `public Future<V> poll(long timeout, TimeUnit unit) throws InterruptedException`	移除下一个已完成的结果，如果没有任何已完成结果可用则返回 null。第二个方法将等待给定的时间

Fork-Join 框架（ `ForkJoinPool` ）

有些应用使用了大量线程，但其中大多数都是空闲的。举例来说，一个 Web 服务器可能会为每个连接分别使用一个线程。另外一些应用可能对每个处理器内核分别使用一个线程，来完成计算密集型任务，如图像或视频处理。Java SE 7 中新引入了 fork-join 框架，专门用来
支持后一类应用。假设有一个处理任务，它可以很自然地分解为子任务

if (problemSize < threshold) {
    // 直接计算出结果
} else {
    // 将计算分解成更小规模的计算，递归完成
}

要采用框架可用的一种方式完成这种递归计算，需要提供一个扩展 RecursiveTask<T> 的类（计算会生成一个类型为 T 的结果）或者提供一个扩展 RecursiveAction 的类（不生成任何结果) 。再覆盖 compute 方法来生成并调用子任务，然后合并其结果。

invokeAll 方法接收到很多任务并阻塞，直到所有这些任务都已经完成。join 方法将生成结果

还有一个 get 方法可以得到当前结果，不过一般不太使用，因为它可能抛出已检查异常，而在 compute 方法中不允许抛出这些异常。

在后台， fork-join 框架使用了一种有效的智能方法来平衡可用线程的工作负载，这种方法称为 工作密取（work stealing) 。每个工作线程都有一个双端队列 ( deque ) 来完成任务。一个工作线程将子任务压入其双端队列的队头。（只有一个线程可以访问队头，所以不需要加锁）。一个工作线程空闲时，它会从另一个双端队列的队尾 “密取” 一个任务。由于大的子任务都在队尾，这种密取很少出现。

实例：统计数组中大于 5000000 的元素的个数

import java.util.concurrent.ForkJoinPool;
import java.util.concurrent.RecursiveTask;
import java.util.function.DoublePredicate;


public class ForkJoinTest {
    public static void main(String[] args) {
        final int SIZE = 10000000;
        double[] numbers = new double[SIZE];
        for (int i = 0; i < SIZE; i++) {
            numbers[i] = i;
        }
        Counter counter = new Counter(numbers, 0, numbers.length, x -> x > 5000000);
        ForkJoinPool pool = new ForkJoinPool();
        pool.invoke(counter);
        System.out.println(counter.join());
    }
}

class Counter extends RecursiveTask<Integer> {
    public static final int THRESHOLD = 1000;
    private double[] values;
    private int from;
    private int to;
    private DoublePredicate filter;

    public Counter(double[] values, int from, int to, DoublePredicate filter) {
        this.values = values;
        this.from = from;
        this.to = to;
        this.filter = filter;
    }

    protected Integer compute() {
        if (to - from < THRESHOLD) {
            int count = 0;
            for (int i = from; i < to; i++) {
                if (filter.test(values[i])) {
                    count++;
                }
            }
            return count;
        } else {
            int mid = (from + to) / 2;
            Counter first = new Counter(values, from, mid, filter);
            Counter second = new Counter(values, mid, to, filter);
            invokeAll(first, second);
            return first.join() + second.join();
        }
    }
}

可完成 Future （ `CompletableFuture` ）

处理非阻塞调用的传统方法是使用事件处理器，程序员为任务完成之后要出现的动作注册一个处理器。

Java SE 8 的 CompletableFuture 类提供了一种候选方法。与事件处理器不同，“可完成 future" 可以 “组合”（ composed )

例如，假设我们希望从一个 Web 页面抽取所有链接来建立一个网络爬虫。下面假设有这样一个方法，Web 页面可用时这会生成这个页面的文本

public CompletableFuture<String> readPage(URL url)

另一个方法生成一个 HTML 页面中的 URL

public static List<URL> getLinks(String page)

可以调度当页面可用时再调用 getLinks 方法：

CompletableFuture<String> contents = readPage(url);
CompletableFuture<List<URL>> links = contents.thenApply(Parser::getlinks);

thenApply 方法不会阻塞。它会返回另一个 future 。第一个 future 完成时，其结果会提供给 getLinks 方法，这个方法的返回值就是最终的结果。

利用可完成 future ，可以指定你希望做什么，以及希望以什么顺序执行这些工作。当然，这不会立即发生，不过重要的是所有代码都放在一处。

从概念上讲， CompletableFuture 是一个简单 API , 不过有很多不同方法来组合可完成 future 。

以下方法处理单个 future ，对于这里所示的每个方法，还有两个 Async 形式，不过这里没有给出，其中一种形式使用一个共享 ForkJoinPool ，另一种形式有一个 Executor 参数。在这个表中，我使用了简写记法来表示复杂的函数式接口，这里会把 Function<? super T, U> 写为 T-> U。当然这并不是真正的 Java 类型。

方法	参数	描述
`thenRun`	`Runnable`	执行 `Runnable` , 结果为 `void`
`thenApply`	`T-> U`	对结果应用一个函数
`thenAccept`	`T-> void`	类似于 `thenApply` , 不过结果为 `void`
`thenCompose`	`T-> CompletableFuture<U>`	结果调用函数并执行返回的 future
`handle`	`(T, Throwable)-> U`	处理结果或错误
`whenComplete`	`(T, Throwable)-> void`	类似于 `handle` , 不过结果为 `void`

public <U> CompletableFuture<U> thenApply(Function<? super T,? extends U> fn)
public <U> CompletableFuture<U> thenApplyAsync(Function<? super T,? extends U> fn) 
public <U> CompletableFuture<U> thenApplyAsync(Function<? super T,? extends U> fn, Executor executor)

thenCompose 方法取函数 T -> CompletableFuture<U> 。这里有两个函数 T -> CompletableFuture<U> 和 U -> CompletableFuture<V> 。显然，如果第二个函数在第一个函数完成时调用，它们就可以组合为一个函数 T ->
CompletableFuture<V> 。这正是 thenCompose 所做的。

handle 方法强调了目前为止我一直忽略的另一个方面：失败（ failure )。CompletableFuture 中拋出一个异常时，会捕获这个异常并在调用 get 方法时包装在一个受查异常 ExecutionException 中。不过，可能 get 永远也不会被调用。要处理异常，可以使用 handle 方法。调用指定的函数时要提供结果（如果没有则为 null ) 和异常（如果没有则为 null ), 这种情况下就有意义了。其余的方法结果都为 void，通常用在处理管线的最后。

**组合多个 future 的方法 **

方法	参数	描述
`thenCombine`	`CompletableFuture<U>, (T, U)-> V`	执行两个动作并用给定函数组合结果
`thenAcceptBoth`	`CompletableFuture<U>, (T, U) -> void`	与 `thenCombine` 类似，不过结果为 `void`
`runAfterBoth`	`CompletableFuture<?>, Runnable`	两个都完成后执行 `runnable`
`applyToEither`	`CompletableFuture<T>, T-> V`	得到其中一个的结果时，传入给定的函数
`acceptEither`	`CompletableFuture<T>, T-> void`	与 `applyToEither` 类似，不过结果为 `void`
`runAfterEither`	`CompletableFuture<?>, Runnable`	其中一个完成后执行 `runnable`
`static allOf`	`CompletableFuture<?>...`	所有给定的 `future` 都完成后完成，结果为 `void`
`static anyOf`	`CompletableFuture<?>...`	任意给定的 `future` 完成后则完成，结果为 `void`

thenCombine 、thenAcceptBoth 、runAfterBoth 方法并行运行一个 CompletableFuture<T> 和一个 CompletableFuture<U> 动作，并组合结果

applyToEither 、acceptEither 、runAfterEither 方法并行运行两个 CompletableFuture<T> 动作。一旦其中一个动作完成，就传递它的结果，并忽略另一个结果。

静态 allOf 和 anyOf 方法取一组可完成 future (数目可变)，并生成一个 CompletableFuture<Void> , 它会在所有这些 future 都完成时或者其中任意一个 future 完成时结束。不会传递任何结果。

理论上讲，这一节介绍的方法接受 CompletionStage 类型的参教，而不是 CompletableFuture 。这个接口有几乎 40 个抽象方法，只由 CompletableFuture 实现。提供这个接口是为了让第三方框架可以实现这个接口。

同步器

java.util.concurrent 包包含了几个能帮助人们管理相互合作的线程集的类。这些机制具有为线程之间的 共用集结点模式（ common rendezvous patterns) 提供的 “预置功能” ( canned functionality )。如果有一个相互合作的线程集满足这些行为模式之一，那么应该直接重用合适的库类而不要试图提供手工的锁与条件的集合。

类	作用	描述
`CyclicBarrier`	允许线程集等待直至其中预定数目的线程到达一个公共障栅（barrier) ，然后可以选择执行一个处理障栅的动作	当大量的线程需要在它们的结果可用之前完成时
`Phaser`	类似于循环障栅，不过有一个可变的计数	Java SE 7 中引入
`CountDownLatch`	允许线程集等待直到计数器减为 0	当一个或多个线程需要等待直到指定数目的事件发生
`Exchanger`	允许两个线程在要交换的对象准备好时交换对象	当两个线程工作在同一数据结构的两个实例上的时候，一个向实例添加数据而另一个从实例清除数据
`Semaphore`	允许线程集等待直到被允许继续运行为止	限制访问资源的线程总数。如果许可数是 1，常常阻塞线程直到另一个线程给出许可为止
`SynchronousQueue`	允许一个线程把对象交给另一个线程	在没有显式同步的情况下，当两个线程准备好将一个对象从一个线程传递到另一个时

信号置（ `Semaphore` ）

概念上讲，一个信号量管理许多的 许可证（permit) 。为了通过信号量，线程通过调用 acquire 请求许可。其实没有实际的许可对象，信号量仅维护一个计数。许可的数目是固定的，由此限制了通过的线程数量。其他线程可以通过调用 release 释放许可。而且，许可不是必须由获取它的线程释放。事实上，任何线程都可以释放任意数目的许可，这可能会增加许可数目以至于超出初始数目。

信号量在 1968 年由 Edsger Dijkstra 发明，作为 同步原语（synchronization primitive ) 。Dijkstra 指出信号量可以被有效地实现，并且有足够的能力解决许多常见的线程同步问题。在几乎任何一本操作系统教科书中，都能看到使用信号量实现的有界队列。

当然，应用程序员不必自己实现有界队列。通常，信号量不必直接映射到通用应用场景。

倒计时门栓（ `CountDownLatch` ）

一个倒计时门栓（ CountDownLatch ) 让一个线程集等待直到计数变为 0。倒计时门栓是一次性的。一旦计数为 0, 就不能再重用了。

一个有用的特例是计数值为 1 的门栓。实现一个只能通过一次的门。线程在门外等候直到另一个线程将计数器值置为 0

举例来讲，假定一个线程集需要一些初始的数据来完成工作。工作器线程被启动并在门外等候。另一个线程准备数据。当数据准备好的时候，调用 countDown , 所有工作器线程就可以继续运行了。

然后，可以使用第二个门栓检査什么时候所有工作器线程完成工作。用线程数初始化门栓。每个工作器线程在结束前将门栓计数减 1 。另一个获取工作结果的线程在门外等待，一旦所有工作器线程终止该线程继续运行。

障栅（ `CyclicBarrier` ）

CyclicBarrier 类实现了一个 集结点（rendezvous) 称为 障栅（barrier) 。考虑大量线程运行在一次计算的不同部分的情形。当所有部分都准备好时，需要把结果组合在一起。当一个线程完成了它的那部分任务后，我们让它运行到障栅处。一旦所有的线程都到达了这个障栅，障栅就撤销，线程就可以继续运行。

首先，构造一个障栅，并给出参与的线程数：

CyclicBarrier barrier = new CyclicBarrier(nthreads);

每一个线程做一些工作，完成后在障栅上调用 await :

public void run() {
    doWork();
    barrier.await();
    // ...
}

await 方法有一个可选的超时参数：

barrier.await(100, TimeUnit.MILLISECONDS);

如果任何一个在障栅上等待的线程离开了障栅，那么障栅就被破坏了（线程可能离开是因为它调用 await 时设置了超时，或者因为它被中断了）。在这种情况下，所有其他线程的 await 方法抛出 BrokenBarrierException 异常。那些已经在等待的线程立即终止 await 的调用。

可以提供一个可选的 障栅动作（barrier action) , 当所有线程到达障栅的时候就会执行这一动作，该动作可以收集那些单个线程的运行结果

Runnable barrierAction = ...;
CyclicBarrier barrier = new CyclicBarrier(nthreads, barrierAction);

障栅被称为是 循环的（cyclic) , 因为可以在所有等待线程被释放后被重用。在这一点上，有别于 CountDownLatch , CountDownLatch 只能被使用一次。

Phaser 类增加了更大的灵活性，允许改变不同阶段中参与线程的个数。

交换器（ `Exchanger` ）

当两个线程在同一个数据缓冲区的两个实例上工作的时候，就可以使用交换器( Exchanger) 。典型的情况是，一个线程向缓冲区填入数据，另一个线程消耗这些数据。当它们都完成以后，相互交换缓冲区。

同步队列（ `SynchronousQueue` ）

同步队列是一种将生产者与消费者线程配对的机制。当一个线程调用 SynchronousQueue 的 put 方法时，它会阻塞直到另一个线程调用 take 方法为止，反之亦然。与 Exchanger 的情况不同，数据仅仅沿一个方向传递，从生产者到消费者。

即使 SynchronousQueue 类实现了 BlockingQueue 接口，概念上讲，它依然不是一个队列。它没有包含任何元素，它的 size 方法总是返回 0 。

posted @ 2022-04-24 21:16 流星<。)#)))≦ 阅读(22) 评论(0) 编辑收藏举报

会员力量，点亮园子希望

刷新页面返回顶部

20220424 Java核心技术 卷1 基础知识 14

并 发

什么是线程

中 断 线 程

线程状态

新创建线程（ NEW ）

可运行线程（ RUNNABLE ）

被阻塞线程（ BLOCKED ）和等待线程（ WAITING 、TIMED_WAITING ）

被终止的线程

线 程 属 性

线程优先级

守护线程

未捕获异常处理器

同 步

竞争条件的一个例子

竞争条件详解

锁对象

条件对象

synchronized 关键字

同步阻塞

监视器概念

volatile 域

final 变置

原子性

死锁

线程局部变量（ ThreadLocal ）

锁测试与超时

读 / 写锁 （ ReentrantReadWriteLock ）

为什么弃用 stop 和 suspend 方法

阻塞队列（ BlockingQueue ）