CAS原理 Java SE1.6中的Synchronized

在JDK 5以前Java语言是靠synchronized关键字保证同步的，这会致使有锁（后面的章节还会谈到锁）。

锁机制存在如下问题：

（1）在多线程竞争下，加锁、释放锁会致使比较多的上下文切换和调度延时，引发性能问题。

（2）一个线程持有锁会致使其它全部须要此锁的线程挂起。

（3）若是一个优先级高的线程等待一个优先级低的线程释放锁会致使优先级倒置，引发性能风险。

volatile是不错的机制，可是volatile不能保证原子性。所以对于同步最终仍是要回到锁机制上来。

独占锁是一种悲观锁，synchronized就是一种独占锁，会致使其它全部须要锁的线程挂起，等待持有锁的线程释放锁。而另外一个更加有效的锁就是乐观锁。所谓乐观锁就是，每次不加锁而是假设没有冲突而去完成某项操做，若是由于冲突失败就重试，直到成功为止。

CAS 操做

上面的乐观锁用到的机制就是CAS，Compare and Swap。

CAS有3个操做数，内存值V，旧的预期值A，要修改的新值B。当且仅当预期值A和内存值V相同时，将内存值V修改成B，不然什么都不作。

非阻塞算法 （nonblocking algorithms）

一个线程的失败或者挂起不该该影响其余线程的失败或挂起的算法。

现代的CPU提供了特殊的指令，能够自动更新共享数据，并且可以检测到其余线程的干扰，而 compareAndSet() 就用这些代替了锁定。

拿出AtomicInteger来研究在没有锁的状况下是如何作到数据正确性的。

private volatile int value;

首先毫无觉得，在没有锁的机制下可能须要借助volatile原语，保证线程间的数据是可见的（共享的）。这样才获取变量的值的时候才能直接读取。

public final int get() {
        return value;
    }

而后来看看++i是怎么作到的。

public final int incrementAndGet() {
    for (;;) {
        int current = get();
        int next = current + 1;
        if (compareAndSet(current, next))
            return next;
    }
}

在这里采用了CAS操做，每次从内存中读取数据而后将此数据和+1后的结果进行CAS操做，若是成功就返回结果，不然重试直到成功为止。

而compareAndSet利用JNI来完成CPU指令的操做。

public final boolean compareAndSet(int expect, int update) {   
    return unsafe.compareAndSwapInt(this, valueOffset, expect, update);
    }

总体的过程就是这样子的，利用CPU的CAS指令，同时借助JNI来完成Java的非阻塞算法。其它原子操做都是利用相似的特性完成的。

而整个J.U.C都是创建在CAS之上的，所以对于synchronized阻塞算法，J.U.C在性能上有了很大的提高。

CAS看起来很爽，可是会致使“ABA问题”。

CAS算法实现一个重要前提须要取出内存中某时刻的数据，而在下时刻比较并替换，那么在这个时间差类会致使数据的变化。

好比说一个线程one从内存位置V中取出A，这时候另外一个线程two也从内存中取出A，而且two进行了一些操做变成了B，而后two又将V位置的数据变成A，这时候线程one进行CAS操做发现内存中仍然是A，而后one操做成功。尽管线程one的CAS操做成功，可是不表明这个过程就是没有问题的。若是链表的头在变化了两次后恢复了原值，可是不表明链表就没有变化。所以前面提到的原子操做AtomicStampedReference/AtomicMarkableReference就颇有用了。这容许一对变化的元素进行原子操做。

可扩展阅读：http://ifeve.com/java-synchronized/

本文属做者原创，原文发表于InfoQ：http://www.infoq.com/cn/articles/java-se-16-synchronized

1 引言

在多线程并发编程中Synchronized一直是元老级角色，不少人都会称呼它为重量级锁，可是随着Java SE1.6对Synchronized进行了各类优化以后，有些状况下它并不那么重了，本文详细介绍了Java SE1.6中为了减小得到锁和释放锁带来的性能消耗而引入的偏向锁和轻量级锁，以及锁的存储结构和升级过程。

2 术语定义

术语	英文	说明
CAS	Compare and Swap	比较并设置。用于在硬件层面上提供原子性操做。在 Intel 处理器中，比较并交换经过指令cmpxchg实现。比较是否和给定的数值一致，若是一致则修改，不一致则不修改。

3 同步的基础

Java中的每个对象均可以做为锁。

• 对于同步方法，锁是当前实例对象。
• 对于静态同步方法，锁是当前对象的Class对象。
• 对于同步方法块，锁是Synchonized括号里配置的对象。

当一个线程试图访问同步代码块时，它首先必须获得锁，退出或抛出异常时必须释放锁。那么锁存在哪里呢？锁里面会存储什么信息呢？

4 同步的原理

JVM规范规定JVM基于进入和退出Monitor对象来实现方法同步和代码块同步，但二者的实现细节不同。代码块同步是使用monitorenter和monitorexit指令实现，而方法同步是使用另一种方式实现的，细节在JVM规范里并无详细说明，可是方法的同步一样可使用这两个指令来实现。monitorenter指令是在编译后插入到同步代码块的开始位置，而monitorexit是插入到方法结束处和异常处， JVM要保证每一个monitorenter必须有对应的monitorexit与之配对。任何对象都有一个 monitor 与之关联，当且一个monitor 被持有后，它将处于锁定状态。线程执行到 monitorenter 指令时，将会尝试获取对象所对应的 monitor 的全部权，即尝试得到对象的锁。

4.1 Java对象头

锁存在Java对象头里。若是对象是数组类型，则虚拟机用3个Word（字宽）存储对象头，若是对象是非数组类型，则用2字宽存储对象头。在32位虚拟机中，一字宽等于四字节，即32bit。

长度	内容	说明
32/64bit	Mark Word	存储对象的hashCode或锁信息等。
32/64bit	Class Metadata Address	存储到对象类型数据的指针
32/64bit	Array length	数组的长度（若是当前对象是数组）

Java对象头里的Mark Word里默认存储对象的HashCode，分代年龄和锁标记位。32位JVM的Mark Word的默认存储结构以下：

	25 bit	4bit	1bit是不是偏向锁	2bit锁标志位
无锁状态	对象的hashCode	对象分代年龄	0	01

在运行期间Mark Word里存储的数据会随着锁标志位的变化而变化。Mark Word可能变化为存储如下4种数据：

锁状态	25 bit	4bit	1bit	2bit
23bit	2bit	是不是偏向锁	锁标志位
轻量级锁	指向栈中锁记录的指针	00
重量级锁	指向互斥量（重量级锁）的指针	10
GC标记	空	11
偏向锁	线程ID	Epoch	对象分代年龄	1	01

在64位虚拟机下，Mark Word是64bit大小的，其存储结构以下：

锁状态	25bit	31bit	1bit	4bit	1bit	2bit
		cms_free	分代年龄	偏向锁	锁标志位
无锁	unused	hashCode			0	01
偏向锁	ThreadID(54bit) Epoch(2bit)			1	01

4.2 锁的升级

Java SE1.6为了减小得到锁和释放锁所带来的性能消耗，引入了“偏向锁”和“轻量级锁”，因此在Java SE1.6里锁一共有四种状态，无锁状态，偏向锁状态，轻量级锁状态和重量级锁状态，它会随着竞争状况逐渐升级。锁能够升级但不能降级，意味着偏向锁升级成轻量级锁后不能降级成偏向锁。这种锁升级却不能降级的策略，目的是为了提升得到锁和释放锁的效率，下文会详细分析。

4.3 偏向锁

Hotspot的做者通过以往的研究发现大多数状况下锁不只不存在多线程竞争，并且老是由同一线程屡次得到，为了让线程得到锁的代价更低而引入了偏向锁。当一个线程访问同步块并获取锁时，会在对象头和栈帧中的锁记录里存储锁偏向的线程ID，之后该线程在进入和退出同步块时不须要花费CAS操做来加锁和解锁，而只需简单的测试一下对象头的Mark Word里是否存储着指向当前线程的偏向锁，若是测试成功，表示线程已经得到了锁，若是测试失败，则须要再测试下Mark Word中偏向锁的标识是否设置成1（表示当前是偏向锁），若是没有设置，则使用CAS竞争锁，若是设置了，则尝试使用CAS将对象头的偏向锁指向当前线程。

偏向锁的撤销：偏向锁使用了一种等到竞争出现才释放锁的机制，因此当其余线程尝试竞争偏向锁时，持有偏向锁的线程才会释放锁。偏向锁的撤销，须要等待全局安全点（在这个时间点上没有字节码正在执行），它会首先暂停拥有偏向锁的线程，而后检查持有偏向锁的线程是否活着，若是线程不处于活动状态，则将对象头设置成无锁状态，若是线程仍然活着，拥有偏向锁的栈会被执行，遍历偏向对象的锁记录，栈中的锁记录和对象头的Mark Word要么从新偏向于其余线程，要么恢复到无锁或者标记对象不适合做为偏向锁，最后唤醒暂停的线程。下图中的线程1演示了偏向锁初始化的流程，线程2演示了偏向锁撤销的流程。

关闭偏向锁：偏向锁在Java 6和Java 7里是默认启用的，可是它在应用程序启动几秒钟以后才激活，若有必要可使用JVM参数来关闭延迟-XX：BiasedLockingStartupDelay = 0。若是你肯定本身应用程序里全部的锁一般状况下处于竞争状态，能够经过JVM参数关闭偏向锁-XX:-UseBiasedLocking=false，那么默认会进入轻量级锁状态。

4.4 轻量级锁

轻量级锁加锁：线程在执行同步块以前，JVM会先在当前线程的栈桢中建立用于存储锁记录的空间，并将对象头中的Mark Word复制到锁记录中，官方称为Displaced Mark Word。而后线程尝试使用CAS将对象头中的Mark Word替换为指向锁记录的指针。若是成功，当前线程得到锁，若是失败，表示其余线程竞争锁，当前线程便尝试使用自旋来获取锁。

轻量级锁解锁：轻量级解锁时，会使用原子的CAS操做来将Displaced Mark Word替换回到对象头，若是成功，则表示没有竞争发生。若是失败，表示当前锁存在竞争，锁就会膨胀成重量级锁。下图是两个线程同时争夺锁，致使锁膨胀的流程图。

由于自旋会消耗CPU，为了不无用的自旋（好比得到锁的线程被阻塞住了），一旦锁升级成重量级锁，就不会再恢复到轻量级锁状态。当锁处于这个状态下，其余线程试图获取锁时，都会被阻塞住，当持有锁的线程释放锁以后会唤醒这些线程，被唤醒的线程就会进行新一轮的夺锁之争。

5 锁的优缺点对比

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

6 参考源码

本文一些内容参考了HotSpot源码 。对象头源码markOop.hpp。偏向锁源码biasedLocking.cpp。以及其余源码ObjectMonitor.cpp和BasicLock.cpp。

7 参考资料

• 偏向锁
• java-overview-and-java-se6 Synchronization Optimization章节
• Dave Dice “Synchronization in Java SE 6”
• Java SE 6 Performance White Paper 2.1章节
• JVM规范（Java SE 7）
• Java语言规范（JAVA SE7）
• 周志明的《深刻理解Java虚拟机》
• Java偏向锁实现原理
• hotspot Synchronization

（全文完）若是您喜欢此文请点赞，分享，评论。