一、悲观锁和乐观锁的概念
对于并发控制而言,我们平时用的锁(synchronized,Lock)是一种悲观的策略。它总是假设每一次临界区操作会产生冲突,因此,必须对每次操作都小心翼翼。如果多个线程同时访问临界区资源,就宁可牺牲性能让线程进行等待,线程一旦得到锁,其他需要锁的线程就挂起的情况就是悲观锁。。

与之相对的有一种乐观的策略,它会假设对资源的访问是没有冲突的。既然没有冲突也就无需等待了,所有的线程都在不停顿的状态下持续执行。那如果遇到问题了无锁的策略使用一种叫做比较交换(CAS Compare And Swap)来鉴别线程冲突,一旦检测到冲突产生,就重试当前操作直到没有冲突。CAS算法是非阻塞的,它对死锁问题天生免疫,而且它比基于锁的方式拥有更优越的性能。

CAS操作的就是乐观锁,每次不加锁而是假设没有冲突而去完成某项操作,如果因为冲突失败就重试,直到成功为止。
二、CAS算法
在进入正题之前,我们先理解下下面的代码:

private static int count = 0;public static void main(String[] args) {for (int i = 0; i < 2; i++) {new Thread(new Runnable() {@Overridepublic void run() {try {Thread.sleep(10);} catch (Exception e) {e.printStackTrace();}//每个线程让count自增100次for (int i = 0; i < 100; i++) {count++;}}}).start();}try{Thread.sleep(2000);}catch (Exception e){e.printStackTrace();}System.out.println(count);}

请问cout的输出值是否为200?答案是否定的,因为这个程序是线程不安全的,所以造成的结果count值可能小于200;
那么如何改造成线程安全的呢,其实我们可以使用上Synchronized同步锁,我们只需要在count++的位置添加同步锁,代码如下:

private static int count = 0;public static void main(String[] args) {for (int i = 0; i < 2; i++) {new Thread(new Runnable() {@Overridepublic void run() {try {Thread.sleep(10);} catch (Exception e) {e.printStackTrace();}//每个线程让count自增100次for (int i = 0; i < 100; i++) {synchronized (ThreadCas.class){count++;}}}}).start();}try{Thread.sleep(2000);}catch (Exception e){e.printStackTrace();}System.out.println(count);}

加了同步锁之后,count自增的操作变成了原子性操作,所以最终的输出一定是count=200,代码实现了线程安全。
但是Synchronized虽然确保了线程的安全,但是在性能上却不是最优的,Synchronized关键字会让没有得到锁资源的线程进入BLOCKED状态,而后在争夺到锁资源后恢复为RUNNABLE状态,这个过程中涉及到操作系统用户模式和内核模式的转换,代价比较高。
尽管Java1.6为Synchronized做了优化,增加了从偏向锁到轻量级锁再到重量级锁的过度,但是在最终转变为重量级锁之后,性能仍然较低。
所谓原子操作类,指的是java.util.concurrent.atomic包下,一系列以Atomic开头的包装类。例如AtomicBoolean,AtomicInteger,AtomicLong。它们分别用于Boolean,Integer,Long类型的原子性操作。

private static AtomicInteger count = new AtomicInteger(0);public static void main(String[] args) {for (int i = 0; i < 2; i++) {new Thread(new Runnable() {@Overridepublic void run() {try {Thread.sleep(10);} catch (Exception e) {e.printStackTrace();}//每个线程让count自增100次for (int i = 0; i < 100; i++) {count.incrementAndGet();}}}).start();}try{Thread.sleep(2000);}catch (Exception e){e.printStackTrace();}System.out.println(count);}

使用AtomicInteger之后,最终的输出结果同样可以保证是200。并且在某些情况下,代码的性能会比Synchronized更好。
而Atomic操作的底层实现正是利用的CAS机制,好的,我们切入到这个博客的正点。
什么是CAS机制
CAS是英文单词Compare And Swap的缩写,翻译过来就是比较并替换。
CAS机制当中使用了3个基本操作数:内存地址V,旧的预期值A,要修改的新值B。
更新一个变量的时候,只有当变量的预期值A和内存地址V当中的实际值相同时,才会将内存地址V对应的值修改为B。

当多个线程同时使用CAS 操作一个变量时,只有一个会胜出,并成功更新,其余均会失败。失败的线程不会挂起,仅是被告知失败,并且允许再次尝试,当然也允许实现的线程放弃操作。基于这样的原理,CAS 操作即使没有锁,也可以发现其他线程对当前线程的干扰。

与锁相比,使用CAS会使程序看起来更加复杂一些,但由于其非阻塞的,它对死锁问题天生免疫,并且,线程间的相互影响也非常小。更为重要的是,使用无锁的方式完全没有锁竞争带来的系统开销,也没有线程间频繁调度带来的开销,因此,他要比基于锁的方式拥有更优越的性能。

简单的说,CAS 需要你额外给出一个期望值,也就是你认为这个变量现在应该是什么样子的。如果变量不是你想象的那样,哪说明它已经被别人修改过了。你就需要重新读取,再次尝试修改就好了。
这样说或许有些抽象,我们来看一个例子:
1.在内存地址V当中,存储着值为10的变量。

2.此时线程1想要把变量的值增加1。对线程1来说,旧的预期值A=10,要修改的新值B=11。


3.在线程1要提交更新之前,另一个线程2抢先一步,把内存地址V中的变量值率先更新成了11。

4.线程1开始提交更新,首先进行A和地址V的实际值比较(Compare),发现A不等于V的实际值,提交失败。

5.线程1重新获取内存地址V的当前值,并重新计算想要修改的新值。此时对线程1来说,A=11,B=12。这个重新尝试的过程被称为自旋。

6.这一次比较幸运,没有其他线程改变地址V的值。线程1进行Compare,发现A和地址V的实际值是相等的。

7.线程1进行SWAP,把地址V的值替换为B,也就是12。

从思想上来说,Synchronized属于悲观锁,悲观地认为程序中的并发情况严重,所以严防死守。CAS属于乐观锁,乐观地认为程序中的并发情况不那么严重,所以让线程不断去尝试更新。
看到上面的解释是不是索然无味,查找了很多资料也没完全弄明白,通过几次验证后,终于明白,最终可以理解成一个无阻塞多线程争抢资源的模型。先上代码

import java.util.concurrent.atomic.AtomicBoolean;/*** @author hrabbit* 2018/07/16.*/
public class AtomicBooleanTest implements Runnable {private static AtomicBoolean flag = new AtomicBoolean(true);public static void main(String[] args) {AtomicBooleanTest ast = new AtomicBooleanTest();Thread thread1 = new Thread(ast);Thread thread = new Thread(ast);thread1.start();thread.start();}@Overridepublic void run() {System.out.println("thread:"+Thread.currentThread().getName()+";flag:"+flag.get());if (flag.compareAndSet(true,false)){System.out.println(Thread.currentThread().getName()+""+flag.get());try {Thread.sleep(5000);} catch (InterruptedException e) {e.printStackTrace();}flag.set(true);}else{System.out.println("重试机制thread:"+Thread.currentThread().getName()+";flag:"+flag.get());try {Thread.sleep(500);} catch (InterruptedException e) {e.printStackTrace();}run();}}
}

输出的结果:

thread:Thread-1;flag:true
thread:Thread-0;flag:true
Thread-1false
重试机制thread:Thread-0;flag:false
thread:Thread-0;flag:false
重试机制thread:Thread-0;flag:false
thread:Thread-0;flag:false
重试机制thread:Thread-0;flag:false
thread:Thread-0;flag:false
重试机制thread:Thread-0;flag:false
thread:Thread-0;flag:false
重试机制thread:Thread-0;flag:false
thread:Thread-0;flag:false
重试机制thread:Thread-0;flag:false
thread:Thread-0;flag:false
重试机制thread:Thread-0;flag:false
thread:Thread-0;flag:false
重试机制thread:Thread-0;flag:false
thread:Thread-0;flag:false
重试机制thread:Thread-0;flag:false
thread:Thread-0;flag:false
重试机制thread:Thread-0;flag:false
thread:Thread-0;flag:true
Thread-0false

这里无论怎么运行,Thread-1、Thread-0都会执行if=true条件,而且还不会产生线程脏读脏写,这是如何做到的了,这就用到了我们的compareAndSet(boolean expect,boolean update)方法
我们看到当Thread-1在进行操作的时候,Thread一直在进行重试机制,程序原理图:

这个图中重最要的是compareAndSet(true,false)方法要拆开成compare(true)方法和Set(false)方法理解,是compare(true)是等于true后,就马上设置共享内存为false,这个时候,其它线程无论怎么走都无法走到只有得到共享内存为true时的程序隔离方法区。
CPU指令对CAS的支持
或许我们可能会有这样的疑问,假设存在多个线程执行CAS操作并且CAS的步骤很多,有没有可能在判断V和E相同后,正要赋值时,切换了线程,更改了值。造成了数据不一致呢?答案是否定的,因为CAS是一种系统原语,原语属于操作系统用语范畴,是由若干条指令组成的,用于完成某个功能的一个过程,并且原语的执行必须是连续的,在执行过程中不允许被中断,也就是说CAS是一条CPU的原子指令,不会造成所谓的数据不一致问题。所以如果需要自定义比较和设置方法,需要使用unsafe类提供的硬件级别的方法,否则可能会出现多线程安全问题。

看到这里,这种CAS机制就是完美的吗?这个程序其实存在一个问题,不知道大家注意到没有?
但是这种得不到状态为true时使用递归算法是很耗cpu资源的,所以一般情况下,都会有线程sleep。
三、CAS的缺点
1.CPU开销较大
在并发量比较高的情况下,如果许多线程反复尝试更新某一个变量,即不停的自旋,却又一直更新不成功,循环往复,会给CPU带来很大的压力。
2.不能保证代码块的原子性
CAS机制所保证的只是一个变量的原子性操作,而不能保证整个代码块的原子性。比如需要保证3个变量共同进行原子性的更新,就不得不使用Synchronized了。除此之外,可以考虑使用AtomicReference来包装多个变量,通过这种方式来处理多个共享变量的情况。

3.ABA问题

CAS需要检查操作值有没有发生改变,如果没有发生改变则更新。但是存在这样一种情况:如果一个值原来是A,变成了B,然后又变成了A,那么在CAS检查的时候会发现没有改变,但是实质上它已经发生了改变,这就是所谓的ABA问题。对于ABA问题其解决方案是加上版本号,即在每个变量都加上一个版本号,每次改变时加1,即A —> B —> A,变成1A —> 2B —> 3A。

用一个例子来阐述ABA问题所带来的影响。
线程1准备用CAS将变量的值由A替换为B,在此之前,线程2将变量的值由A替换为C,又由C替换为A,然后线程1执行CAS时发现变量的值仍然为A,所以CAS成功。但实际上这时的现场已经和最初不同了,尽管CAS成功,但可能存在潜藏的问题,例如下面的例子:

现有一个用单向链表实现的堆栈,栈顶为A,这时线程T1已经知道A.next为B,然后希望用CAS将栈顶替换为B:

head.compareAndSet(A,B);

在T1执行上面这条指令之前,线程T2介入,将A、B出栈,再pushD、C、A,此时堆栈结构如下图,而对象B此时处于游离状态(B在线程1中还有引用):

此时轮到线程T1执行CAS操作,检测发现栈顶仍为A,所以CAS成功,栈顶变为B,但实际上B.next为null,所以此时的情况变为:

其中堆栈中只有B一个元素,C和D组成的链表不再存在于堆栈中,平白无故就把C、D丢掉了。

以上就是由于ABA问题带来的隐患,解决办法是给变量加一个版本号即可,在比较的时候不仅要比较当前变量的值 还需要比较当前变量的版本号,Java提供了AtomicStampedReference来解决。AtomicStampedReference通过包装[E,Integer]的元组来对对象标记版本戳stamp,从而避免ABA问题。当然,在大部分情况下ABA问题并不会影响程序并发的正确性。

示例:

import java.util.concurrent.TimeUnit;
import java.util.concurrent.atomic.AtomicInteger;
import java.util.concurrent.atomic.AtomicStampedReference;public class ABA {private static AtomicInteger atomicInt = new AtomicInteger(100);private static AtomicStampedReference atomicStampedRef = new AtomicStampedReference(100, 0);public static void main(String[] args) throws InterruptedException {Thread refT1 = new Thread(new Runnable() {@Overridepublic void run() {try {TimeUnit.SECONDS.sleep(1);} catch (InterruptedException e) {}atomicStampedRef.compareAndSet(100, 101, atomicStampedRef.getStamp(), atomicStampedRef.getStamp() + 1);atomicStampedRef.compareAndSet(101, 100, atomicStampedRef.getStamp(), atomicStampedRef.getStamp() + 1);}});Thread refT2 = new Thread(new Runnable() {@Overridepublic void run() {int stamp = atomicStampedRef.getStamp();try {TimeUnit.SECONDS.sleep(2);} catch (InterruptedException e) {}boolean c3 = atomicStampedRef.compareAndSet(100, 101, stamp, stamp + 1);System.out.println(c3); }});refT1.start();refT2.start();}
}

并发编程 CAS算法相关推荐

  1. JAVA并发编程: CAS和AQS

    说起JAVA并发编程,就不得不聊聊CAS(Compare And Swap)和AQS了(AbstractQueuedSynchronizer). CAS(Compare And Swap) 什么是CA ...

  2. Java 并发编程CAS、volatile、synchronized原理详解

    CAS(CompareAndSwap) 什么是CAS? 在Java中调用的是Unsafe的如下方法来CAS修改对象int属性的值(借助C来调用CPU底层指令实现的): /*** * @param o ...

  3. 并发策略-CAS算法

    对于并发控制而言,我们平时用的锁(synchronized,Lock)是一种悲观的策略.它总是假设每一次临界区操作会产生冲突,因此,必须对每次操作都小心翼翼.如果多个线程同时访问临界区资源,就宁可牺牲 ...

  4. 《java并发编程的艺术》阅读笔记总结

    第1章 并发编程的挑战 并发编程的目的是为了让程序运行得更快,但是不是更多的线程就能让程序最大限度的并发执行.比如上下文切换.死锁的问题,以及受限于软件和硬件的资源限制问题. 软件资源限制:有数据库的 ...

  5. Java并发编程,无锁CAS与Unsafe类及其并发包Atomic

    为什么80%的码农都做不了架构师?>>>    我们曾经详谈过有锁并发的典型代表synchronized关键字,通过该关键字可以控制并发执行过程中有且只有一个线程可以访问共享资源,其 ...

  6. 面试准备每日系列:计算机底层之并发编程(一)原子性、atomic、CAS、ABA、可见性、有序性、指令重排、volatile、内存屏障、缓存一致性、四核八线程

    文章目录 1. 什么是进程?什么是线程? 2. 线程切换 3. 四核八线程是什么意思 3.1 单核CPU设定多线程是否有意义 4. 并发编程的原子性 4.1 如何解决原子性问题 & atomi ...

  7. Java并发编程-无锁CAS与Unsafe类及其并发包Atomic

    [版权申明]未经博主同意,谢绝转载!(请尊重原创,博主保留追究权) http://blog.csdn.net/javazejian/article/details/72772470 出自[zejian ...

  8. 徐无忌并发编程笔记:无锁机制CAS及其底层实现原理?

    徐无忌并发编程笔记:无锁机制CAS及其底层实现原理? 完成:第一遍 1.什么是CAS算法? compare and swap:比较与交换,是一种有名的无锁算法 CAS带来了一种无锁解决线程同步,冲突问 ...

  9. cas无法使用_并发编程中cas的这三大问题你知道吗?

    在java中cas真的无处不在,它的全名是compare and swap,即比较和交换.它不只是一种技术更是一种思想,让我们在并发编程中保证数据原子性,除了用锁之外还多了一种选择. 一.cas的思想 ...

  10. 【并发编程】Atomic与CAS

    多线程开发中确保这三大特性.首先,最简单的方式就是使用 synchronized 关键字或者其它加锁.这种方式最大的好处是–简单!不需要动脑子,在需要的地方加锁就好了.同步方式在并发时包治百病,但治病 ...

最新文章

  1. 【转】Android 面试题笔记-------android五种布局及其作用
  2. golang适合做什么_这年头中年女人适合做什么兼职
  3. 润乾实现简单自定义动态列报表
  4. Stanford CoreNLP使用需要注意的一点
  5. Python的__str__()方法
  6. 从道的角度来论述大数据对企业价值
  7. AutoMapper多个对象映射到一个Dto对象
  8. Android 网络状态的监控
  9. 解决Another app is currently holding the yum lock; waiting for it to exit...问题
  10. 10条途径迅速提高你的生活
  11. Linux守护进程编程编写,linux守护进程编程实例
  12. Windows Phone 7 立体旋转动画的实现
  13. Terraform 支持自动化开通阿里云产品
  14. Houdini函数表达式
  15. Linux系统下修改DNS地址的三种方法:
  16. whith ~ as 用法
  17. 移动电源最大多少毫安?移动电源多少毫安合适
  18. centos7 telnet访问mysql出错Connection closed by foreign host
  19. 十大项目管理知识-相关方识别管理
  20. 如何设置自定义任务栏图标_轻松自定义Windows 7任务栏图标

热门文章

  1. 银联支付接口研究(Android端和Java服务端)
  2. 这些JAVA毕业设计拿走不谢
  3. selenium弹窗处理,包括Javascript弹窗、HTML弹出层和Windows弹窗
  4. 安卓手机修改ntp服务器,修改安卓手机ntp服务器地址
  5. ubuntu下安装matlab
  6. MS VS 2013下载和安装中文语言包教程
  7. 插件 阴阳师 百鬼夜行
  8. 2019年中科院信工所复试经验帖
  9. 对数周期天线hfss建模_07 HFSS软件二次开发在对数周期天线设计中的应用
  10. 将手机投屏到电脑以及用手机实现对电脑的控制