1 CAS
1.1 CAS应用分析
CAS
:Compare and Swap
, 翻译成比较并交换。
java.util.concurrent
包中借助CAS
实现了区别于synchronouse
同步锁的一种乐观锁。
本文先从CAS
的应用说起,再深入原理解析。
CAS
有3
个操作数,内存值V
,旧的预期值A
,要修改的新值B
。当且仅当预期值A
和内存值V
相同时,将内存值V
修改为B
,否则什么都不做。
看下非阻塞算法 (nonblocking algorithms
)
一个线程的失败或者挂起不应该影响其他线程的失败或挂起的算法。
现代的CPU
提供了特殊的指令,可以自动更新共享数据,而且能够检测到其他线程的干扰,而compareAndSet()
就用这些代替了锁定。
那么拿出AtomicInteger
来研究在没有锁的情况下是如何做到数据正确性的。
private volatile int value;
首先毫无以为,在没有锁的机制下可能需要借助volatile
原语,保证线程间的数据是可见的(共享的)。
这样才获取变量的值的时候才能直接读取。
public final int get() {
return value;
}
然后来看看++i
是怎么做到的
public final int incrementAndGet() {
for (;;) {
int current = get();
int next = current + 1;
if (compareAndSet(current, next))
return next;
}
}
在这里采用了CAS
操作,每次从内存中读取数据然后将此数据和+1
后的结果进行CAS
操作,如果成功就返回结果,否则重试直到成功为止。
而compareAndSet
利用JNI
来完成CPU
指令的操作
public final boolean compareAndSet(int expect, int update) {
return unsafe.compareAndSwapInt(this, valueOffset, expect, update);
}
整体的过程就是这样子的,利用CPU
的CAS
指令,同时借助JNI
来完成Java
的非阻塞算法。其它原子操作都是利用类似的特性完成的。
其中unsafe.compareAndSwapInt(this, valueOffset, expect, update);
类似与:
if (this == expect) {
this = update
return true;
} else {
return false;
}
那么问题就来了,成功过程中需要2个步骤:比较this == expect
,替换this = update
,compareAndSwapInt
如何这两个步骤的原子性呢
1.2 CAS原理
CAS
通过调用JNI
的代码实现的。JNI:Java Native Interface
为JAVA
本地调用,允许java
调用其他语言。
而compareAndSwapInt
就是借助C
来调用CPU
底层指令实现的。
下面从分析比较常用的CPU(intel x86)
来解释CAS
的实现原理。
下面是sun.misc.Unsafe
类的compareAndSwapInt()
方法的源代码:
public final native boolean compareAndSwapInt(Object o, long offset, int expected, int x);
可以看到这是个本地方法调用。这个本地方法在openjdk
中依次调用的c++
代码为:unsafe.cpp,atomic.cpp和atomicwindowsx86.inline.hpp
。这个本地方法的最终实现在openjdk
的如下位置:openjdk-7-fcs-src-b147-27jun2011\openjdk\hotspot\src\oscpu\windowsx86\vm\ atomicwindowsx86.inline.hpp
(对应于windows
操作系统,X86
处理器)。下面是对应于intel x86
处理器的源代码的片段:
// Adding a lock prefix to an instruction on MP machine
// VC++ doesn't like the lock prefix to be on a single line
// so we can't insert a label after the lock prefix.
// By emitting a lock prefix, we can define a label after it.
#define LOCK_IF_MP(mp) __asm cmp mp, 0 \
__asm je L0 \
__asm _emit 0xF0 \
__asm L0:
inline jint Atomic::cmpxchg (jint exchange_value, volatile jint* dest, jint compare_value) {
// alternative for InterlockedCompareExchange
int mp = os::is_MP();
__asm {
mov edx, dest
mov ecx, exchange_value
mov eax, compare_value
LOCK_IF_MP(mp)
cmpxchg dword ptr [edx], ecx
}
}
如上面源代码所示,程序会根据当前处理器的类型来决定是否为cmpxchg
指令添加lock
前缀。如果程序是在多处理器上运行,就为cmpxchg
指令加上lock
前缀(lock cmpxchg
)。反之,如果程序是在单处理器上运行,就省略lock
前缀(单处理器自身会维护单处理器内的顺序一致性,不需要lock
前缀提供的内存屏障效果)。
intel
的手册对lock
前缀的说明如下:
确保对内存的读-改-写
操作原子执行。在Pentium及Pentium
之前的处理器中,带有lock
前缀的指令在执行期间会锁住总线,使得其他处理器暂时无法通过总线访问内存。很显然,这会带来昂贵的开销。从Pentium 4,Intel X eon及P6
处理器开始,intel
在原有总线锁的基础上做了一个很有意义的优化:如果要访问的内存区域(area of memory
)在lock
前缀指令执行期间已经在处理器内部的缓存中被锁定(即包含该内存区域的缓存行当前处于独占或以修改状态),并且该内存区域被完全包含在单个缓存行(cache line
)中,那么处理器将直接执行该指令。由于在指令执行期间该缓存行会一直被锁定,其它处理器无法读/写
该指令要访问的内存区域,因此能保证指令执行的原子性。这个操作过程叫做缓存锁定
(cache locking
),缓存锁定将大大降低lock
前缀指令的执行开销,但是当多处理器之间的竞争程度很高或者指令访问的内存地址未对齐时,仍然会锁住总线。
禁止该指令与之前和之后的读和写指令重排序。
把写缓冲区中的所有数据刷新到内存中。
1.3 CPU锁分类
见下面的原子操作
1.4 CAS缺点
CAS
虽然很高效的解决原子操作,但是CAS
仍然存在三大问题。ABA
问题,循环时间长开销大和只能保证一个共享变量的原子操作
1.4.1 ABA问题
因为CAS
需要在操作值的时候检查下值有没有发生变化,如果没有发生变化则更新,但是如果一个值原来是A
,变成了B
,又变成了A
,那么使用CAS
进行检查时会发现它的值没有发生变化,但是实际上却变化了。ABA
问题的解决思路就是使用版本号。在变量前面追加上版本号,每次变量更新的时候把版本号加一,那么A-B-A
就会变成1A-2B-3A
。
从Java1.5
开始JDK
的atomic
包里提供了一个类AtomicStampedReference
来解决ABA
问题。这个类的compareAndSet
方法作用是首先检查当前引用是否等于预期引用,并且当前标志是否等于预期标志,如果全部相等,则以原子方式将该引用和该标志的值设置为给定的更新值。
关于ABA问题参考文档: http://blog.hesey.net/2011/09/resolve-aba-by-atomicstampedreference.html
1.4.2 循环时间长开销大
自旋CAS
如果长时间不成功,会给CPU
带来非常大的执行开销。如果JVM
能支持处理器提供的pause
指令那么效率会有一定的提升,pause
指令有两个作用,第一它可以延迟流水线执行指令(de-pipeline
),使CPU
不会消耗过多的执行资源,延迟的时间取决于具体实现的版本,在一些处理器上延迟时间是零。第二它可以避免在退出循环的时候因内存顺序冲突(memory order violation
)而引起CPU
流水线被清空(CPU pipeline flush
),从而提高CPU
的执行效率。
1.4.3 只能保证一个共享变量的原子操作
只能保证一个共享变量的原子操作,当对一个共享变量执行操作时,我们可以使用循环CAS
的方式来保证原子操作,但是对多个共享变量操作时,循环CAS
就无法保证操作的原子性,这个时候就可以用锁,或者有一个取巧的办法,就是把多个共享变量合并成一个共享变量来操作。比如有两个共享变量i=2,j=a,
合并一下ij=2a
,然后用CAS
来操作ij
。从Java1.5开始JDK提供了AtomicReference
类来保证引用对象之间的原子性,你可以把多个变量放在一个对象里来进行CAS操作。
1.5 concurrent包的实现
由于java的CAS
同时具有 volatile
读和volatile
写的内存语义,因此Java
线程之间的通信现在有了下面四种方式:
- A线程写
volatile
变量,随后B线程读这个volatile
变量。 - A线程写
volatile
变量,随后B线程用CAS更新这个volatile
变量。 - A线程用
CAS
更新一个volatile
变量,随后B线程用CAS更新这个volatile
变量。 - A线程用
CAS
更新一个volatile
变量,随后B线程读这个volatile
变量。
Java
的CAS
会使用现代处理器上提供的高效机器级别原子指令,这些原子指令以原子方式对内存执行读-改-写
操作,这是在多处理器中实现同步的关键(从本质上来说,能够支持原子性读-改-写
指令的计算机器,是顺序计算图灵机的异步等价机器,因此任何现代的多处理器都会去支持某种能对内存执行原子性读-改-写操作的原子指令)。同时,volatile
变量的读/写和CAS可以实现线程之间的通信。把这些特性整合在一起,就形成了整个concurrent
包得以实现的基石。如果我们仔细分析concurrent
包的源代码实现,会发现一个通用化的实现模式:
- 声明共享变量为
volatile
; - 使用CAS的原子条件更新来实现线程之间的同步;
- 配合以
volatile
的读/写和CAS
所具有的volatile
读和写的内存语义来实现线程之间的通信。
AQS
,非阻塞数据结构和原子变量类(java.util.concurrent.atomic包中的类),这些concurrent
包中的基础类都是使用这种模式来实现的,而concurrent
包中的高层类又是依赖于这些基础类来实现的。从整体来看,concurrent
包的实现示意图如下:
1.6 和其他锁比较
1.6.1 CAS锁和Synchronized比较
假如cas
可以保证操作的线程安全吗,为什么还要用Synchronized
呢
原因:CAS也是适用一些场合的,比如资源竞争小时,是非常适用的,不用进行内核态和用户态之间的线程上下文切换,同时自旋概率也会大大减少,提升性能,但资源竞争激烈时(比如大量线程对同一资源进行写和读操作)并不适用,自旋概率会大大增加,浪费CPU资源,降低性能,就很不划算
点此了解Synchronized更多知识点
2 原子操作
2.1 引言
原子(atom
)本意是不能被进一步分割的最小粒子
,而原子操作(atomic operation
)意为不可被中断的一个或一系列操作
。在多处理器上实现原子操作就变得有点复杂。本文让我们一起来聊一聊在Inter处理器和Java里是如何实现原子操作的
2.2 术语定义
术语名称 | 英文 | 解释 |
---|---|---|
缓存行 | Cache line | 缓存的最小操作单位 |
比较并交换 | Compare and Swap | CAS操作需要输入两个数值,一个旧值(期望操作前的值)和一个新值,在操作期间先比较下在旧值有没有发生变化,如果没有发生变化,才交换成新值,发生了变化则不交换 |
CPU流水线 | CPU pipeline | CPU流水线的工作方式就象工业生产上的装配流水线,在CPU中由5~6 个不同功能的电路单元组成一条指令处理流水线,然后将一条X86指令分成5~6步后再由这些电路单元分别执行,这样就能实现在一个CPU时钟周期完成一条指令,因此提高CPU的运算速度 |
内存顺序冲突 | Memory order violation | 内存顺序冲突一般是由假共享 引起,假共享是指多个CPU 同时修改同一个缓存行的不同部分而引起其中一个CPU的操作无效,当出现这个内存顺序冲突时,CPU必须清空流水线 |
2.3 处理器如何实现原子操作
现在大致cpu,缓存,主存图示
具体内存模型详细信息
32位IA-32
处理器使用基于对缓存加锁或总线加锁的方式来实现多处理器之间的原子操作
关于
CPU
的锁有如下3种
2.3.1 处理器自动保证基本内存操作的原子性
首先处理器会自动保证基本的内存操作的原子性。 处理器保证从系统内存当中读取或者写入一个字节是原子的,意思是当一个处理器读取一个字节时,其他处理器不能访问这个字节的内存地址
。奔腾6和最新的处理器能自动保证单处理器对同一个缓存行里进行16/32/64位的操作是原子的,但是复杂的内存操作处理器不能自动保证其原子性,比如跨总线宽度,跨多个缓存行,跨页表的访问。但是处理器提供 总线锁定
和 缓存锁定
两个机制来保证复杂内存操作的原子性
2.3.2 使用总线锁保证原子性
第一个机制是通过总线锁保证原子性。如果多个处理器同时对共享变量进行读改写(i++
就是经典的读改写操作)操作,那么共享变量就会被多个处理器同时进行操作,这样读改写操作就不是原子的,操作完之后共享变量的值会和期望的不一致,举个例子:如果i=1,我们进行两次i++操作,我们期望的结果是3,但是有可能结果是2。如下图
原因是有可能多个处理器同时从各自的缓存中读取变量
i
,分别进行加一操作,然后分别写入系统内存当中。那么想要保证读改写共享变量的操作是原子的,就必须保证CPU1
读改写共享变量的时候,CPU2
不能操作缓存了该共享变量内存地址的缓存。
处理器使用总线锁就是来解决这个问题的。所谓总线锁就是使用处理器提供的一个LOCK#信号,当一个处理器在总线上输出此信号时,其他处理器的请求将被阻塞住,那么该处理器可以独占使用共享内存
2.3.3 使用缓存锁保证原子性
第二个机制是通过缓存锁定保证原子性。在同一时刻我们只需保证对某个内存地址的操作是原子性即可,但总线锁定把CPU
和内存之间通信锁住了,这使得锁定期间,其他处理器不能操作其他内存地址的数据,所以总线锁定的开销比较大,最近的处理器在某些场合下使用缓存锁定代替总线锁定来进行优化。
频繁使用的内存会缓存在处理器的L1,L2和L3
高速缓存里,那么原子操作就可以直接在处理器内部缓存中进行,并不需要声明总线锁,在奔腾6和最近的处理器中可以使用缓存锁定
的方式来实现复杂的原子性。
所谓缓存锁定
就是如果缓存在处理器缓存行中内存区域在LOCK操作期间被锁定,当它执行锁操作回写内存时,处理器不在总线上声言LOCK#信号,而是修改内部的内存地址,并允许它的缓存一致性机制来保证操作的原子性,因为缓存一致性机制会阻止
被两个以上处理器缓存的内存区域数据同时修改
,当其他处理器回写已被锁定的缓存行的数据时会起缓存行无效,在例1中,当CPU1
修改缓存行中的i
时使用缓存锁定,那么CPU2
就不能同时缓存了i
的缓存行。
缓存一致性协议中,最出名的就是Intel
的MESI
协议,MESI
协议保证了每个缓存中使用的共享变量的副本是一致的。它核心的思想是:当CPU
写数据时,如果发现操作的变量是共享变量,即在其他CPU
中也存在该变量的副本,会发出信号通知其他CPU
将该变量的缓存行置为无效状态,因此当其他CPU
需要读取这个变量时,发现自己缓存中缓存该变量的缓存行是无效的,那么它就会从内存重新读取
MESI状态 | 描述 |
---|---|
M(Modified) 修改 | 这行数据有效,数据被修改了,和内存中的数据不一致,数据只存在于本Cache中 |
E(Exclusive)独占 | 数据只存储在⼀个 CPU核心的 Cache里,而其他 CPU 核心的 Cache 没有该数据。若向独占的 Cache 写数据,就可以直接自由地写入,而不需要通知其他 CPU 核心,因为只有这有这个数据,就不存在缓存⼀致性的问题了,于是就可以随便操作该数据。在独占状态下的数据,如果有其他核心从内存读取了相同的数据到各自的 Cache ,那么这个时候,独占状态下的数据就会变成共享状态 |
S(Shared)共享 | 代表着相同的数据在多个 CPU 核心的 Cache里都有,所以当我们要更新 Cache里面的数据的时候,不能直接修改,而是要先向所有的其他 CPU 核心广播⼀个请求,要求先把其他核心的 Cache 中对应的 Cache Line 标记为无效状态,然后再更新当前Cache里面的数据 |
I(Invalid)失效 | 这行数据无效 |
但是有两种情况下处理器不会使用缓存锁定。
第一种情况是:当操作的数据不能被缓存在处理器内部,或操作的数据跨多个缓存行(cache line
),则处理器会调用总线锁定。第二种情况是:有些处理器不支持缓存锁定。对于Inter486和奔腾处理器,就算锁定的内存区域在处理器的缓存行中也会调用总线锁定。
以上两个机制我们可以通过Inter处理器提供了很多LOCK前缀的指令来实现。比如位测试和修改指令BTS,BTR,BTC,交换指令XADD,CMPXCHG和其他一些操作数和逻辑指令,比如ADD(加),OR(或)等,被这些指令操作的内存区域就会加锁,导致其他处理器不能同时访问它
点击了解volatile中伪共享问题
2.4 JAVA如何实现原子操作
在java
中可以通过锁和循环CAS
的方式来实现原子操作。
2.4.1 使用循环CAS实现原子操作
JVM
中的CAS
操作正是利用了上面中提到的处理器提供的CMPXCHG指令实现的。自旋CAS
实现的基本思路就是循环进行CAS
操作直到成功为止,以下代码实现了一个基于CAS
线程安全的计数器方法safeCount
和一个非线程安全的计数器count
public class Counter {
private AtomicInteger atomicI = new AtomicInteger(0);
private int i = 0;
public static void main(String[] args) {
final Counter cas = new Counter();
List ts = new ArrayList(600);
long start = System.currentTimeMillis();
for (int j = 0; j < 100; j++) {
Thread t = new Thread(new Runnable() {
@Override
public void run() {
for (int i = 0; i < 10000; i++) {
cas.count();
cas.safeCount();
}
}
});
ts.add(t);
}
for (Thread t : ts) {
t.start();
}
// 等待所有线程执行完成
for (Thread t : ts) {
try {
t.join();
} catch (InterruptedException e) {
e.printStackTrace();
}
}
System.out.println(cas.i);
System.out.println(cas.atomicI.get());
System.out.println(System.currentTimeMillis() - start);
}
/**
* 使用CAS实现线程安全计数器
*/
private void safeCount() {
for (;;) {
int i = atomicI.get();
boolean suc = atomicI.compareAndSet(i, ++i);
if (suc) {
break;
}
}
}
/**
* 非线程安全计数器
*/
private void count() {
i++;
}
}
从Java1.5开始JDK的并发包里提供了一些类来支持原子操作,如AtomicBoolean
(用原子方式更新的 boolean 值),AtomicInteger
(用原子方式更新的 int 值),AtomicLong
(用原子方式更新的 long 值),这些原子包装类还提供了有用的工具方法,比如以原子的方式将当前值自增1和自减1。
在Java
并发包中有一些并发框架也使用了自旋CAS
的方式来实现原子操作,比如LinkedTransferQueue
类的Xfer方法。CAS虽然很高效的解决原子操作,但是CAS仍然存在三大问题。ABA问题,循环时间长开销大和只能保证一个共享变量的原子操作
2.4.2 使用锁机制实现原子操作
锁机制保证了只有获得锁的线程能够操作锁定的内存区域。JVM内部实现了很多种锁机制,有偏向锁,轻量级锁和互斥锁,有意思的是除了偏向锁,JVM
实现锁的方式都用到的循环CAS,当一个线程想进入同步块的时候使用循环CAS的方式来获取锁,当它退出同步块的时候使用循环CAS释放锁