Java面试07——并发知识点汇总及源码解析_实现 runnable 和 callable 接口的类只能当做一个可以在线程中运行的任务,不是真

前言

这篇文章最开始是我基于Cyc2018 java并发的知识点 加上自己一些理解 所写的一篇面试总结。涵盖了java 并发 多线程必备的基础知识点和一些高频考试的点，后续会持续更新~

并发和并行的区别

• 并发是两个任务可以在重叠的时间段内启动，运行和完成。
• 并行是任务在同一时间运行，例如，在多核处理器上。
• 并发是独立执行过程的组合，而并行是同时执行（可能相关的）计算。
• 并发是一次处理很多事情，并行是同时做很多事情。
• 应用程序可以是并发的，但不是并行的，这意味着它可以同时处理多个任务，但是没有两个任务在同一时刻执行。
• 应用程序可以是并行的，但不是并发的，这意味着它同时处理多核CPU中的任务的多个子任务。
• 一个应用程序可以即不是并行的，也不是并发的，这意味着它一次一个地处理所有任务。
• 应用程序可以即是并行的也是并发的，这意味着它同时在多核CPU中同时处理多个任务。

为了更加直观的表达，有以下两张图表述：

线程状态转换

线程一共有5个状态：
1.新建状态(New) :线程对象被创建后，就进入了新建状态，注意这时线程并未启动。例如，Thread thread = new Thread()。

2.就绪状态(Runnable): 也被称为“可执行状态”。线程对象被创建后，其它线程调用了该对象的start()方法，从而来启动该线程。例如，thread.start()。处于就绪状态的线程，随时可能被CPU调度执行。
这个状态下可能正在运行，也可能正在等待 CPU 时间片。包含了操作系统线程状态中的 Running 和 Ready。

3.运行状态(Running) : 线程获取CPU权限进行执行。需要注意的是，线程只能从就绪状态进入到运行状态。

4.阻塞状态(Blocked) : 阻塞状态是线程因为某种原因放弃CPU使用权，暂时停止运行。直到线程进入就绪状态，才有机会转到运行状态。阻塞的情况分三种：

• 1、等待阻塞 – 通过调用线程的wait()方法，让线程等待某工作的完成。

• 2、同步阻塞 – 线程在获取synchronized同步锁失败(因为锁被其它线程所占用)，它会进入同步阻塞状态。

• 3、 其他阻塞 – 通过调用线程的sleep()或join()或发出了I/O请求时，线程会进入到阻塞状态。当sleep()状态超时、join()等待线程终止或者超时、或者I/O处理完毕时，线程重新转入就绪状态。

5.死亡状态(Dead) : 线程执行完了或者因异常退出了run()方法，该线程结束生命周期。

• 1、run()或者call()方法执行完成，线程正常结束；

• 2、线程抛出一个未捕获的Exception或Error；

• 3、直接调用该线程的stop()方法来结束该线程；

使用线程

有三种使用线程的方法：

• 实现 Runnable 接口；
• 实现 Callable 接口；
• 继承 Thread 类。

实现 Runnable 和 Callable 接口的类只能当做一个可以在线程中运行的任务，不是真正意义上的线程，因此最后还需要通过 Thread 来调用。可以说任务是通过线程驱动从而执行的。

实现 Runnable 接口

需要实现 run()方法。

通过 Thread 调用 start() 方法来启动线程。

class MyRunnable implements Runnable {
    public void run() {
        // ...
    }
}
public static void main(String[] args) {
    MyRunnable instance = new MyRunnable();
    Thread thread = new Thread(instance);
    thread.start();
}
1
2
3
4
5
6
7
8
9
10

实现 Callable 接口

自定义一个类，实现Callable接口，重写call()方法。

与 Runnable 相比，Callable 可以有返回值，返回值通过 FutureTask 进行封装。

class MyCallable implements Callable<Integer> {
    public Integer call() {
        return 123;
    }
}
public static void main(String[] args) throws ExecutionException, InterruptedException {
    MyCallable mc = new MyCallable();
    FutureTask<Integer> ft = new FutureTask<>(mc);
    Thread thread = new Thread(ft);
    thread.start();
    System.out.println(ft.get());
}
1
2
3
4
5
6
7
8
9
10
11
12

Callable和Runnable的区别

关于Callable和Runnable二者的区别，这是Java面试出现的高频的面试知识点，总结如下：

1. Callable规定的方法是call()，而Runnable规定的方法是run().
2. Callable的任务执行后可返回值，而Runnable的任务是不能返回值的；
3. call()方法可抛出异常，而run()方法是不能抛出异常的；
4. 运行Callable任务可拿到一个Future对象，与Runnable相比，Callable可以有返回值，返回值可通过FutureTask进行封装。

FutureTask

(2019.12.28 更新)
在Executors框架体系中，FutureTask用来表示可获取结果的异步任务。FutureTask实现了Runnable接口，FutureTask提供了启动和取消异步任务，查询异步任务是否计算结束以及获取最终的异步任务的结果的一些常用的方法。通过get()方法来获取异步任务的结果，但是会阻塞当前线程直至异步任务执行结束。一旦任务执行结束，任务不能重新启动或取消，除非调用runAndReset()方法。在FutureTask的源码中为其定义了这些状态：

private static final int NEW          = 0;
private static final int COMPLETING   = 1;
private static final int NORMAL       = 2;
private static final int EXCEPTIONAL  = 3;
private static final int CANCELLED    = 4;
private static final int INTERRUPTING = 5;
private static final int INTERRUPTED  = 6;
1
2
3
4
5
6
7

另外，在《java并发编程的艺术》一书，作者根据FutureTask.run()方法的执行的时机，FutureTask分为了3种状态：

1. 未启动。FutureTask.run()方法还没有被执行之前，FutureTask处于未启动状态。当创建一个FutureTask，还没有执行FutureTask.run()方法之前，FutureTask处于未启动状态。
2. 已启动。FutureTask.run()方法被执行的过程中，FutureTask处于已启动状态。
3. 已完成。FutureTask.run()方法执行结束，或者调用FutureTask.cancel(…)方法取消任务，或者在执行任务期间抛出异常，这些情况都称之为FutureTask的已完成状态。

下图总结了FutureTask的状态变化的过程：

由于FutureTask具有这三种状态，因此执行FutureTask的get方法和cancel方法，当前处于不同的状态对应的结果也是大不相同。这里对get方法和cancel方法做个总结：

get方法:
当FutureTask处于未启动或已启动状态时，执行FutureTask.get()方法将导致调用线程阻塞。如果FutureTask处于已完成状态，调用FutureTask.get()方法将导致调用线程立即返回结果或者抛出异常

cancel方法:
当FutureTask处于未启动状态时，执行FutureTask.cancel()方法将此任务永远不会执行；

当FutureTask处于已启动状态时，执行FutureTask.cancel(true)方法将以中断线程的方式来阻止任务继续进行，如果执行FutureTask.cancel(false)将不会对正在执行任务的线程有任何影响；

当FutureTask处于已完成状态时，执行FutureTask.cancel(…)方法将返回false。

对Future的get()方法和cancel()方法用下图进行总结

FutureTask除了实现Future接口外，还实现了Runnable接口。因此，FutureTask可以交给Executor执行，也可以由调用的线程直接执行（FutureTask.run()）。另外，FutureTask的获取也可以通过ExecutorService.submit()方法返回一个FutureTask对象，然后在通过FutureTask.get()或者FutureTask.cancel方法。

应用场景：当一个线程需要等待另一个线程把某个任务执行完后它才能继续执行，此时可以使用FutureTask。假设有多个线程执行若干任务，每个任务最多只能被执行一次。当多个线程试图执行同一个任务时，只允许一个线程执行任务，其他线程需要等待这个任务执行完后才能继续执行。

继承 Thread 类

同样也是需要实现 run() 方法，因为 Thread 类也实现了 Runable 接口。

当调用 start() 方法启动一个线程时，虚拟机会将该线程放入就绪队列中等待被调度，当一个线程被调度时会执行该线程的 run() 方法。

class MyThread extends Thread {
    public void run() {
        // ...
    }
}
public static void main(String[] args) {
    MyThread mt = new MyThread();
    mt.start();
}
1
2
3
4
5
6
7
8
9

实现接口 VS 继承 Thread

实现接口会更好一些，因为：

Java 不支持多重继承，因此继承了 Thread 类就无法继承其它类，但是可以实现多个接口；
类可能只要求可执行就行，继承整个 Thread 类开销过大。

多线程

通过前面所讲的知识，相比你对线程有了一定的了解。实际上，代码中的一个任务就是一个线程，一个应用程序为了同时执行多个任务提供运行效率，一般会涉及到一个线程以上的数量。如果，一个应用程序有一个以上的线程，我们把这种情况就称之为多线程。

本质来说，多线程是为了使得多个线程完成多项任务，以提高系统的效率。我们编程实现多线程应用程序的目的是尽可能多地使用计算机处理器资源（本质是为了让效率最大化）。所以，看起来我们仅需要为每个独立的任务分配一个不同的线程，并让处理器确定在任何时间它总会处理其中的某一个任务。但是，这样就会出现一些问题，对小系统来说这样做很好。但是当系统越来越复杂时，线程的数量也会越来越多，操作系统将会花费更多时间去理清线程之间的关系。为了让我们的程序具备可扩展性，我们将不得不对线程进行一些有效的控制。

对于这种问题，Java中提供线程池来有效解决：

线程池

什么是线程池？

线程池是指在初始化时创建一个线程集合，然后在需要执行新的任务时重用这些线程而不是新建一个线程(提高线程复用，减少性能开销)。线程池中线程的数量通常完全取决于可用内存数量和应用程序的需求。然而，增加可用线程数量是可能的。线程池中的每个线程都有被分配一个任务，一旦任务已经完成了，线程回到池子中然后等待下一次分配任务。

为什么要用线程池?

基于以下几个原因在多线程应用程序中使用线程池是必须的：

1. 线程池改进了一个应用程序的响应时间。由于线程池中的线程已经准备好且等待被分配任务，应用程序可以直接拿来使用而不用新建一个线程。
2. 线程池节省了CLR 为每个短生存周期任务创建一个完整的线程的开销并可以在任务完成后回收资源。
3. 线程池根据当前在系统中运行的进程来优化线程时间片。
4. 线程池允许我们开启多个任务而不用为每个线程设置属性。
5. 线程池允许我们为正在执行的任务的程序参数传递一个包含状态信息的对象引用。
6. 线程池可以用来解决处理一个特定请求最大线程数量限制问题。

总结，我们使用线程池主要就是为了减少了创建和销毁线程的次数，每个工作线程都可以被重复利用，可执行多个任务；节约应用内存（线程开的越多，消耗的内存也就越大，最后死机）

线程池的作用

线程池作用一句话概括就是限制系统中执行线程的数量。根据系统的环境情况，可以自动或手动设置线程数量，达到运行的最佳效果；少了浪费了系统资源，多了造成系统拥挤效率不高。用线程池控制线程数量，其他线程排队等候。一个任务执行完毕，再从队列的中取最前面的任务开始执行。若队列中没有等待进程，线程池的这一资源处于等待。当一个新任务需要运行时，如果线程池中有等待的工作线程，就可以开始运行了；否则进入等待队列。

Executor

解释完线程池的理论知识，我们下面重点关注在Java中的线程池实现。在Java中，线程池起源于接口Executor，严格意义上Exrcutor并不是一个线程池，我们查看jdk 1.8中的源码 它只有一个execute()方法，如下所示：

public interface Executor {

    /**
     * Executes the given command at some time in the future.  The command
     * may execute in a new thread, in a pooled thread, or in the calling
     * thread, at the discretion of the {@code Executor} implementation.
     *
     * @param command the runnable task
     * @throws RejectedExecutionException if this task cannot be
     * accepted for execution
     * @throws NullPointerException if command is null
     */
    void execute(Runnable command);
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14

实际上，Executor有一个子接口ExecutorService，如下图所示：

public interface ExecutorService extends Executor {
*** shutdown();
*** awaitTermination();
*** invokeAny();
}
1
2
3
4
5

在ExecutorService接口中，它提供了各种api用于功能实现。而ExecutorService接口的默认实现类为ThreadPoolExecutor，所以在关于线程池的问题上，我们首先要弄清楚ThreadPoolExecutor.

ThreadPoolExecutor

线程池ThreadPoolExecutor参数设置

参数的设置跟系统的负载有直接的关系，下面为系统负载的相关参数：

• tasks，每秒需要处理的的任务数
• tasktime，处理每个任务花费的时间
• responsetime，系统允许任务最大的响应时间，比如每个任务的响应时间不得超过2秒。

corePoolSize(该线程池中核心线程最大值)
每个任务需要tasktime秒处理，则每个线程每钞可处理1/tasktime个任务。系统每秒有tasks个任务需要处理，则需要的线程数为：tasks/(1/tasktime)，即tasks*tasktime个线程数。

maxPoolSize(该线程池中线程总数的最大值)
当系统负载达到最大值时，核心线程数已无法按时处理完所有任务，这时就需要增加线程。每秒200个任务需要20个线程，那么当每秒达到1000个任务时，则需要(1000-queueCapacity)*(20/200)，即60个线程，可将maxPoolSize设置为60。

queueCapacity(队列长度)
任务队列的长度要根据核心线程数，以及系统对任务响应时间的要求有关。队列长度可以设置为(corePoolSize/tasktime)*responsetime： (20/0.1)*2=400，即队列长度可设置为400。

队列长度设置过大，会导致任务响应时间过长，切忌以下写法：

LinkedBlockingQueue queue = new LinkedBlockingQueue();
1

这实际上是将队列长度设置为Integer.MAX_VALUE，将会导致线程数量永远为corePoolSize，再也不会增加，当任务数量陡增时，任务响应时间也将随之陡增。

keepAliveTime(该线程池中非核心线程闲置时间时长)
当负载降低时，可减少线程数量，当线程的空闲时间超过keepAliveTime，会自动释放线程资源。默认情况下线程池停止多余的线程并最少会保持corePoolSize个线程。

allowCoreThreadTimeout
默认情况下核心线程不会退出，可通过将该参数设置为true，让核心线程也退出。

ThreadPoolExecutor执行的策略

• 线程数量未达到corePoolSize，则新建一个线程(核心线程)执行任务
• 线程数量达到了corePools，则将任务移入队列等待
• 队列已满，新建线程(非核心线程)执行任务
• 队列已满，总线程数又达到了maximumPoolSize，就会由(RejectedExecutionHandler)抛出异常

新建线程 -> 达到核心数 -> 加入队列 -> 新建线程（非核心） -> 达到最大数 -> 触发拒绝策略

Executors提供的常见四种线程池

实际上，Java中Executors类已经为我们提供日常开发中常用的几种线程池 随着jdk的不断在更新，南国猜想还会再增加。注意这里时Executors类，而不是我们之前提到的Executor接口。

1.newCachedThreadPool()：可缓存线程池。

• 线程数无限制
• 有空闲线程则复用空闲线程，若无空闲线程则新建线程
• 一定程度减少频繁创建/销毁线程，减少系统开销

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

CachedThreadPool 的corePoolSize 被设置为空（0），maximumPoolSize被设置为 Integer.MAX.VALUE，即它是无界的，这也就意味着如果主线程提交任务的速度高于 maximumPool 中线程处理任务的速度时，CachedThreadPool 会不断创建新的线程。极端情况下，这样会导致耗尽 cpu 和内存资源。
CachedThreadPool 的 execute()方法的执行示意图（该图片来源：《Java 并发编程的艺术》）：

上图说明：

• 首先执行 SynchronousQueue.offer(Runnable task) 提交任务到任务队列。如果当前 maximumPool 中有闲线程正在执行 SynchronousQueue.poll(keepAliveTime,TimeUnit.NANOSECONDS)，那么主线程执行 offer 操作与空闲线程执行的 poll 操作配对成功，主线程把任务交给空闲线程执行，execute()方法执行完成，否则执行下面的步骤 2；
• 当初始 maximumPool 为空，或者 maximumPool 中没有空闲线程时，将没有线程执行 SynchronousQueue.poll(keepAliveTime,TimeUnit.NANOSECONDS)。这种情况下，步骤 1 将失败，此时 CachedThreadPool 会创建新线程执行任务，execute 方法执行完成；

缺点：
CachedThreadPool允许创建的线程数量为 Integer.MAX_VALUE ，可能会创建大量线程，从而导致 OOM。

2.newFixedThreadPool()：定长线程池。

• 可控制线程最大并发数（同时执行的线程数）
• 超出的线程会在队列中等待

public class Executors {
	....
	public static ExecutorService newFixedThreadPool(int nThreads) {
        return new ThreadPoolExecutor(nThreads, nThreads,
                                      0L, TimeUnit.MILLISECONDS,
                                      new LinkedBlockingQueue<Runnable>());
    }    
}
1
2
3
4
5
6
7
8

从上面源代码可以看出新创建的 FixedThreadPool 的 corePoolSize 和 maximumPoolSize 都被设置为 nThreads，这个 nThreads 参数是我们使用的时候自己传递的。
FixedThreadPool 的 execute() 方法运行示意图（该图片来源：《Java 并发编程的艺术》）：

上图说明：
如果当前运行的线程数小于 corePoolSize， 如果再来新任务的话，就创建新的线程来执行任务；
当前运行的线程数等于 corePoolSize 后， 如果再来新任务的话，会将任务加入 LinkedBlockingQueue；
线程池中的线程执行完 手头的任务后，会在循环中反复从 LinkedBlockingQueue 中获取任务来执行；

缺点：
FixedThreadPool 使用无界队列 LinkedBlockingQueue（队列的容量为 Integer.MAX_VALUE）作为线程池的工作队列会对线程池带来如下影响 ：

• 当线程池中的线程数达到 corePoolSize 后，新任务将在无界队列中等待，因此线程池中的线程数不会超过 corePoolSize；
• 由于使用无界队列时 maximumPoolSize 将是一个无效参数，因为不可能存在任务队列满的情况。所以，通过创建 FixedThreadPool的源码可以看出创建的 FixedThreadPool 的 corePoolSize 和 maximumPoolSize 被设置为同一个值。
• 由于 1 和 2，使用无界队列时 keepAliveTime 将是一个无效参数；
• 运行中的 FixedThreadPool（未执行 shutdown()或 shutdownNow()）不会拒绝任务，在任务比较多的时候会导致 OOM（内存溢出）。

3.SingleThreadExecutor()：单线程化的线程池。

• 有且仅有一个工作线程执行任务
• 所有任务按照指定顺序执行，即遵循队列的入队出队规则

 public static ExecutorService newSingleThreadExecutor(ThreadFactory threadFactory) {
        return new FinalizableDelegatedExecutorService
            (new ThreadPoolExecutor(1, 1,
                                    0L, TimeUnit.MILLISECONDS,
                                    new LinkedBlockingQueue<Runnable>(),
                                    threadFactory));
    }
1
2
3
4
5
6
7

从上面源代码可以看出新创建的 SingleThreadExecutor 的 corePoolSize 和 maximumPoolSize 都被设置为 1.其他参数和 FixedThreadPool 相同。
SingleThreadExecutor 的运行示意图（该图片来源：《Java 并发编程的艺术》）：

上图说明;

• 如果当前运行的线程数少于 corePoolSize，则创建一个新的线程执行任务；
• 当前线程池中有一个运行的线程后，将任务加入 LinkedBlockingQueue
• 线程执行完当前的任务后，会在循环中反复从LinkedBlockingQueue 中获取任务来执行；

缺点：
SingleThreadExecutor 使用无界队列 LinkedBlockingQueue 作为线程池的工作队列（队列的容量为 Intger.MAX_VALUE）。SingleThreadExecutor 使用无界队列作为线程池的工作队列会对线程池带来的影响与 FixedThreadPool 相同。说简单点就是可能会导致 OOM，

4.newScheduledThreadPool()：定时线程池。

• 支持定时及周期性任务执行。

public static ScheduledExecutorService newScheduledThreadPool(int corePoolSize) {
        return new ScheduledThreadPoolExecutor(corePoolSize);
    }
public static ScheduledExecutorService newScheduledThreadPool(
            int corePoolSize, ThreadFactory threadFactory) {
        return new ScheduledThreadPoolExecutor(corePoolSize, threadFactory);
    }
1
2
3
4
5
6
7

ScheduledThreadPoolExecutor 主要用来在给定的延迟后运行任务，或者定期执行任务。 这个在实际项目中基本不会被用到，常见的定时调度可以用quartz(单机) xx-job(分布式)， 推荐使用xxl-job

更多详细信息请查看源码java.util.concurrent.Executors,这里有一篇不错的线程池文章必须要理清的Java线程池

Executors和ThreaPoolExecutor创建线程池的缺点

• Executors 各个方法的弊端：
  newFixedThreadPool 和 newSingleThreadExecutor: 主要问题是堆积的请求处理队列可能会耗费非常大的内存，甚至 OOM。
  newCachedThreadPool 和 newScheduledThreadPool: 主要问题是线程数最大数是 Integer.MAX_VALUE，可能会创建数量非常多的线程，甚至 OOM。
• ThreaPoolExecutor的缺点：
  创建线程池方式只有一种，就是走它的构造函数，参数自己指定

2021-05-28补充：

线程池大小确定(重要)

线程池数量的确定一直是困扰着程序员的一个难题，大部分程序员在设定线程池大小的时候就是随心而定。

很多人甚至可能都会觉得把线程池配置过大一点比较好！我觉得这明显是有问题的。就拿我们生活中非常常见的一例子来说：并不是人多就能把事情做好，增加了沟通交流成本。你本来一件事情只需要 3 个人做，你硬是拉来了 6 个人，会提升做事效率嘛？我想并不会。 线程数量过多的影响也是和我们分配多少人做事情一样，对于多线程这个场景来说主要是增加了上下文切换成本。

补充-上下文切换：
多线程编程中一般线程的个数都大于 CPU 核心的个数，而一个 CPU 核心在任意时刻只能被一个线程使用，为了让这些线程都能得到有效执行，CPU 采取的策略是为每个线程分配时间片并轮转的形式。当一个线程的时间片用完的时候就会重新处于就绪状态让给其他线程使用，这个过程就属于一次上下文切换。概括来说就是：当前任务在执行完 CPU 时间片切换到另一个任务之前会先保存自己的状态，以便下次再切换回这个任务时，可以再加载这个任务的状态。任务从保存到再加载的过程就是一次上下文切换。

上下文切换通常是计算密集型的。也就是说，它需要相当可观的处理器时间，在每秒几十上百次的切换中，每次切换都需要纳秒量级的时间。所以，上下文切换对系统来说意味着消耗大量的 CPU 时间，事实上，可能是操作系统中时间消耗最大的操作。

Linux 相比与其他操作系统（包括其他类 Unix 系统）有很多的优点，其中有一项就是，其上下文切换和模式切换的时间消耗非常少。
1
2
3
4
5
6

类比于实现世界中的人类通过合作做某件事情，我们可以肯定的一点是线程池大小设置过大或者过小都会有问题，合适的才是最好。

如果我们设置的线程池数量太小的话，如果同一时间有大量任务/请求需要处理，可能会导致大量的请求/任务在任务队列中排队等待执行，甚至会出现任务队列满了之后任务/请求无法处理的情况，或者大量任务堆积在任务队列导致 OOM。这样很明显是有问题的！ CPU 根本没有得到充分利用。
但是，如果我们设置线程数量太大，大量线程可能会同时在争取 CPU 资源，这样会导致大量的上下文切换，从而增加线程的执行时间，影响了整体执行效率。

有一个简单并且适用面比较广的公式：

CPU 密集型任务(N+1)： 这种任务消耗的主要是 CPU 资源，可以将线程数设置为 N（CPU 核心数）+1，比 CPU 核心数多出来的一个线程是为了防止线程偶发的缺页中断，或者其它原因导致的任务暂停而带来的影响。一旦任务暂停，CPU 就会处于空闲状态，而在这种情况下多出来的一个线程就可以充分利用 CPU 的空闲时间。
I/O 密集型任务(2N)： 这种任务应用起来，系统会用大部分的时间来处理 I/O 交互，而线程在处理 I/O 的时间段内不会占用 CPU 来处理，这时就可以将 CPU 交出给其它线程使用。因此在 I/O 密集型任务的应用中，我们可以多配置一些线程，具体的计算方法是 2N。

如何判断是 CPU 密集任务还是 IO 密集任务？
CPU 密集型简单理解就是利用 CPU 计算能力的任务比如你在内存中对大量数据进行排序。但凡涉及到网络读取，文件读取这类都是 IO 密集型，这类任务的特点是 CPU 计算耗费时间相比于等待 IO 操作完成的时间来说很少，大部分时间都花在了等待 IO 操作完成上。

Daemon

守护线程是程序运行时在后台提供服务的线程，不属于程序中不可或缺的部分。

当所有非守护线程结束时，程序也就终止，同时会杀死所有守护线程。

main() 属于非守护线程。

使用 setDaemon() 方法将一个线程设置为守护线程。

public static void main(String[] args) {
    Thread thread = new Thread(new MyRunnable());
    thread.setDaemon(true);
}
1
2
3
4

sleep()

Thread.sleep(millisec) 方法会休眠当前正在执行的线程，millisec 单位为毫秒。

sleep() 可能会抛出 InterruptedException，因为异常不能跨线程传播回 main() 中，因此必须在本地进行处理。线程中抛出的其它异常也同样需要在本地进行处理。

public void run() {
    try {
        Thread.sleep(3000);
    } catch (InterruptedException e) {
        e.printStackTrace();
    }
}
1
2
3
4
5
6
7

yield()

对静态方法 Thread.yield() 的调用声明了当前线程已经完成了生命周期中最重要的部分，可以切换给其它线程来执行。该方法只是对线程调度器的一个建议，而且也只是建议具有相同优先级的其它线程可以运行。

public void run() {
    Thread.yield();
}
1
2
3

中断

一个线程执行完毕之后会自动结束，如果在运行过程中发生异常也会提前结束。

InterruptedException

通过调用一个线程的 interrupt() 来中断该线程，如果该线程处于阻塞、限期等待或者无限期等待状态，那么就会抛出 InterruptedException，从而提前结束该线程。但是不能中断 I/O 阻塞和 synchronized 锁阻塞。

对于以下代码，在 main() 中启动一个线程之后再中断它，由于线程中调用了 Thread.sleep() 方法，因此会抛出一个 InterruptedException，从而提前结束线程，不执行之后的语句。

public class InterruptExample {
    private static class MyThread1 extends Thread {
        @Override
        public void run() {
            try {
                Thread.sleep(2000);
                System.out.println("Thread run");
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    }
}
public static void main(String[] args) throws InterruptedException {
    Thread thread1 = new MyThread1();
    thread1.start();
    thread1.interrupt();
    System.out.println("Main run");
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

运行结果：

Main run
java.lang.InterruptedException: sleep interrupted
    at java.lang.Thread.sleep(Native Method)
    at InterruptExample.lambda$main$0(InterruptExample.java:5)
    at InterruptExample$$Lambda$1/713338599.run(Unknown Source)
    at java.lang.Thread.run(Thread.java:745)
1
2
3
4
5
6

interrupted()

如果一个线程的 run() 方法执行一个无限循环，并且没有执行 sleep() 等会抛出 InterruptedException 的操作，那么调用线程的 interrupt() 方法就无法使线程提前结束。

但是调用 interrupt() 方法会设置线程的中断标记，此时调用 interrupted() 方法会返回 true。因此可以在循环体中使用 interrupted() 方法来判断线程是否处于中断状态，从而提前结束线程。

public class InterruptExample {

    private static class MyThread2 extends Thread {
        @Override
        public void run() {
            while (!interrupted()) {
                // ..
            }
            System.out.println("Thread end");
        }
    }
}
public static void main(String[] args) throws InterruptedException {
    Thread thread2 = new MyThread2();
    thread2.start();
    thread2.interrupt();
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

Thread end
1

Executor 的中断操作

调用 ExecutorService 的 shutdown() 方法会等待线程都执行完毕之后再关闭，但是如果调用的是 shutdownNow() 方法，则相当于调用每个线程的 interrupt() 方法。

以下使用 Lambda 创建线程，相当于创建了一个匿名内部线程。

public static void main(String[] args) {
    ExecutorService executorService = Executors.newCachedThreadPool();
    executorService.execute(() -> {
        try {
            Thread.sleep(2000);
            System.out.println("Thread run");
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    });
    executorService.shutdownNow();
    System.out.println("Main run");
}
1
2
3
4
5
6
7
8
9
10
11
12
13

运行结果：

Main run
java.lang.InterruptedException: sleep interrupted
    at java.lang.Thread.sleep(Native Method)
    at ExecutorInterruptExample.lambda$main$0(ExecutorInterruptExample.java:9)
    at ExecutorInterruptExample$$Lambda$1/1160460865.run(Unknown Source)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)
1
2
3
4
5
6
7
8

如果只想中断 Executor 中的一个线程，可以通过使用 submit() 方法来提交一个线程，它会返回一个 Future<?> 对象，通过调用该对象的 cancel(true) 方法就可以中断线程。

Future<?> future = executorService.submit(() -> {
    // ..
});
future.cancel(true);
1
2
3
4

互斥同步

Java 提供了两种锁机制来控制多个线程对共享资源的互斥访问，第一个是 JVM 实现的 synchronized，而另一个是 JDK 实现的 ReentrantLock。

synchronized

1.同步一个代码块

public void func() {
    synchronized (this) {
        // ...
    }
}
1
2
3
4
5

它只作用于同一个对象，如果调用两个对象上的同步代码块，就不会进行同步。

对于以下代码，使用 ExecutorService 执行了两个线程，由于调用的是同一个对象的同步代码块，因此这两个线程会进行同步，当一个线程进入同步语句块时，另一个线程就必须等待。

public class SynchronizedExample {
    public void func1() {
        synchronized (this) {
            for (int i = 0; i < 10; i++) {
                System.out.print(i + " ");
            }
        }
    }
}
public static void main(String[] args) {
    SynchronizedExample e1 = new SynchronizedExample();
    ExecutorService executorService = Executors.newCachedThreadPool();
    executorService.execute(() -> e1.func1());
    executorService.execute(() -> e1.func1());
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9

对于以下代码，两个线程调用了不同对象的同步代码块，因此这两个线程就不需要同步。从输出结果可以看出，两个线程交叉执行。

public static void main(String[] args) {
    SynchronizedExample e1 = new SynchronizedExample();
    SynchronizedExample e2 = new SynchronizedExample();
    ExecutorService executorService = Executors.newCachedThreadPool();
    executorService.execute(() -> e1.func1());
    executorService.execute(() -> e2.func1());
}
1
2
3
4
5
6
7

0 0 1 1 2 2 3 3 4 4 5 5 6 6 7 7 8 8 9 9

2.同步一个方法

public synchronized void func () {
    // ...
}
1
2
3

它和同步代码块一样，作用于同一个对象。

3.同步一个类

public void func() {
    synchronized (SynchronizedExample.class) {
        // ...
    }
}
1
2
3
4
5

作用于整个类，也就是说两个线程调用同一个类的不同对象上的这种同步语句，也会进行同步。

public class SynchronizedExample {

    public void func2() {
        synchronized (SynchronizedExample.class) {
            for (int i = 0; i < 10; i++) {
                System.out.print(i + " ");
            }
        }
    }
}
public static void main(String[] args) {
    SynchronizedExample e1 = new SynchronizedExample();
    SynchronizedExample e2 = new SynchronizedExample();
    ExecutorService executorService = Executors.newCachedThreadPool();
    executorService.execute(() -> e1.func2());
    executorService.execute(() -> e2.func2());
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9

4.同步一个静态方法

public synchronized static void fun() {
    // ...
}
1
2
3

作用于整个类。

synchronized 的底层怎么实现

1.同步代码块(Synchronization)基于进入和退出管程(Monitor)对象实现。每个对象有一个监视器锁（monitor）。当monitor被占用时就会处于锁定状态，线程执行monitorenter指令时尝试获取monitor的所有权，过程如下：

• 如果monitor的进入数为0，则该线程进入monitor，然后将进入数设置为1，该线程即为monitor的所有者。

• 如果线程已经占有该monitor，只是重新进入，则进入monitor的进入数加1。

• 如果其他线程已经占用了monitor，则该线程进入阻塞状态，直到monitor的进入数为0，再重新尝试获取monitor的所有权。

2.被 synchronized 修饰的同步方法并没有通过指令monitorenter和monitorexit来完成（理论上其实也可以通过这两条指令来实现），不过相对于普通方法，其常量池中多了ACC_SYNCHRONIZED标示符。JVM就是根据该标示符来实现方法的同步的：当方法调用时，调用指令将会检查方法的 ACC_SYNCHRONIZED 访问标志是否被设置，如果设置了，执行线程将先获取monitor，获取成功之后才能执行方法体，方法执行完后再释放monitor。在方法执行期间，其他任何线程都无法再获得同一个monitor对象。 其实本质上没有区别，只是方法的同步是一种隐式的方式来实现，无需通过字节码来完成。

关于synchronized的底层实现 这里我只做个简短的介绍。关于synchronized的底层原理深度剖析，这里有浅到深 推荐两篇博客：
Java并发编程：Synchronized及其实现原理
深入理解Java并发之synchronized实现原理

ReentrantLock

ReentrantLock 是 java.util.concurrent（J.U.C）包中的锁。

public class LockExample {
    private Lock lock = new ReentrantLock();
    public void func() {
        lock.lock();
        try {
            for (int i = 0; i < 10; i++) {
                System.out.print(i + " ");
            }
        } finally {
            lock.unlock(); // 确保释放锁，从而避免发生死锁。
        }
    }
}
public static void main(String[] args) {
    LockExample lockExample = new LockExample();
    ExecutorService executorService = Executors.newCachedThreadPool();
    executorService.execute(() -> lockExample.func());
    executorService.execute(() -> lockExample.func());
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9

二者比较

1.锁的实现
synchronized 是 JVM 实现的，而 ReentrantLock 是 JDK 实现的。

2.性能
新版本 Java 对 synchronized 进行了很多优化，例如自旋锁等，synchronized 与 ReentrantLock 大致相同。

3.等待可中断
当持有锁的线程长期不释放锁的时候，正在等待的线程可以选择放弃等待，改为处理其他事情。
ReentranceLock可以让等待锁的线程响应中断(可中断锁)；而 synchronized 不行，使用Synchronized时等待的线程会一直等待下去，不能响应中断。

4.公平锁
公平锁是指多个线程在等待同一个锁时，必须按照申请锁的时间顺序来依次获得锁。
synchronized 中的锁是非公平的，ReentrantLock 默认情况下也是非公平的，但是也可以是公平的。

5.锁绑定多个条件
一个 ReentrantLock 可以同时绑定多个 Condition 对象。

使用选择：
除非需要使用 ReentrantLock 的高级功能，否则优先使用 synchronized。这是因为 synchronized 是 JVM 实现的一种锁机制，JVM 原生地支持它，而 ReentrantLock 不是所有的 JDK 版本都支持。并且使用 synchronized 不用担心没有释放锁而导致死锁问题，因为 JVM 会确保锁的释放。

线程之间的协作

当多个线程可以一起工作去解决某个问题时，如果某些部分必须在其它部分之前完成，那么就需要对线程进行协调。

join()

在线程中调用另一个线程的 join() 方法，会将当前线程挂起，而不是忙等待，直到目标线程结束。

对于以下代码，虽然 b 线程先启动，但是因为在 b 线程中调用了 a 线程的 join() 方法，b 线程会等待 a 线程结束才继续执行，因此最后能够保证 a 线程的输出先于 b 线程的输出。

public class JoinExample {
    private class A extends Thread {
        @Override
        public void run() {
            System.out.println("A");
        }
    }
    private class B extends Thread {
        private A a;
        B(A a) {
            this.a = a;
        }
        @Override
        public void run() {
            try {
                a.join();
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            System.out.println("B");
        }
    }
    public void test() {
        A a = new A();
        B b = new B(a);
        b.start();
        a.start();
    }
}
public static void main(String[] args) {
    JoinExample example = new JoinExample();
    example.test();
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

运行结果：

A
B
1
2

wait() notify() notifyAll()

调用 wait() 使得线程等待某个条件满足，线程在等待时会被挂起，当其他线程的运行使得这个条件满足时，其它线程会调用 notify() 或者 notifyAll() 来唤醒挂起的线程。

它们都属于 Object 的一部分，而不属于 Thread。

只能用在同步方法或者同步控制块中使用，否则会在运行时抛出 IllegalMonitorStateException。

使用 wait() 挂起期间，线程会释放锁。这是因为，如果没有释放锁，那么其它线程就无法进入对象的同步方法或者同步控制块中，那么就无法执行 notify() 或者 notifyAll() 来唤醒挂起的线程，造成死锁。

public class WaitNotifyExample {
    public synchronized void before() {
        System.out.println("before");
        notifyAll();
    }

    public synchronized void after() {
        try {
            wait();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        System.out.println("after");
    }
}
public static void main(String[] args) {
    ExecutorService executorService = Executors.newCachedThreadPool();
    WaitNotifyExample example = new WaitNotifyExample();
    executorService.execute(() -> example.after());
    executorService.execute(() -> example.before());
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

运行结果：

before
after
1
2

wait() 和 sleep() 的区别：

• wait() 是 Object 的方法，而 sleep() 是 Thread 的静态方法；
• wait() 会释放锁，sleep() 不会。

await() signal() signalAll()

java.util.concurrent 类库中提供了 Condition 类来实现线程之间的协调，可以在 Condition 上调用 await() 方法使线程等待，其它线程调用 signal() 或 signalAll() 方法唤醒等待的线程。

相比于 wait() 这种等待方式，await() 可以指定等待的条件，因此更加灵活。

使用 Lock 来获取一个 Condition 对象。

public class AwaitSignalExample {
    private Lock lock = new ReentrantLock();
    private Condition condition = lock.newCondition();
    public void before() {
        lock.lock();
        try {
            System.out.println("before");
            condition.signalAll();
        } finally {
            lock.unlock();
        }
    }

    public void after() {
        lock.lock();
        try {
            condition.await();
            System.out.println("after");
        } catch (InterruptedException e) {
            e.printStackTrace();
        } finally {
            lock.unlock();
        }
    }
}
public static void main(String[] args) {
    ExecutorService executorService = Executors.newCachedThreadPool();
    AwaitSignalExample example = new AwaitSignalExample();
    executorService.execute(() -> example.after());
    executorService.execute(() -> example.before());
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

运行结果：

before
after
1
2

CAS

CAS,compare and swap的缩写，中文翻译成比较并交换。乐观锁用到的机制就是CAS，每次不加锁而是假设没有冲突而去完成某项操作，如果因为冲突失败就重试。

原理：

CAS有3个操作数，内存值V，旧的预期值A，要修改的新值B。当且仅当预期值A和内存值V相同时，将内存值V修改为B，否则什么都不做。
JDK文档说cas同时具有volatile读和volatile写的内存语义。

缺点：

1.ABA问题。 因为CAS需要在操作值的时候检查下值有没有发生变化，如果没有发生变化则更新，但是如果一个值原来是A，变成了B，又变成了A，那么使用CAS进行检查时会发现它的值没有发生变化

2.循环时间长开销大。 自旋CAS如果长时间不成功，会给CPU带来非常大的执行开销。

3.只能保证一个共享变量的原子操作。 对多个共享变量操作时，循环CAS就无法保证操作的原子性，这个时候就可以用锁，或者有一个取巧的办法，就是把多个共享变量合并成一个共享变量来操作。比如有两个共享变量i＝2,j=a，合并一下ij=2a，然后用CAS来操作ij。从Java1.5开始JDK提供了AtomicReference类来保证引用对象之间的原子性，你可以把多个变量放在一个对象里来进行CAS操作。

Java 内存模型（JMM）

Java 内存模型试图屏蔽各种硬件和操作系统的内存访问差异，以实现让 Java 程序在各种平台下都能达到一致的内存访问效果。

主内存与工作内存

处理器上的寄存器的读写的速度比内存快几个数量级，为了解决这种速度矛盾，在它们之间加入了高速缓存。

加入高速缓存带来了一个新的问题：缓存一致性。如果多个缓存共享同一块主内存区域，那么多个缓存的数据可能会不一致，需要一些协议来解决这个问题。

所有的变量都存储在主内存中，每个线程还有自己的工作内存，工作内存存储在高速缓存或者寄存器中，保存了该线程使用的变量的主内存副本拷贝。

线程只能直接操作工作内存中的变量，不同线程之间的变量值传递需要通过主内存来完成。

内存模型三大特性

1.原子性
原子性是指一个操作是不可中断的，要么全部执行成功要么全部执行失败，有着“同生共死”的感觉。及时在多个线程一起执行的时候，一个操作一旦开始，就不会被其他线程所干扰。我们先来看看哪些是原子操作，哪些不是原子操作，有一个直观的印象：

int a = 10; //1
a++; //2
int b=a; //3
a = a+1; //4
1
2
3
4

上面这四个语句中只有第1个语句是原子操作，将10赋值给线程工作内存的变量a,而语句2（a++），实际上包含了三个操作：1. 读取变量a的值；2：对a进行加一的操作；3.将计算后的值再赋值给变量a，而这三个操作无法构成原子操作。对语句3,4的分析同理可得这两条语句不具备原子性。当然，java内存模型中定义了下图中的8种操作都是原子的，不可再分的。例如对一个 int 类型的变量执行 assign 赋值操作，这个操作就是原子性的。但是 Java 内存模型允许虚拟机将没有被 volatile 修饰的 64 位数据（long，double）的读写操作划分为两次 32 位的操作来进行，即 load、store、read 和 write 操作可以不具备原子性。

上面的这些指令操作是相当底层的，可以作为扩展知识面掌握下。那么如何理解这些指令了?比如，把一个变量从主内存中复制到工作内存中就需要执行read,load操作，将工作内存同步到主内存中就需要执行store,write操作。注意的是：java内存模型只是要求上述两个操作是顺序执行的并不是连续执行的。也就是说read和load之间可以插入其他指令，store和writer可以插入其他指令。比如对主内存中的a,b进行访问就可以出现这样的操作顺序：read a,read b, load b,load a。

有一个错误认识就是，int 等原子性的类型在多线程环境中不会出现线程安全问题。下面是一个线程不安全示例代码，cnt 属于 int 类型变量，1000 个线程对它进行自增操作之后，得到的值为 997 而不是 1000。

public class ThreadUnsafeExample {
    private int cnt = 0;
    public void add() {
        cnt++;
    }
    public int get() {
        return cnt;
    }
}
public static void main(String[] args) throws InterruptedException {
    final int threadSize = 1000;
    ThreadUnsafeExample example = new ThreadUnsafeExample();
    final CountDownLatch countDownLatch = new CountDownLatch(threadSize);
    ExecutorService executorService = Executors.newCachedThreadPool();
    for (int i = 0; i < threadSize; i++) {
        executorService.execute(() -> {
            example.add();
            countDownLatch.countDown();
        });
    }
    countDownLatch.await();
    executorService.shutdown();
    System.out.println(example.get());
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

997

为了方便讨论，将内存间的交互操作简化为 3 个：load、assign、store。

下图演示了两个线程同时对 cnt 进行操作，load、assign、store 这一系列操作整体上看不具备原子性，那么在 T1 修改 cnt 并且还没有将修改后的值写入主内存，T2 依然可以读入旧值。可以看出，这两个线程虽然执行了两次自增运算，但是主内存中 cnt 的值最后为 1 而不是 2。因此对 int 类型读写操作满足原子性只是说明 load、assign、store 这些单个操作具备原子性。

使用 AtomicInteger 重写之前线程不安全的代码之后得到以下线程安全实现：

public class AtomicExample {
    private AtomicInteger cnt = new AtomicInteger();

    public void add() {
        cnt.incrementAndGet();
    }

    public int get() {
        return cnt.get();
    }
}
public static void main(String[] args) throws InterruptedException {
    final int threadSize = 1000;
    AtomicExample example = new AtomicExample(); // 只修改这条语句
    final CountDownLatch countDownLatch = new CountDownLatch(threadSize);
    ExecutorService executorService = Executors.newCachedThreadPool();
    for (int i = 0; i < threadSize; i++) {
        executorService.execute(() -> {
            example.add();
            countDownLatch.countDown();
        });
    }
    countDownLatch.await();
    executorService.shutdown();
    System.out.println(example.get());
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

1000

除了使用原子类之外，也可以使用 synchronized 互斥锁来保证操作的原子性。它对应的内存间交互操作为：lock 和 unlock，在虚拟机实现上对应的字节码指令为 monitorenter 和 monitorexit。

public class AtomicSynchronizedExample {
    private int cnt = 0;
    public synchronized void add() {
        cnt++;
    }
    public synchronized int get() {
        return cnt;
    }
}
public static void main(String[] args) throws InterruptedException {
    final int threadSize = 1000;
    AtomicSynchronizedExample example = new AtomicSynchronizedExample();
    final CountDownLatch countDownLatch = new CountDownLatch(threadSize);
    ExecutorService executorService = Executors.newCachedThreadPool();
    for (int i = 0; i < threadSize; i++) {
        executorService.execute(() -> {
            example.add();
            countDownLatch.countDown();
        });
    }
    countDownLatch.await();
    executorService.shutdown();
    System.out.println(example.get());
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

1000

2.可见性
可见性指当一个线程修改了共享变量的值，其它线程能够立即得知这个修改。Java 内存模型是通过在变量修改后将新值同步回主内存，在变量读取前从主内存刷新变量值来实现可见性的。

主要有有三种实现可见性的方式：

• volatile
• synchronized，对一个变量执行 unlock 操作之前，必须把变量值同步回主内存。
• final，被 final 关键字修饰的字段在构造器中一旦初始化完成，并且没有发生 this 逃逸（其它线程通过 this 引用访问到初始化了一半的对象），那么其它线程就能看见 final 字段的值。

对前面的线程不安全示例中的 cnt 变量使用 volatile 修饰，不能解决线程不安全问题，因为 volatile 并不能保证操作的原子性。

3.有序性
有序性是指：在本线程内观察，所有操作都是有序的。在一个线程观察另一个线程，所有操作都是无序的，无序是因为发生了指令重排序。在 Java 内存模型中，允许编译器和处理器对指令进行重排序，重排序过程不会影响到单线程程序的执行，却会影响到多线程并发执行的正确性。

volatile 关键字通过添加内存屏障的方式来禁止指令重排，即重排序时不能把后面的指令放到内存屏障之前。

也可以通过 synchronized 来保证有序性，它保证每个时刻只有一个线程执行同步代码，相当于是让线程顺序执行同步代码。

线程安全

多个线程不管以何种方式访问某个类，并且在主调代码中不需要进行同步，都能表现正确的行为。
线程安全有以下几种实现方式：

1.不可变

不可变（Immutable）的对象一定是线程安全的，不需要再采取任何的线程安全保障措施。只要一个不可变的对象被正确地构建出来，永远也不会看到它在多个线程之中处于不一致的状态。多线程环境下，应当尽量使对象成为不可变，来满足线程安全。

不可变的类型：

• final 关键字修饰的基本数据类型
• String
• 枚举类型
• Number 部分子类，如 Long 和 Double 等数值包装类型，BigInteger 和 BigDecimal 等大数据类型。但同为 Number 的原子类 AtomicInteger 和 AtomicLong 则是可变的。

对于集合类型，可以使用 Collections.unmodifiableXXX() 方法来获取一个不可变的集合。

public class ImmutableExample {
    public static void main(String[] args) {
        Map<String, Integer> map = new HashMap<>();
        Map<String, Integer> unmodifiableMap = Collections.unmodifiableMap(map);
        unmodifiableMap.put("a", 1);
    }
  }
1
2
3
4
5
6
7

运行结果显示：

Exception in thread "main" java.lang.UnsupportedOperationException
    at java.util.Collections$UnmodifiableMap.put(Collections.java:1457)
    at ImmutableExample.main(ImmutableExample.java:9)
1
2
3

Collections.unmodifiableXXX() 先对原始的集合进行拷贝，需要对集合进行修改的方法都直接抛出异常。

public V put(K key, V value) {
    throw new UnsupportedOperationException();
}
1
2
3

2.互斥同步

synchronized 和 ReentrantLock，具体内容上文中已经写了。

3.非阻塞同步

互斥同步最主要的问题就是线程阻塞和唤醒所带来的性能问题，因此这种同步也称为阻塞同步。

互斥同步属于一种悲观的并发策略，总是认为只要不去做正确的同步措施，那就肯定会出现问题。无论共享数据是否真的会出现竞争，它都要进行加锁（这里讨论的是概念模型，实际上虚拟机会优化掉很大一部分不必要的加锁）、用户态核心态转换、维护锁计数器和检查是否有被阻塞的线程需要唤醒等操作。

1.CAS
随着硬件指令集的发展，我们可以使用基于冲突检测的乐观并发策略：先进行操作，如果没有其它线程争用共享数据，那操作就成功了，否则采取补偿措施（不断地重试，直到成功为止）。这种乐观的并发策略的许多实现都不需要将线程阻塞，因此这种同步操作称为非阻塞同步。

乐观锁需要操作和冲突检测这两个步骤具备原子性，这里就不能再使用互斥同步来保证了，只能靠硬件来完成。硬件支持的原子性操作最典型的是：比较并交换（Compare-and-Swap，CAS）。CAS 指令需要有 3 个操作数，分别是内存地址 V、旧的预期值 A 和新值 B。当执行操作时，只有当 V 的值等于 A，才将 V 的值更新为 B。

JDK文档说cas同时具有volatile读和volatile写的内存语义。

CAS的缺点：
1.ABA问题。 因为CAS需要在操作值的时候检查下值有没有发生变化，如果没有发生变化则更新，但是如果一个值原来是A，变成了B，又变成了A，那么使用CAS进行检查时会发现它的值没有发生变化

2.循环时间长开销大。 自旋CAS如果长时间不成功，会给CPU带来非常大的执行开销。

3.只能保证一个共享变量的原子操作。 对多个共享变量操作时，循环CAS就无法保证操作的原子性，这个时候就可以用锁，或者有一个取巧的办法，就是把多个共享变量合并成一个共享变量来操作。比如有两个共享变量i＝2,j=a，合并一下ij=2a，然后用CAS来操作ij。从Java1.5开始JDK提供了AtomicReference类来保证引用对象之间的原子性，你可以把多个变量放在一个对象里来进行CAS操作。

2.AtomicInteger
J.U.C(java.util.concurrent) 包里面的整数原子类 AtomicInteger 的方法调用了 Unsafe 类的 CAS 操作。

以下代码使用了 AtomicInteger 执行了自增的操作。

private AtomicInteger cnt = new AtomicInteger();
public void add() {
    cnt.incrementAndGet();
}
1
2
3
4

以下代码是 incrementAndGet() 的源码，它调用了 Unsafe 的 getAndAddInt() 。

public final int incrementAndGet() {
    return unsafe.getAndAddInt(this, valueOffset, 1) + 1;
}
1
2
3

以下代码是 getAndAddInt() 源码，var1 指示对象内存地址，var2 指示该字段相对对象内存地址的偏移，var4 指示操作需要加的数值，这里为 1。通过 getIntVolatile(var1, var2) 得到旧的预期值，通过调用 compareAndSwapInt() 来进行 CAS 比较，如果该字段内存地址中的值等于 var5，那么就更新内存地址为 var1+var2 的变量为 var5+var4。

可以看到 getAndAddInt() 在一个循环中进行，发生冲突的做法是不断的进行重试。

public final int getAndAddInt(Object var1, long var2, int var4) {
    int var5;
    do {
        var5 = this.getIntVolatile(var1, var2);
    } while(!this.compareAndSwapInt(var1, var2, var5, var5 + var4));

    return var5;
}
1
2
3
4
5
6
7
8

3.ABA
如果一个变量初次读取的时候是 A 值，它的值被改成了 B，后来又被改回为 A，那 CAS 操作就会误认为它从来没有被改变过。

J.U.C 包提供了一个带有标记的原子引用类 AtomicStampedReference 来解决这个问题，它可以通过控制变量值的版本来保证 CAS 的正确性。大部分情况下 ABA 问题不会影响程序并发的正确性，如果需要解决 ABA 问题，改用传统的互斥同步可能会比原子类更高效。

无同步方案

要保证线程安全，并不是一定就要进行同步。如果一个方法本来就不涉及共享数据，那它自然就无须任何同步措施去保证正确性。

1.栈封闭
多个线程访问同一个方法的局部变量时，不会出现线程安全问题，因为局部变量存储在虚拟机栈中，属于线程私有的。

public class StackClosedExample {
    public void add100() {
        int cnt = 0;
        for (int i = 0; i < 100; i++) {
            cnt++;
        }
        System.out.println(cnt);
    }
}
public static void main(String[] args) {
    StackClosedExample example = new StackClosedExample();
    ExecutorService executorService = Executors.newCachedThreadPool();
    executorService.execute(() -> example.add100());
    executorService.execute(() -> example.add100());
    executorService.shutdown();
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

运行结果：

100
100
1
2

2.线程本地存储（Thread Local Storage）
如果一段代码中所需要的数据必须与其他代码共享，那就看看这些共享数据的代码是否能保证在同一个线程中执行。如果能保证，我们就可以把共享数据的可见范围限制在同一个线程之内，这样，无须同步也能保证线程之间不出现数据争用的问题。

符合这种特点的应用并不少见，大部分使用消费队列的架构模式（如“生产者-消费者”模式）都会将产品的消费过程尽量在一个线程中消费完。其中最重要的一个应用实例就是经典 Web 交互模型中的“一个请求对应一个服务器线程”（Thread-per-Request）的处理方式，这种处理方式的广泛应用使得很多 Web 服务端应用都可以使用线程本地存储来解决线程安全问题。

可以使用 java.lang.ThreadLocal 类来实现线程本地存储功能。

对于以下代码，thread1 中设置 threadLocal 为 1，而 thread2 设置 threadLocal 为 2。过了一段时间之后，thread1 读取 threadLocal 依然是 1，不受 thread2 的影响。

public class ThreadLocalExample {
    public static void main(String[] args) {
        ThreadLocal threadLocal = new ThreadLocal();
        Thread thread1 = new Thread(() -> {
            threadLocal.set(1);
            try {
                Thread.sleep(1000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            System.out.println(threadLocal.get());
            threadLocal.remove();
        });
        Thread thread2 = new Thread(() -> {
            threadLocal.set(2);
            threadLocal.remove();
        });
        thread1.start();
        thread2.start();
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

1

为了理解 ThreadLocal，先看以下代码：

public class ThreadLocalExample1 {
    public static void main(String[] args) {
        ThreadLocal threadLocal1 = new ThreadLocal();
        ThreadLocal threadLocal2 = new ThreadLocal();
        Thread thread1 = new Thread(() -> {
            threadLocal1.set(1);
            threadLocal2.set(1);
        });
        Thread thread2 = new Thread(() -> {
            threadLocal1.set(2);
            threadLocal2.set(2);
        });
        thread1.start();
        thread2.start();
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

每个 Thread 都有一个 ThreadLocal.ThreadLocalMap 对象。

/* ThreadLocal values pertaining to this thread. This map is maintained
 * by the ThreadLocal class. */
ThreadLocal.ThreadLocalMap threadLocals = null;
1
2
3

当调用一个 ThreadLocal 的 set(T value) 方法时，先得到当前线程的 ThreadLocalMap 对象，然后将 ThreadLocal->value 键值对插入到该 Map 中。

public void set(T value) {
    Thread t = Thread.currentThread();
    ThreadLocalMap map = getMap(t);
    if (map != null)
        map.set(this, value);
    else
        createMap(t, value);
}
1
2
3
4
5
6
7
8

get() 方法类似。

public T get() {
    Thread t = Thread.currentThread();
    ThreadLocalMap map = getMap(t);
    if (map != null) {
        ThreadLocalMap.Entry e = map.getEntry(this);
        if (e != null) {
            @SuppressWarnings("unchecked")
            T result = (T)e.value;
            return result;
        }
    }
    return setInitialValue();
}
1
2
3
4
5
6
7
8
9
10
11
12
13

ThreadLocal 从理论上讲并不是用来解决多线程并发问题的，因为根本不存在多线程竞争。

在一些场景 (尤其是使用线程池) 下，由于 ThreadLocal.ThreadLocalMap 的底层数据结构导致 ThreadLocal 有内存泄漏的情况，应该尽可能在每次使用 ThreadLocal 后手动调用 remove()，以避免出现 ThreadLocal 经典的内存泄漏甚至是造成自身业务混乱的风险。

3.可重入代码（Reentrant Code）
这种代码也叫做纯代码（Pure Code），可以在代码执行的任何时刻中断它，转而去执行另外一段代码（包括递归调用它本身），而在控制权返回后，原来的程序不会出现任何错误。

可重入代码有一些共同的特征，例如不依赖存储在堆上的数据和公用的系统资源、用到的状态量都由参数中传入、不调用非可重入的方法等。

其他考点

1.CountDownLatch与CyclicBarrier的比较

CountDownLatch与CyclicBarrier都是用于控制并发的工具类，都可以理解成维护的就是一个计数器，但是这两者还是各有不同侧重点的：

• CountDownLatch一般用于某个线程A等待若干个其他线程执行完任务之后，它才执行；而CyclicBarrier一般用于一组线程互相等待至某个状态，然后这一组线程再同时执行；CountDownLatch强调一个线程等多个线程完成某件事情。CyclicBarrier是多个线程互等，等大家都完成，再携手共进。
• 调用CountDownLatch的countDown方法后，当前线程并不会阻塞，会继续往下执行；而调用CyclicBarrier的await方法，会阻塞当前线程，直到CyclicBarrier指定的线程全部都到达了指定点的时候，才能继续往下执行；
• CountDownLatch方法比较少，操作比较简单，而CyclicBarrier提供的方法更多，比如能够通过getNumberWaiting()，isBroken()这些方法获取当前多个线程的状态，并且CyclicBarrier的构造方法可以传入barrierAction，指定当所有线程都到达时执行的业务功能；
• CountDownLatch是不能复用的，而CyclicLatch是可以复用的。

2.对象锁和静态锁之间的区别

1.对象锁用于对象实例方法，
2.类锁用于类的静态方法或一个类的class对象。
3.类的对象实例可以有很多，不同对象实例的对象锁互不干扰，而每个类只有一个类锁

3.简述volatile字

两个特性：

• 保证了不同线程对这个变量进行 读取 时的可见性，即一个线程修改 了某个变量的值 ， 这新值对其他线程来说是立即可见的 。(volatile 解决了 线程间 共享变量
• 禁止进行指令重排序 ，阻止编译器对代码的优化

要想并发程序正确地执行，必须要保证原子性、可见性以及有序性，锁保证了原子性，而volatile保证可见性和有序性

4.happens-before 原则（先行发生原则）

我们无法就所有场景来规定某个线程修改的变量何时对其他线程可见，但是我们可以指定某些规则，这规则就是happens-before。特别关注在多线程之间的内存可见性。

它是判断数据是否存在竞争、线程是否安全的主要依据，依靠这个原则，我们解决在并发环境下两操作之间是否可能存在冲突的所有问题。

1.程序次序规则：一个线程内，按照代码顺序，书写在前面的操作先行发生于书写在 后面的操作
2.锁定规则：一个 unLock 操作先行发生于后面对同一个锁的 lock 操作
3.volatile 变量规则：对一个变量的写操作先行发生于后面对这个变量的读操作
4.传递规则：如果操作 A 先行发生于操作 B，而操作 B 又先行发生于操作 C，则可以 得出操作 A 先行发生于操作 C
5.线程启动规则：Thread 对象的 start()方法先行发生于此线程的每个一个动作
6.线程中断规则：对线程 interrupt()方法的调用先行发生于被中断线程的代码检测 到中断事件的发生
7.线程终结规则：线程中所有的操作都先行发生于线程的终止检测，我们可以通过 T hread.join()方法结束、Thread.isAlive()的返回值手段检测到线程已经终止执行
8.对象终结规则：一个对象的初始化完成先行发生于他的 finalize()方法的开始

5.Lock 和synchronized 的区别

1.Lock 是一个 接口，而 synchronized 是 Java 中的 关键字， synchronized 是 内置的语言实现；

2.synchronized 在 发生异常时，会 自动释放线程占有的锁，因此 不会导 致死锁现象发生；而 Lock 在发生异常时，如果没有主动通过 unLock()去释放 锁，则很 可能造成死锁现象，因此用 使用 Lock 时需要在 finally 块中释放锁；

3.Lock 可以让 等待锁的线程响应中断 （可中断锁），而 synchronized 却不行，使用 synchronized 时，等待的线程会一直等待下去， 不能够响应中 断 （不可中断锁）；

4.通过 Lock 可以知道 有没有成功获取锁 （tryLock （ ） 方法 ： 如果获取 了锁，则返回 true；否则返回 false。 也就说这个方法无论如何都会立即返回。在拿不到锁时不会一直在那等待。 ）而 synchronized 却无法办到。

5.Lock 可以提高 多个线程进行读操作的效率（ 读写锁）。

6.Lock 可以实现 公平锁，synchronized 不保证公平性。 在性能上来说，如果线程竞争资源不激烈时，两者的性能是差不多的，而 当竞争资源非常激烈时（即有大量线程同时竞争），此时 Lock 的性能要远远优 于 synchronized。所以说，在具体使用时要根据适当情况选择。

6.ThreadLocal

Synchronized实现内存共享，ThreadLocal为每个线程维护一个本地变量。 采用空间换时间，它用于线程间的数据隔离，为每一个使用该变量的线程提供一个副本，每个线程都可以独立地改变自己的副本，而不会和其他线程的副本冲突。 ThreadLocal类中维护一个Map，用于存储每一个线程的变量副本，Map中元素的键为线程对象，而值为对应线程的变量副本。 ThreadLocal在Spring中发挥着巨大的作用，在管理Request作用域中的Bean、事务管理、任务调度、AOP等模块都出现了它的身影。 Spring中绝大部分Bean都可以声明成Singleton作用域，采用ThreadLocal进行封装，因此有状态的Bean就能够以singleton的方式在多线程中正常工作了。

7.通过Callable和Future创建线程

Java 5在concurrency包中引入了java.util.concurrent.Callable 接口，它和Runnable接口很相似，但它可以返回一个对象或者抛出一个异常。

Callable接口使用泛型去定义它的返回类型。Executors类提供了一些有用的方法去在线程池中执行Callable内的任务。由于Callable任务是并行的，我们必须等待它返回的结果。java.util.concurrent.Future对象为我们解决了这个问题。在线程池提交Callable任务后返回了一个Future对象，使用它我们可以知道Callable任务的状态和得到Callable返回的执行结果。Future提供了get()方法让我们可以等待Callable结束并获取它的执行结果。

1.创建Callable接口的实现类，并实现call()方法，该call()方法将作为线程执行体，并且有返回值。
2.创建Callable实现类的实例，使用FutureTask类来包装Callable对象，该FutureTask对象封装了该Callable对象的call()方法的返回值。
3.使用FutureTask对象作为Thread对象的target创建并启动新线程。
4.调用FutureTask对象的get()方法来获得子线程执行结束后的返回值

8.什么叫守护线程，用什么方法实现守护线程（Thread.setDeamon()的含义）

在Java中有两类线程：User Thread(用户线程)、Daemon Thread(守护线程) 用个比较通俗的比如，任何一个守护线程都是整个JVM中所有非守护线程的保姆： 只要当前JVM实例中尚存在任何一个非守护线程没有结束，守护线程就没有结束；只有当最后一个非守护线程结束时，守护线程随着JVM一同结束工作。
JVM内部的实现是如果运行的程序只剩下守护线程的话，程序将终止运行，直接结束。所以守护线程是作为辅助线程存在的，主要的作用是提供计数等等辅助的功能。

9.如何停止一个线程？

终止线程的三种方法：
1.使用退出标志，使线程正常退出，也就是当run方法完成后线程终止。 在定义退出标志exit时，使用了一个Java关键字volatile，这个关键字的目的是使exit同步，也就是说在同一时刻只能由一个线程来修改exit的值，
thread.exit = true; // 终止线程thread
2.使用stop方法强行终止线程（这个方法不推荐使用，因为stop和suspend、resume一样，也可能发生不可预料的结果）。 使用stop方法可以强行终止正在运行或挂起的线程。我们可以使用如下的代码来终止线程： thread.stop(); 虽然使用上面的代码可以终止线程，但使用stop方法是很危险的，就象突然关闭计算机电源，而不是按正常程序关机一样，可能会产生不可预料的结果，因此，并不推荐使用stop方法来终止线程。

3.使用interrupt方法中断线程，使用interrupt方法来终端线程可分为两种情况：

• 线程处于阻塞状态，如使用了sleep方法。
• 使用while（！isInterrupted（））{……}来判断线程是否被中断。 在第一种情况下使用interrupt方法，sleep方法将抛出一个InterruptedException例外，而在第二种情况下线程将直接退出。

注意：在Thread类中有两个方法可以判断线程是否通过interrupt方法被终止。一个是静态的方法interrupted（），一个是非静态的方法isInterrupted（），这两个方法的区别是interrupted用来判断当前线是否被中断，而isInterrupted可以用来判断其他线程是否被中断。因此，while （！isInterrupted（））也可以换成while （！Thread.interrupted（））。

10.什么是线程安全？什么是线程不安全？

线程安全就是多线程访问时，采用了加锁机制，当一个线程访问该类的某个数据时，进行保护，其他线程不能进行访问直到该线程读取完，其他线程才可使用。不会出现数据不一致或者数据污染。

线程不安全就是不提供数据访问保护，有可能出现多个线程先后更改数据造成所得到的数据是脏数据 在多线程的情况下，由于同一进程的多个线程共享同一片存储空间，在带来方便的同时，也带来了访问冲突这个严重的问题。Java语言提供了专门机制以解决这种冲突，有效避免了同一个数据对象被多个线程同时访问。

11.I/O多路复用

单个线程，通过记录跟踪每个I/O流(sock)的状态，来同时管理多个I/O流 。尽量多的提高服务器的吞吐能力 select, poll, epoll 都是I/O多路复用的具体的实现

12.netty

netty通过Reactor模型基于多路复用器接收并处理用户请求，内部实现了两个线程池，boss线程和work线程池，其中boss线程池的线程负责处理请求的accept事件，当接收到accept事件的请求，把对应的socket封装到一个NioSocketChannel中，并交给work线程池，其中work线程池负责请求的read和write事件

13.Nio的原理（同步非阻塞）

服务端和客户端各自维护一个管理通道的对象，我们称之为 selector，该对象能检测一个或多个通道（channel）上的事件。我们以服务端为例，如果服务端的 selector 上注册了读事件，某时刻客户端给服务端送了一些数据，阻塞 I/O 这时会调用 read()方法阻塞地读取数据，而 NIO 的服务端会在 selector 中添加 一个读事件。服务端的处理线程会轮询地访问 selector，如果访问 selector 时发 现有感兴趣的事件到达，则处理这些事件，如果没有感兴趣的事件到达，则处 理线程会一直阻塞直到感兴趣的事件到达为止。

14.缓冲区Buffer、通道Channel、选择器Selector

缓冲区Buffer
缓冲区实际上是一个容器对象，更直接的说，其实就是一个数组，在NIO库中，所有数据都是用缓冲区处理的。在读取数据时，它是直接读到缓冲区中的； 在写入数据时，它也是写入到缓冲区中的；任何时候访问 NIO 中的数据，都是将它放到缓冲区中。而在面向流I/O系统中，所有数据都是直接写入或者直接将数据读取到Stream对象中。

通道Channel
通道是一个对象，通过它可以读取和写入数据，当然了所有数据都通过Buffer对象来处理。我们永远不会将字节直接写入通道中，相反是将数据写入包含一个或者多个字节的缓冲区。同样不会直接从通道中读取字节，而是将数据从通道读入缓冲区，再从缓冲区获取这个字节。通道与流的不同之处在于 通道是双向 的。而流只是在一个方向上移动(一个流必须是 InputStream 或者 OutputStream 的子类，比如 InputStream 只能进行读取操作，OutputStream 只能进行写操作)，而通道是双向的，可以用于读、写或者同时用于读写。

选择器（Selector ）
NIO 有一个主要的类 Selector,这个类似一个观察者，只要我们把需要探知 的 socketchannel 告诉 Selector,我们接着做别的事情， 当有事件发生时，他会 通知我们，传回一组 SelectionKey, 我们读取这些 Key, 就会获得我们刚刚注册 过的 socketchannel, 然后，我们从这个 Channel 中读取数据，放心，包准能 够读到，接着我们可以处理这些数据。
Selector 内部原理实际是在做一个 对所注册的 channel 的轮询访问，不断 地轮询，一旦轮询到一个 channel 有所注册的事情发生，比如数据来了，他就 会站起来报告， 交出一把钥匙，让我们 通过这把钥匙来读取这个 channel 的内 容。

14.BIO和NIO的区别

BIO：同步阻塞式IO，服务器实现模式为一个连接一个线程，即客户端有连接请求时服务器端就需要启动一个线程进行处理，如果这个连接不做任何事情会造成不必要的线程开销，当然可以通过线程池机制改善。

NIO：同步非阻塞式IO，服务器实现模式为一个请求一个线程，即客户端发送的连接请求都会注册到多路复用器上，多路复用器轮询到连接有I/O请求时才启动一个线程进行处理。

15.NIO的selector作用

Selector（选择器）是Java NIO中能够检测一到多个NIO通道，并能够知晓通道是否为诸如读写事件做好准备的组件。这样，一个单独的线程可以管理多个channel，从而管理多个网络连接。

为了实现Selector管理多个SocketChannel，必须将具体的SocketChannel对象注册到Selector，并声明需要监听的事件（这样Selector才知道需要记录什么数据），一共有4种事件：
1.connect：客户端连接服务端事件，对应值为SelectionKey.OP_CONNECT(8)
2.accept：服务端接收客户端连接事件，对应值为SelectionKey.OP_ACCEPT(16)
3.read：读事件，对应值为SelectionKey.OP_READ(1)
4.write：写事件，对应值为SelectionKey.OP_WRITE(4)
每次请求到达服务器，都是从connect开始，connect成功后，服务端开始准备accept，准备就绪，开始读数据，并处理，最后写回数据返回。

所以，当SocketChannel有对应的事件发生时，Selector都可以观察到，并进行相应的处理。

16.final域的内存语义

JMM禁止编译器把final域的写重排序到构造函数之外。
编译器会在final域的写之后，构造函数return之前，插入一个StoreStore屏障。这个屏障 禁止处理器把final域的写重排序到构造函数之外。

写final域的重排序规则
对于 final 域，编译器和处理器要遵守两个重排序规则：

JMM 禁止编译器把 final 域的写重排序到构造函数之外
编译器会在 final 域的写之后，构造函数 return 之前，插入一个 StoreStore 屏障，这个屏障禁止处理器把 final 域的写重排序到构造函数之外。

读final域的重排序规则
在一个线程中,初次读对象引用与初次读该对象包含的 final 域,JMM 禁止处理器重排序这两个操作(注意,这个规则仅仅针对处理器)。编译器会在读 final 域操作的前面插入一个 LoadLoad 屏障。 reader() 方法包含三个操作:

初次读引用变量 obj;
初次读引用变量 obj 指向对象的普通域 j。
初次读引用变量 obj 指向对象的 final 域 i。

(2019.02.18更新) Java面试常见考点：wait 和sleep 方法比较
1.这两个方法来自不同的类分别是Thread和Object

2.最主要是sleep方法没有释放锁，而wait方法释放了锁，使得其他线程可以使用同步控制块或者方法。

3.wait，notify和notifyAll只能在同步控制方法或者同步控制块里面使用，而sleep可以在任何地方使用(使用范围)

4.sleep必须捕获异常，而wait，notify和notifyAll不需要捕获异常

5.sleep方法属于Thread类中方法，表示让一个线程进入睡眠状态，等待一定的时间之后，自动醒来进入到可运行状态，不会马上进入运行状态，因为线程调度机制恢复线程的运行也需要时间，一个线程对象调用了sleep方法之后，并不会释放他所持有的所有对象锁，所以也就不会影响其他进程对象的运行。但在sleep的过程中过程中有可能被其他对象调用它的interrupt(),产生InterruptedException异常，如果你的程序不捕获这个异常，线程就会异常终止，进入TERMINATED状态，如果你的程序捕获了这个异常，那么程序就会继续执行catch语句块(可能还有finally语句块)以及以后的代码。

6.注意sleep()方法是一个静态方法，也就是说他只对当前对象有效，通过t.sleep()让对象进入sleep，这样的做法是错误的，它只会是使当前线程被sleep 而不是t线程

7.wait属于Object的成员方法，一旦一个对象调用了wait方法，必须要采用notify()和notifyAll()方法唤醒该进程;如果线程拥有某个或某些对象的同步锁，那么在调用了wait()后，这个线程就会释放它持有的所有同步资源，而不限于这个被调用了wait()方法的对象。wait()方法也同样会在wait的过程中有可能被其他对象调用interrupt()方法而产生。

(2019.03.03更新)

多线程程序使用的高性能数据结构

java.util.concurrent包中提供了一些适合多线程程序使用的高性能数据结构，包括队列和集合类对象等。

1、队列

a、BlockingQueue接口：线程安全的阻塞式队列；当队列已满时，队列添加数据会阻塞；当队列空时，取数据会阻塞。（非常适合消费者-生产者模式）

阻塞方式：put()、take()。

非阻塞方式：offer()、poll()。

实现类：基于数组的固定元素个数的ArrayBolockingQueue和基于链表结构的不固定元素个数的LinkedBlockQueue类。

b、BlockingDeque接口： 与BlockingQueue相似，但可以对头尾进行添加和删除操作的双向队列；方法分为两类，分别在队首和对尾进行操作。

实现类：标准库值提供了一个基于链表的实现，LinkedBlockgingDeque。

2、集合类

在多线程程序中，如果共享变量是集合类的对象，则不适合直接使用java.util包中的集合类。这些类要么不是线程安全，要么在多线程下性能比较差。

应该使用java.util.concurrent包中的集合类。

a、ConcurrentMap接口： 继承自java.util.Map接口

putIfAbsent()：只有在散列表不包含给定键时，才会把给定的值放入。

remove()：删除条目。

replace(key,value)：把value 替换到给定的key上。

replace(key, oldvalue, newvalue)：CAS的实现。

实现类：ConcurrentHashMap：

创建时，如果可以预估可能包含的条目个数，可以优化性能。（因为动态调整所能包含的数目操作比较耗时，这个HashMap也一样，只是多线程下更耗时）。

创建时，预估进行更新操作的线程数，这样实现中会根据这个数把内部空间划分为对应数量的部分。（默认是16，如果只有一个线程进行写操作，其他都是读取，那么把值设为1 可以提高性能）。

注：当从集合中创建出迭代器遍历Map元素时，不一定能看到正在添加的数据，只能和集合保证弱一致性。（当然使用迭代器不会因为查看正在改变的Map，而抛出java.util.ConcurrentModifycationException）

b、CopyOnWriteArrayList接口：继承自java.util.List接口

顾名思义，在CopyOnWriteArrayList的实现类，所有对列表的更新操作都会新创建一个底层数组的副本，并使用副本来存储数据；对列表更新操作加锁，读取操作不加锁。

适合多读取少修改的场景，如果更新操作多，那么不适合用，同样迭代器只能表示创建时列表的状态，更新后使用了新的底层数组，迭代器还是引用旧的底层数组。

多线程任务的执行

以往线程的执行，是先创建Thread类的想，再调用start方法启动，这种做法要求开发人员对线程进行维护，在线程较多时，一般创建一个线程池同一管理，同时降低重复创建线程的开销

在jdk 1.5中，java.util.concurrent包提供了丰富的用来管理线程和执行任务的实现。

1、基本接口（描述任务）

a、Callable接口：

Runnable接口受限于run方法的类型签名，而Callable只有一个方法call()，可以有返回值，可以抛出受检异常。

b、Future接口：

过去，需要异步线程的任务执行结果，要求主线程和任务执行线程之间进行同步和数据传递。

Future简化了任务的异步执行，作为异步操作的一个抽象。调用get()方法可以获取异步的执行结果，如果任务没有执行完，会等待，直到任务完成或被取消，cancel()可以取消。

c、Delayed接口：

延迟执行任务，getDelay()返回当前剩余的延迟时间，如果不大于0，说明延迟时间已经过去，应该调度并执行该任务。

2、组合接口（描述任务）

a、RunnableFuture接口：继承自Runnable接口和Future接口。

当来自Runnalbe接口中的run方法成功执行之后，相当于Future接口表示的异步任务已经完成，可以通过get()获取运行结果。

b、ScheduledFuture接口：继承Future接口和Delayed接口，表示一个可以调用的异步操作。

c、RunnableScheduledFuture接口：继承自Runnable、Delayed和Future，接口中包含isPeriodic，表明该异步操作是否可以被重复执行。

3、Executor接口、ExcutorServer接口、ScheduleExecutorService接口和CompletionService接口（描述任务执行）

a、executor接口，execute()用来执行一个Runnable接口的实现对象，不同的Executor实现采取不同执行策略，但提供的任务执行功能比较弱。

b、excutorServer接口，继承自executor；

提供了对任务的管理：submit()，可以吧Callable和Runnable作为任务提交，得到一个Future作为返回，可以获取任务结果或取消任务。

提供批量执行：invokeAll()和invokeAny()，同时提交多个Callable；invokeAll()，会等待所有任务都执行完成，返回一个包含每个任务对应Future的列表；invokeAny()，任何一个任务成功完成，即返回该任务结果。

提供任务关闭：shutdown()、shutdownNow()来关闭服务，前者不允许新的任务提交，后者试图终止正在运行和等待的任务，并返回已经提交单没有被运行的任务列表。（两个方法都不会等待服务真正关闭，只是发出关闭请求。）。shutdownDow，通常做法是向线程发出中断请求，所以确保提交的任务实现了正确的中断处理逻辑。

c、ScheduleExecutorService接口，继承自excutorServer接口：支持任务的延迟执行和定期执行，可以执行Callable或Runnable。

schedule()，调度一个任务在延迟若干时间之后执行；

scheduleAtFixedRate()：在初始延迟后，每隔一段时间循环执行；在下一次执行开始时，上一次执行可能还未结束。（同一时间，可能有多个）

scheduleWithFixedDelay：同上，只是在上一次任务执行完后，经过给定的间隔时间再开始下一次执行。（同一时间，只有一个）

以上三个方法都返回ScheduledFuture接口的实现对象。

d、CompletionService接口，共享任务执行结果。

通常在使用ExecutorService接口，通过submit提交任务，并得到一个Future接口来获取任务结果，如果任务提交者和执行结果的使用者是程序的不同部分，那就要把Future在不同部分进行传递；而CompletionService就是解决这个问题，程序不同部分可以共享CompletionService，任务提交后，执行结果可以通过take（阻塞），poll（非阻塞）来获取。

标准库提供的实现是 ExecutorCompletionService，在创建时，需要提供一个Executor接口的实现作为参数，用来实际执行任务。

jdk 1.7对JUC的更新

jdk 1.7对java.util.concurrent包进行更新，增加了新的轻量级任务执行框架fork/join和多阶段线程同步工具。

1、轻量级任务执行框架fork/join

这个框架的目的主要是更好地利用底层平台上的多核和多处理器来进行并行处理。

通过分治算法或map/reduce算法来解决问题。

fork/join 类比于 map/reduce。

fork操作是把一个大的问题划分为若干个较小的问题，划分过程一般为递归，直到可以直接进行计算的粒度适合的子问题；子问题在结算后，可以得到整个问题的部分解

join操作收集子结果，合并，得到完整解，也可能是 递归进行的。

相对一般的线程池实现，F/J框架的优势在任务的处理方式上。在一般线程池中，一个线程由于某些原因无法运行，会等待；而在F/J，某个子问题由于等待另外一个子问题的完成而无法继续运行，那么处理该子问题的线程会主动寻找其他尚未运行的子问题来执行。这种方式减少了等待时间，提高了性能。

为了F/J能高效，在每个子问题视线中应避免使用synchronized或其他方式进行同步，也不应使用阻塞式IO或过多访问共享变量。在理想情况下，每个子问题都应值进行CPU计算，只使用每个问题的内部对象，唯一的同步应只发生在子问题和创建它的父问题之间。（这完全就是Hadoop的MapReduce嘛）

a、ForkJoinTask类：表示一个由F/J框架执行的任务，该类实现了Future接口，可以按照Future接口的方式来使用。（表示任务）

fork()，异步方式启动任务的执行。

join()，等待任务完成并返回执行结果。

在创建自己的任务时，最好不要直接继承自ForkJoinTask，而是继承其子类，RecuriveTask或RecursiveAction，前者可以返回结果，后者不行。

b、ForkJoinPool类：表示任务执行，实现了ExecutorService接口，除了可以执行ForkJoinTask，也可以执行Callable和Runnable。（任务执行）

执行任务的两大类：

第一类：execute、invoke或submit方法：直接提交任务。

第二类：fork()：运行ForkJoinTask在执行过程中的子任务。

一般作法是表示整个问题的ForkJoinTask用第一类提交，执行过程中产生的子任务不需要处理，ForkJoinPool会负责子任务执行。

2、多阶段线程同步工具

Phaser类是Java SE 7中新增的一个使用同步工具，功能和灵活性比倒数闸门和循环屏障要强很多。

在F/J框架中的子任务之间要进行同步时，应优先考虑Phaser。

Phaser把多个线程写作执行的任务划分成多个阶段（phase），编程时要明确各个阶段的任务，每个阶段都可以有任意个参与者，线程可以随时注册并参与到某个阶段，当一个阶段中所有线程都成功完成之后，Phaser的onAdvance()被调用，可以通过覆盖添加自定义处理逻辑（类似循环屏障的使用的Runnable接口），然后Phaser类会自动进入下个阶段。如此循环，知道Phaser不再包含任何参与者。

Phaser创建后，初始阶段编号为0，构造函数中指定初始参与个数。

register()，bulkRegister()，动态添加一个或多个参与者。

arrive()，某个参与者完成任务后调用

arriveAndDeregister()，任务完成，取消自己的注册。

arriveAndAwaitAdvance()，自己完成等待其他参与者完成。，进入阻塞，直到Phaser成功进入下个阶段。

awaitAdvance()、awaitAdvanceInterruptibly()，等待phaser进入下个阶段，参数为当前阶段的编号，后者可以设置超时和处理中断请求。

另外，Phaser的一个重要特征是多个Phaser可以组成树形结构，Phaser提供了构造方法来指定当前对象的父对象；当一个子对象参与者>0，会自动注册到父对象中；当=0，自动解除注册。

(2019.11.19更新)

java并发的优缺点

ok，上文中关于java并发的知识点 南国已经讲了很多了，那么归根起来java并发的优缺点是什么呢？？

优点

关于java并发的优点，相比大家都多多少少知道，这里简单概括的话：
1.并发编程的形式可以将多核CPU的计算能力发挥到极致，性能得到提升
2.面对复杂业务模型，并行程序会比串行程序更适应业务需求，而并发编程更能吻合这种业务拆分

缺点

1.频繁的上下文切换
2.线程安全

首先关于上下文切换：
时间片是CPU分配给各个线程的时间，因为时间非常短，所以CPU不断通过切换线程，让我们觉得多个线程是同时执行的，时间片一般是几十毫秒。而每次切换时，需要保存当前的状态起来，以便能够进行恢复先前状态，而这个切换时非常损耗性能，过于频繁反而无法发挥出多线程编程的优势。通常减少上下文切换可以采用无锁并发编程，CAS算法，使用最少的线程和使用协程。

1. 无锁并发编程：可以参照concurrentHashMap锁分段的思想，不同的线程处理不同段的数据，这样在多线程竞争的条件下，可以减少上下文切换的时间。
2. CAS算法，利用Atomic下使用CAS算法来更新数据，使用了乐观锁，可以有效的减少一部分不必要的锁竞争带来的上下文切换
3. 使用最少线程：避免创建不需要的线程，比如任务很少，但是创建了很多的线程，这样会造成大量的线程都处于等待状态
   协程：在单线程里实现多任务的调度，并在单线程里维持多个任务间的切换

再者关于线程安全问题：
多线程编程中最难以把握的就是临界区线程安全问题，稍微不注意就会出现死锁的情况，一旦产生死锁就会造成系统功能不可用。
一般处理线程安全问题：上文中南国已经做了详细描述。这里简单归纳一下：

1. 使用不可变(Immutable)的对象
2. 使用互斥同步的方式：使用Synchronized或者ReentrantLock
3. 非阻塞同步：CAS AtomicInteger AtmoicBoolean AtomicReference

参考资料：
https://github.com/CyC2018/CS-Notes/blob/master/docs/notes/Java%20%E5%B9%B6%E5%8F%91.md