多线程中锁（synchronized、volatile）原理及锁优化的相关问题

1.synchronized的实现原理

Java中每一个对象都可以作为锁，这是synchronized实现同步的基础：

1. 普通同步方法，锁是当前实例对象
2. 静态同步方法，锁是当前类的class对象
3. 同步方法块，锁是括号里面的对象

当一个线程访问同步代码块时，它首先是需要得到锁才能执行同步代码，当退出或者抛出异常时必须要释放锁，那么它是如何来实现这个机制的呢？我们先看一段简单的代码：

public class SynchronizedTest {
    public synchronized void test1(){

    }

    public void test2(){
        synchronized (this){

        }
    }
}

利用javap工具查看生成的class文件信息来分析Synchronize的实现 ：

可以看到在同步块的入口和出口分别有monitorenter和monitorexit指令。当执行monitorenter指令时，线程试图获取锁也就是获取monitor（monitor对象，对象监视器存在于每个Java对象的对象头中，synchronized锁便是通过这种方式获取锁的，也是为什么Java中任意对象可以作为锁的原因）的持有权。当计数器为0则可以成功获取，获取后将锁计数器加1（考虑出现锁重入的情况，锁计数器大于等于1）。相应的在执行monitorexit指令后，将锁计数器自减1。当锁计数器为0时，线程释放锁。如果获取对象锁失败，那当前线程就要阻塞等待，直到锁被另外一个线程释放为止。

synchronized方法则会被翻译成普通的方法调用和返回指令如:invokevirtual、areturn指令，在VM字节码层面并没有任何特别的指令来实现被synchronized修饰的方法，而是在Class文件的方法表中将该方法的access_flags字段中的synchronized标志位置1，表示该方法是同步方法并使用调用该方法的对象或该方法所属的Class在JVM的内部对象表示Klass做为锁对象。

下面我们来继续分析，但是在深入之前我们需要了解两个重要的概念：Java对象头，Monitor（对象监视器）。

Java对象头

synchronized用的锁是存在Java对象头里的，那么什么是Java对象头呢？Hotspot虚拟机的对象头主要包括两部分数据：Mark Word（标记字段）、Klass Pointer（类型指针）。其中Klass Point是是对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例，Mark Word用于存储对象自身的运行时数据，它是实现轻量级锁和偏向锁的关键，所以下面将重点阐述Mark Word。

Mark Word用于存储对象自身的运行时数据，如哈希码（HashCode）、GC分代年龄、锁状态标志、线程持有的锁、偏向线程 ID、偏向时间戳等等。Java对象头一般占有两个机器码（在32位虚拟机中，1个机器码等于4字节，也就是32bit），但是如果对象是数组类型，则需要三个机器码，因为JVM虚拟机可以通过Java对象的元数据信息确定Java对象的大小，但是无法从数组的元数据来确认数组的大小，所以用一块来记录数组长度。

对象头信息是与对象自身定义的数据无关的额外存储成本，但是考虑到虚拟机的空间效率，Mark Word被设计成一个非固定的数据结构以便在极小的空间内存存储尽量多的数据，它会根据对象的状态复用自己的存储空间，也就是说，Mark Word会随着程序的运行发生变化，变化状态如下（32位虚拟机）：

Monitor（监视器）

我们可以把它理解为一个同步工具，也可以描述为一种同步机制，它通常被描述为一个对象。所有的 Java 对象都是天生的 Monitor，在 Java 的设计中 ，每一个 Java 对象都带了一把看不见的锁，它叫做内置锁或者 Monitor 锁。

这里我们主要分析一下重量级锁也就是通常说 synchronized 的对象锁，锁标识位为 10，其中指针指向的是 monitor 对象（也称为管程或监视器锁）的起始地址。每个对象都存在着一个 monitor 与之关联，对象与其 monitor 之间的关系存在多种实现方式，如 monitor 可以与对象一起创建销毁或当线程试图获取对象锁时自动生成，但当一个 monitor 被某个线程持有后，它便处于锁定状态。在 Java 虚拟机(HotSpot)中，monitor 是由 ObjectMonitor（对象监视器） 实现的，其主要数据结构如下：（位于 HotSpot 虚拟机源码 ObjectMonitor.cpp 文件，C++实现）

ObjectMonitor() {
    _header       = NULL;
    _count        = 0;          // 记录个数
    _waiters      = 0,
    _recursions   = 0;
    _object       = NULL;
    _owner        = NULL;
    _WaitSet      = NULL;       // 处于 wait 状态的线程，会被加入到 _WaitSet
    _WaitSetLock  = 0;
    _Responsible  = NULL;
    _succ         = NULL;
    _cxq          = NULL;
    FreeNext      = NULL;
    _EntryList    = NULL;       // 处于等待锁 block 状态的线程，会被加入到该列表
    _SpinFreq     = 0;
    _SpinClock    = 0;
    OwnerIsThread = 0;
}

ObjectMonitor 中有两个队列，_WaitSet 和 _EntryList，用来保存 ObjectWaiter 对象列表( 每个等待锁的线程都会被封装成 ObjectWaiter 对象)，_owner 指向持有 ObjectMonitor 对象的线程，当多个线程同时访问一段同步代码时，首先会进入 _EntryList 集合，当线程获取到对象的 monitor 后会把 monitor 中的 _owner 变量设置为当前线程，同时 monitor 中的计数器 _count 加 1（考虑锁重入）。若线程调用 wait() 方法，将释放当前持有的 monitor，_owner 变量恢复为 null，_count 自减 1，同时该线程进入 _WaitSet 集合中等待被唤醒。若当前线程执行完毕也将释放 monitor（锁）并复位变量的值，以便其它线程进入获取 monitor(锁)。

由此看来，monitor 对象存在于每个 Java 对象的对象头中(存储的是指针)，synchronized 便是通过这种方式获取锁的，也是为什么 Java 中任意对象可以作为锁的原因，同时也是 notify/notifyAll/wait 等方法存在于顶级对象 Object 中的原因（锁可以是任意对象，所以可以被任意对象调用的方法是定义在 object 类中）。

Monitor机制
Monitor的机制如下图：

结合上图来分析Object的Monitor机制。

Monitor可以类比为一个特殊的房间，这个房间中有一些被保护的数据，Monitor保证每次只能有一个线程能进入这个房间进行访问被保护的数据，进入房间即为持有Monitor，退出房间即为释放Monitor。

当一个线程需要访问受保护的数据（即需要获取对象的Monitor）时，它会首先在entry-set入口队列中排队（这里并不是真正的按照排队顺序），如果没有其他线程正在持有对象的Monitor，那么它会和entry-set队列和wait-set队列中的被唤醒的其他线程进行竞争（即通过CPU调度），选出一个线程来获取对象的Monitor，执行受保护的代码段，执行完毕后释放Monitor，如果已经有线程持有对象的Monitor，那么需要等待其释放Monitor后再进行竞争。

再说一下wait-set队列。当一个线程拥有Monitor后，经过某些条件的判断（比如用户取钱发现账户没钱），这个时候需要调用Object的wait方法，线程就释放了Monitor，进入wait-set队列，等待Object的notify方法（比如用户向账户里面存钱）。当该对象调用了notify方法或者notifyAll方法后，wait-set中的线程就会被唤醒，然后在wait-set队列中被唤醒的线程和entry-set队列中的线程一起通过CPU调度来竞争对象的Monitor，最终只有一个线程能获取对象的Monitor。

需要注意的是：
当一个线程在wait-set中被唤醒后，并不一定会立刻获取Monitor，它需要和其他线程去竞争
如果一个线程是从wait-set队列中唤醒后，获取到的Monitor，它会去读取它自己保存的PC计数器中的地址，从它调用wait方法的地方开始执行。

synchronized方法底层原理补充

在 Java 早期版本中，synchronized 属于重量级锁，效率低下，因为监视器锁（monitor）是依赖于底层操作系统的 Mutex Lock 来实现的，而操作系统实现线程之间的切换时需要从用户态转换到核心态，这个状态之间的转换需要相对比较长的时间，时间成本相对较高，这也是为什么早期的 synchronized 效率低的原因。庆幸的是在 Java 6 之后 Java 官方从 JVM 层面对 synchronized 进行了较大优化，所以现在的 synchronized 锁效率也优化得很不错了。Java 6 之后，为了减少获得锁和释放锁所带来的性能消耗，引入了轻量级锁和偏向锁，关于锁优化的内容，我们稍后再谈。

synchronized代码块底层原理

当执行 monitorenter 指令时，当前线程将试图获取对象锁所对应的 monitor 的持有权，当对象锁的 monitor 的进入计数器为 0，那线程可以成功取得 monitor，并将计数器值设置为 1，取锁成功。如果当前线程已经拥有对象锁的 monitor 的持有权，那它可以重入这个 monitor，重入时计数器的值会加 1。倘若其他线程已经拥有对象锁的 monitor 的所有权，那当前线程将被阻塞，直到正在执行的线程执行完毕，即 monitorexit 指令被执行，执行线程将释放 monitor 并设置计数器值为 0，其他线程将有机会持有 monitor。值得注意的是编译器将会确保无论方法通过何种方式完成，方法中调用过的每条 monitorenter 指令都有执行其对应 monitorexit 指令，无论这个方法是正常结束还是异常结束。为了保证在方法异常完成时 monitorenter 和 monitorexit 指令依然可以正确配对执行，编译器会自动产生一个异常处理器，这个异常处理器可处理所有的异常，它的目的就是用来执行 monitorexit 指令。从字节码中也可以看出多了一个 monitorexit 指令。

2.锁膨胀

在 Java 早期版本中，synchronized 属于重量级锁，效率低下，因为监视器锁（monitor）是依赖于底层操作系统的 Mutex Lock 来实现的，而操作系统实现线程之间的切换时需要从用户态转换到核心态，这个状态之间的转换需要相对比较长的时间，时间成本相对较高，这也是为什么早期的 synchronized 效率低的原因。

jdk1.6对锁的实现引入了大量的优化，如自旋锁、适应性自旋锁、锁消除、锁粗化、偏向锁、轻量级锁等技术来减少锁操作的开销。 锁主要存在四中状态，依次是：无锁状态、偏向锁状态、轻量级锁状态、重量级锁状态，他们会随着竞争的激烈而逐渐升级。注意锁可以升级不可降级，这种策略是为了提高获得锁和释放锁的效率。

自旋锁

研究表明，大多数情况下，线程持有锁的时间都不会太长，如果直接挂起操作系统层面的线程可能会得不偿失，毕竟操作系统实现线程之间的切换时需要从用户态转换到核心态，这个状态之间的转换需要相对比较长的时间，时间成本相对较高。自旋锁会假设在不久将来，当前的线程可以获得锁，因此虚拟机会让当前想要获取锁的线程做几个空循环，使当前线程不放弃处理器的执行时间(这也是称为自旋的原因)，在经过若干次循环后，如果得到锁，就顺利进入临界区。

但是自旋不能代替阻塞，首先，自旋锁需要多处理器或一个处理器拥有多个核心的 CPU 环境，这样才能保证两个及以上的线程并行执行（一个是获取锁的执行线程，一个是进行自旋的线程）。除了对处理器数量的要求外，自旋虽然避免了线程切换的开销，但它是要占用处理器时间的，因此，如果锁被占用的时间比较短，自旋的效果就比较好，否则只是白白占用了 CPU 资源，带来性能上的浪费。

那么自旋就需要有一定的限度，如果自旋超过了一定的次数后，还没有成功获取锁，就只能进行挂起了，这个次数默认是 10。

在 JDK 1.4.2 中引入了自旋锁，在 JDK 1.6 中引入了自适应自旋锁。自适应意味自旋的时间不再固定：

如果同一个锁对象上，自旋等待刚刚成功获取锁，并且持有锁的线程正在运行，那么虚拟机就会认为此次自旋也很有可能成功，进而它将允许自旋等待持续相对更长的时间，比如 100 个循环。如果对于某个锁，自旋很少成功获取过，那么在以后获取这个锁时将可能自动省略掉自旋过程，以避免浪费处理器资源。有了自适应自旋，随着程序运行和性能监控信息的不断完善，虚拟机对程序锁的状况预测就会越来越精准，虚拟机也就会越来越“聪明”。

锁消除

消除锁是虚拟机另外一种锁的优化，这种优化更彻底，Java 虚拟机在 JIT 编译时(关于 JIT 编译可以参考我的这篇博客：JVM–解析运行期优化与JIT编译器)，通过对运行上下文的扫描，去除不可能存在共享资源竞争的锁，通过这种方式消除没有必要的锁，可以节省毫无意义的请求锁时间。

锁消除的主要判定依据来源于逃逸分析技术的支持(关于逃逸分析技术可以参考周志明老师所出的《深入理解 Java 虚拟机》一书中第 11 章内容或自行百度)。

也许你会有疑惑，变量是否逃逸，程序员本身应该就可以判断，怎么会存在明知道不存在数据争用的情况下还使用同步？来看如下代码

public String concatString(String s1, String s2, String s3) {
    return s1 + s2 + s3;
}

由于 String 是一个不可变类，因此对字符串的连接操作总是通过新生成的 String 对象来进行的，在 JDK 1.5 之前，javac 编译器会对 String 连接进行自动优化，将连接转换为 StringBuffer 对象的连续 append 操作，在 JDK 1.5 之后，会转化为 StringBuilder 对象的连续 append 操作。也就是说，上述代码经过 javac 优化之后，有可能变为下面这样：

public String concatString(String s1, String s2, String s3) {
    StringBuffer sb = new StringBuffer();
    sb.append(s1);
    sb.append(s2);
    sb.append(s3);

    return sb.toString();
}

StringBuffer 是一个线程安全的类，在它的 append 方法中有一个同步块，锁对象就是 sb，但是虚拟机观察变量 sb，发现它是一个局部变量，本身线程安全，并不需要额外的同步机制。因此，这里虽然有锁，但可以被安全的清除，在 JIT 编译之后，这段代码就会忽略掉所有的同步而直接执行。这就是锁消除。

锁粗化

原则上，我们在使用同步块的时候，总是建议将同步块的作用范围限制的尽量小—使需要同步的操作数量尽可能变小，在存在锁竞争的情况下，等待锁的线程可以尽快的拿到锁。

大部分情况下，上述原则都正确，但是存在特殊情况，如果一系列操作下来，都对同一个对象反复加锁与解锁，甚至加锁与解锁操作出现在循环体中，那即使没有线程竞争，频繁的进行互斥同步操作也会导致不必要的性能损耗。

如上述代码中的 append 方法。如果虚拟机探测到了这样的操作，就会把加锁的同步范围扩展（粗化）到整个操作序列的外部。以上述代码为例，就是扩展到第一个 append 操作之前直至最后一个 append 操作之后，这样只需要加锁一次。

偏向锁

偏向锁会偏向第一个获取它的线程，如果在接下来的执行过程中，该锁没有被其他线程获取，则持有偏向锁的线程将永远不需要进行同步。

HotSpot 的作者经过以往的研究发现大多数情况下锁不仅不存在多线程竞争，而且总是由同一线程多次获得（比如在单线程中使用 StringBuffer 类），为了让线程获得锁的代价更低而引入了偏向锁。当锁对象第一次被线程获取的时候，虚拟机把对象头中的标志位设为“01”，即偏向模式。同时使用 CAS 操作把获取这个锁的线程 ID 记录在对象的 Mark Word 中，如果 CAS 操作成功，持有偏向锁的线程以后每次进入这个锁相关的同步块时，虚拟机都可以不用进行任何同步操作。

引入偏向锁是为了在无多线程竞争的情况下尽量减少不必要的轻量级锁执行路径，因为轻量级锁的获取及释放依赖多次CAS原子指令，而偏向锁只需要在置换ThreadID的时候依赖一次CAS原子指令（由于一旦出现多线程竞争的情况就必须撤销偏向锁，所以偏向锁的撤销操作的性能损耗必须小于节省下来的CAS原子指令的性能消耗）。

偏向锁逻辑

1.线程A第一次访问同步块时，先检测对象头Mark Word中的标志位是否为01，依此判断此时对象锁是否处于无所状态或者偏向锁状态（匿名偏向锁）；

2.然后判断偏向锁标志位是否为1，如果不是，则进入轻量级锁逻辑（使用CAS竞争锁），如果是，则进入下一步流程；

3.判断是偏向锁时，检查对象头Mark Word中记录的Thread Id是否是当前线程ID，如果是，则表明当前线程已经获得对象锁，以后该线程进入同步块时，不需要CAS进行加锁，只会往当前线程的栈中添加一条Displaced Mark Word为空的Lock Record中，用来统计重入的次数（如图为当对象所处于偏向锁时，当前线程重入3次，线程栈帧中Lock Record记录）。

退出同步块释放偏向锁时，则依次删除对应Lock Record，但是不会修改对象头中的Thread Id；

注：偏向锁撤销是指在获取偏向锁的过程中因不满足条件导致要将锁对象改为非偏向锁状态，而偏向锁释放是指退出同步块时的过程。

4.如果对象头Mark Word中Thread Id不是当前线程ID，则进行CAS操作，企图将当前线程ID替换进Mark Word。如果当前对象锁状态处于匿名偏向锁状态（可偏向未锁定），则会替换成功（将Mark Word中的Thread id由匿名0改成当前线程ID，在当前线程栈中找到内存地址最高的可用Lock Record，将线程ID存入），获取到锁，执行同步代码块（仅线程是第一个获取该对象锁时，此时对象锁时“匿名偏向锁”状态，CAS可以成功，线程ID写入对象头Mark Word。而当对象锁被锁定后，即使偏向锁释放，Mark Word中Thread Id也不会修改，上个线程的ID仍在，故之后想要获取对象锁（对象锁已不是“匿名偏向锁”）的线程在进行CAS操作替换Thread ID时会失败。）；

• 匿名偏向(Anonymously biased)
  在此状态下thread_ptr为NULL(0)，意味着还没有线程偏向于这个锁对象。第一个试图获取该锁的线程将会面临这个情况，使用原子CAS指令可将该锁对象绑定于当前线程。这是允许偏向锁的类对象的初始状态。
• 可重偏向(Rebiasable)
  在此状态下，偏向锁的epoch字段是无效的(与锁对象对应的klass的mark_prototype的epoch值不匹配)。下一个试图获取锁对象的线程将会面临这个情况，使用原子CAS指令可将该锁对象绑定于当前线程。在批量重偏向的操作中，未被持有的锁对象都被至于这个状态，以便允许被快速重偏向。
• 已偏向(Biased)
  这种状态下，thread ptr非空，且epoch为有效值——意味着其他线程正在只有这个锁对象。

5.如果对象锁已经被其他线程占用，则会替换失败，开始进行偏向锁撤销，这也是偏向锁的特点，一旦出现线程竞争，就会撤销偏向锁；

6.偏向锁的撤销需要等待全局安全点（safe point，代表了一个状态，在该状态下所有线程都是暂停的）,暂停持有偏向锁的线程，检查持有偏向锁的线程状态（遍历当前JVM的所有线程，如果能找到，则说明偏向的线程还存活），如果线程还存活，则检查线程是否在执行同步代码块中的代码，如果是，则升级为轻量级锁，进行CAS竞争锁；

注：每次进入同步块（即执行monitorenter）的时候都会以从高往低的顺序在栈中找到第一个可用的Lock Record，并设置偏向线程ID；每次解锁（即执行monitorexit）的时候都会从最低的一个Lock Record移除。所以如果能找到对应的Lock Record说明偏向的线程还在执行同步代码块中的代码。

7.如果持有偏向锁的线程未存活，或者持有偏向锁的线程未在执行同步代码块中的代码，则进行校验是否允许重偏向，如果不允许重偏向，则撤销偏向锁，将Mark Word设置为无锁状态（未锁定不可偏向状态），然后升级为轻量级锁，进行CAS竞争锁；

8.如果允许重偏向，设置为匿名偏向锁状态,CAS将偏向锁重新指向线程A（在对象头和线程栈帧的锁记录中存储当前线程ID）；

9.唤醒暂停的线程，从安全点继续执行代码。

轻量级锁

引入轻量级锁的主要目的是在多没有多线程竞争的前提下，减少传统的重量级锁使用操作系统互斥量产生的性能消耗。当关闭偏向锁功能或者多个线程竞争偏向锁导致偏向锁升级为轻量级锁（上述6、7点），则会尝试获取轻量级锁。

轻量级锁加锁：线程在执行同步块之前，如果同步对象没有被锁定，JVM 会先在当前线程的栈桢中创建用于存储锁记录（Lock Record）的空间，并将对象头中的 Mark Word 复制到锁记录中，官方称为 Displaced Mark Word。然后线程尝试使用 CAS 将对象头中的 Mark Word 替换为指向锁记录的指针。如果成功，当前线程获得锁，如果失败，虚拟机首先会检查对象的Mark Word是否指向当前线程的栈帧，如果是就说明当前线程已经拥有了这个对象的锁，那就可以直接进入同步块继续执行。否则说明多个线程竞争锁，轻量级锁就要膨胀为重量级锁，锁标志的状态值变为“10”，Mark Word中存储的就是指向重量级锁（互斥量）的指针，后面等待锁的线程也要进入阻塞状态。 而当前线程便尝试使用自旋来获取锁，自旋就是为了不让线程阻塞，而采用循环去获取锁的过程。

释放锁
轻量级锁的释放也是通过CAS操作来进行的，主要步骤如下：

1. 取出在获取轻量级锁保存在Displaced Mark Word中的数据；
2. 用CAS操作将取出的数据替换当前对象的Mark Word中，如果成功，则说明释放锁成功，否则执行（3）；
3. 如果CAS操作替换失败，说明有其他线程尝试获取该锁，则需要在释放锁的同时需要唤醒被挂起的线程（为什么要环形被挂起的线程？难道是为了让所有线程竞争重量级锁？但这种解释与下图流程不符）。

下图是两个线程同时争夺锁，导致锁膨胀的流程图（为简单起见，初始状态为无锁状态）：

3.volatile的实现原理

从CPU缓存讲起

CPU缓存的出现主要是为了解决CPU运算速度与内存读写速度不匹配的矛盾，因为CPU运算速度要比内存读写速度快得多，举个例子：

• 一次主内存的访问通常在几十到几百个时钟周期
• 一次L1高速缓存的读写只需要1~2个时钟周期
• 一次L2高速缓存的读写也只需要数十个时钟周期

这种访问速度的显著差异，导致CPU可能会花费很长时间等待数据到来或把数据写入内存。基于此，现在CPU大多数情况下读写都不会直接访问内存（CPU都没有连接到内存的管脚），取而代之的是CPU缓存，CPU缓存是位于CPU与内存之间的临时存储器，它的容量比内存小得多但是交换速度却比内存快得多。而缓存中的数据是内存中的一小部分数据，但这一小部分是短时间内CPU即将访问的，当CPU调用大量数据时，就可先从缓存中读取，从而加快读取速度。

按照读取顺序与CPU结合的紧密程度，CPU缓存可分为：

1. 一级缓存：简称L1 Cache，位于CPU内核的旁边，是与CPU结合最为紧密的CPU缓存。
2. 二级缓存：简称L2 Cache，分内部和外部两种芯片，内部芯片二级缓存运行速度与主频相同，外部芯片二级缓存运行速度则只有主频的一半。
3. 三级缓存：简称L3 Cache，部分高端CPU才有。

每一级缓存中所存储的数据全部都是下一级缓存中的一部分，这三种缓存的技术难度和制造成本是相对递减的，所以其容量也相对递增。

当CPU要读取一个数据时，首先从一级缓存中查找，如果没有再从二级缓存中查找，如果还是没有再从三级缓存中或内存中查找。一般来说每级缓存的命中率大概都有80%左右，也就是说全部数据量的80%都可以在一级缓存中找到，只剩下20%的总数据量才需要从二级缓存、三级缓存或内存中读取。

使用CPU缓存带来的问题

用一张图表示一下 CPU –> CPU缓存 –> 主内存 数据读取之间的关系：

当系统运行时，CPU执行计算的过程如下：

1. 程序以及数据被加载到主内存
2. 指令和数据被加载到CPU缓存
3. CPU执行指令，把结果写到高速缓存
4. 高速缓存中的数据写回主内存
5. 如果服务器是单核CPU，那么这些步骤不会有任何的问题，但是如果服务器是多核CPU，那么问题来了，以Intel Core i7处理器的高速缓存概念模型为例（图片来自《深入理解计算机系统》）：

试想下面一种情况：

1. 核0读取了一个字节，根据局部性原理，它相邻的字节同样被被读入核0的缓存
2. 核3做了上面同样的工作，这样核0与核3的缓存拥有同样的数据
3. 核0修改了那个字节，被修改后，那个字节被写回核0的缓存，但是该信息并没有写回主存
4. 核3访问该字节，由于核0并未将数据写回主存，数据不同步
   为了解决这一问题，CPU制造商规定了一个缓存一致性协议。

缓存一致性协议

每个CPU都有一级缓存，但是，我们却无法保证每个CPU的一级缓存数据都是一样的。 所以同一个程序，CPU进行切换的时候，切换前和切换后的数据可能会有不一致的情况。那么这个就是一个很大的问题了。 如何保证各个CPU缓存中的数据是一致的。就是CPU的缓存一致性问题。

总线锁

一种处理一致性问题的办法是使用Bus Locking（总线锁）。当一个CPU对其缓存中的数据进行操作的时候，往总线中发送一个Lock信号。 这个时候，所有CPU收到这个信号之后就不操作自己缓存中的对应数据了，当操作结束，释放锁以后，所有的CPU就去内存中获取最新数据更新。

但是用锁的方式总是避不开性能问题。总线锁总是会导致CPU的性能下降。所以出现另外一种维护CPU缓存一致性的方式，MESI。

MESI

MESI是保持一致性的协议。它的方法是在CPU缓存中保存一个标记位，这个标记位有四种状态:

• M: Modify，修改缓存，当前CPU的缓存已经被修改了，即与内存中数据已经不一致了；
• E: Exclusive，独占缓存，当前CPU的缓存和内存中数据保持一致，而且其他处理器并没有可使用的缓存数据；
• S: Share，共享缓存，和内存保持一致的一份拷贝，多组缓存可以同时拥有针对同一内存地址的共享缓存段；
• I: Invalid，失效缓存，这个说明CPU中的缓存已经不能使用了。

CPU的读取遵循下面几点

• 如果缓存状态是I，那么就从内存中读取，否则就从缓存中直接读取。
• 如果缓存处于M或E的CPU读取到其他CPU有读操作，就把自己的缓存写入到内存中，并将自己的状态设置为S。
• 只有缓存状态是M或E的时候，CPU才可以修改缓存中的数据，修改后，缓存状态变为M。

这样，每个CPU都遵循上面的方式则CPU的效率就提高上来了。

其实每个线程的工作内存就是CPU缓存，每个线程在不同的CPU缓存，与主内存交换数据。有volatile修饰的共享变量进行写操作时会多出第二行汇编代码，该句代码的意思是对原值加零，其中相加指令addl前有lock修饰。通过查IA-32架构软件开发者手册可知，lock前缀的指令在多核处理器下会引发两件事情：

1、将当前处理器缓存行的数据写回到系统内存。

Lock前缀指令导致在执行指令期间，声言处理器的LOCK# 信号。在多处理器环境中，LOCK# 信号确保在声言该信号期间，处理器可以独占任何共享内存（因为它会锁住总线，导致其他CPU不能访问总线，也就不能访问系统内存，在Intel486和Pentium处理器中都是这种策略）。但是，在最近的处理器里，LOCK# 信号一般不锁总线，而是锁缓存，因为锁总线开销的比较大。在P6和目前的处理器中，如果访问的内存区域已经缓存在处理器内部，则不会声言LOCK# 信号。相反，它会锁定这块区域的缓存并回写到内存，并使用缓存一致性机制来确保修改的原子性，此操作被称为“缓存锁定”，缓存一致性机制会阻止同时修改由两个以上的处理器缓存的内存区域数据。

2、这个写回内存的操作会使在其他CPU里缓存了该内存地址的数据无效。

IA-32处理器和Intel 64处理器使用MESI控制协议去维护内部缓存和其他处理器缓存的一致性。在多核处理器系统中进行操作的时候，IA-32和Intel 64处理器能嗅探其他处理器访问系统内存和它们的内部缓存。处理器使用嗅探技术保证它的内部缓存、系统内存和其他处理器的缓存的数据在总线上保持一致。例如，在Pentium和P6 family处理器中，如果通过嗅探一个处理器来检测其他处理器打算写内存地址，而这个地址当前处于共享状态，那么正在嗅探的处理器将使它的缓存行无效，在下次访问相同内存地址时，强行执行缓存行填充。

参考：

https://blog.csdn.net/chenssy/article/details/54883355
https://blog.csdn.net/championhengyi/article/details/80105718
https://blog.csdn.net/weixin_36759405/article/details/83034386
https://www.cnblogs.com/dsj2016/p/5714921.html
https://baijiahao.baidu.com/s?id=1630535202760061296&wfr=spider&for=pc