一文看懂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原则推导出来，那么它们就不能保证它们的有序性，虚拟机能够随意地对它们进行重排序。

1. 程序次序规则（Program Order Rule）：一个线程内，逻辑上书写在前面的操做先行发生于书写在后面的操做。
2. 锁定规则（Monitor Lock Rule）：一个unLock操做先行发生于后面对同一个锁的lock操做。“后面”指时间上的前后顺序。
3. volatile变量规则（Volatile Variable Rule）：对一个volatile变量的写操做先行发生于后面对这个变量的读操做。“后面”指时间上的前后顺序。
4. 传递规则（Transitivity）：若是操做A先行发生于操做B，而操做B又先行发生于操做C，则能够得出操做A先行发生于操做C。
5. 线程启动规则（Thread Start Rule）：Thread对象的start()方法先行发生于此线程的每一个一个动做。
6. 线程中断规则（Thread Interruption Rule）：对线程interrupt()方法的调用先行发生于被中断线程的代码检测到中断事件的发生（经过Thread.interrupted()检测）。
7. 线程终止规则（Thread Termination Rule）：线程中全部的操做都先行发生于线程的终止检测，咱们能够经过Thread.join()方法结束、Thread.isAlive()的返回值手段检测到线程已经终止执行。
8. 对象终结规则（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上出队入队的操做，也就是减小了内部 维护的这些锁的争用。

Lock

另写一篇专门讲解AQS的锁机制的文章，期待