关于java:一文看懂Java锁机制

背景常识

指令流水线

CPU 的根本工作是执行存储的指令序列，即程序。程序的执行过程实际上是一直地取出指令、剖析指令、执行指令的过程。

简直所有的冯•诺伊曼型计算机的 CPU，其工作都能够分为 5 个阶段：取指令、指令译码、执行指令、访存取数和后果写回。

古代处理器的体系结构中，采纳了流水线的解决形式对指令进行解决。指令蕴含了很多阶段，对其进行拆解，每个阶段由专门的硬件电路、寄存器来处 理，就能够实现流水线解决。实现更高的 CPU 吞吐量，然而因为流水线解决自身的额定开销，可能会减少提早。

cpu 多级缓存

在计算机系统中，CPU 高速缓存（CPU Cache，简称缓存）是用于缩小处理器拜访内存所需均匀工夫的部件。在金字塔式存储体系中它位于自顶向下的第二层，仅次于 CPU 寄存器。其容量远小于内存，但速度却能够靠近处理器的频率。

当处理器收回内存拜访申请时，会先查看缓存内是否有申请数据。如果存在（命中），则不经拜访内存间接返回该数据；如果不存在（生效），则要先把内存中的相应数据载入缓存，再将其返回处理器。

缓存之所以无效，次要是因为程序运行时对内存的拜访出现局部性（Locality）特色。这种局部性既包含空间局部性（Spatial Locality），也包含工夫局部性（Temporal Locality）。无效利用这种局部性，缓存能够达到极高的命中率。

问题引入

原子性

原子性：即一个操作或者多个操作 要么全副执行并且执行的过程不会被任何因素打断，要么就都不执行。

示例办法：{i++（i 为实例变量）}

这样一个简略语句次要由三个操作组成：

• 读取变量 i 的值
• 进行加一操作
• 将新的值赋值给变量 i

如果对实例变量 i 的操作不做额定的管制，那么多个线程同时调用，就会呈现笼罩景象，失落局部更新。

另外，如果再思考上工作内存和主存之间的交互，可细分为以下几个操作：

• read 从主存读取到工作内存（非必须）
• load 赋值给工作内存的变量正本（非必须）
• use 工作内存变量的值传给执行引擎
• 执行引擎执行加一操作
• assign 把从执行引擎接管到的值赋给工作内存的变量
• store 把工作内存中的一个变量的值传递给主内存（非必须）
• write 把工作内存中变量的值写到主内存中的变量（非必须）

可见性

可见性：是指当多个线程拜访同一个变量时，一个线程批改了这个变量的值，其余线程可能立刻看失去批改的值

存在可见性问题的根本原因是因为缓存的存在，线程持有的是共享变量的正本，无奈感知其余线程对于共享变量的更改，导致读取的值不是最新的。

while (flag) {// 语句 1
   doSomething();// 语句 2}
flag = false;// 语句 3 

线程 1 判断 flag 标记，满足条件则执行语句 2；线程 2flag 标记置为 false，但因为可见性问题，线程 1 无奈感知，就会始终循环解决语句 2。

程序性

程序性：即程序执行的程序依照代码的先后顺序执行

因为编译重排序和指令重排序的存在，是的程序真正执行的程序不肯定是跟代码的程序统一，这种状况在多线程状况下会呈现问题。

if (inited == false) {context = loadContext();   // 语句 1
   inited = true;             // 语句 2
}
doSomethingwithconfig(context); // 语句 3 

因为语句 1 和语句 2 没有依赖性，语句 1 和语句 2 可能 并行执行 或者 语句 2 先于语句 1 执行，如果这段代码两个线程同时执行，线程 1 执行了语句 2，而语句 1 还没有执行完，这个时候线程 2 判断 inited 为 true，则执行语句 3，但因为 context 没有初始化实现，则会导致呈现未知的异样。

JMM 内存模型

Java 虚拟机标准定义了 Java 内存模型（Java Memory Model，JMM）来屏蔽各种硬件和操作系统的内存拜访差别，以实现让 Java 程序在各种平台下都能达到统一的内存拜访成果（C/C++ 等则间接应用物理机和 OS 的内存模型，使得程序须针对特定平台编写），它在多线程的状况下尤其重要。

内存划分

JMM 的次要指标是定义程序中各个变量的拜访规定，即在虚拟机中将变量存储到内存和从内存中取出变量这样的底层细节。这里的变量是指共享变量，存在竞争问题的变量，如实例字段、动态字段、数组对象元素等，不包含线程公有的局部变量、办法参数等，因为公有变量不存在竞争问题。能够认为 JMM 包含内存划分、变量拜访操作与规定两局部。

分为主内存和工作内存，每个线程都有本人的工作内存，它们共享主内存。

• 主内存（Main Memory）存储所有共享变量的值。
• 工作内存（Working Memory）存储该线程应用到的共享变量在主内存的的值的正本拷贝。

线程对共享变量的所有读写操作都在本人的工作内存中进行，不能间接读写主内存中的变量。

不同线程间也无奈间接拜访对方工作内存中的变量，线程间变量值的传递必须通过主内存实现。

这种划分与 Java 内存区域中堆、栈、办法区等的划分是不同档次的划分，两者根本没有关系。硬要分割的话，大抵上主内存对应 Java 堆中对象的实例数据局部、工作内存对应栈的局部区域；从更低层次上说，主内存对应物理硬件内存、工作内存对应寄存器和高速缓存。

内存间交互规定

对于主内存与工作内存之间的交互协定，即一个变量如何从主内存拷贝到工作内存，如何从工作内存同步到主内存中的实现细节。Java 内存模型定义了 8 种原子操作来实现：

• lock: 将一个变量标识为被一个线程独占状态
• unclock: 将一个变量从独占状态释放出来，开释后的变量才能够被其余线程锁定
• read: 将一个变量的值从主内存传输到工作内存中，以便随后的 load 操作
• load: 把 read 操作从主内存中失去的变量值放入工作内存的变量的正本中
• use: 把工作内存中的一个变量的值传给执行引擎，每当虚拟机遇到一个应用到变量的指令时都会应用该指令
• assign: 把一个从执行引擎接管到的值赋给工作内存中的变量，每当虚拟机遇到一个给变量赋值的指令时，都要应用该操作
• store: 把工作内存中的一个变量的值传递给主内存，以便随后的 write 操作
• write: 把 store 操作从工作内存中失去的变量的值写到主内存中的变量

定义原子操作的应用规定

1. 不容许一个线程无起因地（没有产生过任何 assign 操作）把数据从工作内存同步会主内存中

2. 一个新的变量只能在主内存中诞生，不容许在工作内存中间接应用一个未被初始化（load 或者 assign）的变量。即就是对一个变量施行 use 和 store 操作之前，必须先自行 assign 和 load 操作。

3. 一个变量在同一时刻只容许一条线程对其进行 lock 操作，但 lock 操作能够被同一线程反复执行屡次，屡次执行 lock 后，只有执行雷同次数的 unlock 操作，变量才会被解锁。lock 和 unlock 必须成对呈现。

4. 如果对一个变量执行 lock 操作，将会清空工作内存中此变量的值，在执行引擎应用这个变量之前须要从新执行 load 或 assign 操作初始化变量的值。

5. 如果一个变量当时没有被 lock 操作锁定，则不容许对它执行 unlock 操作；也不容许去 unlock 一个被其余线程锁定的变量。

6. 对一个变量执行 unlock 操作之前，必须先把此变量同步到主内存中（执行 store 和 write 操作）

从下面能够看出，把变量从主内存复制到工作内存须要程序执行 read、load，从工作内存同步回主内存则须要程序执行 store、write。总结：

• read、load、use 必须成对程序呈现，但不要求间断呈现。assign、store、write 同之；
• 变量诞生和初始化：变量只能从主内存“诞生”，且须先初始化后能力应用，即在 use/store 前须先 load/assign；
• lock 一个变量后会清空工作内存中该变量的值，应用前须先初始化；unlock 前须将变量同步回主内存；
• 一个变量同一时刻只能被一线程 lock，lock 几次就须 unlock 几次；未被 lock 的变量不容许被执行 unlock，一个线程不能去 unlock 其余线程 lock 的变量。

long 和 double 型变量的非凡规定

Java 内存模型要求前述 8 个操作具备原子性，但对于 64 位的数据类型 long 和 double，在模型中特地定义了一条宽松的规定：容许虚拟机将没有被 volatile 润饰的 64 位数据的读写操作划分为两次 32 位的操作来进行。即未被 volatile 润饰时线程对其的读取 read 不是原子操作，可能只读到“半个变量”值。尽管如此，商用虚拟机简直都把 64 位数据的读写实现为原子操作，因而咱们能够疏忽这个问题。

后行产生准则

Java 内存模型具备一些先天的“有序性”，即不须要通过任何同步伎俩（volatile、synchronized 等）就可能失去保障的有序性，这个通常也称为 happens-before 准则。

如果两个操作的执行秩序不合乎后行准则且无奈从 happens-before 准则推导进去，那么它们就不能保障它们的有序性，虚拟机能够随便地对它们进行重排序。

• 程序秩序规定（Program Order Rule）：一个线程内，逻辑上书写在后面的操作后行产生于书写在前面的操作。
• 锁定规定（Monitor Lock Rule）：一个 unLock 操作后行产生于前面对同一个锁的 lock 操作。“前面”指工夫上的先后顺序。
• volatile 变量规定（Volatile Variable Rule）：对一个 volatile 变量的写操作后行产生于前面对这个变量的读操作。“前面”指工夫上的先后顺序。
• 传递规定（Transitivity）：如果操作 A 后行产生于操作 B，而操作 B 又后行产生于操作 C，则能够得出操作 A 后行产生于操作 C。
• 线程启动规定（Thread Start Rule）：Thread 对象的 start()办法后行产生于此线程的每个一个动作。
• 线程中断规定（Thread Interruption Rule）：对线程 interrupt()办法的调用后行产生于被中断线程的代码检测到中断事件的产生（通过 Thread.interrupted()检测）。
• 线程终止规定（Thread Termination Rule）：线程中所有的操作都后行产生于线程的终止检测，咱们能够通过 Thread.join()办法完结、Thread.isAlive()的返回值伎俩检测到线程曾经终止执行。
• 对象终结规定（Finaizer Rule）：一个对象的初始化实现（构造函数执行完结）后行产生于他的 finalize()办法的开始。

问题解决

原子性

• 由 JMM 间接保障的原子性变量操作包含 read、load、use、assign、store、write；
• 根本数据类型的读写（工作内存）是原子性的

由 JMM 的 lock、unlock 可实现更大范畴的原子性保障，然而这是 JVM 须要实现反对的性能，对于开发者则是有由 synchronized 关键字 或者 Lock 读写锁 来保障原子性。

可见性

volatile 变量值被一个线程批改后会立刻同步回主内存、变量值被其余线程读取前立刻从主内存刷新值到工作内存。即 read、load、use 三者间断程序执行，assign、store、write 间断程序执行。

synchronized/Lock 由 lock 和 unlock 的应用规定保障

• “对一个变量执行 unlock 操作之前，必须先把此变量同步到主内存中（执行 store 和 write 操作）”。
• “ 如果对一个变量执行 lock 操作，将会清空工作内存中此变量的值，在执行引擎应用这个变量之前须要从新执行 load 或 assign 操作初始化变量的值 ”

final 润饰的字段在结构器中一旦初始化实现，且结构器没有把“this”的援用传递进来，则其余线程可立刻看到 final 字段的值。

程序性

volatile 禁止指令重排序

synchronized/Lock“一个变量在同一个时刻只容许一条线程对其执行 lock 操作”

开发篇

volatile

被 volatile 润饰的变量能保障器程序性和可见性

程序性

• 对一个 volatile 变量的写操作后行产生于前面对这个变量的读操作。“前面”指工夫上的先后顺序

可见性

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

volatile 相比于 synchronized/Lock 是十分轻量级，然而应用场景是有限度的：

• 对变量的写入操作不依赖于其以后值，即仅仅是读取和单纯的写入，比方操作实现、中断或者状态之类的标记
• 禁止对 volatile 变量操作指令的重排序

实现原理

volatile 底层是通过 cpu 提供的内存屏障指令来实现的。硬件层的内存屏障分为两种：Load Barrier 和 Store Barrier 即读屏障和写屏障。

内存屏障有两个作用：

• 阻止屏障两侧的指令重排序
• 强制把写缓冲区 / 高速缓存中的脏数据等写回主内存，让缓存中相应的数据生效

final

对于 final 域的内存语义，编译器和处理器要恪守两个重排序规定（外部实现也是应用内存屏障）：

• 写 final 域的重排序规定：在构造函数内对一个 final 域的写入，与随后把这个被结构对象的援用赋值给一个援用变量，这两个操作之间不能重排序。

• 读 final 域的重排序规定：首次读一个蕴含 final 域的对象的援用，与随后首次读这个 final 域，这两个操作之间不能重排序。

  public class FinalExample {
       int i;// 一般域
       final int j;//final 域
       static FinalExample obj;
       
       public FinalExample () {
              i = 1;// 写一般域。对一般域的写操作【可能会】被重排序到构造函数之外 
              j = 2;// 写 final 域。对 final 域的写操作【不会】被重排序到构造函数之外
       }
       
       // 写线程 A 执行
       public static void writer () {    
              obj = new FinalExample ();}
       
       // 读线程 B 执行
       public static void reader () {    
              FinalExample object = obj;// 读对象援用
              int a = object.i;// 读一般域。可能会看到后果为 0(因为 i = 1 可能被重排序到构造函数外，此时 y 还没有被初始化)
              int b = object.j;// 读 final 域。保障可能看到后果为 2
       }
  }

  首次读对象援用与首次读该对象蕴含的 final 域，这两个操作之间存在间接依赖关系。因为编译器恪守间接依赖关系，因而编译器不会重排序这两个操作。大多数处理器也会恪守间接依赖，也不会重排序这两个操作。但有多数处理器容许对存在间接依赖关系的操作做重排序（比方 alpha 处理器），这个规定就是专门用来针对这种处理器的。

对于 final 域是援用类型，写 final 域的重排序规定对编译器和处理器减少了如下束缚：

• 在构造函数内对一个 final 援用的对象的成员域的写入，与随后在构造函数外把这个被结构对象的援用赋值给一个援用变量，这两个操作之间不能重排序。

synchronized

synchronized 用于润饰一般办法、润饰静态方法、润饰代码块

• 确保代码的同步执行（即不同线程间的互斥）（原子性）
• 确保对共享变量的批改可能及时可见（可见性）
• 无效解决指令重排问题（程序性）

实现原理

应用对象的监视器 (Monitor，也有叫管程的) 进行管制

• 进入 / 加锁时执行字节码指令 MonitorEnter
• 退出 / 解锁时执行字节码指令 MonitorExit
• 当执行代码有异样退出办法 / 代码段时，会主动解锁

应用哪个对象的监视器：

• 润饰对象办法时，应用以后对象的监视器
• 润饰静态方法时，应用类类型（Class 的对象）监视器
• 润饰代码块时，应用括号中的对象的监视器
• 必须为 Object 类或其子类的对象

MonitorEnter（加锁）：

• 每个对象都有一个关联的监视器。
• 监视器被锁住，当且仅当它有属主 (Owner) 时。
• 线程执行 MonitorEnter 就是为了成为 Monitor 的属主。
• 如果 Monitor 对象的记录数 (Entry Count，领有它的线程的重入次数) 为 0，将其置为 1，线程将本人置为 Monitor 对象的属主。
• 如果 Monitor 的属主为以后线程，就会重入监视器，将其记录数增一。
• 如果 Monitor 的属主为其它线程，以后线程会阻塞，直到记录数为 0，才会 去竞争属主权。

MonitorExit（解锁）：

• 执行 MonitorExit 的线程肯定是这个对象所关联的监视器的属主。
• 线程将 Monitor 对象的记录数减一。
• 如果 Monitor 对象的记录数为 0，线程就会执行退出动作，不再是属主。
• 此时其它阻塞的线程就被容许竞争属主。

对于 MonitorEnter、MonitorExit 来说，有两个基本参数:

• 线程
• 关联监视器的对象

要害构造

在 JVM 中，对象在内存中的布局分为三块区域：对象头、实例数据、对齐填充。如下:

实例变量

• 寄存类的属性数据信息，包含父类的属性信息
• 如果是数组的实例变量，还包含数组的长度
• 这部分内存按 4 字节对齐

填充数据

• 因为虚拟机要求对象起始地址必须是 8 字节的整数倍
• 填充数据仅仅是为了字节对齐
• 保障下一个对象的起始地址为 8 的整数倍
• 长度可能为 0

对象头（Object Header）

• 对象头由 Mark Word、Class Metadata Address（类元数据地址）和 数组长度（对象为数组时）组成
• 在 32 位和 64 位的虚拟机中，Mark Word 别离占用 32 字节和 64 字节，因而称其为 word

Mark Word 存储的并非对象的 理论业务数据（如对象的字段值），属于 额定存储老本。为了节约存储空间，Mark Word 被设计为一个 非固定的数据结构，以便在尽量小的空间中存储尽量多的数据，它会依据对象的状态，变换本人的数据结构，从而复用本人的存储空间。

锁的状态共有 4 种: 无锁、偏差锁、轻量级锁、重量级锁。随着竞争的减少，锁的应用状况如下:

无锁 -> 偏差锁 -> 轻量级锁 -> 重量级锁

其中偏差锁和轻量级锁是从 JDK 6 时引入的，在 JDK 6 中默认开启。锁的降级 (锁收缩，inflate) 是单向的，只能从低到高(从左到右)。不会呈现 锁的降级。

偏差锁

当锁对象第一次被线程获取的时候，虚拟机将会把对象头中的标记位设为“01”（可偏差），即偏差模式。同时应用 CAS 操作把获取到这个锁的线程的 ID 记录在对象的 Mark Word 之中，如果 CAS 操作胜利，持有偏差锁的线程当前每次进入这个锁相干的同步块时，虚拟机都能够不再进行任何同步操作。

当有另外一个线程去尝试获取这个锁时，偏差模式就宣告完结。依据锁对象目前是否处于被锁定的状态，撤销偏差（Revoke Bias）后复原到未锁定（标记位为“01”，不可偏差）或 轻量级锁定（标记位为“00”）的状态，后续的同步操作就进入轻量级锁的流程。

轻量级锁

进入到轻量级锁阐明不止一个线程尝试获取锁，这个阶段会通过自适应自旋 CAS 形式获取锁。如果获取失败，则进行锁收缩，进入重量级锁流程，线程阻塞。

重量级锁

重量级锁是通过零碎的线程互斥锁来实现的，代价最低廉

ContentionList，CXQ，寄存最近竞争锁的线程

• LIFO，单向链表
• 很多线程都能够把申请锁的线程放入队列中
• 但只有一个线程能将线程出队
• EntryLis，示意胜者组

双向链表

• 只有领有锁的线程才能够拜访或变更 EntryLis
• 只有领有锁的线程在开释锁时，并且在 EntryList 为空、ContentionList 不为 空的状况下，能力将 ContentionList 中的线程全副出队，放入到 EntryList 中

WaitSet，寄存处于期待状态的线程

• 将进行 wait() 调用的线程放入 WaitSet
• 当进行 notify()、notifyAll()调用时，会将线程放入到 ContentionList 或 EntryList 队列中

留神：

• 对一个线程而言，在任何时候最多只处于三个汇合中的一个
• 处于这三个汇合中的线程，均为 BLOCKED 状态，底层应用互斥量来进行阻塞

当一个线程胜利获取到锁时 对象监视器的 owner 字段从 NULL 变为非空，指向此线程 必须将本人从 ContentionList 或 EntryList 中出队

竞争型的锁传递机制 线程开释锁时，不保障后继线程肯定能够取得到锁，而是后继线程去竞争锁

OnDeck，示意准备就绪的线程，保障任何时候都只有一个线程来间接竞争 锁

• 在获取锁时，如果产生竞争，则应用自旋锁来争用，如果自旋后仍得不 到，再放入上述队列中。
• 自旋能够缩小 ContentionList 和 EntryList 上出队入队的操作，也就是缩小了外部 保护的这些锁的争用。

OS 互斥锁

重量级锁是通过操作系统的线程互斥锁来实现的，在 Linux 下，锁所用的技术是 pthead_mutex_lock / pthead_mutex_unlock，即线程间的互斥锁。

线程互斥锁是基于 futex（Fast Userspace Mutex）机制实现的。惯例的操作系统的同步机制(如 IPC 等)，调用时都须要陷入到内核中执行，即便没有竞争也要执行一次陷入操作(int 0x80，trap)。而 futex 则是内核态和用户态的混合，无竞争时，获取锁和开释锁都不须要陷入内核。

初始调配

首先在内存调配 futex 共享变量，对线程而言，内存是共享的，间接调配 (malloc) 即可，为整数类型，初始值为 1。

获取锁

应用 CAS 对 futex 变量减 1，察看其后果：

• 如果由 1 变为 0，示意无竞争，继续执行
• 如果小于 0，示意有竞争，调用 futex(…, FUTEX_WAIT, …) 使以后线程休眠

开释锁

应用 CAS 给 futex 变量加 1

• 如果 futex 变量由 0 变为 1，示意无竞争，继续执行
• 如果 futex 变量变动前为负值，示意有竞争，调用 futex(…, FUTEX_WAKE, …) 唤醒一个或多个期待线程

作者：VectorJin
起源：https://juejin.cn/post/684490…