CAS乐观锁和Synchronize悲观锁的使用场景与选择

《Lock与synchronized 的区别》

定义:

悲观锁(Pessimistic Lock):

每次获取数据的时候,都会担心数据被修改,所以每次获取数据的时候都会进行加锁,确保在自己使用的过程中数据不会被别人修改,使用完成后进行数据解锁。由于数据进行加锁,期间对该数据进行读写的其他线程都会进行等待。

乐观锁(Optimistic Lock):

每次获取数据的时候,都不会担心数据被修改,所以每次获取数据的时候都不会进行加锁,但是在更新数据的时候需要判断该数据是否被别人修改过。如果数据被其他线程修改,则不进行数据更新,如果数据没有被其他线程修改,则进行数据更新。
由于数据没有进行加锁,期间该数据可以被其他线程进行读写操作。

悲观锁比较适合强一致性的场景,但效率比较低,特别是读的并发低
乐观锁则适用于读多写少并发冲突少的场景。

Synchronized:
Java在JDK1.5之前都是靠 synchronized关键字保证同步的。这种通过使用一致的锁定协议来协调对共享状态的访问,可以确保无论哪个线程持有共享变量的锁,都采用独占的方式来访问这些变量。这就是一种独占锁,独占锁其实就是一种悲观锁。

CAS:Locks.ReentrantLock、
CAS 操作中包含三个操作数 —— 需要读写的内存位置(V)、进行比较的预期原值(A)和拟写入的新值(B)。如果内存位置V的值与预期原值A相匹配,那么处理器会自动将该位置值更新为新值B。否则处理器不做任何操作。无论哪种情况,它都会在 CAS 指令之前返回该位置的值。
在JDK1.5 中新增 java.util.concurrent (J.U.C)就是建立在CAS之上的。相对于对于 synchronized 这种阻塞算法,CAS是非阻塞算法的一种常见实现。

使用场景

这个使用场景我暂时还不能完全确定,但是可以肯定的是,乐观锁适合读多写少的场景,悲观锁适合写的冲突更多、要求强一致性的场景。

CAS与Synchronized的使用情景:

1、对于资源竞争较少(线程冲突较轻)的情况,使用synchronized同步锁进行线程阻塞和唤醒切换以及用户态内核态间的切换操作额外浪费消耗cpu资源;而CAS基于硬件实现,不需要进入内核,不需要切换线程,操作自旋几率较少,因此可以获得更高的性能。

2、对于资源竞争严重(线程冲突严重)的情况,CAS自旋的概率会比较大,从而浪费更多的CPU资源,效率低于synchronized。

补充: synchronized在jdk1.6之后,已经改进优化。synchronized的底层实现主要依靠Lock-Free的队列,基本思路是自旋后阻塞,竞争切换后继续竞争锁,稍微牺牲了公平性,但获得了高吞吐量。在线程冲突较少的情况下,可以获得和CAS类似的性能;而线程冲突严重的情况下,性能远高于CAS。

synchronized:

悲观锁:比较适合写入操作比较频繁的场景,如果出现大量的读取操作,**每次读取的时候都会进行加锁,**这样会增加大量的锁的开销,降低了系统的吞吐量。

在资源竞争不是很激烈的情况下,偶尔会有同步的情形下,synchronized是很合适的。原因在于,编译程序通常会尽可能的进行优化synchronize,另外可读性非常好,不管用没用过5.0多线程包的程序员都能理解。
默认是非公平锁:后等待的线程可以先获得锁。

ReentrantLock:

乐观锁:读多写少。比较适合读取操作比较频繁的场景,如果出现大量的写入操作,数据发生冲突的可能性就会增大,为了保证数据的一致性,应用层需要不断的重新获取数据,这样会增加大量的查询操作,降低了系统的吞吐量。

ReentrantLock提供了多样化的同步,比如有时间限制的同步,可以被Interrupt的同步(synchronized的同步是不能Interrupt的)等。在资源竞争不激烈的情形下,性能稍微比synchronized差点点。但是当同步非常激烈的时候,synchronized的性能一下子能下降好几十倍。而ReentrantLock确还能维持常态。
可以指定是公平锁还是非公平锁。

Atomic:

和上面的类似,不激烈情况下,性能比synchronized略逊,而激烈的时候,也能维持常态。激烈的时候,Atomic的性能会优于ReentrantLock一倍左右。但是其有一个缺点,就是只能同步一个值,一段代码中只能出现一个Atomic的变量,多于一个同步无效。因为他不能在多个Atomic之间同步。

在这里插入图片描述

补充:

CAS通过调用JNI(java native interface)的代码实现的。而**(sun.misc.Unsafe类的)compareAndSwapInt**就是借助C来调用CPU底层指令实现的。

CAS导致了ABA问题:JUC包下的AtomicStampedReference解决该问题。
这个类的compareAndSet方法作用是首先检查当前引用是否等于预期引用,并且当前标志是否等于预期标志,如果全部相等,则以原子方式将该引用和该标志的值设置为给定的更新值。

public boolean compareAndSet(
               V      expectedReference,//预期引用

               V      newReference,//更新后的引用

              int    expectedStamp, //预期标志

              int    newStamp //更新后的标志
)

猜你喜欢

转载自blog.csdn.net/mulinsen77/article/details/89348591