多线程和并发

最新推荐文章于 2023-07-25 15:00:00 发布

原创最新推荐文章于 2023-07-25 15:00:00 发布 · 435 阅读

3 ·

CC 4.0 BY-SA版权

文章标签：

#多线程

服务器开发专栏收录该内容

17 篇文章

订阅专栏

进程和线程的区别

进程和线程相似，但线程是一个比进程更小的执行单位，一个进程在其执行的过程中可以产生很多线程，与进程不同的是同类的多个线程共享一个内存单元和一组系统资源。所以系统在产生一个线程，或者是在各个线程之间切换工作，负担要比进程小的很多，因此线程称为轻量级进程。另外，也是因为共享资源，所以线程中执行时一般都要进行同步和互斥。总的来说，进程和线程的主要差别在于它们是不同的操作系统资源管理方式。

进程是系统资源分配的最小单位，线程是CPU调度的最小单位。所有与进程相关的资源，都被记录在PCB中。

线程由堆栈寄存器，程序计数器和TCB组成

进程的三种状态

就绪态

进程已经获得除处理器以外的其他所有资源，只要分配了处理器就可执行
运行态

进程占用处理器资源，处于此状态的进程的数目小于等于处理器的数目，在没有其他进程可以执行时，通常会自动执行系统的空闲进程
阻塞态

由于进程等待某种条件（如I/O操作，进程同步），在条件满足前无法继续进行，该事件发生前即使把处理机分配给该线程，也无法执行

线程的五种状态

新建

当对象创建后，即进入了新建状态，如Thread thread = new MyThread();
就绪

当线程调用了start（）方法，线程进入了就绪状态，处于就绪状态的线程，只是说明该线程已经准备好了，随时等待CPU调度执行，并不是执行了start（）就开始执行
运行

当CPU开始调度处于就绪状态的线程，此时该线程才能真正执行，即进入运行态，
注：就绪态是进入运行态的唯一入口
阻塞

处于运行态的线程由于某种原因，暂时放弃对CPU的使用权，停止执行，此时进入阻塞状态，直到其进入就绪状态，才有机会被CPU调用以进入运行状态，根据阻塞产生的原因不同，可以分为三种
- 等待阻塞：运行状态的线程执行wait()方法，使本线程进入等待阻塞状态
- 同步阻塞：线程在获取synchronized同步锁失败后，他会进入同步阻塞状态
- 其他阻塞：通过调用线程的sleep（）或join（）或者发出I/O请求时，线程进入阻塞状态，当sleep（）状态超时，join（）等待线程终止或超时，或者I/O处理完毕时，线程重新转入就绪状态
死亡

线程执行完了或者因异常退出了run方法，该线程结束生命周期

进程间的6种通信方式

管道

管道是一种半双工的通信方式，数据只能单向流动，而且只能在具有血缘关系的进程间使用，进程的血缘关系通常指父子进程关系，管道分为pipe【无名管道】和fifo【命名管道】两种，命名管道也是半双工的通信方式，但是它允许无亲缘关系进程间通信。
信号量

信号量是一个计数器，可以用来控制多个进程对共享资源的访问，它通常作为一种锁机制，防止某进程正在访问共享资源时，其他进程也访问该资源。因此，主要作为进程间以及同一进程内不同线程之间的同步手段。
消息队列

消息队列是由消息组成的链表，存放在内核中，由消息队列标识符标识。消息队列克服了信号传递消息少，管道只能承载无格式字节流以及缓冲区大小受限等缺点。消息队列和管道通信相比，其优势是对每个消息指定特定的消息类型，接收的时候不需要按照队列次序，而是可以根据自定义条件接收特定类型的消息
信号

信号是一种比较复杂的通信方式，用于通知接收进程某一事件已经发生
共享内存

共享内存就是映射一段能被其他进程锁访问的内存，这段共享内存由一个进程创建，但多个进程都可以访问，共享内存是最快的IPC方式，他是针对其他进程间的通信方式运行效率低而专门创建设计的。他往往与其他通信机制，如信号量配合使用，来实现进程间的同步和通信
套接字

套接字也是一种通信机制，凭借这种机制，客户/服务器系统的开发工作既可以在本地单机上进行，也可以跨网络进行。也就是说他可以让不在同一台计算机但通过内网连接计算机上的进程进行通信。也因为这样，套接字明确地将客户端和服务器区分开来。

线程间的3种通信方式

锁机制
- 互斥锁：提供了以排他方式阻止数据结构别并发修改的方法
- 读写锁：允许多个线程同时读共享数据，而堆写操作互斥。
- 条件变量：可以以原子的方式阻塞进程，知道某个特定条件为真为止。对条件测试是在互斥锁的保护下进行的。条件变量始终与互斥锁一起使用
信号量机制
- 包括无名线程信号量与有名线程信号量
信号机制
- 类似于进程间的信号处理】

死锁

所谓死锁，是指多个进程在运行过程中因争夺资源而造成的一种僵局，当进程处于这种僵持状态时，若无外力作用，它们都将无法再向前推进。因此我们举个例子来描述，如果此时有一个线程A，按照先锁a再获得锁b的的顺序获得锁，而在此同时又有另外一个线程B，按照先锁b再锁a的顺序获得锁。

产生死锁的原因

竞争资源
- 可剥夺资源：某进程在获得这类资源后，该资源可以再被其他进程或系统剥夺，CPU和主存均属于可剥夺性资源
- 不可剥夺资源：当系统把这类资源分配给某进程后，再不能强行收回，只能在进程用完后自行释放，如磁带机，打印机
进程间推进顺序非法

死锁产生的四个必要条件

互斥条件

进程要求对所分配的资源进行排它性控制，即在一段时间内某资源仅为一进程所占用
请求和保持

当进程因请求资源而阻塞时，对已获得的资源保持不放。
不可剥夺条件

进程已获得的资源在未使用完之前，不能剥夺，只能在使用完时由自己释放。
环路等待条件

在发生死锁时，必然存在一个进程–资源的环形链

死锁解决的方式

预防死锁
- 资源一次性分配：一次性分配所有资源，这样就不会再有请求了：（破坏请求条件）
- 只要有一个资源得不到分配，也不给这个进程分配其他的资源：（破坏请保持条件）
- 可剥夺资源：即当某进程获得了部分资源，但得不到其它资源，则释放已占有的资源（破坏不可剥夺条件）
- 资源有序分配法：系统给每类资源赋予一个编号，每一个进程按编号递增的顺序请求资源，释放则相反（破坏环路等待条件）
- 以确定的顺序获得锁
- 超时放弃
避免死锁
- 预防死锁的几种策略，会严重地损害系统性能。因此在避免死锁时，要施加较弱的限制，从而获得较满意的系统性能。由于在避免死锁的策略中，允许进程动态地申请资源。因而，系统在进行资源分配之前预先计算资源分配的安全性。
- 银行家算法：首先需要定义状态和安全状态的概念。系统的状态是当前给进程分配的资源情况。因此，状态包含两个向量Resource（系统中每种资源的总量）和Available（未分配给进程的每种资源的总量）及两个矩阵Claim（表示进程对资源的需求）和Allocation（表示当前分配给进程的资源）。安全状态是指至少有一个资源分配序列不会导致死锁。当进程请求一组资源时，假设同意该请求，从而改变了系统的状态，然后确定其结果是否还处于安全状态。如果是，同意这个请求；如果不是，阻塞该进程知道同意该请求后系统状态仍然是安全的。
检测死锁
- 首先为每个进程和每个资源指定一个唯一的号码；
- 然后建立资源分配表和进程等待表。
解除死锁
- 当发现有进程死锁后，便应立即把它从死锁状态中解脱出来，常采用的方法有：
  - 剥夺资源：从其它进程剥夺足够数量的资源给死锁进程，以解除死锁状态；
  - 撤消进程：可以直接撤消死锁进程或撤消代价最小的进程，直至有足够的资源可用，死锁状态.消除为止；所谓代价是指优先级、运行代价、进程的重要性和价值等。

死锁检测

Jstack命令

jstack是java虚拟机自带的一种堆栈跟踪工具。jstack用于打印出给定的java进程ID或core file或远程调试服务的Java堆栈信息。 Jstack工具可以用于生成java虚拟机当前时刻的线程快照。线程快照是当前java虚拟机内每一条线程正在执行的方法堆栈的集合，生成线程快照的主要目的是定位线程出现长时间停顿的原因，如线程间死锁、死循环、请求外部资源导致的长时间等待等。线程出现停顿的时候通过jstack来查看各个线程的调用堆栈，就可以知道没有响应的线程到底在后台做什么事情，或者等待什么资源。
JConsole工具

Join 方法

把指定的线程加入到当前线程中，可以将两个交替执行的线程合并为顺序执行的线程。比如在B中调用线程A的join方法，直到线程A执行完毕后，才会继续执行执行线程B。

实现原理：

通过wait【object类提供的方法】，当main线程调用t.join()时候，main线程会获得线程对象t的锁（wait意味着拿到该对象的锁），调用该对象的wait（等待时间），直到该对象唤醒main线程，比如退出后，这就意味着main线程调用t.join时，必须能够拿到线程t对象的锁。

public class JoinTest implements Runnable{
    public static int a = 0;
    @override
    public void run() {
        for(int i = 0 ; i < 5 ;i++){
            a = a + 1 ;
        }
    }
    public static void main(String [] args){
        Runnable r = new JoinTest();
        Thread t = new Thread(r);
        t.start();
        // 假如不加这句话，可能输出的a不会是5，因为是多线程，可能执行输入的时候还没有完成a循环加到5，
        // 但是加上join方法后，会一直执行结果都是5，因为主线程会等待子线程t完成后在进行继续执行输出
        t.join();
		System.out.println(a);
    }
}

Thread中start和run的区别

start会调用JVM_StartThread创建一个新的子线程thread_entry，然后在通过该子线程去调用run方法

创建线程的四种方式

1）继承Thread类创建线程

2）实现Runnable接口实现run方法创建线程

3）使用Callable实现call方法和Future创建线程

4）使用线程池例如用Executor框架

Thread和Runnable的关系

Thread是实现了Runnable接口的类，使得run支持多线程
因类的单一继承原则，推荐使用Runnable接口

实现处理线程的返回值

主线程等待法【不要用】

while(childTread.returnData == null){
    // 主线程等待法
    Thread.currentThread().sleep(100);
}

使用Thread类的join()阻塞当前线程以等待子线程处理完毕
```
CycileWait cw = new CycleWait();
Thread t = new Thread(cw);
t.start();
t.join(); // 使主线程等待子线程执行完毕后在进行操作
syso(cw.value);
```
但是不能实现更细粒度的控制，比如第一个线程执行到一半去执行第二个就做不到

通过Callable接口实现:通过FutureTask or 线程池获取

public class MyCallable implements Callable<String> {
    @override
    public String call() throws Exception {
        String value = "test";
        syso("ready to work");
        Thread.currentThread().sleep(5000);
        syso("task down");
        return value;
    }
}

通过FutureTask的方式

FutureTask<String> task = new FutureTask<String>(new Mycallable());
new Thread(task).start();
if(!task.isDone()){
    syso("task is not finish");
}
syso("task return : " + task.get()); // get方法会阻塞，直到拿到返回值

通过线程池的方式

ExecutorService newCacheThreadPool = Executors.newCachedThreadPool();
Future<String> futrue = newCacheThreadPool.submit(new MyCallable());
if(!future.isDone()){
    syso("task has not finished");
}
try{
    syso(future.get()); // get方法会阻塞直到拿到值以后.
}catch(ExecutionException e){
    e.printStackTrace();
} finally {
    // 关闭线程池
    newCachedThreadPool.shutdown();
}

线程的状态

新建（new）：创建后尚未启动【start()】的线程的状态
运行（Runnable）：包括Running和Ready
无限等待（Waiting）：不会被分配CPU执行时间，需要显示被唤醒
- 没有设置时间的Object.wait()方法；
- 没有设置时间的Thread.Join()方法；
- LockSupport.park();
限期等待（Timed Waiting）：在一定时间后会由系统自动唤醒
- Thread.sleep(time);
- Object.wait(time);
- Thread.join(time);
- LockSupport.parkNanos()
- LockSupport.parkUntil()
阻塞(Blocked)：等待获取排它锁
结束状态(Terminated)：已终止线程的状态，线程已经结束执行

sleep和wait的差别

基本的差别
- Sleep是Thread类的方法，wait是Object类的方法
- sleep方法可以在任何地方使用，wait方法只能在synchronized方法或者synchronized块中使用
- 调用sleep会进入阻塞队列，进入到锁池中，调用wait会进入到等待池中
最本质的区别
- Thread.sleep只会让出cpu，不会导致锁行为的变化，不会释放锁
- Object.wait不仅让出CPU,还会释放已经占有的同步资源锁。会释放锁

notify和notifyAll的区别

共同点

使用Object.wait()，但是不传递时间参数，进程将进入无限期的等待，直到其他进程去唤醒

Object.notify() 和Object.notifyAll()就可以唤醒
区别
- 锁池EntryList
  - 假设线程A已经拥有了某个对象（不是类）的锁，而其他线程B，C想要调用这个对象的某个synchronized方法（或者块），由于B,C线程在进入对象synchronized方法（或者块）之前必须先获得该对象锁的拥有权，但该对象的锁目前正在被线程A占用，此时B,C线程就会被阻塞，进入一个地方去等待锁的释放，这个地方就是对象的锁池
- 等待池WaitSet
  - 假设线程A调用了某个对象的wait（）方法，线程A就会释放该对象的锁，同时线程A就进入了该对象的等待池中，进入到等待池中的线程不会去竞争该对象的锁。
- notifyAll会让所有处于等待池的线程全部进入锁池去竞争获取锁的机会
- notify只会随机选取一个处于等待池中的线程进入锁池去竞争获取锁的机会

yield

概念

当调用thread.yield()的时候，会给线程调度器一个暗示，当前线程愿意让出CPU的使用，但是调度器可能会忽略
对锁的行为不会有影响，也就是不会让出当前占用的锁

interrupt

如何中断线程
- 已经抛弃的方法
  - 通过stop()停止线程
- 目前使用的
  - 调用interrupt()通知线程应该中断了
    - 如果线程处于被阻塞状态，reentrantLock的lock()会有区别，那么线程将立即退出被阻塞状态，并抛出InterruptedException异常
    - 如果线程处于正常活动状态，那么会将该线程的中断标志位设置为true。被设置中断标志的线程将继续正常运行，不受影响
  - 需要被调用的线程配合中断
    - 在正常运行任务时，经常检查本线程的中断标志位，如果被设置了中断标志位就自行停止线程
    - 如果线程处于正常活动状态，那么会将该线程的中断标志设置为true，被设置中断标志的线程将继正常运行，不受影响。

线程的状态转化

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-QmtBoIOW-1592923944111)(C:\Users\32091\AppData\Roaming\Typora\typora-user-images\1582970455863.png)]$

sychronized

线程安全的诱因
- 存在共享数据【临界资源】
- 存在多条线程共同操作共享数据
互斥锁的特性
- 互斥性【操作的原子性】
- 可见性
  
  确保在释放锁之前，对共享变量所做的修改，对随后获得该锁的另一个线程是可见的，即获得锁的时候应该获得对象的最新值
根据获取锁的分类——对象锁和类锁
- 对象锁
  - 同步代码块sychronized（this）
  - 锁对象实例sychronized
  - 同步非静态方法（not static）
- 类锁
  - 同步代码块sychronized（类.class)
  - 同步静态方法（static method）
sychronized的底层实现
- 基础
  - 对象在内存中的布局
    - 对象头
      - Mark Word：存储对象的hashcode，分代年龄，锁类型，锁标志
      - Class Metadata Address：类型指针指向对象的类元数据，JVM通过这个指针确定该对象是哪个类的数据
    - 实例数据
    - 对齐填充
  - Monitor
    - 同步代码块
      - 进入时会添加monitor enter
      - 退出时执行monitor exit
      - 当执行 monitorenter 指令时，线程试图获取锁也就是获取 monitor(monitor对象存在于每个Java对象的对象头中，synchronized 锁便是通过这种方式获取锁的，也是为什么Java中任意对象可以作为锁的原因) 的持有权.当计数器为0则可以成功获取，获取后将锁计数器设为1也就是加1。相应的在执行 monitorexit 指令后，将锁计数器设为0，表明锁被释放。如果获取对象锁失败，那当前线程就要阻塞等待，直到锁被另外一个线程释放为止
    - 同步方法
      - 添加ACC_SYNCHRONIZED访问标志实现互斥访问
- 锁的内存语义
  - 当线程释放锁时，JAVA内存模型会把该线程对应的本地内存中的本地变量刷新到主内存中。
  - 而当线程获取锁时，JAVA内存模型会把该线程对应的本地内存置为无效，从而使得被监视器保护的临界区代码必须从主内存中读取共享变量

1.6以后对synchronized做了什么优化

如偏向锁、轻量级锁、自旋锁、适应性自旋锁、锁消除、锁粗化等技术来减少锁操作的开销。

锁主要存在四种状态：无锁状态，偏向锁状态，轻量级锁状态，重量级锁状态

锁可以升级不可以降级【其实也可以降级】

偏向锁

在无竞争的情况下，把整个同步都消除

如果一个线程获得了锁，那么锁就进入偏向模式，此时Mark Word的结构就变成偏向锁结构，当该线程再次请求锁时，无需再做任何同步操作，即获得锁的过程只需要检查当前Mark Word的锁标志位为偏向锁并且当前线程ID等于Mark Word的ThreadID即可，这样就省去了大量关于申请锁的操作。

偏向锁会偏向第一个获得它的线程，如果该锁没有被其他线程获取，那么持有该偏向锁的线程就不需要同步
轻量级锁

在无竞争的情况下，使用CAS操作去代替使用互斥量
- 轻量级锁加锁过程
  - 代码进入同步块的时候，如果同步对象锁状态为无锁状态（锁标志位为01），虚拟机首先将在当前线程的栈帧中建立一个名为锁记录（Lock Record）的空间，用于存储对象目前的Mark Word的拷贝，官方称之为Displaced Mark Word。这个时候线程堆栈与对象头的状态如图所示
$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-qMcPze2E-1592923944116)(C:\Users\32091\AppData\Roaming\Typora\typora-user-images\1583055822890.png)]$
- 拷贝当前对象的对象头中的Mark Word到锁记录中
- 拷贝成功后，虚拟机将使用CAS操作尝试将对象的Mark Word更新为指向Lock Record的指针，并将Lock Record的ower指针指向Object mark word。
- 如果成功，表示这个线程拥有了该对象的锁，并且对象的Mark Word的锁标志位设置为00，即表示次对象处于轻量级锁状态
- 如果失败，首先检查对象的Mark Word是否已经指向当前线程的栈帧，如果是，则说明该线程已经拥有了该对象的锁，可以直接进入同步代码块，如果不是，则说明已经有其他线程在竞争锁，则锁膨胀为重量级锁。而当前线程则开始尝试使用自旋来获取锁。
- 轻量级锁解锁的过程
  - 通过CAS操作尝试把线程中复制的Displached Mark Word对象替换成当前的Mark Word
  - 成功表示整个同步过程完成
  - 失败则表示有其他线程尝试过该锁，说明锁已经碰撞了，则要求在释放锁的同时，唤醒被挂起的线程。
自旋锁和自适应锁

轻量级锁失效后，虚拟机为了避免线程真实的在操作系统层面挂起，还会进行一项称为自旋锁的优化手段

一般线程持有锁的时间都不是太长，所以仅仅为了这一点时间去挂起线程/恢复线程是得不偿失的，所以我们决定让后面来的线程等待而不是挂起，为了让线程等待，我们只需要让线程执行一个忙循环【自旋】

自旋的默认次数是十次，用户可以通过修改–XX:Pre

BlockSpin更改

在1.6中引入了自适应的自旋锁，自旋的时间不固定，而是通过前一次同一个锁的自旋锁时间以及锁的有用的状态来决定的
锁消除

虚拟机编译器在运行时，如果检测到那些共享数据不可能存在竞争，就执行锁消除
锁粗化

频繁的对对象进行加锁，解锁，会造成性能上的损失，如果虚拟机检测到一连串零碎操作都是对同一对象加锁，就会把加锁同步的范围扩展到整个操作序列的外部

sychronized和ReentrantLock的区别

两者都是可重入锁

自己可以再次获取自己的内部锁，如果不是可重入锁，同一个线程每次获取锁，锁的计数器都加一，所以要等到锁的计数器下降为0才能释放锁

前者依赖JVM后者依赖API

synchronized是虚拟机层面的锁的实现机制，

ReenTrantLock是JDK层面的，需要lock（）和unlock方法配合try/finally完成

private Lock lock = new ReentrantLock();
    public  void testMethod () {
        lock.lock();
       for(int i = 0 ; i < 5 ;i ++){
           System.out.println("ThreadName:" + Thread.currentThread().getName() + " " +(i + 1));
       }
       lock.unlock();
    }

ReenTrantLock比synchronized多一些功能

提供了一种能够中断等待锁的线程的机制

通过lock.lockInterruptibly（）来实现这个机制，也就是说正在等待的线程可以选择放弃等待，改为处理其他事情
可以指定是公平锁还是非公平锁，

公平是指先等待的先获取锁。

sychronized关键字与wait()和notify/notifyall方法相结合可以实现等待/通知机制，ReentrantLock类当然也可以实现，但是需要借助于Condition接口与newCondition方法，线程对象可以注册在指定的condition中，从而可以有选择性的进行线程通知，在调度线程上更加灵活，在使用notify/notifyAll方法进行通知的时候，被通知的线程是有JVM进行选择的，用ReentrantLock类结合Condition实例可以实现选择性通知

public class MyService {
    private Lock lock = new ReentrantLock();
    /**
     * 两个condition，模拟多个condition进行通信
     */
    private Condition conditionA = lock.newCondition();
    private Condition conditionB = lock.newCondition();
    private SimpleDateFormat dateFormat = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");

    private void awaitA() {
        try {
            lock.lock();
            String dateStr = dateFormat.format(System.currentTimeMillis());
            System.out.println("begin awaitA时间为" + dateStr
                    + " ThreadName=" + Thread.currentThread().getName());
            // 第一个condition去await等待唤醒
            conditionA.await();
            dateStr = dateFormat.format(System.currentTimeMillis());
            System.out.println("  end awaitA时间为" + dateStr
                    + " ThreadName=" + Thread.currentThread().getName());
        } catch (InterruptedException e) {
            e.printStackTrace();
        } finally {
            lock.unlock();
        }
    }

    private void awaitB() {
        try {
            lock.lock();
            String dateStr = dateFormat.format(System.currentTimeMillis());
            System.out.println("begin awaitB时间为" + dateStr
                    + " ThreadName=" + Thread.currentThread().getName());
            // 第二个condition去await等待唤醒
            conditionB.await();
            dateStr = dateFormat.format(System.currentTimeMillis());
            System.out.println("  end awaitB时间为" + dateStr
                    + " ThreadName=" + Thread.currentThread().getName());
        } catch (InterruptedException e) {
            e.printStackTrace();
        } finally {
            lock.unlock();
        }
    }

    private void signalAll_A() throws InterruptedException {
        try {
            lock.lock();
            String dateStr = dateFormat.format(System.currentTimeMillis());
            System.out.println("  signalAll_A时间为" + dateStr
                    + " ThreadName=" + Thread.currentThread().getName());
            // 只是将所有的conditionA唤醒
            conditionA.signalAll();
            Thread.sleep(1000);
            // 将某一个conditionB唤醒
            conditionB.signal();
        } finally {
            lock.unlock();
        }
    }

    private void signalAll_B() {
        try {
            lock.lock();
            String dateStr = dateFormat.format(System.currentTimeMillis());
            System.out.println("  signalAll_B时间为" + dateStr
                    + " ThreadName=" + Thread.currentThread().getName());
            conditionB.signalAll();
        } finally {
            lock.unlock();
        }
    }

    public static class ThreadA extends Thread {

        private MyService service;

        public ThreadA(MyService service) {
            super();
            this.service = service;
        }

        @Override
        public void run() {
            service.awaitA();
        }
    }

    public static class ThreadB extends Thread {
        private MyService myService;

        public ThreadB(MyService myService) {
            super();
            this.myService = myService;
        }

        @Override
        public void run() {
            myService.awaitB();
        }
    }

    public static void main(String[] args) throws InterruptedException {
        MyService myService = new MyService();
        ThreadA threadA = new ThreadA(myService);
        threadA.setName("A1");
        threadA.start();

        ThreadA threadA2 = new ThreadA(myService);
        threadA2.setName("A2");
        threadA2.start();

        ThreadB b = new ThreadB(myService);
        b.setName("B");
        b.start();
        Thread.sleep(3000);

        myService.signalAll_A();
    }
}

synchronized是操作Mark Word，而lock是调用unfair的park（）方法

jmm的内存可见性

java内存模型，描述的是一组规则或规范，通过这组规范定义了程序中各个变量（包括实例字段，静态字段和构成数组对象的元素）的访问方式

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-li3Fi0pd-1592923944117)(C:\Users\32091\AppData\Roaming\Typora\typora-user-images\1583154656614.png)]$

JMM的主内存
- 存储java实例对象
- 包括成员变量，类信息，常量，静态变量
- 属于数据共享区域，多线程并发操作时会引起线程安全问题
JMM的工作内存
- 存储当前方法的所有本地变量信息，本地变量对其他线程不可见
- 字节码行号指示器，Native方法信息
- 属于线程私有区域，不存在线程安全问题
JMM与java内存区域划分是不同的概念层次
- JMM描述的是一组规则，围绕原子性，有序性，可见性展开
- 相似点：存在共享区域，私有区域
主内存与工作内存的数据存储类型自己操作方式
- 方法里的基本数据类型本地变量将直接存储在工作内存的栈帧结构中
- 引用类型的本地变量：引用存储在工作内存中，实例存储在主内存中
- 成员变量、static变量、类信息均会存储在主内存中
- 主内存共享的方式是线程各拷贝一份数据到工作内存，操作完成后刷新会主内存
指令重排序需要满足的条件
- 在单线程环境下不能改变程序运行的结果
- 存在数据依赖关系的不允许重排
- 即无法通过happens-before原则推导出来的，才能进行指令重排序
happens-before的原则
- A操作的结果需要对B操作可见，则A于B存在happens-before关系
- 八大原则
  - 程序次序操作，一个线程内，按照代码顺序，书写在前面的操作优先发生与书写在后边的
  - 锁定原则：一个unlock操作先发生于后边的对同一个锁的lock操作
  - volatile规则：对一个变量的写操作先行发生于后面对这个变量的读操作
  - 传递规则：如果操作A先行发生与B，而B先于C，则A先于C
  - 线程启动规则：Thread对象的start方法先行发生于此线程的每一个动作
  - 线程中断规则：对线程interrupt方法的调用先行发生于被中断程序的代码检测到中断事件的发生
  - 线程终结原则：线程中的所有的操作都先行发生于线程的终止检测，我们可以通过Thread.join（）方法结束，Thread.isAlive() 的返回值手段检测到线程已经终止执行
  - 对象终止原则：一个对象的初始化完成先于发生于他的finalize方法的开始

volatile:

保证被修饰的共享变量对所有线程都是可见的
禁止指令重排序
实现原理
- 当写一个volatile变量时，JMM会把该线程对应的工作内存中的共享数据刷新到主内存中
- 当读取一个volatile变量时，JMM会把该线程对应的工作内存设置为无效，从而去读取主内存中的值
如何实现禁止指令重排序
- 内存屏障
  - 保证特定操作的执行顺序
  - 保证某些变量的内存可见性
volatile和sychronized的区别
- volatile本质是告诉JVM当前变量在寄存器（工作内存）中的值是不确定的，需要去从主内存中读取，sychronized则是锁定当前变量，只有当前线程可以访问该变量，其他线程则被阻塞住直到该线程完成变量操作为止
- volatile仅能应用在变量上，sychronized则可以用在变量，方法和类级别
- volatile仅能实现变量的修改可见性，不能保证原子性，sychronized可以保证修改的可见性和原子性
- volatile不会造成线程的阻塞，sychronized可能会造成线程的阻塞
- volatile标记的变量不会被编译器优化，sychronized会被编译器优化

CAS【compare and swap】

支持原子操作，适用于计数器，序列发生器等场景
属于乐观锁机制，号称lock-free
CAS操作失败后由开发者决定是继续操作还是放弃
缺点
- 若循环时间长，开销很大
- 自能保证一个变量的原子操作
- ABA问题解决：AtomicStampedReference

AtomicInteger的CAS算法

AtomicInteger底层是通过unsafe类来操作数据的，其内部维护了一个Integer类型的属性value

获取到value这个属性相对于AtomicInteger对象的内存偏移量

 static {
        try {
            valueOffset = unsafe.objectFieldOffset
                (AtomicInteger.class.getDeclaredField("value"));
        } catch (Exception ex) { throw new Error(ex); }
    }

i++操作代码

 public final int getAndIncrement() {
        return unsafe.getAndAddInt(this, valueOffset, 1);
    }

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;
    }

通过对象和对象中属性的偏移量，来计算出当前偏移量下，存储的旧的数值，然后在旧值上增加新值，这一步需要注意的是，通过do-while这种方式，直到修改成功

最终调用的就是unsafe当中的compareAndSwapInt

// 其参数就是当前对象，var2:属性相对于当前对象的偏移量，var4 :期待值，var5:修改的新值
public final native boolean compareAndSwapInt(Object var1, long var2, int var4, int var5);

Java线程池

使用线程池的好处

降低资源消耗
提高响应速度
提高线程的可管理性

JAVA的四种线程池

FixedThreadPool

适合使用在任务量比较固定但耗时长的任务。

该方法返回一个固定线程数量的线程池。该线程池中的线程数量始终不变。当有一个新的任务提交时，线程池中若有空闲线程，则立即执行。若没有，则新的任务会被暂存在一个任务队列中，待有线程空闲时，便处理在任务队列中的任务。

这种线程池的阻塞队列是LinkedBlockQueue
SingleThreadPool

适合使用在多个任务顺序执行的场景。

方法返回一个只有一个线程的线程池。若多余一个任务被提交到该线程池，任务会被保存在一个任务队列中，待线程空闲，按先入先出的顺序执行队列中的任务。

这种线程池的阻塞队列是LinkedBlockQueue
CachedThreadPool

适合使用在任务量大但耗时少的任务。

该方法返回一个可根据实际情况调整线程数量的线程池。线程池的线程数量不确定，但若有空闲线程可以复用，则会优先使用可复用的线程。若所有线程均在工作，又有新的任务提交，则会创建新的线程处理任务。所有线程在当前任务执行完毕后，将返回线程池进行复用

这种线程池的阻塞队列是SynchronousQueue
ScheduledThreadPoolExecutor

适合使用在执行定时任务和具体固定周期的重复任务

用来在给定的延迟后运行任务，或者定期执行任务。ScheduledThreadPoolExecutor又分为：ScheduledThreadPoolExecutor（包含多个线程）和SingleThreadScheduledExecutor （只包含一个线程）两种

这种线程池的阻塞队列是DelayedWorkQueue

执行execute和submit方法的区别

execute方法用于提交不需要返回值的任务，所以无法判断是否被线程池执行成功与否
submit方法用于提交需要返回值的任务，线程池会返回一个future类型的对象，通过future.get()可以获得返回值，get方法会阻塞当前线程直到任务完成，使用get(long timeout, TimeUnit unit)会阻塞一段时间后立即返回，但任务可能没有完成

如何创建线程池

不允许使用Executors去创建，而是通过ThreadPoolExcutor的方式，这样可以明确线程池的运行规则，避免资源耗尽的风险

Executors返回线程池对象的弊端
- FixedThreadPool和SingleThreadExecutor：允许请求的队列长度为Integer.MAX_VALUE;可能堆积大量请求，从而导致OOM
- CachedThreadPool和ScheduledThreadPool：允许请求的队列长度为Integer.MAX_VALUE;可能堆积大量请求，从而导致OOM

使用Executors创建线程池【不推荐】

public static void main(String[] args) throws Exception{
        ExecutorService executorService = Executors.newFixedThreadPool(1);
        for (int i = 0; i < 5; i++) {
            executorService.execute(new TaskPoolServer(i));
            // execute参数为一个runable接口
        }
        executorService.shutdown();
    }

使用ThreadPoolExecutor创建线程池【推荐】

ThreadPoolExecutor threadPoolExecutor  = new ThreadPoolExecutor(1, 1, 10,
                TimeUnit.HOURS,
                new ArrayBlockingQueue<Runnable>(1));
        for (int i = 0; i < 5; i++) {
            threadPoolExecutor.execute(new TaskPoolServer(i));
        }
        threadPoolExecutor.shutdown();

ThreadPoolExecutor的构造函数

corePoolSize：核心线程数量
maximumPoolSize：线程不够用时能创建的最多的线程数
keepAliveTime：线程池维护线程，所允许的空闲时间，当线程的数量大于corePoolSize。不会立即被销毁，直到被等待的时间超过keepAliveTime才被销毁
unit：keepAliveTime的单位，
- 小时
- 分钟
- …
workQueue：任务等待队列
threadFactory：创建新线程。Excutors.defaultThreadFactory()
handler:线程池的饱和策略，如果阻塞队列满了并且没有空闲的线程，如果继续提交任务就需要采取一种策略处理该任务
- AbortPolicy：直接抛出异常【默认值】
- CallerRunsPolicy：用调用者所在的线程来执行任务
- DiscardOldestPolicy：丢弃队列中靠最前的任务，并执行当前任务
- DiscardPolicy：直接丢弃当前任务
- 实现RejectedExcutionHandler接口自定义的Handler
新任务提交execute执行后的判断
- 如果运行的线程少于corePoolSize，则创建新任务来处理任务，即使线程池中的其他线程是空闲的
- 如果线程池中的数量大于等于corePoolSize且小于maximumPoolSize，则只有当workQueue满时才创建新的线程去处理任务
- 如果设置的corePoolSize和maximumPoolSize相同。则创建的线程池的大小是固定的，这时如果有新任务提交，若workQueue未满，则将请求放入workQueue中，等待有空闲的线程去workQueue中取任务执行
- 如果运行的线程数量大于等于maximumPoolSize，这时如果workQueue已经满了，则通过handler所指定的策略来执行。

ThreadLocal

static final ThreadLocal<T> sThreadLocal = new ThreadLocal<T>();
sThreadLocal.set()
sThreadLocal.get()

ThreadLocal是一个线程内部的存储类，可以在指定线程内存储数据，数据存储以后，只有指定线程可以得到存储数据

每一个线程内部都有一个threadLocals变量，存储一个ThreadLocal的静态内部类ThreadLocalMap，而每一个ThreadLocalMap又是一个map，其中key是ThreadLocal对象，value是Object对象

ThreadLocalMap内部有一个Entry[]的数组，对于每一个ThreadLocal对应一个下标，用来表示当前线程的唯一地址

//set 方法
public void set(T value) {
      //获取当前线程
      Thread t = Thread.currentThread();
      //实际存储的数据结构类型
      ThreadLocalMap map = getMap(t);
      //如果存在map就直接set，没有则创建map并set
      if (map != null)
          map.set(this, value);
      else
          createMap(t, value);
  }
  
//getMap方法
ThreadLocalMap getMap(Thread t) {
      //thred中维护了一个ThreadLocalMap
      return t.threadLocals;
}
 
//createMap
void createMap(Thread t, T firstValue) {
      //实例化一个新的ThreadLocalMap，并赋值给线程的成员变量threadLocals
      t.threadLocals = new ThreadLocalMap(this, firstValue);
}

// Entry为ThreadLocalMap静态内部类，对ThreadLocal的弱引用
// 同时让ThreadLocal和储值形成key-value的关系
static class Entry extends WeakReference<ThreadLocal<?>> {
    /** The value associated with this ThreadLocal. */
    Object value;

    Entry(ThreadLocal<?> k, Object v) {
           super(k);
            value = v;
    }
}

//ThreadLocalMap构造方法
ThreadLocalMap(ThreadLocal<?> firstKey, Object firstValue) {
        //内部成员数组，INITIAL_CAPACITY值为16的常量
        table = new Entry[INITIAL_CAPACITY];
        //位运算，结果与取模相同，计算出需要存放的位置
        //threadLocalHashCode比较有趣
        int i = firstKey.threadLocalHashCode & (INITIAL_CAPACITY - 1);
        table[i] = new Entry(firstKey, firstValue);
        size = 1;
        setThreshold(INITIAL_CAPACITY);
}

对于某一ThreadLocal来讲，他的索引值i是确定的，在不同线程之间访问时访问的是不同的table数组的同一位置即都为table[i]，只不过这个不同线程之间的table是独立的。
对于同一线程的不同ThreadLocal来讲，这些ThreadLocal实例共享一个table数组，然后每个ThreadLocal实例在table中的索引i是不同的。

特性

ThreadLocal和Synchronized都是为了解决多线程中相同变量的访问冲突问题，不同的点是

Synchronized是通过线程等待，牺牲时间来解决访问冲突
ThreadLocal是通过每个线程单独一份存储空间，牺牲空间来解决冲突，并且相比于Synchronized，ThreadLocal具有线程隔离的效果，只有在线程内才能获取到对应的值，线程外则不能访问到想要的值。
正因为ThreadLocal的线程隔离特性，使他的应用场景相对来说更为特殊一些，当某些数据是以线程为作用域并且不同线程具有不同的数据副本的时候，就可以考虑采用ThreadLocal。

从ThreadLocalMap看ThreadLocal使用不当的内存泄漏问题

THreadLocalMap中的Entry的key使用的是ThreadLocal对象的弱引用，在没有其他地方对ThreadLocal依赖，ThreadLocalMap中的ThreadLocal对象就会被回收掉，但是对应的不会被回收，这个时候Map中就可能存在key为null但是value不为null的项，这需要实际的时候使用完毕及时调用remove方法避免内存泄漏。

线程池的状态

RUNNING：能接受新提交的任务，并且也能处理阻塞队列中的任务
SHUTDOWN：不再接受新提交的任务，但可以处理存量任务
STOP:不再接受新提交的任务，并且也不处理存量任务
TIDYING:所有的任务都已经终止了
TERMINATED：terminated方法执行后进入该状态，什么任务都不执行

AtomicInteger如何实现线程安全

private static final Unsafe unsafe = Unsafe.getUnsafe();
private static final long valueOffset;
static{
    try{
        valueOffset = unsafe.objectFieldOffset(AtomicInteger.class.getDeclaredField("value"));
    }catch (Exception e){
        throw new Error(e);
    }
}
private volatile int value;

利用CAS + volatile 和native方法保证原子性

AQS

AbstractQuenedSynchronizer抽象的队列式同步器。是除了java自带的synchronized关键字之外的锁机制。
AQS的全称为（AbstractQueuedSynchronizer），这个类在java.util.concurrent.locks包

基础

是一个同步器，核心是双向链表 + state（状态）
原理

如果被请求的共享资源空闲，那就将当前请求资源的线程设置成有效的工作线程，并且将共享资源设定为锁定状态，如果被请求的共享资源被占用，那么就需要一套线程阻塞等待以及被唤醒时锁分配的机制，这个机制AQS是用CLH队列锁完成的，获取不到锁的线程，会进入队尾，然后自旋，直到其前驱线程释放锁。

CLH(Craig Landin ，and Hagersten) 队列是一个虚拟的双向队列，虚拟的双向队列即不存在队列实例，仅存在节点之间的关联关系，也就是链表

AQS将每一请求共享资源的线程封装成一个CLH锁列队的节点(Node)，来实现锁的分配

AQS就是基于CLH队列，用volatile修饰共享变量state，线程通过CAS去改变状态符，成功则获取锁成功，失败则进入等待队列，等待被唤醒。

实现了AQS的锁有：自旋锁、互斥锁、读锁写锁、条件产量、信号量、栅栏都是AQS的衍生物

AQS实现的具体方式如下

AQS维护了一个volatile int state和一个FIFO线程等待队列，多线程争用资源被阻塞的时候就会进入这个队列。state就是共享资源，其访问方式有如下三种：
getState();setState();compareAndSetState();
AQS定义两种资源共享方式
- Exclusive：独占，只有一个线程能执行，如ReentrantLock
- Share：共享，多个线程可以同时执行，如Semaphore、CountDownLatch、ReadWriteLock，CyclicBarrier
AQS底层使用了模板方法模式

同步器的设计是基于模板方法模式的，如果需要自定义同步器一般的方式是这样（模板方法模式很经典的一个应用）：
1. 使用者继承AbstractQueuedSynchronizer并重写指定的方法。（这些重写方法很简单，无非是对于共享资源state的获取和释放）
2. 将AQS组合在自定义同步组件的实现中，并调用其模板方法，而这些模板方法会调用使用者重写的方法。
  这和我们以往通过实现接口的方式有很大区别，这是模板方法模式很经典的一个运用。
自定义同步器在实现的时候只需要实现共享资源state的获取和释放方式即可，至于具体线程等待队列的维护，AQS已经在顶层实现好了。自定义同步器实现的时候主要实现下面几种方法：
- isHeldExclusively()：该线程是否正在独占资源。只有用到condition才需要去实现它。
- tryAcquire(int)：独占方式。尝试获取资源，成功则返回true，失败则返回false。
- tryRelease(int)：独占方式。尝试释放资源，成功则返回true，失败则返回false。
- tryAcquireShared(int)：共享方式。尝试获取资源。负数表示失败；0表示成功，但没有剩余可用资源，正数表示成功，且有剩余资源。
- tryReleaseShared(int)：共享方式。尝试释放资源，如果释放后允许唤醒后续等待结点返回true，否则返
  
  回false。
ReentrantLock为例，（可重入独占式锁）：state初始化为0，表示未锁定状态，A线程lock()时，会调用tryAcquire()独占锁并将state+1.之后其他线程再想tryAcquire的时候就会失败，直到A线程unlock（）到state=0为止，其他线程才有机会获取该锁。A释放锁之前，自己也是可以重复获取此锁（state累加），这就是可重入的概念。
注意：获取多少次锁就要释放多少次锁，保证state是能回到零态的。

以CountDownLatch为例，任务分N个子线程去执行，state就初始化为N，N个线程并行执行，每个线程执行完之后countDown（）一次，state就会CAS减一。当N子线程全部执行完毕，state=0，会unpark()主调用线程，主调用线程就会从await()函数返回，继续之后的动作。

一般来说，自定义同步器要么是独占方法，要么是共享方式，他们也只需实现tryAcquire-tryRelease、tryAcquireShared-tryReleaseShared中的一种即可。但AQS也支持自定义同步器同时实现独占和共享两种方式，如ReentrantReadWriteLock。
　在acquire() acquireShared()两种方式下，线程在等待队列中都是忽略中断的，acquireInterruptibly()/acquireSharedInterruptibly()是支持响应中断的。

程序并发的特性

程序并发执行的主要特点是并发程序间具有相互制约的关系，程序并发执行失去了程序的封闭性和再现性，程序和机器执行程序的活动不再一一对应。

JAVA的阻塞队列

java中的阻塞队列是一个支持两个附加操作的队列，这两个附加的操作支持阻塞的插入和移除方法

支持阻塞的插入方法：当队列满了以后，队列会阻塞插入元素的线程，直到队列不满
支持阻塞的移除方法：当队列为空时，获取元素的线程会等待队列变成非空。阻塞队列常用于生产者和消费者的场景，生产者向队列添加元素，消费者从队列读取元素。阻塞队列就是生产者用来存放元素，消费者用来获取元素的容器

当阻塞队列不可用的时候，这两个附加操作提供了4中处理方式
$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-EHfYBnXe-1592923944119)(E:\文档\学习资料\笔记\面经\多线程与并发.assets\aHR0cHM6Ly91cGxvYWQtaW1hZ2VzLmppYW5zaHUuaW8vdXBsb2FkX2ltYWdlcy80MDE3NTIzLTYyODQ3Yzk1NGViZTZlMDYucG5nP2ltYWdlTW9ncjIvYXV0by1vcmllbnQvc3RyaXB8aW1hZ2VWaWV3Mi8yL3cvMTIwMC9mb3JtYXQvd2VicA.jpg)]$
插入和移除的四种处理方式
- 抛出异常：当队列满时，如果再往队列里插入元素，会抛出IllegalStateException（“Queuefull”）异常。当队列空时，从队列里获取元素会抛出NoSuchElementException异常。
- 返回特殊值：当往队列插入元素时，会返回元素是否插入成功，成功返回true。如果是移除方法，则是从队列里取出一个元素，如果没有则返回null。
- 一直阻塞：当阻塞队列满时，如果生产者线程往队列里put元素，队列会一直阻塞生产者线程，直到队列可用或者响应中断退出。当队列空时，如果消费者线程从队列里take元素，队列会阻塞住消费者线程，直到队列不为空。
- 超时退出：当阻塞队列满时，如果生产者线程往队列里插入元素，队列会阻塞生产者线程一段时间，如果超过了指定的时间，生产者线程就会退出。

如果是无界阻塞队列，队列不可能会出现满的情况，所以使用put或offer方法永远不会被阻塞，而且使用offer方法时，该方法永远返回true。

JDK7提供了7个阻塞队列

ArrayBlockingQueue：一个由数组结构组成的有界阻塞队列。

此队列按照**先进先出（FIFO）**的原则对元素进行排序。默认情况下不保证线程公平的访问队列，所谓公平访问队列是指阻塞的线程，可以按照阻塞的先后顺序访问队列，即先阻塞线程先访问队列。非公平性是对先等待的线程是非公平的，当队列可用时，阻塞的线程都可以争夺访问队列的资格，有可能先阻塞的线程最后才访问队列。为了保证公平性，通常会降低吞吐量。
LinkedBlockingQueue：一个由链表结构组成的有界阻塞队列。

此队列的默认和最大长度为Integer.MAX_VALUE。此队列按照先进先出的原则对元素进行排序。
PriorityBlockingQueue：一个支持优先级排序的无界阻塞队列。

默认情况下元素采取自然顺序升序排列。也可以自定义类实现compareTo()方法来指定元素排序规则，或者初始化PriorityBlockingQueue时，指定构造参数Comparator来对元素进行排序。需要注意的是不能保证同优先级元素的顺序。
DelayQueue：一个使用优先级队列实现的无界阻塞队列。

队列使用PriorityQueue来实现。队
列中的元素必须实现Delayed接口，在创建元素时可以指定多久才能从队列中获取当前元素。
只有在延迟期满时才能从队列中提取元素。

DelayQueue非常有用，可以将DelayQueue运用在以下应用场景
1. 缓存系统的设计：可以用DelayQueue保存缓存元素的有效期，使用一个线程循环查询DelayQueue，一旦能从DelayQueue中获取元素时，表示缓存有效期到了。
2. 定时任务调度：使用DelayQueue保存当天将会执行的任务和执行时间，一旦从DelayQueue中获取到任务就开始执行，比如TimerQueue就是使用DelayQueue实现的。
SynchronousQueue：一个不存储元素的阻塞队列。

每一个put操作必须等待一个take操作，
否则不能继续添加元素。
它支持公平访问队列。默认情况下线程采用非公平性策略访问队列。

SynchronousQueue可以看成是一个传球手，负责把生产者线程处理的数据直接传递给消费者线程。队列本身并不存储任何元素，非常适合传递性场景。SynchronousQueue的吞吐量高于LinkedBlockingQueue和ArrayBlockingQueue。
LinkedTransferQueue：一个由链表结构组成的无界阻塞队列。

LinkedTransferQueue是一个由链表结构组成的无界阻塞TransferQueue队列。相对于其他阻
塞队列，LinkedTransferQueue多了tryTransfer和transfer方法。

1）transfer方法

如果当前有消费者正在等待接收元素（消费者使用take()方法或带时间限制的poll()方法时），transfer方法可以把生产者传入的元素立刻transfer（传输）给消费者。如果没有消费者在等待接收元素，transfer方法会将元素存放在队列的tail节点，并等到该元素被消费者消费了才返回。transfer方法的关键代码如下
```
// 第一行代码是试图把存放当前元素的s节点作为tail节点。第二行代码是让CPU自旋等待消费者消费元素。因为自旋会消耗CPU，所以自旋一定的次数后使用Thread.yield()方法来暂停当前正在执行的线程，并执行其他线程。
Node pred = tryAppend(s, haveData);
return awaitMatch(s, pred, e, (how == TIMED), nanos);
```
2）tryTransfer方法

tryTransfer方法是用来试探生产者传入的元素是否能直接传给消费者。如果没有消费者等待接收元素，则返回false。和transfer方法的区别是tryTransfer方法无论消费者是否接收，方法立即返回，而transfer方法是必须等到消费者消费了才返回。对于带有时间限制的tryTransfer（E e，long timeout，TimeUnit unit）方法，试图把生产者传入的元素直接传给消费者，但是如果没有消费者消费该元素则等待指定的时间再返回，如果超时还没消费元素，则返回false，如果在超时时间内消费了元素，则返回true。
LinkedBlockingDeque：一个由链表结构组成的双向阻塞队列。

LinkedBlockingDeque是一个由链表结构组成的双向阻塞队列。所谓双向队列指的是可以从队列的两端插入和移出元素。双向队列因为多了一个操作队列的入口，在多线程同时入队时，也就减少了一半的竞争。相比其他的阻塞队列，LinkedBlockingDeque多了addFirst、addLast、offerFirst、offerLast、peekFirst和peekLast等方法，以First单词结尾的方法，表示插入、获取（peek）或移除双端队列的第一个元素。以Last单词结尾的方法，表示插入、获取或移除双端队列的最后一个元素。另外，插入方法add等同于addLast，移除方法remove等效于removeFirst。但是take方法却等同于takeFirst，不知道是不是JDK的bug，使用时还是用带有First和Last后缀的方法更清楚。在初始化LinkedBlockingDeque时可以设置容量防止其过度膨胀。另外，双向阻塞队列可以运用在“工作窃取”模式中。

门栓和栅栏

CountDownLatch门栓

/**
 * CountDownLatch实例
 */
public class DemoCountDownLatch {

    //参赛人数 / 门闩个数
    private static final int COUNT_RUNNER = 3;

    public static void main(String[] args) throws Exception {

        // 3人参加比赛 / 创建一个有3个门闩的门
        CountDownLatch countDownLatch = new CountDownLatch(COUNT_RUNNER);

        // 创建3人跑道 / 装上门
        ExecutorService executorService = Executors.newFixedThreadPool(COUNT_RUNNER);

        for (int i = 0; i < 3; i++) {
            executorService.submit(new Runner("runner" + i, countDownLatch));
        }

        // 等待3人跑到终点 / 把3个门闩都锁上，CountDownLatch的await可以有入参（timeout, TimeUnit）表示最长等待时间;
        countDownLatch.await();

        // 公布3人成绩 / 打开门了
        System.out.println("all runner game over.");
    }

    static class Runner implements Runnable {

        private String name;

        private CountDownLatch countDownLatch;

        public Runner(String name, CountDownLatch countDownLatch) {
            this.name = name;
            this.countDownLatch = countDownLatch;
        }

        @Override
        public void run() {
            try {
                SecureRandom secureRandom = SecureRandom.getInstanceStrong();
                int runTime = Math.abs(secureRandom.nextInt()) % 10;
                TimeUnit.SECONDS.sleep(runTime);
                System.out.println(this.name + " game over cost " + runTime + " second.");
            } catch (Exception e) {
                e.printStackTrace();
            }

            // 跑到终点 / 打开门闩
            this.countDownLatch.countDown();
        }
    }
}

CyclicBarrier栅栏

CyclicBarrier是循环栅栏的的意思，循环表示同一个CyclicBarrier可以重复使用（区别于CountDownLatch），Barrier栅栏可以理解为线程相互依赖的那个点（例如前后端联调时间点），各个线程在那个点相互等待，等所有线程到达点后才继续执行；
CyclicBarrier作为循环栅栏，同一个对象可以循环使用；
上面例子中前端开发人员很短时间开发结束，通过await()一直在等待后端开发结束，可以通过await(timeout, TimeUnit)来设置最长等待时间；
可以通过CyclicBarrier的getNumberWaiting()查看到达依赖点的任务；
CyclicBarrier构造方法的第二个参数指定的任务A，在其他相互依赖的任务到达依赖点后，任务A优先执行，并且是执行结束，其他任务才继续执行；

   /**
    * 前端开发倩倩和后端开发厚厚开发一个需求
    * 两人先独自开发需求，等都开发完再一块联调功能
    */
   public class DemoCyclicBarrier
   {
       public static void main(String[] args) throws InterruptedException
       {
   
           // 创建栅栏，参数一为相互依赖的任务数；参数二为各任务到达依赖点后先执行的任务，等任务执行结束相互依赖的任务继续执行
           CyclicBarrier cyclicBarrier = new CyclicBarrier(2, () -> {
               System.out.println("准备开始联调吧...");
               lastSecond(3L);
           });
   
           // 创建线程池执行2个任务
           ExecutorService executorService = Executors.newFixedThreadPool(2);
           executorService.execute(new Coder(10L, "后端", cyclicBarrier));
           executorService.execute(new Coder(3L, "前端", cyclicBarrier));
       }
   
       /**
        * 线程持续second秒
        */
       private static void lastSecond(long second)
       {
           Instant instant = Instant.now();
           while (Instant.now().minusSeconds(second).isBefore(instant))
           {
           }
       }
   
       static class Coder implements Runnable
       {
           // 完成工作需要的时间
           private long workTime;
   
           private String name;
   
           private CyclicBarrier cyclicBarrier;
   
           public Coder(long workTime, String name, CyclicBarrier cyclicBarrier)
           {
               this.workTime = workTime;
               this.name = name;
               this.cyclicBarrier = cyclicBarrier;
           }
   
           @Override
           public void run()
           {
               try
               {
                   System.out.println(this.name + " are coding...");
                   lastSecond(this.workTime);
                   System.out.println(this.name + " code end wait debugging..");
                   // 完成工作/到达依赖的点/我这边可以开始联调了
                   this.cyclicBarrier.await();
                   System.out.println("we are debugging..");
   
               }
               catch (InterruptedException e)
               {
                   // 当前线程被中断
                   e.printStackTrace();
               }
               catch (BrokenBarrierException e)
               {
                   // 1.其他线程中断；2.其他线程await方法超时；3.cyclicBarrier重置
                   e.printStackTrace();
               }
               // catch (TimeoutException e)
               // {
               // //当前线程的await方法超时(await方法设置超时参数)
               // e.printStackTrace();
               // }
           }
       }
   }

区别
1. CountDownLatch减计数，CyclicBarrier加计数。
2. CountDownLatch是一次性的，CyclicBarrier可以重用。
3. CountDownLatch强调的是一个线程（或多个）需要等待另外的n个线程干完某件事情之后才能继续执行
4. CyclicBarrier强调的是n个线程，大家相互等待，只要有一个没完成，所有人都得等着。正如上例，只有5个人全部跑到终点，大家才能开喝，否则只能全等着。
5. 再强调下，CountDownLatch强调一个线程等多个线程完成某件事情。CyclicBarrier是多个线程互等，等大家都完成。