CAS指令与MESI缓存一致性协议

CAS指令与非阻塞算法

最新推荐文章于 2025-09-07 11:13:12 发布

转载最新推荐文章于 2025-09-07 11:13:12 发布 · 3.3k 阅读

文章标签：

#算法 #jdk #数据结构 #float #cache #java

J2SE 专栏收录该内容

56 篇文章

订阅专栏

CAS指令作为并行程序设计的基础，通过比较并交换内存地址的内容实现数据同步。本文探讨了CAS指令的工作原理，包括它如何利用Intel CPU上的CMPXCHG指令，并介绍了缓存一致性协议（如MESI）在多核环境中确保数据一致性的关键作用。

CAS（Compare-And-Swap）指令是并行程序设计最基础的基石，随着越来越多的本本都用上了双核，这个世界已经快速步入并行计算时代，CAS指令发挥的作用也就越来越大。CAS指令，在Intel CPU上称为CMPXCHG，的作用是将指定内存地址的内容与所给的某个值相比，如果相等，则将其内容替换为所给的另一个值，这一系列操作是原子的，不可能被中断。基本上所有的同步机制，与信号量、Java中的synchronized等的实现最终都要用到CAS指令，即使锁无关的数据结构也离不开CAS指令。

关于CAS指令最著名的传闻是CAS需要锁总线，因此CAS指令不但慢而且会严重影响系统并发度，即使没有冲突是也一样。不过在较新的CPU中（对于Intel CPU来说是486之后），事实并非如此。目前的CPU一般都采用了很好的缓存一致性协议，在很多情况下能够防止锁总线的发生，这其中最著名的就是Intel CPU中使用的MESI缓存一致性协议。

先来说说缓存一致性问题。为了提高数据访问效率，每个CPU上都有一个容量很小（现在一般是1M这个数量级），速度很快的缓存，用于缓存最常访问的那些数据。由于操作内存的速度实在太慢，数据被修改时也只更新缓存，并不直接写出到内存中去，这一来就造成了缓存中的数据与内存不一致。如果系统中只有一个CPU，所有线程看到的都是缓存中的最新数据，当然没问题。但如果系统中有多个CPU，同一份内存可能会被缓存到多个CPU中，如果在不同CPU中运行的不同线程看到同一份内存的缓存值不一样就麻烦了，因此有必要维护这多种缓存的一致性。当然要做到这一点只要一有修改操作，就通知所有CPU更新缓存，或者放弃缓存下次访问的时候再重新从内存中读取。但这会Stupid的实现显然不会有好的性能，为解决这一问题，产生了很多维护缓存一致性的协议，MESI就是其中一种。

MESI协议的名称由来是指这一协议为缓存的每个数据单位（称为cache line，在Intel CPU上一般是64字节）维护两个状态位，使得每个数据单位可能处于M、E、S或I这四种状态之一。各种状态含义如下：

M: 被修改的。处于这一状态的数据只在本CPU中有缓存，且其数据已被修改，没有更新到内存中
E: 独占的。处于这一状态的数据只在本CPU中有缓存，且其数据没有被修改，与内存一致
S: 共享的。处于这一状态的数据在多个CPU中有缓存
I: 无效的。本CPU中的这份缓存已经无效了。

当CPU要读取数据时，只要缓存的状态不是I都可以从缓存中读，否则就要从主存中读。这一读操作可能会被某个处于M或E状态的CPU截获，该CPU将修改的数据写出到内存，并将自己设为S状态后这一读操作才继续进行。只有缓存状态是E或M时，CPU才可以修改其中的数据，修改后缓存即处于M状态。如果CPU要修改数据时发现其缓存不处于E或M状态，则需要发出特殊的RFO指令（Read For Ownership），将其它CPU的缓存设为I状态。

因此，如果一个变量在某段时间内只被一个线程频繁修改，则对应的缓存早就处于M状态，这时CAS操作就不会涉及到总线操作。所以频繁的加锁并不一定会影响系统并发度，关键是看锁冲突的情况严重不严重，如果经常出现冲突，即缓存一会被这个CPU独占，一会被那个CPU独占，这时才会不断产生RFO，影响到并发性能。

CPU原语-比较并交换(CompareAndSet),实现非阻塞算法

　　什么是CAS?

　　cas是现代CPU提供给并发程序使用的原语操作. 不同的CPU有不同的使用规范.

　　在 Intel 处理器中，比较并交换通过指令的 cmpxchg 系列实现。

　　PowerPC 处理器有一对名为“加载并保留”和“条件存储”的指令，它们实现相同的目地；

　　MIPS 与 PowerPC 处理器相似，除了第一个指令称为“加载链接”。

　　CAS 操作包含三个操作数 —— 内存位置（V）、预期原值（A）和新值(B)

　　什么是非阻塞算法?

　　一个线程的失败或挂起不应该影响其他线程的失败或挂起.这类算法称之为非阻塞(nonblocking)算法

　　对比阻塞算法:

　　如果有一类并发操作, 其中一个线程优先得到对象监视器的锁, 当其他线程到达同步边界时, 就会被阻塞.

　　直到前一个线程释放掉锁后, 才可以继续竞争对象锁.(当然,这里的竞争也可是公平的, 按先来后到的次序)

　　CAS 原理:

　　我认为位置 V 应该包含值 A；如果包含该值，则将 B 放到这个位置；否则，不要更改该位置，只告诉我这个位置现在的值即可。

　　CAS使用示例(jdk 1.5 并发包 AtomicInteger类分析

　　/** 　　* Atomically sets to the given value and returns the old value. 　　* 　　* @param newValue the new value 　　* @return the previous value 　　*/ public final int getAndSet(int newValue) { 　　for (;;) { 　　int current = get(); 　　if (compareAndSet(current, newValue)) 　　return current; 　　} 　　} 　　public final boolean compareAndSet(int expect, int update) { 　　return unsafe.compareAndSwapInt(this, valueOffset, expect, update); 　　}

　　这个方法是, AtomicInteger类的常用方法, 作用是, 将变量设置为指定值, 并返回设置前的值.

　　它利用了cpu原语compareAndSet来保障值的唯一性.

　　另, AtomicInteger类中, 其他的实用方法, 也是基于同样的实现方式.

　　比如 getAndIncrement, getAndDecrement, getAndAdd等等.

　　CAS语义上存在的"ABA 问题"

　　什么是ABA问题?

　　假设, 第一次读取V地址的A值, 然后通过CAS来判断V地址的值是否仍旧为A, 如果是, 就将B的值写入V地址,覆盖A值.

　　但是, 语义上, 有一个漏洞, 当第一次读取V的A值, 此时, 内存V的值变为B值, 然后在未执行CAS前, 又变回了A值.

　　此时, CAS再执行时, 会判断其正确的, 并进行赋值.

　　这种判断值的方式来断定内存是否被修改过, 针对某些问题, 是不适用的.

　　为了解决这种问题, jdk 1.5并发包提供了AtomicStampedReference(有标记的原子引用)类, 通过控制变量值的版本来保证CAS正确性.

　　其实, 大部分通过值的变化来CAS, 已经够用了.