何为进程?#

进程是程序的一次执行过程，是系统运行程序的基本单位，因此进程是动态的。系统运行一个程序即是一个进程从创建，运行到消亡的过程。

在 Java 中，当我们启动 main 函数时其实就是启动了一个 JVM 的进程，而 main 函数所在的线程就是这个进程中的一个线程，也称主线程。

何为线程?#

线程与进程相似，但线程是一个比进程更小的执行单位。一个进程在其执行的过程中可以产生多个线程。与进程不同的是同类的多个线程共享进程的堆和方法区资源，但每个线程有自己的程序计数器、虚拟机栈和本地方法栈，所以系统在产生一个线程，或是在各个线程之间作切换工作时，负担要比进程小得多，也正因为如此，线程也被称为轻量级进程。

Java 程序天生就是多线程程序，我们可以通过 JMX 来看看一个普通的 Java 程序有哪些线程，代码如下。

1
public class MultiThread {
2
 public static void main(String[] args) {
3
  // 获取 Java 线程管理 MXBean
4
 ThreadMXBean threadMXBean = ManagementFactory.getThreadMXBean();
5
  // 不需要获取同步的 monitor 和 synchronizer 信息，仅获取线程和线程堆栈信息
6
  ThreadInfo[] threadInfos = threadMXBean.dumpAllThreads(false, false);
7
  // 遍历线程信息，仅打印线程 ID 和线程名称信息
8
  for (ThreadInfo threadInfo : threadInfos) {
9
   System.out.println("[" + threadInfo.getThreadId() + "] " + threadInfo.getThreadName());
10
  }
11
 }
12
}

上述程序输出如下（输出内容可能不同，不用太纠结下面每个线程的作用，只用知道 main 线程执行 main 方法即可）：

1
[5] Attach Listener //添加事件
2
[4] Signal Dispatcher // 分发处理给 JVM 信号的线程
3
[3] Finalizer //调用对象 finalize 方法的线程
4
[2] Reference Handler //清除 reference 线程
5
[1] main //main 线程,程序入口

从上面的输出内容可以看出：一个 Java 程序的运行是 main 线程和多个其他线程同时运行。

图解进程和线程的关系#

下图是 Java 内存区域，通过下图我们从 JVM 的角度来说一下线程和进程之间的关系。

从上图可以看出：一个进程中可以有多个线程，多个线程共享进程的堆和方法区 (JDK1.8 之后的元空间)资源，但是每个线程有自己的程序计数器、虚拟机栈 和 本地方法栈。

总结： 线程是进程划分成的更小的运行单位。线程和进程最大的不同在于基本上各进程是独立的，而各线程则不一定，因为同一进程中的线程极有可能会相互影响。线程执行开销小，但不利于资源的管理和保护；而进程正相反。

下面是该知识点的扩展内容！

下面来思考这样一个问题：为什么程序计数器、虚拟机栈和本地方法栈是线程私有的呢？为什么堆和方法区是线程共享的呢？

程序计数器为什么是私有的?#

程序计数器主要有下面两个作用：

1. 字节码解释器通过改变程序计数器来依次读取指令，从而实现代码的流程控制，如：顺序执行、选择、循环、异常处理。
2. 在多线程的情况下，程序计数器用于记录当前线程执行的位置，从而当线程被切换回来的时候能够知道该线程上次运行到哪儿了。

需要注意的是，如果执行的是 native 方法，那么程序计数器记录的是 undefined 地址，只有执行的是 Java 代码时程序计数器记录的才是下一条指令的地址。

所以，程序计数器私有主要是为了线程切换后能恢复到正确的执行位置。

虚拟机栈和本地方法栈为什么是私有的?#

• 虚拟机栈： 每个 Java 方法在执行之前会创建一个栈帧用于存储局部变量表、操作数栈、常量池引用等信息。从方法调用直至执行完成的过程，就对应着一个栈帧在 Java 虚拟机栈中入栈和出栈的过程。
• 本地方法栈： 和虚拟机栈所发挥的作用非常相似，区别是：虚拟机栈为虚拟机执行 Java 方法 （也就是字节码）服务，而本地方法栈则为虚拟机使用到的 Native 方法服务。 在 HotSpot 虚拟机中和 Java 虚拟机栈合二为一。

所以，为了保证线程中的局部变量不被别的线程访问到，虚拟机栈和本地方法栈是线程私有的。

一句话简单了解堆和方法区#

堆和方法区是所有线程共享的资源，其中堆是进程中最大的一块内存，主要用于存放新创建的对象 (几乎所有对象都在这里分配内存)，方法区主要用于存放已被加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。

认识线程死锁#

线程死锁描述的是这样一种情况：多个线程同时被阻塞，它们中的一个或者全部都在等待某个资源被释放。由于线程被无限期地阻塞，因此程序不可能正常终止。

如下图所示，线程 A 持有资源 2，线程 B 持有资源 1，他们同时都想申请对方的资源，所以这两个线程就会互相等待而进入死锁状态。

产生死锁的四个必要条件：

1. 互斥条件：该资源任意一个时刻只由一个线程占用。
2. 请求与保持条件：一个线程因请求资源而阻塞时，对已获得的资源保持不放。
3. 不剥夺条件:线程已获得的资源在未使用完之前不能被其他线程强行剥夺，只有自己使用完毕后才释放资源。
4. 循环等待条件:若干线程之间形成一种头尾相接的循环等待资源关系。

如何预防和避免线程死锁?#

如何预防死锁？ 破坏死锁的产生的必要条件即可：

1. 破坏请求与保持条件：一次性申请所有的资源。
2. 破坏不剥夺条件：占用部分资源的线程进一步申请其他资源时，如果申请不到，可以主动释放它占有的资源。
3. 破坏循环等待条件：靠按序申请资源来预防。按某一顺序申请资源，释放资源则反序释放。破坏循环等待条件。

如何避免死锁？

避免死锁就是在资源分配时，借助于算法（比如银行家算法）对资源分配进行计算评估，使其进入安全状态。

安全状态 指的是系统能够按照某种线程推进顺序（P1、P2、P3……Pn）来为每个线程分配所需资源，直到满足每个线程对资源的最大需求，使每个线程都可顺利完成。称 <P1、P2、P3…Pn> 序列为安全序列。

我们对线程 2 的代码修改成下面这样就不会产生死锁了。

1
new Thread(() -> {
2
          synchronized (resource1) {
3
              System.out.println(Thread.currentThread() + "get resource1");
4
              try {
5
                  Thread.sleep(1000);
6
              } catch (InterruptedException e) {
7
                  e.printStackTrace();
8
              }
9
              System.out.println(Thread.currentThread() + "waiting get resource2");
10
              synchronized (resource2) {
11
                  System.out.println(Thread.currentThread() + "get resource2");
12
              }
13
          }
14
      }, "线程 1").start();
15

16
new Thread(() -> {
17
          synchronized (resource1) {
18
              System.out.println(Thread.currentThread() + "get resource1");
19
              try {
20
                  Thread.sleep(1000);
21
              } catch (InterruptedException e) {
22
                  e.printStackTrace();
23
              }
24
              System.out.println(Thread.currentThread() + "waiting get resource2");
25
              synchronized (resource2) {
26
                  System.out.println(Thread.currentThread() + "get resource2");
27
              }
28
          }
29
      }, "线程 2").start();

我们分析一下上面的代码为什么避免了死锁的发生?

线程 1 首先获得到 resource1 的监视器锁,这时候线程 2 就获取不到了。然后线程 1 再去获取 resource2 的监视器锁，可以获取到。然后线程 1 释放了对 resource1、resource2 的监视器锁的占用，线程 2 获取到就可以执行了。这样就破坏了破坏循环等待条件，因此避免了死锁。

如何保证变量的可见性？#

在 Java 中，volatile 关键字可以保证变量的可见性，如果我们将变量声明为 volatile ，这就指示 JVM，这个变量是共享且不稳定的，每次使用它都到主存中进行读取。

JMM(Java 内存模型)

JMM(Java 内存模型)强制在主存中进行读取

volatile 关键字其实并非是 Java 语言特有的，在 C 语言里也有，它最原始的意义就是禁用 CPU 缓存。如果我们将一个变量使用 volatile 修饰，这就指示 编译器，这个变量是共享且不稳定的，每次使用它都到主存中进行读取。

volatile 关键字能保证数据的可见性，但不能保证数据的原子性。synchronized 关键字两者都能保证。

如何禁止指令重排序？#

在 Java 中，****volatile 关键字除了可以保证变量的可见性，还有一个重要的作用就是防止 JVM 的指令重排序。 如果我们将变量声明为 volatile ，在对这个变量进行读写操作的时候，会通过插入特定的 内存屏障 的方式来禁止指令重排序。

在 Java 中，Unsafe 类提供了三个开箱即用的内存屏障相关的方法，屏蔽了操作系统底层的差异：

1
public native void loadFence();
2
public native void storeFence();
3
public native void fullFence();

理论上来说，你通过这个三个方法也可以实现和volatile禁止重排序一样的效果，只是会麻烦一些。

下面我以一个常见的面试题为例讲解一下 volatile 关键字禁止指令重排序的效果。

面试中面试官经常会说：“单例模式了解吗？来给我手写一下！给我解释一下双重检验锁方式实现单例模式的原理呗！”

双重校验锁实现对象单例（线程安全）：

1
public class Singleton {
2

3
    private volatile static Singleton uniqueInstance;
4

5
    private Singleton() {
6
    }
7

8
    public  static Singleton getUniqueInstance() {
9
       //先判断对象是否已经实例过，没有实例化过才进入加锁代码
10
        if (uniqueInstance == null) {
11
            //类对象加锁
12
            synchronized (Singleton.class) {
13
                if (uniqueInstance == null) {
14
                    uniqueInstance = new Singleton();
15
                }
16
            }
17
        }
18
        return uniqueInstance;
19
    }
20
}

uniqueInstance 采用 volatile 关键字修饰也是很有必要的， uniqueInstance = new Singleton(); 这段代码其实是分为三步执行：

1. 为 uniqueInstance 分配内存空间
2. 初始化 uniqueInstance
3. 将 uniqueInstance 指向分配的内存地址

但是由于 JVM 具有指令重排的特性，执行顺序有可能变成 1->3->2。指令重排在单线程环境下不会出现问题，但是在多线程环境下会导致一个线程获得还没有初始化的实例。例如，线程 T1 执行了 1 和 3，此时 T2 调用 getUniqueInstance() 后发现 uniqueInstance 不为空，因此返回 uniqueInstance，但此时 uniqueInstance 还未被初始化

volatile 可以保证原子性么？#

volatile 关键字能保证变量的可见性，但不能保证对变量的操作是原子性的。

我们通过下面的代码即可证明：

1
public class VolatoleAtomicityDemo {
2
    public volatile static int inc = 0;
3

4
    public void increase() {
5
        inc++;
6
    }
7

8
    public static void main(String[] args) throws InterruptedException {
9
        ExecutorService threadPool = Executors.newFixedThreadPool(5);
10
        VolatoleAtomicityDemo volatoleAtomicityDemo = new VolatoleAtomicityDemo();
11
        for (int i = 0; i < 5; i++) {
12
            threadPool.execute(() -> {
13
                for (int j = 0; j < 500; j++) {
14
                    volatoleAtomicityDemo.increase();
15
                }
16
            });
17
        }
18
        // 等待1.5秒，保证上面程序执行完成
19
        Thread.sleep(1500);
20
        System.out.println(inc);
21
        threadPool.shutdown();
22
    }
23
}

正常情况下，运行上面的代码理应输出 2500。但你真正运行了上面的代码之后，你会发现每次输出结果都小于 2500。

为什么会出现这种情况呢？不是说好了，volatile 可以保证变量的可见性嘛！

也就是说，如果 volatile 能保证 inc++ 操作的原子性的话。每个线程中对 inc 变量自增完之后，其他线程可以立即看到修改后的值。5 个线程分别进行了 500 次操作，那么最终 inc 的值应该是 5*500=2500。

很多人会误认为自增操作 inc++ 是原子性的，实际上，inc++ 其实是一个复合操作，包括三步：

1. 读取 inc 的值。
2. 对 inc 加 1。
3. 将 inc 的值写回内存。

volatile 是无法保证这三个操作是具有原子性的，有可能导致下面这种情况出现：

1. 线程 1 对 inc 进行读取操作之后，还未对其进行修改。线程 2 又读取了 inc的值并对其进行修改（+1），再将inc 的值写回内存。
2. 线程 2 操作完毕后，线程 1 对 inc的值进行修改（+1），再将inc 的值写回内存。

这也就导致两个线程分别对 inc 进行了一次自增操作后，inc 实际上只增加了 1。

其实，如果想要保证上面的代码运行正确也非常简单，利用 synchronized、Lock或者AtomicInteger都可以。

使用 synchronized 改进：

1
public synchronized void increase() {
2
    inc++;
3
}

使用 AtomicInteger 改进：

1
public AtomicInteger inc = new AtomicInteger();
2

3
public void increase() {
4
    inc.getAndIncrement();
5
}

使用 ReentrantLock 改进：

1
Lock lock = new ReentrantLock();
2
public void increase() {
3
    lock.lock();
4
    try {
5
        inc++;
6
    } finally {
7
        lock.unlock();
8
    }
9
}

什么是悲观锁？#

悲观锁总是假设最坏的情况，认为共享资源每次被访问的时候就会出现问题(比如共享数据被修改)，所以每次在获取资源操作的时候都会上锁，这样其他线程想拿到这个资源就会阻塞直到锁被上一个持有者释放。也就是说，共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程。

像 Java 中synchronized和ReentrantLock等独占锁就是悲观锁思想的实现。

1
public void performSynchronisedTask() {
2
    synchronized (this) {
3
        // 需要同步的操作
4
    }
5
}
6

7
private Lock lock = new ReentrantLock();
8
lock.lock();
9
try {
10
   // 需要同步的操作
11
} finally {
12
    lock.unlock();
13
}

高并发的场景下，激烈的锁竞争会造成线程阻塞，大量阻塞线程会导致系统的上下文切换，增加系统的性能开销。并且，悲观锁还可能会存在死锁问题，影响代码的正常运行。

什么是乐观锁？#

乐观锁总是假设最好的情况，认为共享资源每次被访问的时候不会出现问题，线程可以不停地执行，无需加锁也无需等待，只是在提交修改的时候去验证对应的资源（也就是数据）是否被其它线程修改了（具体方法可以使用版本号机制或 CAS 算法）。

在 Java 中java.util.concurrent.atomic包下面的原子变量类（比如AtomicInteger、LongAdder）就是使用了乐观锁的一种实现方式 CAS 实现的。

1
// LongAdder 在高并发场景下会比 AtomicInteger 和 AtomicLong 的性能更好
2
// 代价就是会消耗更多的内存空间（空间换时间）
3
LongAdder sum = new LongAdder();
4
sum.increment();

高并发的场景下，乐观锁相比悲观锁来说，不存在锁竞争造成线程阻塞，也不会有死锁的问题，在性能上往往会更胜一筹。但是，如果冲突频繁发生（写占比非常多的情况），会频繁失败和重试，这样同样会非常影响性能，导致 CPU 飙升。

不过，大量失败重试的问题也是可以解决的，像我们前面提到的 LongAdder以空间换时间的方式就解决了这个问题。

理论上来说：

• 悲观锁通常多用于写比较多的情况（多写场景，竞争激烈），这样可以避免频繁失败和重试影响性能，悲观锁的开销是固定的。不过，如果乐观锁解决了频繁失败和重试这个问题的话（比如LongAdder），也是可以考虑使用乐观锁的，要视实际情况而定。
• 乐观锁通常多用于写比较少的情况（多读场景，竞争较少），这样可以避免频繁加锁影响性能。不过，乐观锁主要针对的对象是单个共享变量（参考java.util.concurrent.atomic包下面的原子变量类）。

如何实现乐观锁？#

乐观锁一般会使用版本号机制或 CAS 算法实现，CAS 算法相对来说更多一些，这里需要格外注意。

版本号机制#

一般是在数据表中加上一个数据版本号 version 字段，表示数据被修改的次数。当数据被修改时，version 值会加一。当线程 A 要更新数据值时，在读取数据的同时也会读取 version 值，在提交更新时，若刚才读取到的 version 值为当前数据库中的 version 值相等时才更新，否则重试更新操作，直到更新成功。

举一个简单的例子：假设数据库中帐户信息表中有一个 version 字段，当前值为 1 ；而当前帐户余额字段（ balance ）为 $100 。

1. 操作员 A 此时将其读出（ version=1 ），并从其帐户余额中扣除 $50（$100-$50 ）。
2. 在操作员 A 操作的过程中，操作员 B 也读入此用户信息（ version=1 ），并从其帐户余额中扣除 $20 （$100-$20 ）。
3. 操作员 A 完成了修改工作，将数据版本号（ version=1 ），连同帐户扣除后余额（ balance=$50 ），提交至数据库更新，此时由于提交数据版本等于数据库记录当前版本，数据被更新，数据库记录 version 更新为 2 。
4. 操作员 B 完成了操作，也将版本号（ version=1 ）试图向数据库提交数据（ balance=$80 ），但此时比对数据库记录版本时发现，操作员 B 提交的数据版本号为 1 ，数据库记录当前版本也为 2 ，不满足 “ 提交版本必须等于当前版本才能执行更新 “ 的乐观锁策略，因此，操作员 B 的提交被驳回。

这样就避免了操作员 B 用基于 version=1 的旧数据修改的结果覆盖操作员 A 的操作结果的可能。

CAS 算法#

CAS 的全称是 Compare And Swap（比较与交换） ，用于实现乐观锁，被广泛应用于各大框架中。CAS 的思想很简单，就是用一个预期值和要更新的变量值进行比较，两值相等才会进行更新。

CAS 是一个原子操作，底层依赖于一条 CPU 的原子指令。

原子操作 即最小不可拆分的操作，也就是说操作一旦开始，就不能被打断，直到操作完成。

CAS 涉及到三个操作数：

• V：要更新的变量值(Var)
• E：预期值(Expected)
• N：拟写入的新值(New)

当且仅当 V 的值等于 E 时，CAS 通过原子方式用新值 N 来更新 V 的值。如果不等，说明已经有其它线程更新了 V，则当前线程放弃更新。

举一个简单的例子：线程 A 要修改变量 i 的值为 6，i 原值为 1（V = 1，E=1，N=6，假设不存在 ABA 问题）。

1. i 与 1 进行比较，如果相等， 则说明没被其他线程修改，可以被设置为 6 。
2. i 与 1 进行比较，如果不相等，则说明被其他线程修改，当前线程放弃更新，CAS 操作失败。

当多个线程同时使用 CAS 操作一个变量时，只有一个会胜出，并成功更新，其余均会失败，但失败的线程并不会被挂起，仅是被告知失败，并且允许再次尝试，当然也允许失败的线程放弃操作。

Java 语言并没有直接实现 CAS，CAS 相关的实现是通过 C++ 内联汇编的形式实现的（JNI 调用）。因此， CAS 的具体实现和操作系统以及 CPU 都有关系。

sun.misc包下的Unsafe类提供了compareAndSwapObject、compareAndSwapInt、compareAndSwapLong方法来实现的对Object、int、long类型的 CAS 操作

1
/**
2
  *  CAS
3
  * @param o         包含要修改field的对象
4
  * @param offset    对象中某field的偏移量
5
  * @param expected  期望值
6
  * @param update    更新值
7
  * @return          true | false
8
  */
9
public final native boolean compareAndSwapObject(Object o, long offset,  Object expected, Object update);
10

11
public final native boolean compareAndSwapInt(Object o, long offset, int expected,int update);
12

13
public final native boolean compareAndSwapLong(Object o, long offset, long expected, long update);

乐观锁存在哪些问题？#

ABA 问题是乐观锁最常见的问题。

ABA 问题#

如果一个变量 V 初次读取的时候是 A 值，并且在准备赋值的时候检查到它仍然是 A 值，那我们就能说明它的值没有被其他线程修改过了吗？很明显是不能的，因为在这段时间它的值可能被改为其他值，然后又改回 A，那 CAS 操作就会误认为它从来没有被修改过。这个问题被称为 CAS 操作的 “ABA”问题。

ABA 问题的解决思路是在变量前面追加上版本号或者时间戳。JDK 1.5 以后的 AtomicStampedReference 类就是用来解决 ABA 问题的，其中的 compareAndSet() 方法就是首先检查当前引用是否等于预期引用，并且当前标志是否等于预期标志，如果全部相等，则以原子方式将该引用和该标志的值设置为给定的更新值。

1
public boolean compareAndSet(V   expectedReference,
2
                             V   newReference,
3
                             int expectedStamp,
4
                             int newStamp) {
5
    Pair<V> current = pair;
6
    return
7
        expectedReference == current.reference &&
8
        expectedStamp == current.stamp &&
9
        ((newReference == current.reference &&
10
          newStamp == current.stamp) ||
11
         casPair(current, Pair.of(newReference, newStamp)));
12
}

循环时间长开销大#

CAS 经常会用到自旋操作来进行重试，也就是不成功就一直循环执行直到成功。如果长时间不成功，会给 CPU 带来非常大的执行开销。

如果 JVM 能支持处理器提供的 pause 指令那么效率会有一定的提升，pause 指令有两个作用：

1. 可以延迟流水线执行指令，使 CPU 不会消耗过多的执行资源，延迟的时间取决于具体实现的版本，在一些处理器上延迟时间是零。
2. 可以避免在退出循环的时候因内存顺序冲而引起 CPU 流水线被清空，从而提高 CPU 的执行效率。

只能保证一个共享变量的原子操作#

CAS 只对单个共享变量有效，当操作涉及跨多个共享变量时 CAS 无效。但是从 JDK 1.5 开始，提供了AtomicReference类来保证引用对象之间的原子性，你可以把多个变量放在一个对象里来进行 CAS 操作.所以我们可以使用锁或者利用AtomicReference类把多个共享变量合并成一个共享变量来操作。

synchronized 是什么？有什么用？#

synchronized 是 Java 中的一个关键字，翻译成中文是同步的意思，主要解决的是多个线程之间访问资源的同步性，可以保证被它修饰的方法或者代码块在任意时刻只能有一个线程执行。

在 Java 早期版本中，synchronized 属于 重量级锁，效率低下。这是因为监视器锁（monitor）是依赖于底层的操作系统的 Mutex Lock 来实现的，Java 的线程是映射到操作系统的原生线程之上的。如果要挂起或者唤醒一个线程，都需要操作系统帮忙完成，而操作系统实现线程之间的切换时需要从用户态转换到内核态，这个状态之间的转换需要相对比较长的时间，时间成本相对较高。

不过，在 Java 6 之后， synchronized 引入了大量的优化如自旋锁、适应性自旋锁、锁消除、锁粗化、偏向锁、轻量级锁等技术来减少锁操作的开销，这些优化让 synchronized 锁的效率提升了很多。因此， synchronized 还是可以在实际项目中使用的，像 JDK 源码、很多开源框架都大量使用了 synchronized 。

关于偏向锁多补充一点：由于偏向锁增加了 JVM 的复杂性，同时也并没有为所有应用都带来性能提升。因此，在 JDK15 中，偏向锁被默认关闭（仍然可以使用 -XX:+UseBiasedLocking 启用偏向锁），在 JDK18 中，偏向锁已经被彻底废弃（无法通过命令行打开）。

如何使用 synchronized？#

synchronized 关键字的使用方式主要有下面 3 种：

1. 修饰实例方法

   给当前对象实例加锁，进入同步代码前要获得 当前对象实例的锁 。

   1
   synchronized void method() {
   2
       //业务代码
   3
   }

2. 修饰静态方法

   给当前类加锁，会作用于类的所有对象实例 ，进入同步代码前要获得 当前 class 的锁。

   这是因为静态成员不属于任何一个实例对象，归整个类所有，不依赖于类的特定实例，被类的所有实例共享。

   1
   synchronized static void method() {
   2
       //业务代码
   3
   }

   静态 synchronized 方法和非静态 synchronized 方法之间的调用互斥么？不互斥！如果一个线程 A 调用一个实例对象的非静态 synchronized 方法，而线程 B 需要调用这个实例对象所属类的静态 synchronized 方法，是允许的，不会发生互斥现象，因为访问静态 synchronized 方法占用的锁是当前类的锁，而访问非静态 synchronized 方法占用的锁是当前实例对象锁。

3. 修饰代码块

   对括号里指定的对象/类加锁：

   • synchronized(object) 表示进入同步代码库前要获得 给定对象的锁。
   • synchronized(类.class) 表示进入同步代码前要获得 给定 Class 的锁

   1
   synchronized(this) {
   2
       //业务代码
   3
   }

总结：

• synchronized 关键字加到 static 静态方法和 synchronized(class) 代码块上都是是给 Class 类上锁；
• synchronized 关键字加到实例方法上是给对象实例上锁；
• 尽量不要使用 synchronized(String a) 因为 JVM 中，字符串常量池具有缓存功能。

构造方法可以用 synchronized 修饰么？#

先说结论：构造方法不能使用 synchronized 关键字修饰。

构造方法本身就属于线程安全的，不存在同步的构造方法一说。

synchronized 底层原理了解吗？#

synchronized 关键字底层原理属于 JVM 层面的东西。

• synchronized 同步语句块的情况

  1
  public class SynchronizedDemo {
  2
      public void method() {
  3
          synchronized (this) {
  4
              System.out.println("synchronized 代码块");
  5
          }
  6
      }
  7
  }

  通过 JDK 自带的 javap 命令查看 SynchronizedDemo 类的相关字节码信息：首先切换到类的对应目录执行 javac SynchronizedDemo.java 命令生成编译后的 .class 文件，然后执行javap -c -s -v -l SynchronizedDemo.class。

  

  从上面我们可以看出：synchronized 同步语句块的实现使用的是 monitorenter 和 monitorexit 指令，其中 monitorenter 指令指向同步代码块的开始位置，****monitorexit 指令则指明同步代码块的结束位置。

  上面的字节码中包含一个 monitorenter 指令以及两个 monitorexit 指令，这是为了保证锁在同步代码块代码正常执行以及出现异常的这两种情况下都能被正确释放。

  当执行 monitorenter 指令时，线程试图获取锁也就是获取 对象监视器 monitor 的持有权。

  在 Java 虚拟机(Hotspot)中，Monitor 是基于 C++实现的，由ObjectMonitor实现的。每个对象中都内置了一个 ObjectMonitor对象。

1
另外，`wait/notify`等方法也依赖于`monitor`对象，这就是为什么只有在同步的块或者方法中才能调用`wait/notify`等方法，否则会抛出`java.lang.IllegalMonitorStateException`的异常的原因。

1
在执行`monitorenter`时，会尝试获取对象的锁，如果锁的计数器为 0 则表示锁可以被获取，获取后将锁计数器设为 1 也就是加 1。
2

3

4
![20240131203520.png](https://dreaife-1306766477.cos.ap-nanjing.myqcloud.com/20240131203520.png)
5

6

7
对象锁的的拥有者线程才可以执行 `monitorexit` 指令来释放锁。在执行 `monitorexit` 指令后，将锁计数器设为 0，表明锁被释放，其他线程可以尝试获取锁。
8

9

10
[https://camo.githubusercontent.com/ff0fb002626c445b1adc69507f430bc0ffd1202c9e0decfc58749f71c8183587/68747470733a2f2f6f73732e6a61766167756964652e636e2f6769746875622f6a61766167756964652f6a6176612f636f6e63757272656e742f73796e6368726f6e697a65642d72656c656173652d6c6f636b2d626c6f636b2e706e67](https://camo.githubusercontent.com/ff0fb002626c445b1adc69507f430bc0ffd1202c9e0decfc58749f71c8183587/68747470733a2f2f6f73732e6a61766167756964652e636e2f6769746875622f6a61766167756964652f6a6176612f636f6e63757272656e742f73796e6368726f6e697a65642d72656c656173652d6c6f636b2d626c6f636b2e706e67)
11

12

13
如果获取对象锁失败，那当前线程就要阻塞等待，直到锁被另外一个线程释放为止。

• synchronized 修饰方法的的情况

  1
  public class SynchronizedDemo2 {
  2
      public synchronized void method() {
  3
          System.out.println("synchronized 方法");
  4
      }
  5
  }

  

  synchronized 修饰的方法并没有 monitorenter 指令和 monitorexit 指令，取得代之的确实是 ACC_SYNCHRONIZED 标识，该标识指明了该方法是一个同步方法。JVM 通过该 ACC_SYNCHRONIZED 访问标志来辨别一个方法是否声明为同步方法，从而执行相应的同步调用。

  如果是实例方法，JVM 会尝试获取实例对象的锁。如果是静态方法，JVM 会尝试获取当前 class 的锁。

总结#

synchronized 同步语句块的实现使用的是 monitorenter 和 monitorexit 指令，其中 monitorenter 指令指向同步代码块的开始位置，monitorexit 指令则指明同步代码块的结束位置。

synchronized 修饰的方法并没有 monitorenter 指令和 monitorexit 指令，取得代之的确实是 ACC_SYNCHRONIZED 标识，该标识指明了该方法是一个同步方法。

不过两者的本质都是对对象监视器 monitor 的获取。

JDK1.6 之后的 synchronized 底层做了哪些优化？锁升级原理了解吗？#

在 Java 6 之后， synchronized 引入了大量的优化如自旋锁、适应性自旋锁、锁消除、锁粗化、偏向锁、轻量级锁等技术来减少锁操作的开销，这些优化让 synchronized 锁的效率提升了很多（JDK18 中，偏向锁已经被彻底废弃，前面已经提到过了）。

锁主要存在四种状态，依次是：无锁状态、偏向锁状态、轻量级锁状态、重量级锁状态，他们会随着竞争的激烈而逐渐升级。注意锁可以升级不可降级，这种策略是为了提高获得锁和释放锁的效率。

synchronized 和 volatile 有什么区别？#

synchronized 关键字和 volatile 关键字是两个互补的存在，而不是对立的存在！

• volatile 关键字是线程同步的轻量级实现，所以 volatile性能肯定比synchronized关键字要好 。但是 volatile 关键字只能用于变量而 synchronized 关键字可以修饰方法以及代码块 。
• volatile 关键字能保证数据的可见性，但不能保证数据的原子性。synchronized 关键字两者都能保证。
• volatile关键字主要用于解决变量在多个线程之间的可见性，而 synchronized 关键字解决的是多个线程之间访问资源的同步性。

ReentrantLock 是什么？#

ReentrantLock 实现了 Lock 接口，是一个可重入且独占式的锁，和 synchronized 关键字类似。不过，ReentrantLock 更灵活、更强大，增加了轮询、超时、中断、公平锁和非公平锁等高级功能。

1
public class ReentrantLock implements Lock, java.io.Serializable {}

ReentrantLock 里面有一个内部类 Sync，Sync 继承 AQS（AbstractQueuedSynchronizer），添加锁和释放锁的大部分操作实际上都是在 Sync 中实现的。Sync 有公平锁 FairSync 和非公平锁 NonfairSync 两个子类。

ReentrantLock 默认使用非公平锁，也可以通过构造器来显式的指定使用公平锁。

1
// 传入一个 boolean 值，true 时为公平锁，false 时为非公平锁
2
public ReentrantLock(boolean fair) {
3
    sync = fair ? new FairSync() : new NonfairSync();
4
}

从上面的内容可以看出， ReentrantLock 的底层就是由 AQS 来实现的。

公平锁和非公平锁有什么区别？#

• 公平锁 : 锁被释放之后，先申请的线程先得到锁。性能较差一些，因为公平锁为了保证时间上的绝对顺序，上下文切换更频繁。
• 非公平锁：锁被释放之后，后申请的线程可能会先获取到锁，是随机或者按照其他优先级排序的。性能更好，但可能会导致某些线程永远无法获取到锁。

synchronized和 ReentrantLock 有什么区别？#

• 两者都是可重入锁

  可重入锁 也叫递归锁，指的是线程可以再次获取自己的内部锁。比如一个线程获得了某个对象的锁，此时这个对象锁还没有释放，当其再次想要获取这个对象的锁的时候还是可以获取的，如果是不可重入锁的话，就会造成死锁。

  JDK 提供的所有现成的 Lock 实现类，包括 synchronized 关键字锁都是可重入的。

• synchronized 依赖于 JVM 而 ReentrantLock 依赖于 API

  synchronized 是依赖于 JVM 实现的，前面我们也讲到了 虚拟机团队在 JDK1.6 为 synchronized 关键字进行了很多优化，但是这些优化都是在虚拟机层面实现的，并没有直接暴露给我们。

  ReentrantLock 是 JDK 层面实现的（也就是 API 层面，需要 lock() 和 unlock() 方法配合 try/finally 语句块来完成），所以我们可以通过查看它的源代码，来看它是如何实现的。

• ReentrantLock 比 synchronized 增加了一些高级功能

  相比synchronized，ReentrantLock增加了一些高级功能。主要来说主要有三点：

  • 等待可中断 : ReentrantLock提供了一种能够中断等待锁的线程的机制，通过 lock.lockInterruptibly() 来实现这个机制。也就是说正在等待的线程可以选择放弃等待，改为处理其他事情。
  • 可实现公平锁 : ReentrantLock可以指定是公平锁还是非公平锁。而synchronized只能是非公平锁。所谓的公平锁就是先等待的线程先获得锁。ReentrantLock默认情况是非公平的，可以通过 ReentrantLock类的ReentrantLock(boolean fair)构造方法来指定是否是公平的。
  • 可实现选择性通知（锁可以绑定多个条件）: synchronized关键字与wait()和notify()/notifyAll()方法相结合可以实现等待/通知机制。ReentrantLock类当然也可以实现，但是需要借助于Condition接口与newCondition()方法。

如果你想使用上述功能，那么选择 ReentrantLock 是一个不错的选择。

可中断锁和不可中断锁有什么区别？#

• 可中断锁：获取锁的过程中可以被中断，不需要一直等到获取锁之后 才能进行其他逻辑处理。ReentrantLock 就属于是可中断锁。
• 不可中断锁：一旦线程申请了锁，就只能等到拿到锁以后才能进行其他的逻辑处理。 synchronized 就属于是不可中断锁。

ReentrantReadWriteLock 是什么？#

ReentrantReadWriteLock 实现了 ReadWriteLock ，是一个可重入的读写锁，既可以保证多个线程同时读的效率，同时又可以保证有写入操作时的线程安全。

1
public class ReentrantReadWriteLock
2
        implements ReadWriteLock, java.io.Serializable{
3
}
4
public interface ReadWriteLock {
5
    Lock readLock();
6
    Lock writeLock();
7
}

• 一般锁进行并发控制的规则：读读互斥、读写互斥、写写互斥。
• 读写锁进行并发控制的规则：读读不互斥、读写互斥、写写互斥（只有读读不互斥）。

ReentrantReadWriteLock 其实是两把锁，一把是 WriteLock (写锁)，一把是 ReadLock（读锁） 。读锁是共享锁，写锁是独占锁。读锁可以被同时读，可以同时被多个线程持有，而写锁最多只能同时被一个线程持有。

和 ReentrantLock 一样，ReentrantReadWriteLock 底层也是基于 AQS 实现的。

ReentrantReadWriteLock 也支持公平锁和非公平锁，默认使用非公平锁，可以通过构造器来显示的指定。

1
// 传入一个 boolean 值，true 时为公平锁，false 时为非公平锁
2
public ReentrantReadWriteLock(boolean fair) {
3
    sync = fair ? new FairSync() : new NonfairSync();
4
    readerLock = new ReadLock(this);
5
    writerLock = new WriteLock(this);
6
}

ReentrantReadWriteLock 适合什么场景？#

由于 ReentrantReadWriteLock 既可以保证多个线程同时读的效率，同时又可以保证有写入操作时的线程安全。因此，在读多写少的情况下，使用 ReentrantReadWriteLock 能够明显提升系统性能。

共享锁和独占锁有什么区别？#

• 共享锁：一把锁可以被多个线程同时获得。
• 独占锁：一把锁只能被一个线程获得。

线程持有读锁还能获取写锁吗？#

• 在线程持有读锁的情况下，该线程不能取得写锁(因为获取写锁的时候，如果发现当前的读锁被占用，就马上获取失败，不管读锁是不是被当前线程持有)。
• 在线程持有写锁的情况下，该线程可以继续获取读锁（获取读锁时如果发现写锁被占用，只有写锁没有被当前线程占用的情况才会获取失败）。

读锁为什么不能升级为写锁？#

写锁可以降级为读锁，但是读锁却不能升级为写锁。这是因为读锁升级为写锁会引起线程的争夺，毕竟写锁属于是独占锁，这样的话，会影响性能。

另外，还可能会有死锁问题发生。举个例子：假设两个线程的读锁都想升级写锁，则需要对方都释放自己锁，而双方都不释放，就会产生死锁。

ThreadLocal 有什么用？#

通常情况下，我们创建的变量是可以被任何一个线程访问并修改的。如果想实现每一个线程都有自己的专属本地变量该如何解决呢？

JDK 中自带的ThreadLocal类正是为了解决这样的问题。 **ThreadLocal类主要解决的就是让每个线程绑定自己的值，可以将ThreadLocal**类形象的比喻成存放数据的盒子，盒子中可以存储每个线程的私有数据。

如果你创建了一个ThreadLocal变量，那么访问这个变量的每个线程都会有这个变量的本地副本，这也是ThreadLocal变量名的由来。他们可以使用 get() 和 set() 方法来获取默认值或将其值更改为当前线程所存的副本的值，从而避免了线程安全问题。

如何使用 ThreadLocal？#

相信看了上面的解释，大家已经搞懂 ThreadLocal 类是个什么东西了。下面简单演示一下如何在项目中实际使用 ThreadLocal 。

1
import java.text.SimpleDateFormat;
2
import java.util.Random;
3

4
public class ThreadLocalExample implements Runnable{
5

6
     // SimpleDateFormat 不是线程安全的，所以每个线程都要有自己独立的副本
7
    private static final ThreadLocal<SimpleDateFormat> formatter = ThreadLocal.withInitial(() -> new SimpleDateFormat("yyyyMMdd HHmm"));
8

9
    public static void main(String[] args) throws InterruptedException {
10
        ThreadLocalExample obj = new ThreadLocalExample();
11
        for(int i=0 ; i<10; i++){
12
            Thread t = new Thread(obj, ""+i);
13
            Thread.sleep(new Random().nextInt(1000));
14
            t.start();
15
        }
16
    }
17

18
    @Override
19
    public void run() {
20
        System.out.println("Thread Name= "+Thread.currentThread().getName()+" default Formatter = "+formatter.get().toPattern());
21
        try {
22
            Thread.sleep(new Random().nextInt(1000));
23
        } catch (InterruptedException e) {
24
            e.printStackTrace();
25
        }
26
        //formatter pattern is changed here by thread, but it won't reflect to other threads
27
        formatter.set(new SimpleDateFormat());
28

29
        System.out.println("Thread Name= "+Thread.currentThread().getName()+" formatter = "+formatter.get().toPattern());
30
    }
31

32
}

从输出中可以看出，虽然 Thread-0 已经改变了 formatter 的值，但 Thread-1 默认格式化值与初始化值相同，其他线程也一样。

上面有一段代码用到了创建 ThreadLocal 变量的那段代码用到了 Java8 的知识，它等于下面这段代码，如果你写了下面这段代码的话，IDEA 会提示你转换为 Java8 的格式(IDEA 真的不错！)。因为 ThreadLocal 类在 Java 8 中扩展，使用一个新的方法withInitial()，将 Supplier 功能接口作为参数。

1
private static final ThreadLocal<SimpleDateFormat> formatter = new ThreadLocal<SimpleDateFormat>(){
2
    @Override
3
    protected SimpleDateFormat initialValue(){
4
        return new SimpleDateFormat("yyyyMMdd HHmm");
5
    }
6
};

ThreadLocal 原理了解吗？#

从 Thread类源代码入手。

1
public class Thread implements Runnable {
2
    //......
3
    //与此线程有关的ThreadLocal值。由ThreadLocal类维护
4
    ThreadLocal.ThreadLocalMap threadLocals = null;
5

6
    //与此线程有关的InheritableThreadLocal值。由InheritableThreadLocal类维护
7
    ThreadLocal.ThreadLocalMap inheritableThreadLocals = null;
8
    //......
9
}

从上面Thread类 源代码可以看出Thread 类中有一个 threadLocals 和 一个 inheritableThreadLocals 变量，它们都是 ThreadLocalMap 类型的变量,我们可以把 ThreadLocalMap 理解为ThreadLocal 类实现的定制化的 HashMap。默认情况下这两个变量都是 null，只有当前线程调用 ThreadLocal 类的 set或get方法时才创建它们，实际上调用这两个方法的时候，我们调用的是ThreadLocalMap类对应的 get()、set()方法。

ThreadLocal类的set()方法

1
public void set(T value) {
2
    //获取当前请求的线程
3
    Thread t = Thread.currentThread();
4
    //取出 Thread 类内部的 threadLocals 变量(哈希表结构)
5
    ThreadLocalMap map = getMap(t);
6
    if (map != null)
7
        // 将需要存储的值放入到这个哈希表中
8
        map.set(this, value);
9
    else
10
        createMap(t, value);
11
}
12
ThreadLocalMap getMap(Thread t) {
13
    return t.threadLocals;
14
}

通过上面这些内容，我们足以通过猜测得出结论：最终的变量是放在了当前线程的 ThreadLocalMap 中，并不是存在 ThreadLocal 上，****ThreadLocal 可以理解为只是**ThreadLocalMap**的封装，传递了变量值。 ThreadLocal 类中可以通过Thread.currentThread()获取到当前线程对象后，直接通过getMap(Thread t)可以访问到该线程的ThreadLocalMap对象。

每个**Thread中都具备一个ThreadLocalMap，而ThreadLocalMap可以存储以ThreadLocal**为 key ，Object 对象为 value 的键值对。

1
ThreadLocalMap(ThreadLocal<?> firstKey, Object firstValue) {
2
    //......
3
}

比如我们在同一个线程中声明了两个 ThreadLocal 对象的话， Thread内部都是使用仅有的那个ThreadLocalMap 存放数据的，ThreadLocalMap的 key 就是 ThreadLocal对象，value 就是 ThreadLocal 对象调用set方法设置的值。

ThreadLocal 数据结构如下图所示：

ThreadLocalMap是ThreadLocal的静态内部类。

ThreadLocal 内存泄露问题是怎么导致的？#

ThreadLocalMap 中使用的 key 为 ThreadLocal 的弱引用，而 value 是强引用。所以，如果 ThreadLocal 没有被外部强引用的情况下，在垃圾回收的时候，key 会被清理掉，而 value 不会被清理掉。

这样一来，ThreadLocalMap 中就会出现 key 为 null 的 Entry。假如我们不做任何措施的话，value 永远无法被 GC 回收，这个时候就可能会产生内存泄露。ThreadLocalMap 实现中已经考虑了这种情况，在调用 set()、get()、remove() 方法的时候，会清理掉 key 为 null 的记录。使用完 ThreadLocal方法后最好手动调用remove()方法

1
static class Entry extends WeakReference<ThreadLocal<?>> {
2
    /** The value associated with this ThreadLocal. */
3
    Object value;
4

5
    Entry(ThreadLocal<?> k, Object v) {
6
        super(k);
7
        value = v;
8
    }
9
}

弱引用介绍：

如果一个对象只具有弱引用，那就类似于可有可无的生活用品。弱引用与软引用的区别在于：只具有弱引用的对象拥有更短暂的生命周期。在垃圾回收器线程扫描它 所管辖的内存区域的过程中，一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存。不过，由于垃圾回收器是一个优先级很低的线程， 因此不一定会很快发现那些只具有弱引用的对象。

弱引用可以和一个引用队列（ReferenceQueue）联合使用，如果弱引用所引用的对象被垃圾回收，Java 虚拟机就会把这个弱引用加入到与之关联的引用队列中。

什么是线程池?#

顾名思义，线程池就是管理一系列线程的资源池。当有任务要处理时，直接从线程池中获取线程来处理，处理完之后线程并不会立即被销毁，而是等待下一个任务。

为什么要用线程池？#

池化技术想必大家已经屡见不鲜了，线程池、数据库连接池、HTTP 连接池等等都是对这个思想的应用。池化技术的思想主要是为了减少每次获取资源的消耗，提高对资源的利用率。

线程池提供了一种限制和管理资源（包括执行一个任务）的方式。 每个线程池还维护一些基本统计信息，例如已完成任务的数量。

这里借用《Java 并发编程的艺术》提到的来说一下使用线程池的好处：

• 降低资源消耗。通过重复利用已创建的线程降低线程创建和销毁造成的消耗。
• 提高响应速度。当任务到达时，任务可以不需要等到线程创建就能立即执行。
• 提高线程的可管理性。线程是稀缺资源，如果无限制的创建，不仅会消耗系统资源，还会降低系统的稳定性，使用线程池可以进行统一的分配，调优和监控。

如何创建线程池？#

1. 通过**ThreadPoolExecutor**构造函数来创建（推荐）。

2. 通过 Executor 框架的工具类 Executors 来创建。

   我们可以创建多种类型的 ThreadPoolExecutor：

   • FixedThreadPool：该方法返回一个固定线程数量的线程池。该线程池中的线程数量始终不变。当有一个新的任务提交时，线程池中若有空闲线程，则立即执行。若没有，则新的任务会被暂存在一个任务队列中，待有线程空闲时，便处理在任务队列中的任务。
   • SingleThreadExecutor****： 该方法返回一个只有一个线程的线程池。若多余一个任务被提交到该线程池，任务会被保存在一个任务队列中，待线程空闲，按先入先出的顺序执行队列中的任务。
   • CachedThreadPool****： 该方法返回一个可根据实际情况调整线程数量的线程池。初始大小为 0。当有新任务提交时，如果当前线程池中没有线程可用，它会创建一个新的线程来处理该任务。如果在一段时间内（默认为 60 秒）没有新任务提交，核心线程会超时并被销毁，从而缩小线程池的大小。
   • ScheduledThreadPool：该方法返回一个用来在给定的延迟后运行任务或者定期执行任务的线程池。

为什么不推荐使用内置线程池？#

在《阿里巴巴 Java 开发手册》“并发处理”这一章节，明确指出线程资源必须通过线程池提供，不允许在应用中自行显式创建线程。

为什么呢？

使用线程池的好处是减少在创建和销毁线程上所消耗的时间以及系统资源开销，解决资源不足的问题。如果不使用线程池，有可能会造成系统创建大量同类线程而导致消耗完内存或者“过度切换”的问题。

另外，《阿里巴巴 Java 开发手册》中强制线程池不允许使用 Executors 去创建，而是通过 ThreadPoolExecutor 构造函数的方式，这样的处理方式让写的同学更加明确线程池的运行规则，规避资源耗尽的风险

Executors 返回线程池对象的弊端如下(后文会详细介绍到)：

• FixedThreadPool 和 SingleThreadExecutor：使用的是无界的 LinkedBlockingQueue，任务队列最大长度为 Integer.MAX_VALUE,可能堆积大量的请求，从而导致 OOM。
• CachedThreadPool：使用的是同步队列 SynchronousQueue, 允许创建的线程数量为 Integer.MAX_VALUE ，如果任务数量过多且执行速度较慢，可能会创建大量的线程，从而导致 OOM。
• ScheduledThreadPool 和 SingleThreadScheduledExecutor : 使用的无界的延迟阻塞队列DelayedWorkQueue，任务队列最大长度为 Integer.MAX_VALUE,可能堆积大量的请求，从而导致 OOM。

1
// 无界队列 LinkedBlockingQueue
2
public static ExecutorService newFixedThreadPool(int nThreads) {
3
    return new ThreadPoolExecutor(nThreads, nThreads,0L, TimeUnit.MILLISECONDS,new LinkedBlockingQueue<Runnable>());
4
}
5

6
// 无界队列 LinkedBlockingQueue
7
public static ExecutorService newSingleThreadExecutor() {
8
    return new FinalizableDelegatedExecutorService (new ThreadPoolExecutor(1, 1,0L, TimeUnit.MILLISECONDS,new LinkedBlockingQueue<Runnable>()));
9
}
10

11
// 同步队列 SynchronousQueue，没有容量，最大线程数是 Integer.MAX_VALUE
12
public static ExecutorService newCachedThreadPool() {
13
    return new ThreadPoolExecutor(0, Integer.MAX_VALUE,60L, TimeUnit.SECONDS,new SynchronousQueue<Runnable>());
14
}
15

16
// DelayedWorkQueue（延迟阻塞队列）
17
public static ScheduledExecutorService newScheduledThreadPool(int corePoolSize) {
18
    return new ScheduledThreadPoolExecutor(corePoolSize);
19
}
20
public ScheduledThreadPoolExecutor(int corePoolSize) {
21
    super(corePoolSize, Integer.MAX_VALUE, 0, NANOSECONDS,
22
          new DelayedWorkQueue());
23
}

线程池常见参数有哪些？如何解释？#

1
/**
2
     * 用给定的初始参数创建一个新的ThreadPoolExecutor。
3
     */
4
    public ThreadPoolExecutor(int corePoolSize,//线程池的核心线程数量
5
                              int maximumPoolSize,//线程池的最大线程数
6
                              long keepAliveTime,//当线程数大于核心线程数时，多余的空闲线程存活的最长时间
7
                              TimeUnit unit,//时间单位
8
                              BlockingQueue<Runnable> workQueue,//任务队列，用来储存等待执行任务的队列
9
                              ThreadFactory threadFactory,//线程工厂，用来创建线程，一般默认即可
10
                              RejectedExecutionHandler handler//拒绝策略，当提交的任务过多而不能及时处理时，我们可以定制策略来处理任务
11
                               ) {
12
        if (corePoolSize < 0 ||
13
            maximumPoolSize <= 0 ||
14
            maximumPoolSize < corePoolSize ||
15
            keepAliveTime < 0)
16
            throw new IllegalArgumentException();
17
        if (workQueue == null || threadFactory == null || handler == null)
18
            throw new NullPointerException();
19
        this.corePoolSize = corePoolSize;
20
        this.maximumPoolSize = maximumPoolSize;
21
        this.workQueue = workQueue;
22
        this.keepAliveTime = unit.toNanos(keepAliveTime);
23
        this.threadFactory = threadFactory;
24
        this.handler = handler;
25
    }

ThreadPoolExecutor 3 个最重要的参数：

• corePoolSize : 任务队列未达到队列容量时，最大可以同时运行的线程数量。
• maximumPoolSize : 任务队列中存放的任务达到队列容量的时候，当前可以同时运行的线程数量变为最大线程数。
• workQueue****: 新任务来的时候会先判断当前运行的线程数量是否达到核心线程数，如果达到的话，新任务就会被存放在队列中。

ThreadPoolExecutor其他常见参数 :

• keepAliveTime:线程池中的线程数量大于 corePoolSize 的时候，如果这时没有新的任务提交，多余的空闲线程不会立即销毁，而是会等待，直到等待的时间超过了 keepAliveTime才会被回收销毁，线程池回收线程时，会对核心线程和非核心线程一视同仁，直到线程池中线程的数量等于 corePoolSize ，回收过程才会停止。
• unit : keepAliveTime 参数的时间单位。
• threadFactory  创建新线程的时候会用到。
• handler :饱和策略。关于饱和策略下面单独介绍一下。

下面这张图可以加深你对线程池中各个参数的相互关系的理解

线程池的饱和策略有哪些？#

如果当前同时运行的线程数量达到最大线程数量并且队列也已经被放满了任务时，ThreadPoolExecutor 定义一些策略:

• ThreadPoolExecutor.AbortPolicy****： 抛出 RejectedExecutionException来拒绝新任务的处理。
• ThreadPoolExecutor.CallerRunsPolicy****： 调用执行自己的线程运行任务，也就是直接在调用execute方法的线程中运行(run)被拒绝的任务，如果执行程序已关闭，则会丢弃该任务。因此这种策略会降低对于新任务提交速度，影响程序的整体性能。如果您的应用程序可以承受此延迟并且你要求任何一个任务请求都要被执行的话，你可以选择这个策略。
• ThreadPoolExecutor.DiscardPolicy****： 不处理新任务，直接丢弃掉。
• ThreadPoolExecutor.DiscardOldestPolicy****： 此策略将丢弃最早的未处理的任务请求。

举个例子：Spring 通过 ThreadPoolTaskExecutor 或者我们直接通过 ThreadPoolExecutor 的构造函数创建线程池的时候，当我们不指定 RejectedExecutionHandler 饱和策略来配置线程池的时候，默认使用的是 AbortPolicy。在这种饱和策略下，如果队列满了，ThreadPoolExecutor 将抛出 RejectedExecutionException 异常来拒绝新来的任务 ，这代表你将丢失对这个任务的处理。如果不想丢弃任务的话，可以使用CallerRunsPolicy。CallerRunsPolicy 和其他的几个策略不同，它既不会抛弃任务，也不会抛出异常，而是将任务回退给调用者，使用调用者的线程来执行任务

1
public static class CallerRunsPolicy implements RejectedExecutionHandler {
2

3
        public CallerRunsPolicy() { }
4

5
        public void rejectedExecution(Runnable r, ThreadPoolExecutor e) {
6
            if (!e.isShutdown()) {
7
                // 直接主线程执行，而不是线程池中的线程执行
8
                r.run();
9
            }
10
        }
11
    }

线程池常用的阻塞队列有哪些？#

新任务来的时候会先判断当前运行的线程数量是否达到核心线程数，如果达到的话，新任务就会被存放在队列中。

不同的线程池会选用不同的阻塞队列，我们可以结合内置线程池来分析。

• 容量为 Integer.MAX_VALUE 的 LinkedBlockingQueue（无界队列）：FixedThreadPool 和 SingleThreadExector 。FixedThreadPool最多只能创建核心线程数的线程（核心线程数和最大线程数相等），SingleThreadExector只能创建一个线程（核心线程数和最大线程数都是 1），二者的任务队列永远不会被放满。
• SynchronousQueue（同步队列）：CachedThreadPool 。SynchronousQueue 没有容量，不存储元素，目的是保证对于提交的任务，如果有空闲线程，则使用空闲线程来处理；否则新建一个线程来处理任务。也就是说，CachedThreadPool 的最大线程数是 Integer.MAX_VALUE ，可以理解为线程数是可以无限扩展的，可能会创建大量线程，从而导致 OOM。
• DelayedWorkQueue（延迟阻塞队列）：ScheduledThreadPool 和 SingleThreadScheduledExecutor 。DelayedWorkQueue 的内部元素并不是按照放入的时间排序，而是会按照延迟的时间长短对任务进行排序，内部采用的是“堆”的数据结构，可以保证每次出队的任务都是当前队列中执行时间最靠前的。DelayedWorkQueue 添加元素满了之后会自动扩容原来容量的 1/2，即永远不会阻塞，最大扩容可达 Integer.MAX_VALUE，所以最多只能创建核心线程数的线程。

线程池处理任务的流程了解吗？#

1. 如果当前运行的线程数小于核心线程数，那么就会新建一个线程来执行任务。
2. 如果当前运行的线程数等于或大于核心线程数，但是小于最大线程数，那么就把该任务放入到任务队列里等待执行。
3. 如果向任务队列投放任务失败（任务队列已经满了），但是当前运行的线程数是小于最大线程数的，就新建一个线程来执行任务。
4. 如果当前运行的线程数已经等同于最大线程数了，新建线程将会使当前运行的线程超出最大线程数，那么当前任务会被拒绝，饱和策略会调用RejectedExecutionHandler.rejectedExecution()方法。

如何给线程池命名？#

初始化线程池的时候需要显示命名（设置线程池名称前缀），有利于定位问题。

默认情况下创建的线程名字类似 pool-1-thread-n 这样的，没有业务含义，不利于我们定位问题。

给线程池里的线程命名通常有下面两种方式：

1、利用 guava 的 ThreadFactoryBuilder

1
ThreadFactory threadFactory = new ThreadFactoryBuilder()
2
                        .setNameFormat(threadNamePrefix + "-%d")
3
                        .setDaemon(true).build();
4
ExecutorService threadPool = new ThreadPoolExecutor(corePoolSize, maximumPoolSize, keepAliveTime, TimeUnit.MINUTES, workQueue, threadFactory);

2、自己实现 ThreadFactory****。

1
import java.util.concurrent.ThreadFactory;
2
import java.util.concurrent.atomic.AtomicInteger;
3

4
/**
5
 * 线程工厂，它设置线程名称，有利于我们定位问题。
6
 */
7
public final class NamingThreadFactory implements ThreadFactory {
8

9
    private final AtomicInteger threadNum = new AtomicInteger();
10
    private final String name;
11

12
    /**
13
     * 创建一个带名字的线程池生产工厂
14
     */
15
    public NamingThreadFactory(String name) {
16
        this.name = name;
17
    }
18

19
    @Override
20
    public Thread newThread(Runnable r) {
21
        Thread t = new Thread(r);
22
        t.setName(name + " [#" + threadNum.incrementAndGet() + "]");
23
        return t;
24
    }
25
}

如何设定线程池的大小？#

很多人可能会觉得把线程池配置大一点比较好,但线程数量过多，对于多线程这个场景来说主要是增加了上下文切换成本。

• 如果我们设置的线程池数量太小的话，如果同一时间有大量任务/请求需要处理，可能会导致大量的请求/任务在任务队列中排队等待执行，甚至会出现任务队列满了之后任务/请求无法处理的情况，或者大量任务堆积在任务队列导致 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 操作完成上。

线程数更严谨的计算的方法应该是：最佳线程数 = N（CPU 核心数）∗（1+WT（线程等待时间）/ST（线程计算时间）），其中 WT（线程等待时间）=线程运行总时间 - ST（线程计算时间）。

线程等待时间所占比例越高，需要越多线程。线程计算时间所占比例越高，需要越少线程。

我们可以通过 JDK 自带的工具 VisualVM 来查看 WT/ST 比例。

CPU 密集型任务的 WT/ST 接近或者等于 0，因此， 线程数可以设置为 N（CPU 核心数）∗（1+0）= N，和我们上面说的 N（CPU 核心数）+1 差不多。

IO 密集型任务下，几乎全是线程等待时间，从理论上来说，你就可以将线程数设置为 2N。

公示也只是参考，具体还是要根据项目实际线上运行情况来动态调整。

如何动态修改线程池的参数？#

美团技术团队在《Java 线程池实现原理及其在美团业务中的实践》这篇文章中介绍到对线程池参数实现可自定义配置的思路和方法。

美团技术团队的思路是主要对线程池的核心参数实现自定义可配置。这三个核心参数是：

• corePoolSize : 核心线程数线程数定义了最小可以同时运行的线程数量。
• maximumPoolSize : 当队列中存放的任务达到队列容量的时候，当前可以同时运行的线程数量变为最大线程数。
• workQueue****: 当新任务来的时候会先判断当前运行的线程数量是否达到核心线程数，如果达到的话，新任务就会被存放在队列中。

为什么是这三个参数？

这三个参数是 ThreadPoolExecutor 最重要的参数，它们基本决定了线程池对于任务的处理策略。

格外需要注意的是corePoolSize， 程序运行期间的时候，我们调用 setCorePoolSize（）这个方法的话，线程池会首先判断当前工作线程数是否大于corePoolSize，如果大于的话就会回收工作线程。

另外，你也看到了上面并没有动态指定队列长度的方法，美团的方式是自定义了一个叫做 ResizableCapacityLinkedBlockIngQueue 的队列（主要就是把LinkedBlockingQueue的 capacity 字段的 final 关键字修饰给去掉了，让它变为可变的）。

如果我们的项目也想要实现这种效果的话，可以借助现成的开源项目：

• Hippo4j：异步线程池框架，支持线程池动态变更&监控&报警，无需修改代码轻松引入。支持多种使用模式，轻松引入，致力于提高系统运行保障能力。
• Dynamic TP：轻量级动态线程池，内置监控告警功能，集成三方中间件线程池管理，基于主流配置中心（已支持 Nacos、Apollo，Zookeeper、Consul、Etcd，可通过 SPI 自定义实现）。

如何设计一个能够根据任务的优先级来执行的线程池？#

这是一个常见的面试问题，本质其实还是在考察求职者对于线程池以及阻塞队列的掌握。

我们上面也提到了，不同的线程池会选用不同的阻塞队列作为任务队列，比如FixedThreadPool 使用的是LinkedBlockingQueue（无界队列），由于队列永远不会被放满，因此FixedThreadPool最多只能创建核心线程数的线程。

假如我们需要实现一个优先级任务线程池的话，那可以考虑使用 PriorityBlockingQueue （优先级阻塞队列）作为任务队列（ThreadPoolExecutor 的构造函数有一个 workQueue 参数可以传入任务队列）。

PriorityBlockingQueue 是一个支持优先级的无界阻塞队列，可以看作是线程安全的 PriorityQueue，两者底层都是使用小顶堆形式的二叉堆，即值最小的元素优先出队。不过，PriorityQueue 不支持阻塞操作。

要想让 PriorityBlockingQueue 实现对任务的排序，传入其中的任务必须是具备排序能力的，方式有两种：

1. 提交到线程池的任务实现 Comparable 接口，并重写 compareTo 方法来指定任务之间的优先级比较规则。
2. 创建 PriorityBlockingQueue 时传入一个 Comparator 对象来指定任务之间的排序规则(推荐)。

不过，这存在一些风险和问题，比如：

• PriorityBlockingQueue 是无界的，可能堆积大量的请求，从而导致 OOM。
• 可能会导致饥饿问题，即低优先级的任务长时间得不到执行。
• 由于需要对队列中的元素进行排序操作以及保证线程安全（并发控制采用的是可重入锁 ReentrantLock），因此会降低性能。

对于 OOM 这个问题的解决比较简单粗暴，就是继承PriorityBlockingQueue 并重写一下 offer 方法(入队)的逻辑，当插入的元素数量超过指定值就返回 false 。

饥饿问题这个可以通过优化设计来解决（比较麻烦），比如等待时间过长的任务会被移除并重新添加到队列中，但是优先级会被提升。

对于性能方面的影响，是没办法避免的，毕竟需要对任务进行排序操作。并且，对于大部分业务场景来说，这点性能影响是可以接受的。

Future 类有什么用？#

Future 类是异步思想的典型运用，主要用在一些需要执行耗时任务的场景，避免程序一直原地等待耗时任务执行完成，执行效率太低。具体来说是这样的：当我们执行某一耗时的任务时，可以将这个耗时任务交给一个子线程去异步执行，同时我们可以干点其他事情，不用傻傻等待耗时任务执行完成。等我们的事情干完后，我们再通过 Future 类获取到耗时任务的执行结果。这样一来，程序的执行效率就明显提高了。

这其实就是多线程中经典的 Future 模式，你可以将其看作是一种设计模式，核心思想是异步调用，主要用在多线程领域，并非 Java 语言独有。

在 Java 中，Future 类只是一个泛型接口，位于 java.util.concurrent 包下，其中定义了 5 个方法，主要包括下面这 4 个功能：

• 取消任务；
• 判断任务是否被取消;
• 判断任务是否已经执行完成;
• 获取任务执行结果。

1
// V 代表了Future执行的任务返回值的类型
2
public interface Future<V> {
3
    // 取消任务执行
4
    // 成功取消返回 true，否则返回 false
5
    boolean cancel(boolean mayInterruptIfRunning);
6
    // 判断任务是否被取消
7
    boolean isCancelled();
8
    // 判断任务是否已经执行完成
9
    boolean isDone();
10
    // 获取任务执行结果
11
    V get() throws InterruptedException, ExecutionException;
12
    // 指定时间内没有返回计算结果就抛出 TimeOutException 异常
13
    V get(long timeout, TimeUnit unit)
14

15
        throws InterruptedException, ExecutionException, TimeoutExceptio
16

17
}

简单理解就是：我有一个任务，提交给了 Future 来处理。任务执行期间我自己可以去做任何想做的事情。并且，在这期间我还可以取消任务以及获取任务的执行状态。一段时间之后，我就可以 Future 那里直接取出任务执行结果。

Callable 和 Future 有什么关系？#

我们可以通过 FutureTask 来理解 Callable 和 Future 之间的关系。

FutureTask 提供了 Future 接口的基本实现，常用来封装 Callable 和 Runnable，具有取消任务、查看任务是否执行完成以及获取任务执行结果的方法。ExecutorService.submit() 方法返回的其实就是 Future 的实现类 FutureTask 。

FutureTask 不光实现了 Future接口，还实现了Runnable 接口，因此可以作为任务直接被线程执行。

FutureTask 有两个构造函数，可传入 Callable 或者 Runnable 对象。实际上，传入 Runnable 对象也会在方法内部转换为Callable 对象。

1
public FutureTask(Callable<V> callable) {
2
    if (callable == null)
3
        throw new NullPointerException();
4
    this.callable = callable;
5
    this.state = NEW;
6
}
7
public FutureTask(Runnable runnable, V result) {
8
    // 通过适配器RunnableAdapter来将Runnable对象runnable转换成Callable对象
9
    this.callable = Executors.callable(runnable, result);
10
    this.state = NEW;
11
}

FutureTask相当于对Callable 进行了封装，管理着任务执行的情况，存储了 Callable 的 call 方法的任务执行结果。

CompletableFuture 类有什么用？#

Future 在实际使用过程中存在一些局限性比如不支持异步任务的编排组合、获取计算结果的 get() 方法为阻塞调用。

Java 8 才被引入CompletableFuture 类可以解决Future 的这些缺陷。CompletableFuture 除了提供了更为好用和强大的 Future 特性之外，还提供了函数式编程、异步任务编排组合（可以将多个异步任务串联起来，组成一个完整的链式调用）等能力。

下面我们来简单看看 CompletableFuture 类的定义。

1
public class CompletableFuture<T> implements Future<T>, CompletionStage<T> {
2
}

可以看到，CompletableFuture 同时实现了 Future 和 CompletionStage 接口。

CompletionStage 接口描述了一个异步计算的阶段。很多计算可以分成多个阶段或步骤，此时可以通过它将所有步骤组合起来，形成异步计算的流水线。

CompletionStage 接口中的方法比较多，CompletableFuture 的函数式能力就是这个接口赋予的。从这个接口的方法参数你就可以发现其大量使用了 Java8 引入的函数式编程。

AQS 是什么？#

AQS 的全称为 AbstractQueuedSynchronizer ，翻译过来的意思就是抽象队列同步器。这个类在 java.util.concurrent.locks 包下面。

AQS 就是一个抽象类，主要用来构建锁和同步器。

1
public abstract class AbstractQueuedSynchronizer extends AbstractOwnableSynchronizer implements java.io.Serializable {
2
}

AQS 为构建锁和同步器提供了一些通用功能的实现，因此，使用 AQS 能简单且高效地构造出应用广泛的大量的同步器，比如我们提到的 ReentrantLock，Semaphore，其他的诸如 ReentrantReadWriteLock，SynchronousQueue等等皆是基于 AQS 的。

AQS 的原理是什么？#

AQS 核心思想是，如果被请求的共享资源空闲，则将当前请求资源的线程设置为有效的工作线程，并且将共享资源设置为锁定状态。如果被请求的共享资源被占用，那么就需要一套线程阻塞等待以及被唤醒时锁分配的机制，这个机制 AQS 是用 CLH 队列锁 实现的，即将暂时获取不到锁的线程加入到队列中。

CLH(Craig,Landin,and Hagersten) 队列是一个虚拟的双向队列（虚拟的双向队列即不存在队列实例，仅存在结点之间的关联关系）。AQS 是将每条请求共享资源的线程封装成一个 CLH 锁队列的一个结点（Node）来实现锁的分配。在 CLH 同步队列中，一个节点表示一个线程，它保存着线程的引用（thread）、 当前节点在队列中的状态（waitStatus）、前驱节点（prev）、后继节点（next）。

CLH 队列结构如下图所示：

AQS(AbstractQueuedSynchronizer)的核心原理图：

AQS 使用 int 成员变量 state 表示同步状态，通过内置的 线程等待队列 来完成获取资源线程的排队工作。

state 变量由 volatile 修饰，用于展示当前临界资源的获锁情况。

1
// 共享变量，使用volatile修饰保证线程可见性
2
private volatile int state;

另外，状态信息 state 可以通过 protected 类型的getState()、setState()和compareAndSetState() 进行操作。并且，这几个方法都是 final 修饰的，在子类中无法被重写。

1
//返回同步状态的当前值
2
protected final int getState() {
3
     return state;
4
}
5
 // 设置同步状态的值
6
protected final void setState(int newState) {
7
     state = newState;
8
}
9
//原子地（CAS操作）将同步状态值设置为给定值update如果当前同步状态的值等于expect（期望值）
10
protected final boolean compareAndSetState(int expect, int update) {
11
      return unsafe.compareAndSwapInt(this, stateOffset, expect, update);
12
}

以 ReentrantLock 为例，state 初始值为 0，表示未锁定状态。A 线程 lock() 时，会调用 tryAcquire() 独占该锁并将 state+1 。此后，其他线程再 tryAcquire() 时就会失败，直到 A 线程 unlock() 到 state=0（即释放锁）为止，其它线程才有机会获取该锁。当然，释放锁之前，A 线程自己是可以重复获取此锁的（state 会累加），这就是可重入的概念。但要注意，获取多少次就要释放多少次，这样才能保证 state 是能回到零态的。

再以 CountDownLatch 以例，任务分为 N 个子线程去执行，state 也初始化为 N（注意 N 要与线程个数一致）。这 N 个子线程是并行执行的，每个子线程执行完后countDown() 一次，state 会 CAS(Compare and Swap) 减 1。等到所有子线程都执行完后(即 state=0 )，会 unpark() 主调用线程，然后主调用线程就会从 await() 函数返回，继续后余动作。

Semaphore 有什么用？#

synchronized 和 ReentrantLock 都是一次只允许一个线程访问某个资源，而Semaphore(信号量)可以用来控制同时访问特定资源的线程数量。

Semaphore 的使用简单，我们这里假设有 N(N>5) 个线程来获取 Semaphore 中的共享资源，下面的代码表示同一时刻 N 个线程中只有 5 个线程能获取到共享资源，其他线程都会阻塞，只有获取到共享资源的线程才能执行。等到有线程释放了共享资源，其他阻塞的线程才能获取到。

1
// 初始共享资源数量
2
final Semaphore semaphore = new Semaphore(5);
3
// 获取1个许可
4
semaphore.acquire();
5
// 释放1个许可
6
semaphore.release();

当初始的资源个数为 1 的时候，Semaphore 退化为排他锁。

Semaphore 有两种模式：。

• 公平模式： 调用 acquire() 方法的顺序就是获取许可证的顺序，遵循 FIFO；
• 非公平模式： 抢占式的。

Semaphore 对应的两个构造方法如下：

1
public Semaphore(int permits) {
2
    sync = new NonfairSync(permits);
3
}
4

5
public Semaphore(int permits, boolean fair) {
6
    sync = fair ? new FairSync(permits) : new NonfairSync(permits);
7
}

这两个构造方法，都必须提供许可的数量，第二个构造方法可以指定是公平模式还是非公平模式，默认非公平模式。

Semaphore 通常用于那些资源有明确访问数量限制的场景比如限流（仅限于单机模式，实际项目中推荐使用 Redis +Lua 来做限流）。

Semaphore 的原理是什么？#

Semaphore 是共享锁的一种实现，它默认构造 AQS 的 state 值为 permits，你可以将 permits 的值理解为许可证的数量，只有拿到许可证的线程才能执行。

调用semaphore.acquire() ，线程尝试获取许可证，如果 state >= 0 的话，则表示可以获取成功。如果获取成功的话，使用 CAS 操作去修改 state 的值 state=state-1。如果 state<0 的话，则表示许可证数量不足。此时会创建一个 Node 节点加入阻塞队列，挂起当前线程。

1
/**
2
 *  获取1个许可证
3
 */
4
public void acquire() throws InterruptedException {
5
    sync.acquireSharedInterruptibly(1);
6
}
7
/**
8
 * 共享模式下获取许可证，获取成功则返回，失败则加入阻塞队列，挂起线程
9
 */
10
public final void acquireSharedInterruptibly(int arg)
11
    throws InterruptedException {
12
    if (Thread.interrupted())
13
      throw new InterruptedException();
14
        // 尝试获取许可证，arg为获取许可证个数，当可用许可证数减当前获取的许可证数结果小于0,则创建一个节点加入阻塞队列，挂起当前线程。
15
    if (tryAcquireShared(arg) < 0)
16
      doAcquireSharedInterruptibly(arg);
17
}

调用semaphore.release(); ，线程尝试释放许可证，并使用 CAS 操作去修改 state 的值 state=state+1。释放许可证成功之后，同时会唤醒同步队列中的一个线程。被唤醒的线程会重新尝试去修改 state 的值 state=state-1 ，如果 state>=0 则获取令牌成功，否则重新进入阻塞队列，挂起线程。

1
// 释放一个许可证
2
public void release() {
3
    sync.releaseShared(1);
4
}
5

6
// 释放共享锁，同时会唤醒同步队列中的一个线程。
7
public final boolean releaseShared(int arg) {
8
    //释放共享锁
9
    if (tryReleaseShared(arg)) {
10
      //唤醒同步队列中的一个线程
11
      doReleaseShared();
12
      return true;
13
    }
14
    return false;
15
}

CountDownLatch 有什么用？#

CountDownLatch 允许 count 个线程阻塞在一个地方，直至所有线程的任务都执行完毕。

CountDownLatch 是一次性的，计数器的值只能在构造方法中初始化一次，之后没有任何机制再次对其设置值，当 CountDownLatch 使用完毕后，它不能再次被使用。

CountDownLatch 的原理是什么？#

CountDownLatch 是共享锁的一种实现,它默认构造 AQS 的 state 值为 count。当线程使用 countDown() 方法时,其实使用了tryReleaseShared方法以 CAS 的操作来减少 state,直至 state 为 0 。当调用 await() 方法的时候，如果 state 不为 0，那就证明任务还没有执行完毕，await() 方法就会一直阻塞，也就是说 await() 方法之后的语句不会被执行。直到count 个线程调用了countDown()使 state 值被减为 0，或者调用await()的线程被中断，该线程才会从阻塞中被唤醒，await() 方法之后的语句得到执行。

用过 CountDownLatch 么？什么场景下用的？#

CountDownLatch 的作用就是 允许 count 个线程阻塞在一个地方，直至所有线程的任务都执行完毕。比如，有一个使用多线程读取多个文件处理的场景，用到了 CountDownLatch 。

要读取处理 6 个文件，这 6 个任务都是没有执行顺序依赖的任务，但是需要返回给用户的时候将这几个文件的处理的结果进行统计整理。

为此我们定义了一个线程池和 count 为 6 的CountDownLatch对象 。使用线程池处理读取任务，每一个线程处理完之后就将 count-1，调用CountDownLatch对象的 await()方法，直到所有文件读取完之后，才会接着执行后面的逻辑。

伪代码是下面这样的：

1
public class CountDownLatchExample1 {
2
    // 处理文件的数量
3
    private static final int threadCount = 6;
4

5
    public static void main(String[] args) throws InterruptedException {
6
        // 创建一个具有固定线程数量的线程池对象（推荐使用构造方法创建）
7
        ExecutorService threadPool = Executors.newFixedThreadPool(10);
8
        final CountDownLatch countDownLatch = new CountDownLatch(threadCount);
9
        for (int i = 0; i < threadCount; i++) {
10
            final int threadnum = i;
11
            threadPool.execute(() -> {
12
                try {
13
                    //处理文件的业务操作
14
                    //......
15
                } catch (InterruptedException e) {
16
                    e.printStackTrace();
17
                } finally {
18
                    //表示一个文件已经被完成
19
                    countDownLatch.countDown();
20
                }
21

22
            });
23
        }
24
        countDownLatch.await();
25
        threadPool.shutdown();
26
        System.out.println("finish");
27
    }
28
}

有没有可以改进的地方呢？

可以使用 CompletableFuture 类来改进！Java8 的 CompletableFuture 提供了很多对多线程友好的方法，使用它可以很方便地为我们编写多线程程序，什么异步、串行、并行或者等待所有线程执行完任务什么的都非常方便。

1
CompletableFuture<Void> task1 =
2
    CompletableFuture.supplyAsync(()->{
3
        //自定义业务操作
4
    });
5
......
6
CompletableFuture<Void> task6 =
7
    CompletableFuture.supplyAsync(()->{
8
    //自定义业务操作
9
    });
10
......
11
CompletableFuture<Void> headerFuture=CompletableFuture.allOf(task1,.....,task6);
12

13
try {
14
    headerFuture.join();
15
} catch (Exception ex) {
16
    //......
17
}
18
System.out.println("all done. ");

上面的代码还可以继续优化，当任务过多的时候，把每一个 task 都列出来不太现实，可以考虑通过循环来添加任务。

1
//文件夹位置
2
List<String> filePaths = Arrays.asList(...)
3
// 异步处理所有文件
4
List<CompletableFuture<String>> fileFutures = filePaths.stream()
5
    .map(filePath -> doSomeThing(filePath))
6
    .collect(Collectors.toList());
7
// 将他们合并起来
8
CompletableFuture<Void> allFutures = CompletableFuture.allOf(
9
    fileFutures.toArray(new CompletableFuture[fileFutures.size()])
10
);

CyclicBarrier 有什么用？#

CyclicBarrier 和 CountDownLatch 非常类似，它也可以实现线程间的技术等待，但是它的功能比 CountDownLatch 更加复杂和强大。主要应用场景和 CountDownLatch 类似。

CountDownLatch 的实现是基于 AQS 的，而 CycliBarrier 是基于 ReentrantLock(ReentrantLock 也属于 AQS 同步器)和 Condition 的。

CyclicBarrier 的字面意思是可循环使用（Cyclic）的屏障（Barrier）。它要做的事情是：让一组线程到达一个屏障（也可以叫同步点）时被阻塞，直到最后一个线程到达屏障时，屏障才会开门，所有被屏障拦截的线程才会继续干活。

CyclicBarrier 的原理是什么？#

CyclicBarrier 内部通过一个 count 变量作为计数器，count 的初始值为 parties 属性的初始化值，每当一个线程到了栅栏这里了，那么就将计数器减 1。如果 count 值为 0 了，表示这是这一代最后一个线程到达栅栏，就尝试执行我们构造方法中输入的任务。

1. CyclicBarrier 默认的构造方法是 CyclicBarrier(int parties)，其参数表示屏障拦截的线程数量，每个线程调用 await() 方法告诉 CyclicBarrier 我已经到达了屏障，然后当前线程被阻塞。

   其中，parties 就代表了有拦截的线程的数量，当拦截的线程数量达到这个值的时候就打开栅栏，让所有线程通过。

2. 当调用 CyclicBarrier 对象调用 await() 方法时，实际上调用的是 dowait(false, 0L)方法。 await() 方法就像树立起一个栅栏的行为一样，将线程挡住了，当拦住的线程数量达到 parties 的值时，栅栏才会打开，线程才得以通过执行。

What is a process?#

A process is an instance of program execution; it is the basic unit for running programs in the system, so a process is dynamic. When the system runs a program, that is a process from creation, running, to demise.

In Java, when we start the main function, we actually start a JVM process, and the thread containing the main function is a thread within this process, also called the main thread.

What is a thread?#

Threads are similar to processes, but a thread is a smaller execution unit than a process. A process can spawn multiple threads during its execution. Unlike processes, multiple threads of the same kind share the process’s heap and method area resources, but each thread has its own program counter, JVM stack, and native method stack. Therefore, the burden of creating a thread or switching between threads is much lighter than for processes, which is why threads are also called lightweight processes.

Java programs are inherently multi-threaded, and we can use JMX to see what threads exist in a normal Java program. The code is as follows.

1
public class MultiThread {
2
 public static void main(String[] args) {
3
  // Get the Java thread management MXBean
4
 ThreadMXBean threadMXBean = ManagementFactory.getThreadMXBean();
5
  // Do not need to obtain synchronized monitor and synchronizer information, only print thread and thread stack information
6
  ThreadInfo[] threadInfos = threadMXBean.dumpAllThreads(false, false);
7
  // Iterate over thread information, only print thread ID and thread name
8
  for (ThreadInfo threadInfo : threadInfos) {
9
   System.out.println("[" + threadInfo.getThreadId() + "] " + threadInfo.getThreadName());
10
  }
11
 }
12
}

The above program output is as follows (the output contents may differ; don’t worry too much about what each thread does below—just know that the main thread runs the main method):

1
[5] Attach Listener // Add event
2
[4] Signal Dispatcher // Thread that dispatches JVM signals
3
[3] Finalizer // Thread that calls object finalize methods
4
[2] Reference Handler // Thread that clears references
5
[1] main // main thread, program entry

From the above output you can see: a Java program runs with the main thread and multiple other threads concurrently.

Diagram of the relationship between processes and threads#

The following image shows the Java memory areas; from the JVM perspective, here is the relationship between threads and processes.

From the figure above you can see: a process can have multiple threads; multiple threads share the process’s heap and method area (metaspace after JDK 1.8), but each thread has its own program counter, virtual machine stack, and native method stack.

Summary: Threads are smaller running units divided from a process. The biggest difference between threads and processes is that processes are largely independent, while threads in the same process can affect each other. Threads have low execution overhead but are harder to manage and protect resources; processes are the opposite.

Here is some additional extended content about this knowledge point!

Think about this question: why is the program counter, the VM stack, and the native method stack thread-private? Why are the heap and the method area shared among threads?

Why is the program counter private?#

The program counter has two main purposes:

1. The bytecode interpreter uses the program counter to read instructions in sequence, enabling code flow control such as sequential execution, branching, looping, and exception handling.
2. In a multi-threaded scenario, the program counter records the current thread’s execution position, so when the thread is switched back in, it knows where it left off.

Note that if a native method is being executed, the program counter holds an undefined address; only when executing Java code does it hold the address of the next instruction.

Thus, making the program counter private primarily ensures that after a thread switch, execution resumes at the correct position.

Why are the VM stack and the native method stack private?#

• VM stack: Each Java method, before execution, creates a stack frame to store local variables, operand stacks, constant pool references, etc. As the method is invoked and returns, stack frames are pushed onto and popped off the Java VM stack.
• Native method stack: Similar in function to the VM stack, but the VM stack serves Java methods (bytecode), whereas the native method stack serves Native methods used by the VM. In HotSpot, the native method stack is merged with the Java VM stack.

Therefore, to guarantee that local variables in a thread are not accessible by other threads, the VM stack and native method stack are thread-private.

A quick one-sentence explanation of the heap and the method area#

The heap and the method area are shared resources among all threads. The heap is the largest memory region in the process, mainly used for storing newly created objects (almost all objects are allocated here). The method area is mainly used to store loaded class information, constants, static variables, and code generated by the just-in-time compiler, among other data.

Understanding thread deadlock#

Thread deadlock describes a situation where several threads are blocked, one or more of which are waiting for resources to be released. Since threads are blocked indefinitely, the program cannot terminate normally.

As shown below, Thread A holds resource 2 and Thread B holds resource 1; they both attempt to acquire each other’s resource, so they wait for one another and enter a deadlock state.

Four necessary conditions for deadlock:

1. Mutual exclusion: A resource is held by only one thread at any moment.
2. Hold and wait: A thread is blocked while requesting a resource and does not release resources it already holds.
3. No preemption: Resources held by a thread are not forcibly taken away until the thread releases them.
4. Circular wait: A set of threads forms a cycle in which each thread holds a resource the next thread needs.

How to prevent and avoid thread deadlocks?#

How to prevent deadlock? Break the necessary conditions for deadlock:

1. Break the hold-and-wait condition: Acquire all required resources at once.
2. Break the no-preemption condition: If a thread holds some resources and cannot obtain more, it can release its current resources.
3. Break the circular-wait condition: Acquire resources in a fixed order; release in the reverse order. Break the circular waiting condition.

How to avoid deadlocks?

Avoiding deadlock means using an algorithm (e.g., Banker’s algorithm) to compute and evaluate resource distribution so that the system enters a safe state.

A safe state means the system can allocate resources to each thread in some sequence (P1, P2, P3, … Pn) so that every thread can complete. The sequence <P1, P2, P3, … Pn> is called a safe sequence.

We can modify the code for Thread 2 as follows to avoid deadlock.

1
new Thread(() -> {
2
          synchronized (resource1) {
3
              System.out.println(Thread.currentThread() + "get resource1");
4
              try {
5
                  Thread.sleep(1000);
6
              } catch (InterruptedException e) {
7
                  e.printStackTrace();
8
              }
9
              System.out.println(Thread.currentThread() + "waiting get resource2");
10
              synchronized (resource2) {
11
                  System.out.println(Thread.currentThread() + "get resource2");
12
              }
13
          }
14
      }, "Thread 1").start();
15

16
new Thread(() -> {
17
          synchronized (resource1) {
18
              System.out.println(Thread.currentThread() + "get resource1");
19
              try {
20
                  Thread.sleep(1000);
21
              } catch (InterruptedException e) {
22
                  e.printStackTrace();
23
              }
24
              System.out.println(Thread.currentThread() + "waiting get resource2");
25
              synchronized (resource2) {
26
                  System.out.println(Thread.currentThread() + "get resource2");
27
              }
28
          }
29
      }, "Thread 2").start();

We can analyze why the above code avoids deadlock:

Thread 1 first obtains the monitor lock on resource1; Thread 2 cannot obtain it. Then Thread 1 proceeds to obtain the monitor lock on resource2. After completing, Thread 1 releases the locks on resource1 and resource2, allowing Thread 2 to proceed. This breaks the circular wait condition and thereby avoids deadlock.

How to guarantee visibility of variables?#

In Java, the volatile keyword guarantees visibility. If a variable is declared volatile, it indicates to the JVM that this variable is shared and may change; every use of it reads from the main memory.

JMM (Java Memory Model)

JMM (Java Memory Model) forces reads from main memory

The volatile keyword is not unique to Java; in C it exists as well. Its original meaning is to disable CPU caching. If a variable is marked volatile, it tells the compiler that the variable is shared and may change, so every use reads from main memory.

Volatile guarantees visibility but does not guarantee atomicity. The synchronized keyword guarantees both.

How to prevent instruction reordering?#

In Java, the volatile keyword not only guarantees visibility but also prevents the JVM from reordering instructions. If a variable is declared volatile, reads and writes to this variable insert specific memory barriers to prevent instruction reordering.

In Java, the Unsafe class provides three out-of-the-box memory barrier methods, abstracting OS-level differences:

1
public native void loadFence();
2
public native void storeFence();
3
public native void fullFence();

Theoretically, you could achieve the same effect as volatile’s reordering prevention with these three methods, but it’s more cumbersome.

Now I’ll use a common interview question to illustrate how volatile prevents instruction reordering.

Interviewers often say: “Do you know the singleton pattern? Please hand-write it for me! Explain the principle of the double-checked locking approach to implement a singleton.”

Double-checked locking to implement a thread-safe singleton:

1
public class Singleton {
2

3
    private volatile static Singleton uniqueInstance;
4

5
    private Singleton() {
6
    }
7

8
    public  static Singleton getUniqueInstance() {
9
       // First check if the object is already instantiated; if not, enter synchronized code
10
        if (uniqueInstance == null) {
11
            // Lock the class object
12
            synchronized (Singleton.class) {
13
                if (uniqueInstance == null) {
14
                    uniqueInstance = new Singleton();
15
                }
16
            }
17
        }
18
        return uniqueInstance;
19
    }
20
}

Using the volatile keyword for uniqueInstance is very important. The statement uniqueInstance = new Singleton(); is actually executed in three steps:

1. Allocate memory for uniqueInstance
2. Initialize uniqueInstance
3. Set the uniqueInstance reference to the allocated memory address

But due to the JVM’s instruction reordering, the execution order may become 1-3-2. In a single-threaded environment this is not a problem, but in a multi-threaded context it can cause a thread to obtain an instance that has not yet been initialized. For example, Thread T1 executes 1 and 3; then Thread T2 calls getUniqueInstance() and finds uniqueInstance is not null, returns it, but it hasn’t been initialized yet.

Can volatile guarantee atomicity?#

Volatile guarantees visibility but cannot guarantee atomicity of operations on the variable.

We can prove it with the following example:

1
public class VolatoleAtomicityDemo {
2
    public volatile static int inc = 0;
3

4
    public void increase() {
5
        inc++;
6
    }
7

8
    public static void main(String[] args) throws InterruptedException {
9
        ExecutorService threadPool = Executors.newFixedThreadPool(5);
10
        VolatoleAtomicityDemo volatoleAtomicityDemo = new VolatoleAtomicityDemo();
11
        for (int i = 0; i < 5; i++) {
12
            threadPool.execute(() -> {
13
                for (int j = 0; j < 500; j++) {
14
                    volatoleAtomicityDemo.increase();
15
                }
16
            });
17
        }
18
        // Wait 1.5 seconds to ensure above tasks finish
19
        Thread.sleep(1500);
20
        System.out.println(inc);
21
        threadPool.shutdown();
22
    }
23
}

Normally, this should print 2500. But in practice, you’ll find the output is always less than 2500.

Why does this happen? Didn’t volatile guarantee visibility?

In other words, if volatile could guarantee atomicity of inc++, then after each thread increments inc, other threads could see the updated value immediately. If five threads each perform 500 increments, inc should be 5 * 500 = 2500.

Many people mistakenly think the increment operation inc++ is atomic. In fact, inc++ is a composite operation with three steps:

1. Read the value of inc
2. Add 1 to it
3. Write the value back to memory

Volatile cannot guarantee that these three steps are atomic; this can lead to the following situation:

1. Thread 1 reads inc and is not yet modifying it. Thread 2 reads inc, increments it (+1), and writes back.
2. Thread 1 then updates inc (+1) and writes back.

This results in both threads performing one increment, but inc only increases by 1 overall.

In fact, if you want to ensure correctness of the above code, you can easily do so with synchronized, Lock, or AtomicInteger.

Using synchronized:

1
public synchronized void increase() {
2
    inc++;
3
}

Using AtomicInteger:

1
public AtomicInteger inc = new AtomicInteger();
2

3
public void increase() {
4
    inc.getAndIncrement();
5
}

Using ReentrantLock:

1
Lock lock = new ReentrantLock();
2
public void increase() {
3
    lock.lock();
4
    try {
5
        inc++;
6
    } finally {
7
        lock.unlock();
8
    }
9
}