并发编程进阶

文章目录

并发编程进阶
一、JMM
- 1. JMM的定义：
- 2. 内存屏障：
三. volatile
四. as-if-serial
五. happens-before
六. 缓存一致性（Cache coherence）
7. Synchronized
- 1. synchronized 的使用
- 2. synchronized底层原理
8. ConcurrentHashMap
9. CountDownLatch
10. CyclicBarrier 同步屏障
11. Semaphore 信号量
11. Exchange 交换者
12. ThreadLocal

一、JMM

JMM属于整个Java并发编程中最难也是最重要的部分（Java读线程通信模型-共享内存模型），可以从三个反面分析：

Java 层面。
JVM 层面。
硬件层面。

并行（parallel）：

指在同一时刻，有多条指令在多个处理器上同时执行了。所以无论从微观还是从宏观来看，二者都是一起执行的。

并发（concurrency）:

指在同一时刻只能有一条指令执行。但多个进程指令被快速的轮换执行。使得在宏观上具有多个进程同时执行的效果，但在微观上并不是同时执行的，只是把时间分成若干段，使多个进程快速交替的执行。

并发三大特性： 并发编程Bug的源头：可见性、原子性和有序性问题

可见性：当一个线程修改了共享变量的值，其他线程能够看到修改的值。Java 内存模型是通过在变量修改后将新值同步回主内存，在变量读取前从主内存刷新变量值这种依赖主内存作为传递媒介
的方法来实现可见性的。如何保证可见性：
- 通过 volatile 关键字保证可见性。
- 通过内存屏障保证可见性。
- 通过 synchronized 关键字保证可见性。
- 通过 Lock保证可见性。
- 通过 final 关键字保证可见性。
- 如何保证可见性：
  - jvm 层面的 storeLoad 内存屏障。
  - 上下文切换（上下文切换耗时，导致本地内存变量淘汰，重新加载主内存）。如 Thread.yield()；
- 导致不可见性分析图：
  - 通过 read 从主内存中拿到 flag = true.
  - 通过 load 将 flag = true 加载到线程 Thread A 的本地内存中。生成 flag = true 的一个副本。
  - 通过 use 供 CUP 去使用该变量执行代码。
  - 同样的通过read读取主内存的 flag = true。
  - 通过 load 加载到线程 Thread B 的本地内存，并生产副本。
  - 通过 use 供 CUP 去使用该变量执行代码。
  - 通过 assign 将修改后的 flag = false 保存到本地内存。
  - 通过 write 将flag = false 写入主内存中。
  - 但是 Thread A 里面的 flag 读取得到的是本地内存 flag = true（因为while 一直在用 flag，在变量在本地内存中的值没有被淘汰，所以没有重新去主内存去读取最新的值）。从而造成了数据可见性问题。

在这里插入图片描述

有序性：即程序执行的顺序按照代码的先后顺序执行。JVM 存在指令重排，所以存在有序性问题。如何保证有序性：
- 通过 volatile 关键字保证有序性。
- 通过内存屏障保证有序性。
- 通过 synchronized关键字保证有序性。
- 通过 Lock保证有序性。
原子性：一个或多个操作，要么全部执行且在执行过程中不被任何因素打断，要么全部不执行。在Java 中，对基本数据类型的变量的读取和赋值操作是原子性操作（64位处理器）。不采取任何的原子性保障措施的自增操作并不是原子性的。如何保证原子性：
- 通过 synchronized 关键字保证原子性。
- 通过 Lock保证原子性。
- 通过 CAS保证原子性。

什么时候刷主内存，线程执行结束刷回主内存吗，还是一旦更新完之后就立马刷主内存？

线程执行结束会刷，但更新完后不会立即刷，和硬件有关。

本地内存什么时候会没有？

被淘汰后会没有，比如说一定时间内没有使用了，会被淘汰掉。
調用 Thread.yield（）会进行上下文切换，释放时间片，并保存上下文，工作内存失效（上下文切换大约5ms，而工作内存保存时间约为1ms）。重新被CUP调度后，会重新从主内存中加载上下文。

内存交互操作： 关于主内存与工作内存之间的具体交互协议，即一个变量如何从主内存拷贝到工作内存、如何从工作内存同步到主内存之间的实现细节，Java内存模型定义了以下八种操作来完成：

lock（锁定）：作用于主内存的变量，把一个变量标识为一条线程独占状态。
unlock（解锁）：作用于主内存变量，把一个处于锁定状态的变量释放出来，释放后的变量才可以被其他线程锁定。
read（读取）：作用于主内存变量，把一个变量值从主内存传输到线程的工作内存中，以便随后的load动作使用。
load（载入）：作用于工作内存的变量，它把read操作从主内存中得到的变量值放入工作内存的变量副本中。
use（使用）：作用于工作内存的变量，把工作内存中的一个变量值传递给执行引擎，每当虚拟机遇到一个需要使用变量的值的字节码指令时将会执行这个操作。
assign（赋值）：作用于工作内存的变量，它把一个从执行引擎接收到的值赋值给工作内存的变量，每当虚拟机遇到一个给变量赋值的字节码指令时执行这个操作。
store（存储）：作用于工作内存的变量，把工作内存中的一个变量的值传送到主内存中，以便随后的write的操作。
write（写入）：作用于主内存的变量，它把store操作从工作内存中一个变量的值传送到主内存的变量中。

Java内存模型还规定了在执行上述八种基本操作时，必须满足如下规则：

如果要把一个变量从主内存中复制到工作内存，就需要按顺寻地执行read和load操作，如果把变量从工作内存中同步回主内存中，就要按顺序地执行store和write操作。但Java内存模型只要求上述操作必须按顺序执行，而没有保证必须是连续执行。
不允许read和load、store和write操作之一单独出现。
不允许一个线程丢弃它的最近assign的操作，即变量在工作内存中改变了之后必须同步到主内存中。
不允许一个线程无原因地（没有发生过任何assign操作）把数据从工作内存同步回主内存中。
一个新的变量只能在主内存中诞生，不允许在工作内存中直接使用一个未被初始化（load或assign）的变量。即就是对一个变量实施use和store操作之前，必须先执行过了assign和load操作。
一个变量在同一时刻只允许一条线程对其进行lock操作，但lock操作可以被同一条线程重复执行多次，多次执行lock后，只有执行相同次数的unlock操作，变量才会被解锁。lock和unlock必须成对出现。
如果对一个变量执行lock操作，将会清空工作内存中此变量的值，在执行引擎使用这个变量前需要重新执行load或assign操作初始化变量的值
如果一个变量事先没有被lock操作锁定，则不允许对它执行unlock操作；也不允许去unlock一
个被其他线程锁定的变量。
对一个变量执行unlock操作之前，必须先把此变量同步到主内存中（执行store和write操作）。

1. JMM的定义：

Java 虚拟机规范中定义了Java内存模型（Java Memory Model ，JMM），用于屏蔽掉各种硬件和操作系统的内存访问差异，以实现让Java程序在各种平台下都能达到一致的并发效果，JMM 规范了 Java 虚拟机与计算机内存是如何协同工作的：规定了一个线程如何何时可以看到由其他线程修改后的共享变量的值，以及在必须时如何同步的访问共享变量。JMM描述的是一种抽象的概念，一组规则，通过这组规则控制程序中各个变量在共享数据区域和私有数据区域的访问方式，JMM是围绕原子性、有序性、可见性展开的。
不同硬件实现内存屏障的方式不同，Java内存模型屏蔽了这种底层硬件平台的差异，由JVM来为不同的平台生成相应的机器码。

2. 内存屏障：

什么是内存屏障？

现在大多数现代计算机为了提高性能而采取乱序执行，这可能会导致程序运行不符合我们预期，内存屏障就是一类同步屏障指令，是CPU或者编译器在对内存随机访问的操作中的一个同步点，只有在此点之前的所有读写操作都执行后才可以执行此点之后的操作。
内存屏障存在的意义就是为了解决程序在运行过程中出现的内存乱序访问问题，内存乱序访问行为出现的理由是为了提高程序运行时的性能，Memory Bariier能够让CPU或编译器在内存访问上有序。

JVM层面的内存屏障： 在JSR规范中定义了4种内存屏障：

LoadLoad屏障：（指令Load1; LoadLoad; Load2），在Load2及后续读取操作要读取的数据被访问前，保证Load1要读取的数据被读取完毕。
LoadStore屏障：（指令Load1; LoadStore; Store2），在Store2及后续写入操作被刷出前，保证Load1要读取的数据被读取完毕。
StoreStore屏障：（指令Store1; StoreStore; Store2），在Store2及后续写入操作执行前，保证Store1的写入操作对其它处理器可见。
StoreLoad屏障：（指令Store1; StoreLoad; Load2），在Load2及后续所有读取操作执行前，保证 Store1的写入对所有处理器可见。它的开销是四种屏障中最大的。在大多数处理器的实现中，这个屏障是
个万能屏障，兼具其它三种内存屏障的功能。

三. volatile

volatile的特性:

可见性：对一个volatile变量的读，总是能看到（任意线程）对这个volatile变量最后的写入。
有序性：对volatile修饰的变量的读写操作前后加上各种特定的内存屏障来禁止指令重排序来保障有序性。

volatile写-读的内存语义:

当写一个volatile变量时，JMM会把该线程对应的本地内存中的共享变量值刷新到主内存。
当读一个volatile变量时，JMM会把该线程对应的本地内存置为无效，线程接下来将从主内存中读取共享变量。

volatile可见性实现原理:

JMM内存交互层面实现：volatile修饰的变量的read、load、use操作和assign、store、write必须是连续的，即修改后必须立
即同步回主内存，使用时必须从主内存刷新，由此保证volatile变量操作对多线程的可见性。

指令重排序：

Java语言规范规定JVM线程内部维持顺序化语义。即只要程序的最终结果与它顺序化情况的结果相等，那么指令的执行顺序可以与代码顺序不一致，此过程叫指令的重排序。
指令重排序的意义：JVM能根据处理器特性（CPU多级缓存系统、多核处理器等）适当的对机器指令进行重排序，使机器指令能更符合CPU的执行特性，最大限度的发挥机器性能。

JMM内存屏障插入策略

在每个volatile写操作的前面插入一个StoreStore屏障。
在每个volatile写操作的后面插入一个StoreLoad屏障。
在每个volatile读操作的后面插入一个LoadLoad屏障。
在每个volatile读操作的后面插入一个LoadStore屏障。

四. as-if-serial

不管怎么重排序（编译器和处理器为了提高并行度），（单线程）程序的执行结果不能被改变。编译器、runtime和处理器都必须遵守as-if-serial语义。

五. happens-before

从JDK 5 开始，JMM使用happens-before的概念来阐述多线程之间的内存可见性。在JMM中，如果一个操作执行的结果需要对另一个操作可见，那么这两个操作之间必须存在happens-before关系。
happens-before原则非常重要，它是判断数据是否存在竞争、线程是否安全的主要依据，依靠这个原则，我们解决在并发环境下两操作之间是否可能存在冲突的所有问题。

happens-before原则定义如下：

如果一个操作happens-before另一个操作，那么第一个操作的执行结果将对第二个操作可见，而且第一个操作的执行顺序排在第二个操作之前。
两个操作之间存在happens-before关系，并不意味着一定要按照happens-before原则制定的顺序来执行。如果重排序之后的执行结果与按照happens-before关系来执行的结果一致，那么这种重排序并不非法。
happens-before原则是JMM中非常重要的原则，它是判断数据是否存在竞争、线程是否安全的主要依据，保证了多线程环境下的可见性。

六. 缓存一致性（Cache coherence）

在这里插入图片描述

计算机体系结构中，缓存一致性是共享资源数据的一致性，这些数据最终存储在多个本地缓存中。当系统中的客户机维护公共内存资源的缓存时，可能会出现数据不一致的问题，这在多处理系统中的cpu中尤其如此。
在共享内存多处理器系统中，每个处理器都有一个单独的缓存内存，共享数据可能有多个副本:一个副本在主内存中，一个副本在请求它的每个处理器的本地缓存中。当数据的一个副本发生更改时，其他副本必须反映该更改。缓存一致性是确保共享操作数(数据)值的变化能够及时地在整个系统中传播的规程。

缓存一致性的要求：

写传播（Write Propagation）：对任何缓存中的数据的更改都必须传播到对等缓存中的其他副本(该缓存行的副本)。
- 事务串行化（Transaction Serialization）：对单个内存位置的读/写必须被所有处理器以相同的顺序看到。理论上，一致性可以在加载/存储粒度上执行。然而，在实践中，它通常在缓存块的粒度上执行。
一致性机制（Coherence mechanisms）确保一致性的两种最常见的机制是窥探机制（snooping ）和基于目录的机制（directorybased），这两种机制各有优缺点。如果有足够的带宽可用，基于协议的窥探往往会更快，因为所有事务都是所有处理器看到的请求/响应。其缺点是窥探是不可扩展的。每个请求都必须广播到系统中的所有节点，这意味着随着系统变大，(逻辑或物理)总线的大小及其提供的带宽也必须增加。另一方面，目录往往有更长的延迟(3跳请求/转发/响应)，但使用更少的带宽，因为消息是点对点的，而不是广播的。由于这个原因，许多较大的系统(>64处理器)使用这种类型的缓存一致性。

一致性协议（Coherence protocol）：

一致性协议在多处理器系统中应用于高速缓存一致性。为了保持一致性，人们设计了各种模型和协议，如MSI、MESI(又名Illinois)、MOSI、MOESI、MERSI、MESIF、write-once、Synapse、Berkeley、Firefly和Dragon协议。

MESI协议：

MESI协议是一个基于写失效的缓存一致性协议，是支持回写（write-back）缓存的最常用协议。也称作伊利诺伊协议 (Illinois protocol，因为是在伊利诺伊大学厄巴纳-香槟分校被发明的)。与写通过（write through）缓存相比，回写缓冲能节约大量带宽。总是有“脏”（dirty）状态表示缓存中的数据与主存中不同。MESI协议要求在缓存不命中（miss）且数据块在另一个缓存时，允许缓存到缓存的数据复制。与MSI协议相比，MESI协议减少了主存的事务数量。这极大改善了性能。
缓存行有4种不同的状态:
- 已修改Modified (M)：缓存行是脏的（dirty），与主存的值不同。如果别的CPU内核要读主存这块数据，该缓存行必须回写到主存，状态变为共享(S)。
- 独占Exclusive (E)：缓存行只在当前缓存中，但是干净的–缓存数据同于主存数据。当别的缓存读取它时，状态变为共享；当前写数据时，变为已修改状态。
- 共享Shared (S)：缓存行也存在于其它缓存中且是未修改的。缓存行可以在任意时刻抛弃。
- 无效Invalid (I)：缓存行是无效的。

伪共享的问题：

如果多个核的线程在操作同一个缓存行中的不同变量数据，那么就会出现频繁的缓存失效，即使在代码层面看这两个线程操作的数据之间完全没有关系。这种不合理的资源竞争情况就是伪共享（False Sharing）。

避免伪共享方案：
- 缓存行填充：
2.使用 @sun.misc.Contended 注解（java8），注意需要配置jvm参数：-XX:-RestrictContended。

7. Synchronized

1. synchronized 的使用

synchronized 同步块是 Java 提供的一种原子性内置锁，Java 中的每个对象都可以把它当作
一个同步锁来使用，这些 Java 内置的使用者看不到的锁被称为内置锁，也叫作监视器锁。

2. synchronized底层原理

synchronized是JVM内置锁，基于Monitor机制实现，依赖底层操作系统的互斥原语Mutex（互斥量）（需要从用户态切换成内核态），它是一个重量级锁，性能较低。当然，JVM内置锁在1.5之后版本做了重大的优化，如锁粗化（Lock Coarsening）、锁消除（Lock Elimination）、轻量级锁（LightweightLocking）、偏向锁（Biased Locking）、自适应自旋（Adaptive Spinning）等技术来减少锁操作的开销，内置锁的并发性能已经基本与Lock持平。
Java虚拟机通过一个同步结构支持方法和方法中的指令序列的同步：monitor。
同步方法是通过方法中的access_flags中设置ACC_SYNCHRONIZED标志来实现；
同步代码块是通过monitorenter和monitorexit来实现。两个指令的执行是JVM通过调用操作系统的互斥原语mutex来实现，被阻塞的线程会被挂起、等待重新调度，会导致“用户态和内核态”两个态之间来回切换，对性能有较大影响。

Monitor：

Monitor，直译为“监视器”，而操作系统领域一般翻译为“管程”。管程是指管理共享变量以及对共享变量操作的过程，让它们支持并发。在Java 1.5之前，Java语言提供的唯一并发语言就是管程，Java 1.5之后提供的SDK并发包也是以管程为基础的。除了Java之外，C/C++、C#等高级语言也都是支持管程的。synchronized关键字和wait()、notify()、notifyAll()这三个方法是Java中实现管程技术的组成部分。

MESA模型：

在管程的发展史上，先后出现过三种不同的管程模型，分别是Hasen模型、Hoare模型和MESA模型。现在正在广泛使用的是MESA模型。下面我们便介绍MESA模型：
管程中引入了条件变量的概念，而且每个条件变量都对应有一个等待队列。条件变量和等待队列的作用是解决线程之间的同步问题。
执行了wait方法的线程会进入条件变量等待队列。

Java语言的内置管程synchronized：

Java 参考了 MESA 模型，语言内置的管程（synchronized）对 MESA 模型进行了精简。MESA模型中，条件变量可以有多个，Java 语言内置的管程里只有一个条件变量。模型如下图所示。

Monitor机制在Java中的实现
java.lang.Object 类定义了 wait()，notify()，notifyAll() 方法，这些方法的具体实现，依赖于 ObjectMonitor 实现，这是 JVM 内部基于 C++ 实现的一套机制。

ObjectMonitor其主要数据结构如下（hotspot源码ObjectMonitor.hpp）：

ObjectMonitor() {
2 _header = NULL; //对象头 markOop
3 _count = 0;
4 _waiters = 0,
5 _recursions = 0; // 锁的重入次数
6 _object = NULL; //存储锁对象
7 _owner = NULL; // 标识拥有该monitor的线程（当前获取锁的线程）
8 _WaitSet = NULL; // 等待线程（调用wait）组成的双向循环链表，_WaitSet是第一个节点
9 _WaitSetLock = 0 ;
10 _Responsible = NULL ;
11 _succ = NULL ;
12 _cxq = NULL ; //多线程竞争锁会先存到这个单向链表中 （FILO栈结构）
13 FreeNext = NULL ;
14 _EntryList = NULL ; //存放在进入或重新进入时被阻塞(blocked)的线程 (也是存竞争锁失
败的线程)
15 _SpinFreq = 0 ;
16 _SpinClock = 0 ;
17 OwnerIsThread = 0 ;
18 _previous_owner_tid = 0;
19 }

几个关键具体作用：

_header：用于表示监视器的状态。_header 中存储的是一个整型变量，用于表示监视器的状态，具体信息如下。
- 如果 _header 的值为 0，表示该监视器没有被锁定，可以被任意线程锁定。
- 如果 _header 的值大于 0，表示该监视器已经被锁定，值为锁定线程的线程 ID。
- 如果 _header 的值小于 0，表示该监视器已经被锁定，值为等待线程的数量的相反数。
- 总之：通过对 _header 的读写操作，可以实现对象的同步。 当一个线程想要锁定对象时，它会首先读取对象的 _header 字段，如果 _header 的值为 0，则将其值设置为线程 ID，表示锁定成功；如果 _header 的值不为 0，则将线程加入到等待队列中，等待其他线程释放锁。当一个线程释放锁时，它会将 _header 的值设置为 0，并且唤醒等待队列中的线程，让它们竞争锁。 总之，ObjectMonitor 类的作用是实现对象的监视器，用于实现对象的同步。 通过对 _header 字段的读写操作，实现了对象的锁定和释放，保证了多个线程对同一个对象的访问的互斥性和顺序性。
_object：在 ObjectMonitor 类中的作用是用于存储被监视的对象的引用。在对象的同步过程中，ObjectMonitor 会对被监视的对象进行加锁和解锁操作，因此需要保存对象的引用。具体来说，当一个线程想要对某个对象进行加锁时，它会首先获取该对象关联的 ObjectMonitor 对象，并将该对象的引用存储在 ObjectMonitor 的 _object 字段中。然后，该线程会对 ObjectMonitor 对象进行加锁操作，从而实现对对象的加锁。当一个线程释放对象的锁时，它会解锁 ObjectMonitor 对象，并将 _object 字段设置为 null，表示该 ObjectMonitor 对象不再与任何对象相关联。因此，_object 字段在 ObjectMonitor 中的作用是用于保存被监视的对象的引用，用于实现对象的同步。
_owner：用于存储当前持有锁的线程对象的引用。在对象的同步过程中，如果一个线程已经对该对象进行了加锁操作，那么它就持有该对象的锁，此时 _owner 字段就会记录该线程对象的引用。当其他线程想要对该对象进行加锁时，就需要判断 _owner 字段中记录的线程对象是否与当前线程相同，如果不同，则需要等待该线程释放锁后才能进行加锁操作。当一个线程释放锁时，它会将 _owner 字段设置为 null，表示当前没有任何线程持有该对象的锁。因此，_owner 字段在 ObjectMonitor 中的作用是用于记录当前持有锁的线程对象的引用，用于实现对象的同步。
_WaitSet：用于记录等待该对象锁的线程的等待集合。当一个线程想要对某个对象进行加锁时，如果该对象已经被其他线程持有锁，则该线程就需要进入等待状态，等待锁的释放。此时，该线程会被加入到 _WaitSet 中，表示它正在等待该对象的锁。当该对象的锁被释放时，ObjectMonitor 会从 _WaitSet 中选择一个线程唤醒，使其重新进入就绪状态，继续执行。_WaitSet 字段是一个双向链表，用于存储等待该对象锁的线程。每个线程都有一个 WaitNode 对象与之对应，用于表示该线程在等待该对象的锁。WaitNode 包含了与等待线程相关的信息，如等待线程的状态、等待时间等。通过 WaitNode，ObjectMonitor 可以方便地管理等待集合中的线程，实现线程的唤醒和等待。因此，_WaitSet 字段在 ObjectMonitor 中的作用是用于记录等待该对象锁的线程的等待集合，用于实现对象的同步。
- 如果调用了Java中的wait（）方法，会通过Java Native Interface（JNI）本地方法调用在JVM层用C++实现的ObjectMonitor对象的中wait方法，会释放当前持有的monitor，并将owner变量重置为NULL，且count减1,同时该线程会进入到_WaitSet集合中等待被唤醒。大致源码如下：这里的加入阻塞队列，就是加入到_WaitSet的双端队列中，且用的尾差法。有两个指正分别指向头结点和尾结点，分别对应ObjectMonitor对象的中的即_waitSet 和 _waitSetTail 字段。调用wait方法会释放锁以及cpu资源。
- 为什么差用尾差发呢，这样可以保证等待时间越久的线程能够优先唤醒，防止饥饿（即最早的线程越得不到执行），因为调用notify是先唤醒头结点的（hotSpotVM是这样的，可能虚拟机不同，会有不同实现），调用notifyAll也是从头开始遍历的，知道队列为空。
```
void ObjectMonitor::wait() {
  ...
  // 将当前线程加入等待队列
  _WaitSet->enqueue(this, Self->_thread);
  // 释放对象锁
  Self->_current_pending_monitor = nullptr;
  Self->exit();
  // 阻塞当前线程
  os::PlatformEventWaitState wait_event;
  wait_event.Wait();
  ...
}
```
_cxq ：是一个阻塞队列（单向链表），线程被唤醒后根据决策判读是放入cxq还是EntryList;
_EntryList：集合中存放的是没有抢到锁，而被阻塞的线程。
count ：用于记录线程获取锁的次数，成功获取到锁后count会加1，释放锁时count减1。
在获取锁时，是将当前线程插入到cxq的头部，而释放锁时，默认策略（QMode=0）是：如果EntryList为空，则将 cxq中的元素按原有顺序插入到EntryList，并唤醒第一个线程，也就是当EntryList为空时，是后来的线程先获取锁。_EntryList不为空，直接从_EntryList中唤醒线程。
这里先打个疑问，具体是什么样的策略，如何判断是放入_cxq还是_EntryList。

偏向锁：

经研究发现，在大多数情况下锁不仅不存在多线程竞争关系，而且大多数情况都是被同一线程多次获得。因此，为了减少同一线程获取锁的代价而引入了偏向锁的概念。
偏向锁的核心思想是，如果一个线程获得了锁，那么锁就进入偏向模式，此时Mark Word的结构也变为偏向锁结构，即将对象头中Mark Word的第30bit的值改为1，并且在Mark Word中记录该线程的ID。当这个线程再次请求锁时，无需再做任何同步操作，即可获取锁的过程，这样就省去了大量有关锁申请的操作，从而也就提升了程序的性能。所以，对于没有锁竞争的场合，偏向锁有很好的优化效果，毕竟极有可能连续多次是同一个线程申请相同的锁。
但是，对于锁竞争比较激烈的情况，偏向锁就有问题了。因为每次申请锁的都可能是不同线程。这种情况使用偏向锁就会得不偿失，此时就会升级为轻量级锁。

轻量级锁

轻量级锁优化性能的依据是对于大部分的锁，在整个同步生命周期内都不存在竞争。当升级为轻量级锁之后，MarkWord的结构也会随之变为轻量级锁结构。JVM会利用CAS尝试把对象原本的Mark Word 更新为Lock Record的指针，成功就说明加锁成功，改变锁标志位为00，然后执行相关同步操作。
轻量级锁所适应的场景是线程交替执行同步块的场合，如果存在同一时间访问同一锁的场合，就会导致轻量级锁就会失效，进而膨胀为重量级锁。

自旋锁

轻量级锁失败后，虚拟机为了避免线程真实地在操作系统层面挂起，还会进行一项称为自旋锁的优化手段。
自旋锁是基于在大多数情况下，线程持有锁的时间都不会太长。如果直接挂起操作系统层面的线程可能会得不偿失，毕竟操作系统实现线程之间的切换时需要从用户态转换到核心态，这个状态之间的转换需要相对比较长的时间，时间成本相对较高，因此自旋锁会假设在不久将来，当前的线程可以获得锁，因此虚拟机会让当前想要获取锁的线程做几个空循环(这也是称为自旋的原因)，不断的尝试获取锁。空循环一般不会执行太多次，可能是50个循环或100循环，在经过若干次循环后，如果得到锁，就顺利进入同步代码。如果还不能获得锁，那就会将线程在操作系统层面挂起，即进入到重量级锁。
这就是自旋锁的优化方式，这种方式确实也是可以提升效率的。

synchronized锁升级过程：

在了解了jdk1.6引入的这几种锁之后，我们来详细的看一下synchronized是怎么一步步进行锁升级的。
当没有被当成锁时，这就是一个普通的对象，Mark Word记录对象的HashCode，锁标志位是01，是否偏向锁那一位是0;
当对象被当做同步锁并有一个线程A抢到了锁时，锁标志位还是01，但是否偏向锁那一位改成1，前23bit记录抢到锁的线程id，表示进入偏向锁状态;
当线程A再次试图来获得锁时，JVM发现同步锁对象的标志位是01，是否偏向锁是1，也就是偏向状态，Mark Word中记录的线程id就是线程A自己的id，表示线程A已经获得了这个偏向锁，可以执行同步中的代码;
当线程B试图获得这个锁时，JVM发现同步锁处于偏向状态，但是Mark Word中的线程id记录的不是B，那么线程B会先用CAS操作试图获得锁，这里的获得锁操作是有可能成功的，因为线程A一般不会自动释放偏向锁。如果抢锁成功，就把Mark Word里的线程id改为线程B的id，代表线程B获得了这个偏向锁，可以执行同步代码。如果抢锁失败，则继续执行步骤5;
偏向锁状态抢锁失败，代表当前锁有一定的竞争，偏向锁将升级为轻量级锁。JVM会在当前线程的线程栈中开辟一块单独的空间，里面保存指向对象锁Mark Word的指针，同时在对象锁Mark Word中保存指向这片空间的指针。上述两个保存操作都是CAS操作，如果保存成功，代表线程抢到了同步锁，就把Mark Word中的锁标志位改成00，可以执行同步代码。如果保存失败，表示抢锁失败，竞争太激烈，继续执行步骤6;
轻量级锁抢锁失败，JVM会使用自旋锁，自旋锁不是一个锁状态，只是代表不断的重试，尝试抢锁。从JDK1.7开始，自旋锁默认启用，自旋次数由JVM决定。如果抢锁成功则执行同步代码，如果失败则继续执行步骤7;
自旋锁重试之后如果抢锁依然失败，同步锁会升级至重量级锁，锁标志位改为10。在这个状态下，未抢到锁的线程都会被阻塞。

8. ConcurrentHashMap

9. CountDownLatch

CountDownLatch 允许一个或多个线程等待其他线程完成操作。
场景分析：我们需要解析一个 Excel里多个 sheet 的数据，此时可以考虑使用多线程，每个线程解析一个sheet里的数据，等到所有的sheet都解析完之后，程序需要提示解析完成。在这个需求里，主线程需要等待所有线程完成 sheet 的解析操作，最见到的操作就是 join（）方法。其原理是不停的检查 join 线程是否存活，如果 join 线程存活则让当前线程永远等待。直到线程中止后，线程的 this.notifyAll() 方法会被调用，调用notifyAll（）方法是在 JVM 里实现的。

CountDownLatch 也可以实现更多的功能，并且比 join 的功能更多。代码如下

package com.jj;

import java.util.concurrent.CountDownLatch;

public class CountDownLatchTest {

    private static CountDownLatch c = new CountDownLatch(2);

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

        new Thread(() -> {
            System.out.println(1);
            c.countDown();
            System.out.println(2);
            c.countDown();
        }).start();

        c.await();
        System.out.println(3);
    }

}

打印结果：
CountDownLatch 接收一个 int 类型的参数作为计数器。当我们调用 countDown 方法时，N就会减1，CountDownLatch 的 await() 方法会阻塞当前线程，直到 N 变成 0。await 方法也可以指定等待时间，防止等待时间过长。awat（long time，TimeUtil unit），这个方法等待特定时间后，就会不在阻塞当前线程了。
计数器必须大于等于0，等于0 表示不阻塞。CountDownLatch 不可重新初始化可就该计数器。

10. CyclicBarrier 同步屏障

CyclicBarrier 让一组线程到达一个屏障（也可以叫同步点）时被阻塞，知道最后一个线程到达屏障是，屏障才会打开，所有被屏障拦截的线程才会继续执行。

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

package com.jj;

import java.util.concurrent.CyclicBarrier;

public class CyclicBarrierTest {

    private static CyclicBarrier c = new CyclicBarrier(2);

    public static void main(String[] args){

        new Thread(() -> {
            try {
                c.await();
            } catch (Exception e) {
                e.printStackTrace();
            }
            System.out.println(1);
        }).start();


        new Thread(() -> {
            try {
                c.await();
            } catch (Exception e) {
                e.printStackTrace();
            }
            System.out.println(2);
        }).start();
    }
}

因为主线程和子线程的调度由CPU决定的，两个线程都有可能先执行，所以会产生两个输出 1,2或2,1。
如果 new CyclicBarrier(3) 设置为3，则不会输出内容，一直阻塞下去。
CyclicBarrier 还提供了更高级的构造函数 CyclicBarrier( int parties, Runnable barrier-Action),用于线程达到屏障时，优先执行 barrierAction。

应用场景：CyclicBarrier 可以用于多线程计算数据，最后合并计算结果的场景。例如：一个 Excel 保存了用户所有银行的流水，每个 Sheet 保存一个账户近一年的每笔银行流水，现在需要统计用户的日均银行流水，都执行完之后，得到每个 sheet 的日均银行流水，最后，再用 barrierAction 用这些线程的计算结果，计算出整个 Excel 的日均银行流水。代码如下：

package com.jj.usercenter;

import java.util.Map;
import java.util.concurrent.*;

public class BankWaterService implements Runnable {

    /**
     * 创建 4 个屏障，处理完之后执行当前类的run方法。
     */
    private CyclicBarrier c = new CyclicBarrier(4,this);

    /**
     * 假设只有4个sheet，所以只启动4个线程
     */
    private Executor executor = Executors.newFixedThreadPool(4);

    /**
     * 保存每个sheet计算出的银行流水结果
     */
    private ConcurrentHashMap<String,Integer> sheetBankWaterCount = new ConcurrentHashMap<>();


    private void count(){
        for (int i = 0;i < 4;i ++){
            executor.execute(() -> {
                //计算当前 sheet 的银行数据，计算代码省略
                sheetBankWaterCount.put(Thread.currentThread().getName(),1);
                //计算完成，插入一个屏障
                try {
                    c.await();
                } catch (Exception e) {
                    e.printStackTrace();
                }
            });
        }
    }

    @Override
    public void run() {

        int result = 0;
        //汇总每个 sheet 计算出的结果
        for (Map.Entry<String, Integer> stringIntegerEntry : sheetBankWaterCount.entrySet()) {
            result += stringIntegerEntry.getValue();
        }
        //将结果输出
        sheetBankWaterCount.put("result",result);
        System.out.println(result);
    }


    public static void main(String[] args){
        BankWaterService bankWaterService = new BankWaterService();
        bankWaterService.count();
    }
}

CyclicBarrier 与 CountDownLatch 的区别：

CountDownLatch 计数器只能用一次，而 CyclicBarrier 的计数器可以使用 reset（）方法重置。所以 CyclicBarrier 能处理更加负责的业务。
CyclicBarrier 还提供了其他有用的方法，比如 getNumberWaiting 方法可以获得 CyclicBarrier 阻塞的线程数量。isBroken（）方法用来了解阻塞的线程是否被中断。

11. Semaphore 信号量

用来控制同时访问特定资源的线程数量，它通过协调各个线程，以保证隔离的使用公共资源。

应用场景：可以用于做流量控制，特别是公用资源有限的应用场景，比如数据库连接。加入有一个需求，要读取几万个文件的数据，应为都是IO密集型任务，我们可以启动几个线程并发读取，但是如果读到内存后，还需要存储到数据库中，而数据库的连接数只有10个，这是我们必须控制只有10个线程同时获取数据连接保存数据，否则会报错无法获取到数据库连接，这个时候，可以用 Semaphore 来做流量控制。

package com.jj.usercenter;

import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.Semaphore;

public class SemaphoreTest {

    private static final int THREAD_COUNT = 30;

    private static ExecutorService executor = Executors.newFixedThreadPool(THREAD_COUNT);

    private static Semaphore s = new Semaphore(10);

    public static void main(String[] args){
        for (int i = 0; i < THREAD_COUNT; i++) {
            executor.execute(() -> {
                try {
                	//获取锁
                    s.acquire();
                    System.out.println("save data");
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }finally {
                	//释放锁
                    s.release();
                }

            });
        }
        executor.shutdown();
    }
}

11. Exchange 交换者

是一个用于线程间写作的工具类，进行线程之间的数据交换。它提供一个同步点，在这个同步点，连个线程可以交换彼此的数据，这两个线程通过 exchange 方法交换数据，如果第一个先执行 exchange（），他会一直等待第二个线程也执行 exchange 方法，当两个线程都达到同步点时，这两个线程都可以交换数据，将本线程生产出来的数据传递给对方。

应用场景：可以用于校验工作，比如我们需要将纸质银行流水通过人工的方式录入成电子银行流水，为了避免错误，采用AB岗两人进行录入，录入到Excel之后，系统需要加载这两个 Excel，并对两个 Excel 数据进行校对，看看是否录入一致。

package com.jj.usercenter;

import java.util.concurrent.Exchanger;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;

public class ExchangeTest {

    private static final Exchanger<String> ex = new Exchanger<>();

    private static ExecutorService excutor = Executors.newFixedThreadPool(2);

    public static void main(String[] args){

        excutor.execute(() -> {
            //A 录入银行流水数据
            String A = "银行流水A";
            try {
                ex.exchange(A);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        });

        excutor.execute(() -> {
            //A 录入银行流水数据
            String B = "银行流水A";
            try {
                String A = ex.exchange(B);
                System.out.println("A与B是否录入一致:" + A.equals(B));
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        });
    }
}