背景常识

指令流水线

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...