Java多线程与并发笔记

时间 2019-11-11

标签 java 多线程并发笔记栏目 Java 繁體版

原文原文链接

synchronized

synchronized主要是用于解决线程安全问题的，而线程安全问题的主要诱因有以下两点：java

存在共享数据（也称临界资源）
存在多条线程共同操做这些共享数据

解决线程安全问题的根本方法：算法

同一时刻有且只有一个线程在操做共享数据，其余线程必须等到该线程处理完数据后再对共享数据进行操做

因此互斥锁是解决问题的办法之一，互斥锁的特性以下：数组

互斥性：即在同一时间只容许一个线程持有某个对象锁，经过这种特性来实现多线程的协调机制，这样在同一时间只有一个线程对须要同步的代码块（复合操做）进行访问。互斥性也称为操做的原子性
可见性：必须确保在锁被释放以前，对共享变量所作的修改，对于随后得到该锁的另外一个线程是可见的（即在得到锁时应得到最新共享变量的值），不然另外一个线程多是在本地缓存的某个副本上继续操做，从而引发数据不一致问题缓存

而synchronized就能够实现互斥锁的特性，不过须要注意的是synchronized锁的不是代码，而是对象。安全

根据获取的锁能够分为两类：数据结构

对象锁：获取对象锁有两种用法
1. 同步代码块（synchronized(this)，synchronized(类实例对象)），锁是小括号()中的实例对象
2. 同步非静态方法（synchronized method），锁是当前的实例对象，即this
类锁：获取类锁也有两种用法
1. 同步代码块（synchronized(类.class)），锁是小括号()中的类对象（Class对象）
2. 同步静态方法（synchronized static method），锁是当前对象的类对象（Class对象）

对象锁和类锁的总结：多线程

有线程访问对象的同步块代码时，另外的线程能够访问该对象的非同步代码块
若锁住的是同一个对象，一个线程在访问对象的同步代码块时，另外一个访问对象的同步代码块的线程会被阻塞
若锁住的是同一个对象，一个线程在访问对象的同步方法时，另外一个访问对象同步方法的线程会被阻塞
若锁住的是同一个对象，一个线程在访问对象的同步块时，另外一个访问对象同步方法的线程会被阻塞，反之亦然
同一个类的不一样对象的对象锁互不干扰
类锁因为也是一把特殊的对象锁，所以表现与上述1，2，3，4一致，而因为一个类只有一把对象锁，因此同一个类的不一样对象使用类锁将会是同步的
类锁和对象锁互补干扰，由于类对象和实例对象不是同一个对象

synchronized底层实现原理

实现synchronized须要依赖两个基础概念：并发

Java对象头
Monitor

Java对象在内存中的布局主要分为三块区域：app

对象头
实例数据
对齐填充

synchronized使用的锁对象是存储在Java对象头里的，对象头结构以下：
框架

因为对象头信息是与对象自身定义的数据没有关系的额外存储成本，考虑到JVM的空间效率，Mark Word被设计为非固定的数据结构以便存储更多有效的数据，它会根据对象自身的状态赋予本身的存储空间：

简单介绍了对象头，接着咱们来了解一下Monitor，每一个Java对象天生自带了一把看不见的锁，它叫作内部锁或Monitor锁。Monitor的主要实现代码在ObjectMonitor.hpp中：

Monitor锁的竞争、获取与释放：

而后咱们从字节码层面上看一下synchronized，将以下代码经过javac编译成class文件：

package com.example.demo.thread;

/**
 * @author 01
 * @date 2019-07-20
 **/
public class SyncBlockAndMethod {

    public void syncsTask() {
        synchronized (this) {
            System.out.println("Hello syncsTask");
        }
    }

    public synchronized void syncTask() {
        System.out.println("Hello syncTask");
    }
}

而后经过 javap -verbose 将class文件反编译成可阅读的字节码内容，以下：

Classfile /E:/Java_IDEA/demo/src/main/java/com/example/demo/thread/SyncBlockAndMethod.class
  Last modified 2019年7月20日; size 637 bytes
  MD5 checksum 7600723349daa088a5353acd84c80fa5
  Compiled from "SyncBlockAndMethod.java"
public class com.example.demo.thread.SyncBlockAndMethod
  minor version: 0
  major version: 55
  flags: (0x0021) ACC_PUBLIC, ACC_SUPER
  this_class: #6                          // com/example/demo/thread/SyncBlockAndMethod
  super_class: #7                         // java/lang/Object
  interfaces: 0, fields: 0, methods: 3, attributes: 1
Constant pool:
   #1 = Methodref          #7.#18         // java/lang/Object."<init>":()V
   #2 = Fieldref           #19.#20        // java/lang/System.out:Ljava/io/PrintStream;
   #3 = String             #21            // Hello syncsTask
   #4 = Methodref          #22.#23        // java/io/PrintStream.println:(Ljava/lang/String;)V
   #5 = String             #24            // Hello syncTask
   #6 = Class              #25            // com/example/demo/thread/SyncBlockAndMethod
   #7 = Class              #26            // java/lang/Object
   #8 = Utf8               <init>
   #9 = Utf8               ()V
  #10 = Utf8               Code
  #11 = Utf8               LineNumberTable
  #12 = Utf8               syncsTask
  #13 = Utf8               StackMapTable
  #14 = Class              #27            // java/lang/Throwable
  #15 = Utf8               syncTask
  #16 = Utf8               SourceFile
  #17 = Utf8               SyncBlockAndMethod.java
  #18 = NameAndType        #8:#9          // "<init>":()V
  #19 = Class              #28            // java/lang/System
  #20 = NameAndType        #29:#30        // out:Ljava/io/PrintStream;
  #21 = Utf8               Hello syncsTask
  #22 = Class              #31            // java/io/PrintStream
  #23 = NameAndType        #32:#33        // println:(Ljava/lang/String;)V
  #24 = Utf8               Hello syncTask
  #25 = Utf8               com/example/demo/thread/SyncBlockAndMethod
  #26 = Utf8               java/lang/Object
  #27 = Utf8               java/lang/Throwable
  #28 = Utf8               java/lang/System
  #29 = Utf8               out
  #30 = Utf8               Ljava/io/PrintStream;
  #31 = Utf8               java/io/PrintStream
  #32 = Utf8               println
  #33 = Utf8               (Ljava/lang/String;)V
{
  public com.example.demo.thread.SyncBlockAndMethod();
    descriptor: ()V
    flags: (0x0001) ACC_PUBLIC
    Code:
      stack=1, locals=1, args_size=1
         0: aload_0
         1: invokespecial #1                  // Method java/lang/Object."<init>":()V
         4: return
      LineNumberTable:
        line 7: 0

  public void syncsTask();
    descriptor: ()V
    flags: (0x0001) ACC_PUBLIC
    Code:
      stack=2, locals=3, args_size=1
         0: aload_0
         1: dup
         2: astore_1
         3: monitorenter                      // 指向同步代码块的开始位置
         4: getstatic     #2                  // Field java/lang/System.out:Ljava/io/PrintStream;
         7: ldc           #3                  // String Hello syncsTask
         9: invokevirtual #4                  // Method java/io/PrintStream.println:(Ljava/lang/String;)V
        12: aload_1
        13: monitorexit                       // 指向同步代码块的结束位置，monitorenter和monitorexit之间就是同步代码块
        14: goto          22
        17: astore_2
        18: aload_1
        19: monitorexit                       // 若代码发生异常时就会执行这句指令释放锁
        20: aload_2
        21: athrow
        22: return
      Exception table:
         from    to  target type
             4    14    17   any
            17    20    17   any
      LineNumberTable:
        line 10: 0
        line 11: 4
        line 12: 12
        line 13: 22
      StackMapTable: number_of_entries = 2
        frame_type = 255 /* full_frame */
          offset_delta = 17
          locals = [ class com/example/demo/thread/SyncBlockAndMethod, class java/lang/Object ]
          stack = [ class java/lang/Throwable ]
        frame_type = 250 /* chop */
          offset_delta = 4

  public synchronized void syncTask();
    descriptor: ()V
    flags: (0x0021) ACC_PUBLIC, ACC_SYNCHRONIZED  // 用于标识是一个同步方法，不须要像同步块那样须要经过显式的字节码指令去标识哪里须要获取锁，哪里须要释放锁。同步方法不管是正常执行仍是发生异常都会释放锁
    Code:
      stack=2, locals=1, args_size=1
         0: getstatic     #2                  // Field java/lang/System.out:Ljava/io/PrintStream;
         3: ldc           #5                  // String Hello syncTask
         5: invokevirtual #4                  // Method java/io/PrintStream.println:(Ljava/lang/String;)V
         8: return
      LineNumberTable:
        line 16: 0
        line 17: 8
}
SourceFile: "SyncBlockAndMethod.java"

什么是重入：

从互斥锁的设计上来讲，当一个线程试图操做一个由其余线程持有的对象锁的临界资源时，将会处于阻塞状态，但当一个线程再次请求本身持有对象锁的临界资源时，这种状况属于重入

为何会对synchronized嗤之以鼻：

在早期版本中，synchronized属于重量级锁效率低下，由于依赖于Mutex Lock实现，由于线程之间的切换须要从用户态转换到核心态，开销较大。不过在Java6之后引入了许多锁优化机制，synchronized性能已经获得了很大的提高

锁优化之自旋锁：

许多状况下，共享数据的锁定状态持续时间较短，切换线程不值得。因而自旋锁应运而生，所谓自旋就是经过让线程执行忙循环等待锁的释放，从而不让出CPU时间片，例如while某个标识变量

缺点：若锁被其余线程长时间占用，将会带来许多性能上的开销，因此通常超过指定的自旋次数就会将线程挂起处于阻塞状态

锁优化之自适应自旋锁：

自适应自旋锁与普通自旋锁不一样的就是能够自适应自旋次数，即自旋次数再也不固定。而是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定

锁优化之锁消除，锁消除是JVM另外一种锁优化，这种优化更完全：

在JIT编译时，对运行上下文进行扫描，去除不可能存在资源竞争的锁。这种方式能够消除没必要要的锁，能够减小毫无心义的请求锁时间

关于锁消除，咱们能够看一个例子，代码以下：

public class StringBufferWithoutSync {

    public void add(String str1, String str2) {
        //StringBuffer是线程安全,因为sb只会在append方法中使用,不可能被其余线程引用
        //所以sb属于不可能共享的资源,JVM会自动消除内部的锁
        StringBuffer sb = new StringBuffer();
        sb.append(str1).append(str2);
    }

    public static void main(String[] args) {
        StringBufferWithoutSync withoutSync = new StringBufferWithoutSync();
        for (int i = 0; i < 1000; i++) {
            withoutSync.add("aaa", "bbb");
        }
    }
}

锁优化之锁粗化，咱们再来了解锁粗化的概念，有些状况下可能会须要频繁且重复进行加锁和解锁操做，例如同步代码写在循环语句里，此时JVM会有锁粗化的机制，即经过扩大加锁的范围，以免反复加锁和解锁操做。代码示例：

public class CoarseSync {

    public static String copyString100Times(String target){
        int i = 0;
        // JVM会将锁粗化到外部，使得重复的加解锁操做只须要进行一次
        StringBuffer sb = new StringBuffer();
        while (i < 100){
            sb.append(target);
        }

        return sb.toString();
    }
}

synchronized锁存在四种状态：

无锁、偏向锁、轻量级锁、重量级锁
锁膨胀的方向：无锁 -> 偏向锁 -> 轻量级锁 -> 重量级锁
锁膨胀存在跨级现象，例如直接从无锁膨胀到重量级锁

偏向锁：

大多数状况下，锁不存在多线程竞争，老是由同一线程屡次得到，为了减小同一线程获取锁的代价，就会使用偏向锁

核心思想：
若是一个线程得到了锁，那么锁就进入偏向模式，此时Mark Word的结构也变为偏向锁结构，当该线程再次请求锁时，无需再作任何同步操做，即获取锁的过程只须要检查Mark Word的锁标记位为偏向锁以及当前线程id等于Mark Word的ThreadID便可，这样就省去了大量有关锁申请的操做，那么这个锁也就偏向于该线程了

偏向锁不适用于锁竞争比较激烈的多线程场合

轻量级锁：

轻量级锁是由偏向锁升级而来，偏向锁运行在一个线程进入同步块的状况下，当有第二个线程加入锁竞争时，偏向锁就会升级为轻量级锁

适用场景：线程交替执行同步块

若存在线程同一时间访问同一锁的状况，就会致使轻量级锁膨胀为重量级锁

轻量级锁的加锁过程：

在代码进入同步块的时候，若是同步对象锁状态为无锁状态（锁标志位为“01”状态），虚拟机首先将在当前线程的栈帧中创建一个名为锁记录（LockRecord）的空间，用于存储锁对象目前的Mark Word的拷贝，官方称之为Displaced Mark Word。这时候线程堆栈与对象头的状态以下图所示：
拷贝对象头中的Mark Word复制到锁记录中
拷贝成功后，虚拟机将使用CAS操做尝试将对象的Mark Word更新为指向Lock Record的指针,并将Lock record里的owner指针指向object mark word。若是更新成功，则执行步骤4，不然执行步骤5
若是这个更新动做成功了，那么这个线程就拥有了该对象的锁，而且对象Mark Word的锁标志位设置为“00"，即表示此对象处于轻量级锁定状态，这时候线程堆栈与对象头的状态以下图所示：
若是这个更新操做失败了，虚拟机首先会检查对象的Mark Word是否指向当前线程的栈帧，若是是就说明当前线程已经拥有了这个对象的锁，那就能够直接进入同步块继续执行。不然说明多个线程竞争锁，轻量级锁就要膨胀为重量级锁，锁标志的状态值变为“10"，Mark Word中存储的就是指向重量级锁（互斥量）的指针，后面等待锁的线程也要进入阻塞状态。而当前线程便尝试使用自旋来获取锁，自旋我们前面讲过，就是为了避免让线程阻塞，而采用循环去获取锁的过程

轻量级锁的解锁过程：

经过CAS操做尝试把线程中复制的Displaced Mark Word对象替换当前的Mark Word
若是替换成功，整个同步过程就完成了
若是替换失败，说明有其余线程尝试过获取该锁（此时锁己膨胀），那就要在释放锁的同时，唤醒被挂起的线程

锁的内存语义：

当线程释放锁时，Java内存模型会把该线程对应的本地内存中的共享变量刷新到主内存中；而当线程获取锁时，Java内存模型会把该线程对应的本地内存置为无效，从而使得被监视器保护的临界区代码必须从主内存中读取共享变量

偏向锁、轻量级锁、重量级锁的汇总：

synchronized和ReentrantLock的区别

在JDK1.5以前，synchronized是Java惟一的同步手段，而在1.5以后则有了ReentrantLock类（重入锁）：

位于java.util.concurrent.locks包
和CountDownLatch、FuturaTask、Semaphore同样基于AQS框架实现
可以实现比synchronized更细粒度的控制，如控制fairness
调用lock以后，必须调用unlock释放锁
在JDK6以后性能未必比synchronized高，而且也是可重入的

ReentrantLock公平性的设置：

ReentrantLock fairLock = new ReentrantLock(true);
参数为true时，倾向于将锁赋予等待时间最久的线程，即设置为所谓的公平锁，公平性是减小线程饥饿的一个办法
公平锁：获取锁的顺序按前后调用lock方法的顺序，公平锁需慎用，由于会影响性能
非公平锁：线程抢占锁的顺序不必定，与调用顺序无关，看运气
synchronized是非公平锁

ReentrantLock的好处在于将锁对象化了，所以能够实现synchronized难以实现的逻辑，例如：

判断是否有线程，或者某个特定线程，在排队等待获取锁
带超时的获取锁的尝试
感知有没有成功获取锁

若是说ReentrantLock将synchronized转变为了可控的对象，那么是否能将wait、notify及notifyall等方法对象化，答案是有的，即Condition：

位于java.util.concurrent.locks包
能够经过ReentrantLock的newCondition方法获取该Condition对象实例

synchronized和ReentrantLock的区别：

synchronized是关键字，ReentrantLock是类
ReentrantLock能够对获取锁的等待时间进行设置，避免死锁
ReentrantLock能够获取各类锁的信息
ReentrantLock能够灵活地实现多路通知
内部机制：synchronized操做的是Mark Word，而ReentrantLock底层是调用Unsafe类的park方法来加锁

jmm的内存可见性

Java内存模型（JMM）：

Java内存模型（Java Memory Model，简称JMM）自己是一种抽象的概念，并不真实存在，它描述的是一组规则或规范，经过这组规范定义了程序中各个变量（包括实例字段，静态字段和构成数组对象的元素）的访问方式

JMM中的主内存（即堆空间）：

存储Java实例对象
包括成员变量、类信息、常量、静态变量等
属于数据共享的区域，多线程并发操做时会引起线程安全问题

JMM中的工做内存（即本地内存，或线程栈）：

存储当前方法的全部本地变量信息，本地变量对其余线程不可见
字节码行号指示器、Native方法信息
属于线程私有数据区域，不存在线程安全问题

JMM与Java内存区域划分（即Java内存结构）是不一样的概念层次：

JMM描述的是一组规则，经过这组控制程序中各个变量在共享数据区域和私有数据区域的访问方式，JMM是围绕原子性、有序性及可见性展开的
二者类似点：存在共享数据区域和私有数据区域

主内存与工做内存的数据存储类型以及操做方式概括：

方法里的基本数据类型本地变量将直接存储在工做内存的栈帧结构中
引用类型的本地变量，则是其引用存储在工做内存中，而具体的实例存储在主内存中
对象的成员变量、static变量、类信息均会被存储在主内存中
主内存共享的方式是线程各拷贝一份数据到工做内存，操做完成后刷新回主内存

JMM如何解决可见性问题：

指令重排序须要知足的条件：

在单线程环境下不能改变程序运行的结果
存在数据依赖关系的不容许重排序
以上两点能够归结为：没法经过happens-before原则推导出来的，才能进行指令的重排序

什么是Java内存模型中的happens-before：

若是两个操做不知足下述任意一个happens-before原则，那么这两个操做就没有顺序的保障，JVM能够对这两个操做进行重排序
若是操做A happens-before 操做B，那么操做A在内存上所作的操做对操做B都是可见的
若A操做的结果须要对B操做可见，则A与B存在happens-before关系

happens-before的八大原则：

程序次序规则：一个线程内，按照代码顺序，书写在前面的操做先行发生于书写在后面的操做

锁定规则：一个unLock操做先行发生于后面对同一个锁的lock操做

volatile变量规则：对一个变量的写操做先行发生于后面对这个变量的读操做（保证了可见性）

传递规则：若是操做A先行发生于操做B，而操做B又先行发生于操做C，则能够得出操做A先行发生于操做C

线程启动规则：Thread对象的start()方法先行发生于此线程的每个动做

线程中断规则：对线程interrupt()方法的调用先行发生于被中断线程的代码检测到中断事件的发生

线程终结规则：线程中全部的操做都先行发生于线程的终止检测，咱们能够经过Thread.join()方法结束、Thread.isAlive()的返回值手段检测到线程已经终止执行

对象终结规则：一个对象的初始化完成先行发生于他的finalize()方法的开始

volatile：

是JVM提供的轻量级同步机制
JVM保证被volatile修饰的共享变量对全部线程老是可见的
禁止指令的重排序优化
使用volatile不能保证线程安全，须要变量的操做知足原子性

volatile变量为什么当即可见？简单来讲：

当写一个volatile变量时，JMM会把该线程对应的工做内存中的共享变量值刷新到主内存中
当读取一个volatile变量时，JMM会把该线程对应的工做内存置为无效，那么就须要从主内存中从新读取该变量

volatile变量如何禁止重排序优化：

对此咱们须要先了解内存屏障（Memory Barrier），其做用有二：
1. 保证特定操做的执行顺序
2. 保证某些变量的内存可见性
经过插入内存屏障指令来禁止对内存屏障先后的指令执行重排序优化
强制刷出各类CPU的缓存数据，所以任何CPU上的线程都能读取到这些数据的最新版本

volatile和synchronized的区别：

volatile本质是在告诉JVM当前变量在寄存器（工做内存）中的值是不肯定的，须要从主存中读取；synchronized则是锁定当前变量，只有当前线程能够访问该变量，其余线程被阻塞住直到该线程完成变量操做为止

volatile仅能使用在变量级别；synchronized则可使用在变量、方法和类级别

volatile仅能实现变量的修改可见性，不能保证原子性；而synchronized则能够保证变量修改的可见性和原子性

volatile不会形成线程的阻塞；synchronized可能会形成线程的阻塞

volatile标记的变量不会被编译器优化；synchronized标记的变量能够被编译器优化

CAS

CAS（Compare and Swap）是一种线程安全性的方法：

支持原子更新操做，适用于计数器，序列发生器等场景
属于乐观锁机制，号称lock-free
CAS操做失败时由开发者决定是继续尝试，仍是执行别的操做

CAS思想：

包含三个操做数：内存位置（V）、预期原值（A）和新值（B）

CAS多数状况下对开发者来讲是透明的：

J.U.C的atomic包提供了经常使用的原子性数据类型以及引用、数组等相关原子类型和更新操做工做，是不少线程安全程序的首选
Unsafe类虽然提供CAS服务，但因可以操纵任意内存地址读写而有隐患
Java9之后，可使用Variable Handle API来代替Unsafe

缺点：

若循环时间长，则开销很大
只能保证一个共享变量的原子操做
存在ABA问题，能够经过使用AtomicStampedReference来解决，但因为是经过版本标记来解决因此存在必定程度的性能损耗

Java线程池

利用Executors建立不一样的线程池知足不一样场景的需求：

newFixedThreadPool(int nThreads)：指定工做线程数量的线程池

newCachedThreadPool()：处理大量短期工做任务的线程池，特色：

试图缓存线程并重用，当无缓存线程可用时，就会建立新的工做线程

若是线程闲置的时间超过阈值，则会被终止并移出缓存

系统长时间闲置的时候，不会消耗什么资源

newSingleThreadExecutor()：建立惟一的工做者线程来执行任务，若是线程异常结束，会有另外一个线程取代它

newSingleThreadScheduledExecutor()与newScheduledThreadPool(int corePoolSize)：定时或者周期性的工做调度，二者的区别在于单一工做线程仍是多个线程

JDK8新增的newWorkStealingPool()：内部会构建ForkJoinPool ，利用working-stealing算法，并行地处理任务，不保证处理顺序

working-stealing算法：某个线程从其余线程的任务队列里窃取任务来执行

Fork/Join框架（JDK7提供）：

是一个能够把大任务分割成若干个小任务并行执行，最终汇总每一个小任务结果后获得大任务结果的框架

为何要使用线程池：

减低资源消耗，避免频繁地建立和销毁线程
提升线程的可管理性，例如可控的线程数量，线程状态的监控和统一建立/销毁线程

Executor的框架：

J.U.C的三个Executor接口：

Executor：运行新任务的简单接口，将任务提交和任务执行细节解耦
ExecutorService：具有管理执行器和任务生命周期的方法，提交任务机制更完善
ScheduleExecutorService：支持Future和按期执行任务

线程池执行任务流程图：

ThreadPoolExecutor的七个构造器参数：

int corePoolSize：核心线程数
int maximumPoolSize：最大线程数
long keepAliveTime：线程空闲存活时间
TimeUnit unit：存活时间的单位
BlockingQueue<Runnable> workQueue：任务等待队列
ThreadFactory threadFactory：线程建立工厂，用于建立新线程
RejectedExecutionHandler handler：任务拒绝策略
- AbortPolicy：直接抛出异常，这是默认策略
- CallerRunsPolicy：使用调用者所在的线程来执行任务
- DiscardOldestPolicy：丢弃队列中最靠前的任务，并执行当前任务
- DiscardPolicy：直接丢弃提交的任务
- 另外能够实现RejectedExecutionHandler接口来自定义handler

新任务提交execute执行后的判断：

若是运行的线程少于corePoolSize ，则建立新线程来处理任务，即便线程池中的其余线程是空闲的;
若是线程池中的线程数量大于等于corePoolSize且小于maximumPoolSize，则只有当workQueue满时才建立新的线程去处理任务;
若是设置的corePoolSize和maximumPoolSize相同，则建立的线程池的大小是固定的，这时若是有新任务提交，若workQueue未满,则将请求放入workQueue中，等待有空闲的线程去从workQueue中取任务并处理;
若是运行的线程数量大于等于maximumPoolSize，这时若是workQueue已经满了，则经过handler所指定的策略来处理任务;

execute执行流程图：

线程池的状态：

RUNNING：能接受新提交的任务，而且也能处理阻塞队列中的任务
SHUTDOWN：再也不接受新提交的任务，但能够处理存量任务（调用shutdown方法）
STOP：再也不接受新提交的任务，也不处理存量任务（调用shutdownNow方法）
TIDYING：全部的任务都已终止
TERMINATED：terminated() 方法执行完后进入该状态

线程池状态转换图：

线程池中工做线程的生命周期：

关于线程池大小如何选定参考：

CPU密集型任务：线程数 = 按照CPU核心数或者CPU核心数 + 1设定
I/O密集型任务：线程数 = CPU核心数 * (1 + 平均等待时间 / 平均工做时间)