[转]Java中的CAS操作以及锁机制详解

原文： Dyson~ - Java中的CAS操作以及锁机制详解

1. 关于CAS操作

• CAS：Compare And Swap -- 乐观锁策略
• CAS（无锁操作）：使用CAS叫做比较交换来判断是否出现冲突，出现冲突就重试当前操作直到不冲突为止。
• 悲观锁（JDK1.6之前的内建锁）：假设每一次执行同步代码块均会产生冲突，所以当线程获取锁成功，会阻塞其他尝试获取该锁的线程。
• 乐观锁（Lock机制）：假设所有线程访问共享资源时不会出现冲突，既然不会出现冲突自然就不会阻塞其他线程。线程不会出现阻塞状态。

1.1 CAS的操作过程

CAS的操作过程和（V，O，N）三个值有关

·	V	O	N
具体含义	内存中地址存放的实际值	预期值（旧值）	更新后的值

下面就介绍一下操作的具体过程：

CAS在最开始的时候V和O的是相等的，N中的每次线程要进行CAS操作时要新放入的值。当要进行CAS操作时，要先判断一下V和O，若相等，说明没有V中的值还没有被其他线程更改，这时就可以将N中的值替换到V中。若不相等表明N中的值已经被其他的线程所更改，这时直接将N中的值返回即可；

当多个线程同时进行CAS操作时，只有一个线程会成功，并且更新V的值，其余的线程会失败。失败后可以选择不断的进行CAS操作，也可以直接挂起进行等待；

CAS操作与内建锁的对比：

类型	描述
元老级的内建锁（synchronized）	当存在线程竞争的情况下会出现线程阻塞以及唤醒带来的性能问题，对应互斥同步（阻塞同步），效率很低。
CAS操作	并不会直接挂起线程，会尝试若干次CAS操作，并非进行耗时的挂起与唤醒操作，因此非阻塞式同步。

1.2 引入CAS所造成的问题

1.2.1 关于ABA问题，如下图所示

解决思路：沿用数据库的乐观锁机制，添加版本号 1A-2B-3A

JDK1.5提供atomic包下AtomicMarkableReference和AtomicStampedReference类来解决CAS的ABA问题

• AtomicMarkableReference boolean 有没有发生变化
• AtomicStampedReference int 发生过几次变化

AtomicStampedReference<String> asr = new AtomicStampedReference<>("Mark",0);
int oldStamp = asr.getStamp(); //初始的版本号
String oldReferenc = asr.getReference(); // 值
// 更新
asr.compareAndSet(oldReferenc, oldReferenc + "Java", oldStamp, oldStamp + 1));

1.2.2 自旋（CAS）会浪费大量的处理器资源（CPU） 简单来说就是太耗费时间

自旋与阻塞：举个栗子来说，当你开车到了一个十字路口时，这时发现亮的是红灯，那么这时的你就有两种选择，要么将车子直接熄火等待，要么踩住刹车等待；而这时的熄火和刹车就相当于阻塞和自旋，那么我们该如何去选择使用哪种处理方法呢？当又回到刚才的栗子，当你到达十字路口时发现，额的神呀，今天的红灯的等待时间竟然有半个小时，这时你二话不说将车子熄火，自己蒙头大睡来等待红灯；但是当你发现红灯只有10秒钟时，你就会选择踩住刹车来等待红灯；你这里的处理机制就是在不同的情况下，哪种方法使得车子耗油最少就选择哪个方法。又回到主题上，所以不能说自旋就一定会比阻塞的性能好。

为了解决这个问题，CPU就采取了一种处理机制：自适应自旋（根据以往自旋等待时能否获取到锁，来动态调整自旋的时间（循环尝试数量））

自适应自旋和出现其实也是与现实生活相关的，再次回到上个栗子中，如果之前不熄火等到了绿灯，那么这次不熄火的时间就长一点，多等会也没事；如果之前不熄火没等待绿灯， 那么这次不熄火的时间就短一点。自适应自旋也是如此，如果在上一次自旋时获取到锁，则此次自旋时间稍微变长一点；如果在上一次自旋结束还没有获取到锁，此次自旋时间稍微短一点。

1.2.3 关于公平性

公平性就可以这样理解：

模式	描述
公平模式	比如一个锁被很多线程等待是时，锁会选择等待时间最长的线程访问它的临界资源，可以和队列类比一下理解为先到先得原则（lock锁）它就是公平的。
非公平模式	而当一个锁是可以被后来的线程抢占时，它就是非公平性的，比如内建锁（饥饿问题：由于访问权限总是分配给了其他线程，而造成一个或多个线程被饿死的现象）。

自旋也是一种不公平的模式：处于阻塞状态的线程无法立刻竞争被释放的锁；而处于自旋状态的线程很有可能先获取到锁。

2. Java锁机制

2.1 Java对象头（包括标记字段和类型指针）

2.1.1 关于Mark Word

Mark Word(标记字段)：用于存储运行时对象自身的数据，相当于线程在运行时贴上自己的标签，别的线程不可用，其占用内存大小与虚拟机位长一致，在运行期间，考虑到JVM的空间效率，Mark Word被设计成为一个非固定的数据结构，以便存储更多有效的数据。

2.1.2 存储运行时对象自身数据（重量级锁JDK1.6之前）

关于Epoch：Epoch 默认最大值为40，到超过40后会变成轻量级锁

2.1.3 关于锁的升级

为了提高获得锁与释放锁的效率，JDK1.6之后对内建锁做了优化（新增偏向，轻量级锁），所以在 Java SE1.6 里锁一共有四种状态，无锁状态，偏向锁状态，轻量级锁状态和重量级锁状态，它会随着竞争情况逐渐升级，锁可以升级不能降级，意味着偏向锁升级成轻量级锁后不能降级成偏向锁。这种锁升级却不能降级的策略，目的是为了提高获得锁和释放锁的效率

2.2 偏向锁

偏向锁：最乐观的锁，从始至终只有一个线程请求一把锁。

偏向锁获取，如下图：

偏向锁获取流程

当一个线程访问同步代码块并获取锁时，会在对象头的栈帧中的锁记录中 记录存储偏向锁的线程ID 。以后该线程再次进入同步块时不再需要CAS来加锁和解锁，只需简单测试一下对象头的mark word中偏向锁线程ID是否是当前线程ID，

• 如果成功，表示线程已获取到锁直接进入代码块运行。
• 如果测试失败，检查当前偏向锁字段是否为0，如果为0，将偏向锁字段设置为1，并且更新自己的线程ID到mark word字段当中
• 如果为1，表示此时偏向锁已经被别的线程获取。则此线程不断尝试使用CAS获取偏向锁或者将偏向锁撤销，升级为轻量级锁（升级概率较大）。

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

小tips：偏向锁的撤销开销较大，需要等待线程进入全局安全点safepoint（当前线程在CPU上没有执行任何有用字节码）

偏向锁从JDK1.6默认开启，但是它在应用程序几秒后才激活。

# JVM锁升级参数
-XX：BiasedLockingStartupDelay=0，将延迟关闭，JVM一启动就激活偏向锁
-XX：-UseBiasedLocking=false，关闭偏向锁，程序默认进入轻量级锁。

偏向锁的获得和撤销流程

偏向锁的获得和撤销流程

2.3 轻量级锁 减少多线程进入互斥（mutex）的几率

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

只要在同一时间内有线程去竞争锁，那么线程执行一次CAS操作，然后发现已经被别的线程抢占，直接升级为重量级锁，不在进行CAS操作；

偏向锁的获得和撤销流程

轻量级锁及膨胀流程图

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

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

三种锁的对比：

锁	优点	缺点	适用场景
偏向锁	加锁和解锁不需要额外的消耗，和执行非同步方法比仅存在纳秒级的差距。	如果线程间存在锁竞争，会带来额外的锁撤销的消耗。	适用于一个线程访问同步代码块
轻量级锁	竞争的线程不会阻塞，提高了程序的响应速度。	如果始终得不到锁竞争的线程使用自旋会消耗CPU。	响应时间很短，同步块执行速度非常快，适用于多个线程在不同时间段申请同一把锁
重量级锁	线程竞争不使用自旋，不会消耗CPU。	线程阻塞，响应时间缓慢。	追求吞吐量。同步块执行速度较长。

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

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

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

CAS的问题
A---》B----》A，版本号: A1B2-A3
CAS操作长期不成功，cpu不断的循环，
Jdk中相关原子操作类的使用
AtomicMarkableReference，boolean 有没有动过
AtomicStampedReference 动过几次