CAS

Posted xk920

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了CAS相关的知识,希望对你有一定的参考价值。

一.什么是CAS?

  CAS是compare and swap的缩写(比较和交换)。

  在计算机科学中,比较和交换(Conmpare And Swap)是用于实现多线程同步的原子指令。 它将内存位置的内容与给定值进行比较,只有在相同的情况下,将该内存位置的内容修改为新的给定值。 这是作为单个原子操作完成的。 原子性保证新值基于最新信息计算; 如果该值在同一时间被另一个线程更新,则写入将失败。

  CAS 操作包含三个操作数 —— 内存位置(V)、预期原值(A)和新值(B)。如果内存地址里面的值和A的值是一样的,那么就将内存里面的值更新成B。CAS是通过无限循环来获取数据的,若果在第一轮循环中,a线程获取地址里面的值被b线程修改了,那么a线程需要自旋,到下次循环才有可能机会执行。

  Java中的乐观锁基本都是由CAS操作实现的。

二.为什么要用CAS?

  在JDK5之前Java语言是靠synchronized关键字保证同步的,这会导致有锁,锁机制存在以下问题:

  • 在多线程竞争下,加锁、释放锁会导致比较多的上下文切换和调度延时,引起性能问题
  • 一个线程持有锁会导致其他所有需要此锁的线程挂起
  • 如果一个优先级高的线程等待一个优先级低的线程释放锁会导致优先级倒置,引起性能风险

  volatile是不错的机制,但是volatile不能保证原子性。因此对于同步最终还是要回到锁机制上来。

  独占锁是一个悲观锁,synchronized就是一种独占锁,会导致其他所有需要锁的线程挂起,等待持有锁的线程释放锁。而另一种更加有效的锁就是乐观锁,CAS就是一种乐观锁

 

  cas是一种基于锁的操作,而且是乐观锁。在java中锁分为乐观锁和悲观锁。悲观锁是将资源锁住,等一个之前获得锁的线程释放锁之后,下一个线程才可以访问。而乐观锁采取了一种宽泛的态度,通过某种方式不加锁来处理资源,比如通过给记录加version来获取数据,性能较悲观锁有很大的提高。

  无锁是一种乐观策略(无锁算法),因为对于加锁的并发程序来说,它们总是认为每次访问共享资源时总会发生冲突,因此必须对每一次数据操作实施加锁策略。而无锁则总是假设对共享资源的访问没有冲突,线程可以不停执行,无需加锁,无需等待,一旦发现冲突,无锁策略则采用CAS的技术来保证线程执行的安全性,这项CAS技术就是无锁策略实现的关键。

  (PS:为啥说CAS是乐观锁?乐观锁,严格来说并不是锁,通过原子性来保证数据的同步,比如说数据库的乐观锁,通过版本控制来实现,所以CAS不会保证线程同步。乐观的认为在数据更新期间没有其他线程影响。)

三.CAS能做什么?

  

由于CAS是CPU指令,我们只能通过JNI与操作系统交互,关于CAS的方法都在sun.misc包下Unsafe的类里,java.util.concurrent.atomic包下的原子类等通过CAS来实现原子操作。

  技术图片

 

 

   由于CAS操作属于乐观派,它总认为自己可以成功完成操作,当多个线程同时使用CAS操作一个变量时,只有一个会胜出,并成功更新,其余均会失败,但失败的线程并不会被挂起,仅是被告知失败,并且允许再次尝试,当然也允许失败的线程放弃操作,这点从图中也可以看出来。基于这样的原理,CAS操作即使没有锁,同样知道其他线程对共享资源操作影响,并执行相应的处理措施。同时从这点也可以看出,由于无锁操作中没有锁的存在,因此不可能出现死锁的情况,也就是说无锁操作天生免疫死锁。

  

四.CAS的优缺点

• 优点:

  非阻塞的轻量级的乐观锁,通过CPU指令实现,在资源竞争不激烈的情况下性能高,相比synchronized重量锁,synchronized会进行比较复杂的加锁、解锁和唤醒操作。

 

• 缺点: CAS 存在三个问题

  1.ABA问题:

  比如一个线程one从内存位置V中取出A,这是另一个线程two也从内存中取出A,并且two进行了一些操作变成了B,然后two又将V位置的数据变成A,这时候线程one进行CAS操作发现内存中仍然是A,然后one操作成功。尽管线程one的CAS操作成功,但是不代表这个过程就是没有问题的。

  部分乐观锁的实现是通过版本号(version)的方式来解决ABA问题:

  从Java1.5开始JDK的atomic包里提供了一个类AtomicStampedReference来解决ABA问题。这个类的compareAndSet方法作用是首先检查当前引用是否等于预期引用,并且当前标志是否等于预期标志,如果全部相等,则以原子方式将该引用和该标志的值设置为给定的更新值。具体解决思路就是在变量前追加上版本号,每次变量更新的时候把版本号加一,那么A - B - A就会变成1A - 2B - 3A。

  2.循环时间过长(即自旋耗时久)资源开销大:

  自旋CAS如果长时间不成功,会给CPU带来非常大的执行开销。因此CAS不适合竞争十分频繁的场景,消耗CPU资源,如果资源竞争激烈,多线程自旋长时间消耗资源。

  (先说一下什么叫自旋,自旋就是cas的一个操作周期,如果一个线程特别倒霉,每次获取的值都被其他线程的修改了,那么它就会一直进行自旋比较,直到成功为止,在这个过程中cpu的开销十分的大,所以要尽量避免。)

  3.只能保证一个共享变量的原子操作:

  当对一个共享变量执行操作时,我们可以使用循环CAS的方式来保证原子操作,但是对多个共享变量操作时,循环CAS就无法保证操作的原子性,这个时候就可以用锁。

使用乐观锁还是悲观锁

  两种锁各有优缺点,不可认为一种好于另一种,像乐观锁适用于写比较少的情况下(多读场景),即冲突真的很少发生的时候,这样可以省去了锁的开销,加大了系统的吞吐量。但如果是多写的情况,一般会经常发生冲突,这就会导致CAS算法会不断的进行retry,这样反倒是降低了性能,所以一般多写的场景下用悲观锁就比较合适。

 

参考:

  深入理解CAS(乐观锁)

  java CAS(无锁 乐观锁 轻量级锁)

 

  

以上是关于CAS的主要内容,如果未能解决你的问题,请参考以下文章

CAS原理解析 CAS底层

单点登录CAS使用记:使用maven的overlay实现无侵入的改造CAS

cas客户端集成方案

CAS —— Mac下配置CAS到Tomcat(服务端)(转)

CAS集成源码解析

Java并发多线程编程——CAS