CAS 无锁机制

参考链接

面试必备：CAS无锁机制

CAS无锁机制和AQS

CAS无锁机制

不可不说的Java“锁”事

基础知识

保证多线程安全有三种方式：

使用Synchronize关键字

• 使用了Synchronize加锁后的多线程相当于串行，执行效率并不是太高
• 思想上：Synchronized属于 悲观锁，悲观地认为程序中的并发情况严重，所以严防死守

Lock锁

• 在高并发场景下使用，Lock锁底层就是通过 AQS+CAS机制 实现的，属于 悲观锁

Atomic 原子类

• 使用Java并发包（java.util.concurrent）下的Atomic 原子类是基于 CAS无锁算法 实现了乐观锁
• jdk1.5增加了并发包 java.util.concurrent.*，其下面的类使用CAS算法实现了 区别于synchronized同步锁 的一种乐观锁

CAS 算法

CAS全称 Compare And Swap（比较与交换），是一种无锁算法

三个操作数

• 需要读写的内存值 V
• 进行比较的值 A
• 要写入的新值 B

当且仅当 V 的值等于 A 时，CAS通过原子方式用新值B来更新V的值（“比较+更新”整体是一个原子操作），否则不会执行任何操作

一般情况下，“更新”是一个不断重试的操作：

• CAS操作是抱着乐观的态度进行的，它总是认为自己可以成功完成操作
• 当多个线程同时使用CAS操作一个变量时，只有一个会胜出，并成功更新，其余均会失败
• 失败的线程不会被挂起，仅是被告知失败，并且允许再次尝试，当然也允许失败的线程放弃操作
• 基于这样的原理，CAS操作即使没有锁，也可以发现其他线程对当前线程的干扰，并进行恰当的处理

优缺点

• 缺点
  • CPU开销比较大：在并发量比较高的情况下，如果线程反复尝试更新一个变量，却又一直更新不成功，循环往复，会给CPU带来很大的压力
  • 只能保证一个共享变量的原子操作：无法确保整个代码块的原子性，也就是在需要保证2个及以上变量共同进行原子性的更新时，就不得不使用Synchronized
  • ABA问题：假设有一个变量 A ，经修改后变为B，然后又修改为 A，实际已经修改过了，但 CAS操作就会误任务它从来没有被修改过，造成了不合理的值修改操作
    • 解决方案是：使用版本号，在 变量前面追加上版本号，每次变量更新的时候把版本号加一，那么 从“A－B－A”变成了“1A－2B－3A”
    • java并发包提供了一个带有标记的原子应用类AtomicStampedRefernce，它可以通过变量值的版本来保证CAS的正确性
• 优点
  • 在一般情况下，性能优先于锁的使用
  • 与锁相比，使用比较交换会使程序看起来更加复杂一些。但由于其 非阻塞性，它对死锁问题天生免疫，并且，线程间的相互影响也远远比基于锁的方式要小
  • 更为重要的是，使用无锁的方式 完全没有锁竞争带来的系统开销，也没有线程间频繁调度带来的开销