Java并发之CAS机制 —— 乐观锁

引入

在单实例（一个JVM）环境下，多个线程并发操作某一共享资源时，我们可以通过synchronized同步锁保证资源的可见性和原子性。但会存在性能问题：

（Synchronized关键字会让没有得到锁资源的线程进入BLOCKED状态，而后在争夺到锁资源后恢复为RUNNABLE状态，这个过程中涉及到操作系统用户模式和内核模式的转换，代价比较高。

尽管Java1.6为Synchronized做了优化，增加了从偏向锁到轻量级锁再到重量级锁的过度，但是在最终转变为重量级锁之后，性能仍然较低。）

 

我们可以使用原子类进行操作。在java.util.concurrent.atomic包下，一系列以Atomic开头的包装类。例如AtomicBoolean，AtomicInteger，AtomicLong。它们分别用于Boolean，Integer，Long类型的原子性操作。

Atomic操作类的底层正使用了CAS机制。

 

CAS是什么

 

CAS是英文单词Compare And Swap的缩写，翻译过来就是比较并替换。通过CPU指令级保证比较替换为一个原子操作。

 

CAS机制当中使用了3个基本操作数：内存地址V，旧的预期值A，要修改的新值B。

更新一个变量的时候，只有当变量的预期值A和内存地址V当中的实际值相同时，才会将内存地址V对应的值修改为B。

 

我们举一个例子来说明CAS操作的机制：

1.在内存V中存在旧的预期值A=10 

2.此时线程一想修改内存V中的值，新值B=11

3.但线程二抢先一步，内存V中的值被修改为11

4.在线程一准备修改时，先进行将旧的预期值A和此时的内存V中的值比较 A！=V，修改失败

5.线程一重新获得内存V值，此时A=11,B=12这个重新尝试的过程叫自旋

6.线程一在次进行操作时，A=V，进行修改操作

7.线程一进行SWAP,修改V值为B

从思想上来说，Synchronized属于悲观锁，悲观地认为程序中的并发情况严重，所以严防死守。CAS属于乐观锁，乐观地认为程序中的并发情况不那么严重，所以让线程不断去尝试更新。

 

缺点

1.CPU开销较大

在并发量比较高的情况下，如果许多线程反复尝试更新某一个变量，却又一直更新不成功，循环往复，会给CPU带来很大的压力。

2.不能保证代码块的原子性

CAS机制所保证的只是一个变量的原子性操作，而不能保证整个代码块的原子性。比如需要保证3个变量共同进行原子性的更新，就不得不使用Synchronized了。

3.ABA问题

这是CAS机制最大的问题所在。

线程1准备用CAS将变量的值由A替换为B，在此之前，线程2将变量的值由A替换为C，又由C替换为A，然后线程1执行CAS时发现变量的值仍然为A，所以CAS成功。但实际上这时的现场已经和最初不同了，尽管CAS成功，但可能存在潜藏的问题。

解决办法，使用时间戳stamp标记需要更改的对象。在java.util.concurrent.atomic中提供了AtomicStampReference来解决CAS操作中ABA问题。

//旧的预期值，新值，旧的预期标记值，新标记值。当预期标记值发生改变是，不予更新
atomicStampedRef.compareAndSet(100,101,atomicStampedRef.getStamp(),atomicStampedRef.getStamp()+1);

 

 

参考：https://www.cnblogs.com/myopensource/p/8177074.html