CAS操作

最新推荐文章于 2024-02-06 09:43:17 发布

Burder

最新推荐文章于 2024-02-06 09:43:17 发布

阅读量855

点赞数 1

文章标签： CAS 乐观锁悲观锁偏向锁轻量级重量级 ABA问题

本文链接：https://blog.csdn.net/Burder/article/details/97244131

版权

1 .CAS ：Compare And Swap （比较交换机制）–乐观锁

悲观锁：（JDK1 . 6之前的内建锁）假设每一次执行同步代码块均会产生冲突，所以当线程获取锁成功，会阻塞其他尝试获取该锁的线程。

乐观锁：（Lock）假设所有线程访问共享资源时不会出现冲突，既然不会出现冲突自然就不会阻塞时其他线程。线程不会出现阻塞状态。

CAS（无锁操作），使用CAS叫做比较交换来判断是否出现冲突，出现冲突就重试当前操作直到不冲突为止。

1 . 1 CAS操作过程
—一般来说，CAS（V,O,N）：
V：内存中地址存放的实际值
O：预期值（旧值）
N：更新后的值

–当执行CAS时，如果V==O,即旧值与内存中实际值相等，表示上次修改该值后没有任何线程再次修改此值，因此可以将N替换到内存中。

–如果V！=O,表示该内存中的值已经被其他线程做了修改，所以无法将N替换，返回最新的V。

–当多个线程使用CAS操作同一个变量时，只有一个线程会成功，并成功更新变量值，其余线程均会失败。失败线程会重新尝试或将线程挂起（阻塞）。

元老级内建锁（synchronized）最重要的问题：当存在线程竞争的情况下会出现线程阻塞以及唤醒带来的性能问题，对应互斥同步（阻塞同步），效率很低。

–而CAS并不是武断将线程挂起，会尝试若干次CAS操作，并非进行耗时的挂起与唤醒操作，因而非阻塞式同步。

1 . 2 CAS的问题：
1 . 2. 1 ABA问题：
–解决思路：沿用数据库的乐观锁机制，添加版本号1A->2B->3A
JDK1.5提供的atomic包下AtomicStampedReference类来解决CAS的ABA问题

1 . 2 .2 自旋（CAS）会浪费大量的处理器资源（CPU）
-与线程阻塞相比，自旋会浪费大量的CPU资源。因此此时线程任处于运行状态，只不过跑的是无用指令时，锁能被释放出来。

解决思路：自适应自旋根据以往自旋等待时能否获取到锁，来动态调整自旋的时间（循环尝试数量）。

–如果在上一次自旋时获取到锁，则此次自旋时间稍微变长一点; 如果在上一次自旋结束还没有获取到锁，此次自旋时间稍微短一点。

1 . 2 .3 公平性
–处于阻塞状态的线程无法立刻竞争被释放的锁；而处于自旋状态的线程很有可能先获取到锁。

–内建锁无法实现公平性
–lock 体系可以实现公平锁

2 . Java 对象头

JDK1 . 6之后对内建锁做了优化（新增偏向、轻量级锁）
锁对象在对象头的mark word 中。
–无锁状态0 01
–偏向锁1 01
–轻量级锁00
–重量级锁（JDK1 . 6之前）内建锁 10

这四种状态随着竞争情况逐渐升级，锁可以升级不能降级，为了提高获得锁与释放锁的效率。

2 .1 偏向锁

偏向锁：最乐观的锁，从始至终只有一个线程请求一把锁。
偏向锁获取：
–当一个线程访问同步代码块并获取锁时，会在对象头和棧帧中的锁记录中记录存储偏向锁的线程ID。以后该线程再次进入同步块时不在需要CAS来加锁和解锁，只需要简单测试一下对象头的mark word中偏向线程ID是否是当前线程ID，如果成功，表示线程已经获取到锁，直接进入代码块运行。

–如果测试失败，检查当前偏向锁字段是否为0，如果为0 ，采用CAS操作将偏向锁字段设置为1，并且更新自己的线程ID到mark word字段中。

–如果为1 ，表示此时偏向锁易已经被别的线程获取。则此线程不断尝试使用CAS获取偏向锁或者将偏向锁撤销，升级为轻量级锁（升级概率较大）

–偏向锁撤销：
偏向锁使用一种等待竞争出现才释放锁的机制，当有其他线程尝试竞争偏向锁时，持有偏向锁的线程才会释放偏向锁。

小提示：偏向锁的撤销开销较大，需要等待线程进入全局安全点safepoint（当前线程在CPU上没有执行任何又有用字节码）
–偏向锁从JDK6之后默认开启，但是它在应用程序启动几秒后才激活。
-XX：BiasedLockingStartupDelay=0,将延迟关闭JVM一启动就激活偏向锁。
-XX：-UseBisedLocking=false，关闭偏向锁，程序默认进入轻量级锁。

2 . 2 轻量级锁：
轻量级锁：多个线程在不同的时间段请求同一把锁，也就是基本不存在锁竞争。针对此种状况，JVM采用轻量级锁来避免线程的阻塞以及唤醒。

加锁：
线程在执行同步代码块之前，JVM先在当前线程的棧帧中创建用于存储锁记录的空间，并将对象头的mark word字段直接复制到此空间中。然后线程尝试使用CAS将对象头的mark word替换为指向锁记录的指针（指向当前线程），如果成功表示获取到轻量级锁。如果失败，表示其他线程竞争轻量级锁，当前线程便使用自旋来不断尝试。

释放：
解锁时，会使用CAS将复制的mark word替换回对象头，如果成功，表示没有竞争发生，正常解锁。如果失败，表示当前锁存在竞争，进一步膨胀为重量级锁。

总结：
–重量级锁会阻塞、唤醒请求加锁的线程。针对的是多个线程同一时刻竞争同一把锁的情况，JVM采用自适应自旋，来避免线程在面对非常小的同步块时，仍会被阻塞以及唤醒。

–轻量级锁采用CAS操作，将对象的标记字段提花为指向在的指针，存储着锁对象原本标记的字段。针对的是不同时间段申请同一把锁的情况。

–偏向锁只会在第一次请求时采用CAS操作，在锁对象的mark word字段中记录下当前线程ID，此后运行中持有偏向锁的线程不再有加锁过程。针对的是锁仅会被同一线程持有。

同步关键字：synchronized
++多线程同一时间访问同一资源（锁），产生竞争，线程阻塞和唤醒2

JVM实现：开发者经过大量的程序分析，多线程访问同一资源的时候，大多数情况下并不是同一时间进行的。

无锁：无同步
偏向锁：一个线程访问一个资源，产生竞争（多线程）
轻量级锁：多线程不同时间访问同一资源
重量级锁：多线程同一时间访问同一资源
锁的升级：无锁–>偏向锁–>轻量级锁–>重量级锁

代码级的优化
锁的粗化：将连续的加锁、解锁，变成更大范围的加锁、解锁。
锁的消除：参考代码逃逸分析，堆上的对象

ABA：添加版本号
–自旋浪费处理器资源：自适应自旋

公平性

2 . Java对象头
10：重量级锁
00 ：轻量级锁
1 01：偏向锁
0 01：无锁

3 . 生产消费模型