Java并发指南4：Java中的锁 Lock和synchronized

Java中的锁机制及Lock类

锁的释放-获取创建的happens before 关系

锁是java并发编程中最重要的同步机制。锁除了让临界区互斥执行外，还可让释放锁的线程向获取同一个锁的线程发送消息。

下面是锁释放-获取的示例代码：

class MonitorExample {    int a = 0;     public synchronized void writer() {  //1        a++;                             //2    }                                    //3     public synchronized void reader() {  //4        int i = a;                       //5        ……    }                                    //6} 

根据程序次序规则，1 happens before 2, 2 happens before 3; 4 happens before 5, 5 happens before 6。假设线程A执行writer()方法，随后线程B执行reader()方法。根据happens before规则，这个过程包含的happens before 关系能够分为两类：

1. 根据监视器锁规则，3 happens before 4。
2. 根据happens before 的传递性，2 happens before 5。

上述happens before 关系的图形化表现形式以下：

在上图中，每个箭头连接的两个节点，表明了一个happens before 关系。黑色箭头表示程序顺序规则；橙色箭头表示监视器锁规则；蓝色箭头表示组合这些规则后提供的happens before保证。

上图表示在线程A释放了锁以后，随后线程B获取同一个锁。在上图中，2 happens before 5。所以，线程A在释放锁以前全部可见的共享变量，在线程B获取同一个锁以后，将马上变得对B线程可见。

锁释放和获取的内存语义

当线程释放锁时，JMM会把该线程对应的本地内存中的共享变量刷新到主内存中。以上面的MonitorExample程序为例，A线程释放锁后，共享数据的状态示意图以下：

当线程获取锁时，JMM会把该线程对应的本地内存置为无效。从而使得被监视器保护的临界区代码必需要从主内存中去读取共享变量。下面是锁获取的状态示意图：

对比锁释放-获取的内存语义与volatile写-读的内存语义，能够看出：锁释放与volatile写有相同的内存语义；锁获取与volatile读有相同的内存语义。

下面对锁释放和锁获取的内存语义作个总结：

• 线程A释放一个锁，实质上是线程A向接下来将要获取这个锁的某个线程发出了（线程A对共享变量所作修改的）消息。
• 线程B获取一个锁，实质上是线程B接收了以前某个线程发出的（在释放这个锁以前对共享变量所作修改的）消息。
• 线程A释放锁，随后线程B获取这个锁，这个过程实质上是线程A经过主内存向线程B发送消息。

锁内存语义的实现

本文将借助ReentrantLock的源代码，来分析锁内存语义的具体实现机制。

请看下面的示例代码：

class ReentrantLockExample {int a = 0;ReentrantLock lock = new ReentrantLock(); public void writer() {    lock.lock();         //获取锁    try {        a++;    } finally {        lock.unlock();  //释放锁    }} public void reader () {    lock.lock();        //获取锁    try {        int i = a;        ……    } finally {        lock.unlock();  //释放锁    }}}

在ReentrantLock中，调用lock()方法获取锁；调用unlock()方法释放锁。

ReentrantLock的实现依赖于java同步器框架AbstractQueuedSynchronizer（本文简称之为AQS）。AQS使用一个整型的volatile变量（命名为state）来维护同步状态，立刻咱们会看到，这个volatile变量是ReentrantLock内存语义实现的关键。 下面是ReentrantLock的类图（仅画出与本文相关的部分）：

ReentrantLock分为公平锁和非公平锁，咱们首先分析公平锁。

使用公平锁时，加锁方法lock()的方法调用轨迹以下：

1. ReentrantLock : lock()
2. FairSync : lock()
3. AbstractQueuedSynchronizer : acquire(int arg)
4. ReentrantLock : tryAcquire(int acquires)

在第4步真正开始加锁，下面是该方法的源代码：

protected final boolean tryAcquire(int acquires) {    final Thread current = Thread.currentThread();    int c = getState();   //获取锁的开始，首先读volatile变量state    if (c == 0) {        if (isFirst(current) &&            compareAndSetState(0, acquires)) {            setExclusiveOwnerThread(current);            return true;        }    }    else if (current == getExclusiveOwnerThread()) {        int nextc = c + acquires;        if (nextc < 0)              throw new Error("Maximum lock count exceeded");        setState(nextc);        return true;    }    return false;}

从上面源代码中咱们能够看出，加锁方法首先读volatile变量state。

在使用公平锁时，解锁方法unlock()的方法调用轨迹以下：

1. ReentrantLock : unlock()
2. AbstractQueuedSynchronizer : release(int arg)
3. Sync : tryRelease(int releases)

在第3步真正开始释放锁，下面是该方法的源代码：

protected final boolean tryRelease(int releases) {    int c = getState() - releases;    if (Thread.currentThread() != getExclusiveOwnerThread())        throw new IllegalMonitorStateException();    boolean free = false;    if (c == 0) {        free = true;        setExclusiveOwnerThread(null);    }    setState(c);           //释放锁的最后，写volatile变量state    return free;}

从上面的源代码咱们能够看出，在释放锁的最后写volatile变量state。

公平锁在释放锁的最后写volatile变量state；在获取锁时首先读这个volatile变量。根据volatile的happens-before规则，释放锁的线程在写volatile变量以前可见的共享变量，在获取锁的线程读取同一个volatile变量后将当即变的对获取锁的线程可见。

如今咱们分析非公平锁的内存语义的实现。

非公平锁的释放和公平锁彻底同样，因此这里仅仅分析非公平锁的获取。

使用公平锁时，加锁方法lock()的方法调用轨迹以下：

1. ReentrantLock : lock()
2. NonfairSync : lock()
3. AbstractQueuedSynchronizer : compareAndSetState(int expect, int update)

在第3步真正开始加锁，下面是该方法的源代码：

protected final boolean compareAndSetState(int expect, int update) {    return unsafe.compareAndSwapInt(this, stateOffset, expect, update);}

该方法以原子操做的方式更新state变量，本文把java的compareAndSet()方法调用简称为CAS。JDK文档对该方法的说明以下：若是当前状态值等于预期值，则以原子方式将同步状态设置为给定的更新值。此操做具备 volatile 读和写的内存语义。

这里咱们分别从编译器和处理器的角度来分析,CAS如何同时具备volatile读和volatile写的内存语义。

前文咱们提到过，编译器不会对volatile读与volatile读后面的任意内存操做重排序；编译器不会对volatile写与volatile写前面的任意内存操做重排序。组合这两个条件，意味着为了同时实现volatile读和volatile写的内存语义，编译器不能对CAS与CAS前面和后面的任意内存操做重排序。

下面咱们来分析在常见的intel x86处理器中，CAS是如何同时具备volatile读和volatile写的内存语义的。

下面是sun.misc.Unsafe类的compareAndSwapInt()方法的源代码：

public final native boolean compareAndSwapInt(Object o, long offset,                                              int expected,                                              int x);

能够看到这是个本地方法调用。这个本地方法在openjdk中依次调用的c++代码为：unsafe.cpp，atomic.cpp和atomicwindowsx86.inline.hpp。这个本地方法的最终实如今openjdk的以下位置：openjdk-7-fcs-src-b147-27jun2011openjdkhotspotsrcoscpuwindowsx86vm atomicwindowsx86.inline.hpp（对应于windows操做系统，X86处理器）。下面是对应于intel x86处理器的源代码的片断：

// Adding a lock prefix to an instruction on MP machine// VC++ doesn't like the lock prefix to be on a single line// so we can't insert a label after the lock prefix.// By emitting a lock prefix, we can define a label after it.#define LOCK_IF_MP(mp) __asm cmp mp, 0  \                       __asm je L0      \                       __asm _emit 0xF0 \                       __asm L0: inline jint     Atomic::cmpxchg    (jint     exchange_value, volatile jint*     dest, jint     compare_value) {  // alternative for InterlockedCompareExchange  int mp = os::is_MP();  __asm {    mov edx, dest    mov ecx, exchange_value    mov eax, compare_value    LOCK_IF_MP(mp)    cmpxchg dword ptr [edx], ecx  }}

如上面源代码所示，程序会根据当前处理器的类型来决定是否为cmpxchg指令添加lock前缀。若是程序是在多处理器上运行，就为cmpxchg指令加上lock前缀（lock cmpxchg）。反之，若是程序是在单处理器上运行，就省略lock前缀（单处理器自身会维护单处理器内的顺序一致性，不须要lock前缀提供的内存屏障效果）。

intel的手册对lock前缀的说明以下：

1. 确保对内存的读-改-写操做原子执行。在Pentium及Pentium以前的处理器中，带有lock前缀的指令在执行期间会锁住总线，使得其余处理器暂时没法经过总线访问内存。很显然，这会带来昂贵的开销。从Pentium 4，Intel Xeon及P6处理器开始，intel在原有总线锁的基础上作了一个颇有意义的优化：若是要访问的内存区域（area of memory）在lock前缀指令执行期间已经在处理器内部的缓存中被锁定（即包含该内存区域的缓存行当前处于独占或以修改状态），而且该内存区域被彻底包含在单个缓存行（cache line）中，那么处理器将直接执行该指令。因为在指令执行期间该缓存行会一直被锁定，其它处理器没法读/写该指令要访问的内存区域，所以能保证指令执行的原子性。这个操做过程叫作缓存锁定（cache locking），缓存锁定将大大下降lock前缀指令的执行开销，可是当多处理器之间的竞争程度很高或者指令访问的内存地址未对齐时，仍然会锁住总线。
2. 禁止该指令与以前和以后的读和写指令重排序。
3. 把写缓冲区中的全部数据刷新到内存中。

上面的第2点和第3点所具备的内存屏障效果，足以同时实现volatile读和volatile写的内存语义。

通过上面的这些分析，如今咱们终于能明白为何JDK文档说CAS同时具备volatile读和volatile写的内存语义了。

如今对公平锁和非公平锁的内存语义作个总结：

• 公平锁和非公平锁释放时，最后都要写一个volatile变量state。
• 公平锁获取时，首先会去读这个volatile变量。
• 非公平锁获取时，首先会用CAS更新这个volatile变量,这个操做同时具备volatile读和volatile写的内存语义。

从本文对ReentrantLock的分析能够看出，锁释放-获取的内存语义的实现至少有下面两种方式：

1. 利用volatile变量的写-读所具备的内存语义。
2. 利用CAS所附带的volatile读和volatile写的内存语义。

concurrent包的实现

因为java的CAS同时具备 volatile 读和volatile写的内存语义，所以Java线程之间的通讯如今有了下面四种方式：

1. A线程写volatile变量，随后B线程读这个volatile变量。
2. A线程写volatile变量，随后B线程用CAS更新这个volatile变量。
3. A线程用CAS更新一个volatile变量，随后B线程用CAS更新这个volatile变量。
4. A线程用CAS更新一个volatile变量，随后B线程读这个volatile变量。

Java的CAS会使用现代处理器上提供的高效机器级别原子指令，这些原子指令以原子方式对内存执行读-改-写操做，这是在多处理器中实现同步的关键（从本质上来讲，可以支持原子性读-改-写指令的计算机器，是顺序计算图灵机的异步等价机器，所以任何现代的多处理器都会去支持某种能对内存执行原子性读-改-写操做的原子指令）。同时，volatile变量的读/写和CAS能够实现线程之间的通讯。把这些特性整合在一块儿，就造成了整个concurrent包得以实现的基石。若是咱们仔细分析concurrent包的源代码实现，会发现一个通用化的实现模式：

1. 首先，声明共享变量为volatile；
2. 而后，使用CAS的原子条件更新来实现线程之间的同步；
3. 同时，配合以volatile的读/写和CAS所具备的volatile读和写的内存语义来实现线程之间的通讯。

AQS，非阻塞数据结构和原子变量类（java.util.concurrent.atomic包中的类），这些concurrent包中的基础类都是使用这种模式来实现的，而concurrent包中的高层类又是依赖于这些基础类来实现的。从总体来看，concurrent包的实现示意图以下：

 

synchronized实现原理

 

记得刚刚开始学习Java的时候，一遇到多线程状况就是synchronized，相对于当时的咱们来讲synchronized是这么的神奇而又强大，那个时候咱们赋予它一个名字“同步”，也成为了咱们解决多线程状况的百试不爽的良药。可是，随着咱们学习的进行咱们知道synchronized是一个重量级锁，相对于Lock，它会显得那么笨重，以致于咱们认为它不是那么的高效而慢慢摒弃它。 
诚然，随着Javs SE 1.6对synchronized进行的各类优化后，synchronized并不会显得那么重了。下面跟随LZ一块儿来探索synchronized的实现机制、Java是如何对它进行了优化、锁优化机制、锁的存储结构和升级过程；

实现原理

synchronized能够保证方法或者代码块在运行时，同一时刻只有一个方法能够进入到临界区，同时它还能够保证共享变量的内存可见性

Java中每个对象均可以做为锁，这是synchronized实现同步的基础：

1. 普通同步方法，锁是当前实例对象
2. 静态同步方法，锁是当前类的class对象
3. 同步方法块，锁是括号里面的对象

当一个线程访问同步代码块时，它首先是须要获得锁才能执行同步代码，当退出或者抛出异常时必需要释放锁，那么它是如何来实现这个机制的呢？咱们先看一段简单的代码：

public class SynchronizedTest {    public synchronized void test1(){     }     public void test2(){        synchronized (this){         }    }}

利用javap工具查看生成的class文件信息来分析Synchronized的实现  

从上面能够看出，同步代码块是使用monitorenter和monitorexit指令实现的，同步方法（在这看不出来须要看JVM底层实现）依靠的是方法修饰符上的ACC_SYNCHRONIZED实现。 
同步代码块：monitorenter指令插入到同步代码块的开始位置，monitorexit指令插入到同步代码块的结束位置，JVM须要保证每个monitorenter都有一个monitorexit与之相对应。任何对象都有一个monitor与之相关联，当且一个monitor被持有以后，他将处于锁定状态。线程执行到monitorenter指令时，将会尝试获取对象所对应的monitor全部权，即尝试获取对象的锁； 
同步方法：synchronized方法则会被翻译成普通的方法调用和返回指令如:invokevirtual、areturn指令，在VM字节码层面并无任何特别的指令来实现被synchronized修饰的方法，而是在Class文件的方法表中将该方法的access_flags字段中的synchronized标志位置1，表示该方法是同步方法并使用调用该方法的对象或该方法所属的Class在JVM的内部对象表示Klass作为锁对象。(摘自：http://www.cnblogs.com/javaminer/p/3889023.html)

下面咱们来继续分析，可是在深刻以前咱们须要了解两个重要的概念：Java对象头，Monitor。

Java对象头、monitor

Java对象头和monitor是实现synchronized的基础！下面就这两个概念来作详细介绍。

Java对象头

synchronized用的锁是存在Java对象头里的，那么什么是Java对象头呢？Hotspot虚拟机的对象头主要包括两部分数据：Mark Word（标记字段）、Klass Pointer（类型指针）。其中Klass Point是是对象指向它的类元数据的指针，虚拟机经过这个指针来肯定这个对象是哪一个类的实例，Mark Word用于存储对象自身的运行时数据，它是实现轻量级锁和偏向锁的关键，因此下面将重点阐述

Mark Word。 
Mark Word用于存储对象自身的运行时数据，如哈希码（HashCode）、GC分代年龄、锁状态标志、线程持有的锁、偏向线程 ID、偏向时间戳等等。Java对象头通常占有两个机器码（在32位虚拟机中，1个机器码等于4字节，也就是32bit），可是若是对象是数组类型，则须要三个机器码，由于JVM虚拟机能够经过Java对象的元数据信息肯定Java对象的大小，可是没法从数组的元数据来确认数组的大小，因此用一块来记录数组长度。下图是Java对象头的存储结构（32位虚拟机）： 
 
对象头信息是与对象自身定义的数据无关的额外存储成本，可是考虑到虚拟机的空间效率，Mark Word被设计成一个非固定的数据结构以便在极小的空间内存存储尽可能多的数据，它会根据对象的状态复用本身的存储空间，也就是说，Mark Word会随着程序的运行发生变化，变化状态以下（32位虚拟机）： 

简单介绍了Java对象头，咱们下面再看Monitor。

Monitor

什么是Monitor？咱们能够把它理解为一个同步工具，也能够描述为一种同步机制，它一般被描述为一个对象。 
与一切皆对象同样，全部的Java对象是天生的Monitor，每个Java对象都有成为Monitor的潜质，由于在Java的设计中 ，每个Java对象自打娘胎里出来就带了一把看不见的锁，它叫作内部锁或者Monitor锁。 
Monitor 是线程私有的数据结构，每个线程都有一个可用monitor record列表，同时还有一个全局的可用列表。每个被锁住的对象都会和一个monitor关联（对象头的MarkWord中的LockWord指向monitor的起始地址），同时monitor中有一个Owner字段存放拥有该锁的线程的惟一标识，表示该锁被这个线程占用。其结构以下：  
 
Owner：初始时为NULL表示当前没有任何线程拥有该monitor record，当线程成功拥有该锁后保存线程惟一标识，当锁被释放时又设置为NULL； 
EntryQ:关联一个系统互斥锁（semaphore），阻塞全部试图锁住monitor record失败的线程。 
RcThis:表示blocked或waiting在该monitor record上的全部线程的个数。 
Nest:用来实现重入锁的计数。 
HashCode:保存从对象头拷贝过来的HashCode值（可能还包含GC age）。 
Candidate:用来避免没必要要的阻塞或等待线程唤醒，由于每一次只有一个线程可以成功拥有锁，若是每次前一个释放锁的线程唤醒全部正在阻塞或等待的线程，会引发没必要要的上下文切换（从阻塞到就绪而后由于竞争锁失败又被阻塞）从而致使性能严重降低。Candidate只有两种可能的值0表示没有须要唤醒的线程1表示要唤醒一个继任线程来竞争锁。 
摘自：Java中synchronized的实现原理与应用） 
咱们知道synchronized是重量级锁，效率不怎么滴，同时这个观念也一直存在咱们脑海里，不过在jdk 1.6中对synchronize的实现进行了各类优化，使得它显得不是那么重了，那么JVM采用了那些优化手段呢？

锁优化

jdk1.6对锁的实现引入了大量的优化，如自旋锁、适应性自旋锁、锁消除、锁粗化、偏向锁、轻量级锁等技术来减小锁操做的开销。 
锁主要存在四中状态，依次是：无锁状态、偏向锁状态、轻量级锁状态、重量级锁状态，他们会随着竞争的激烈而逐渐升级。注意锁能够升级不可降级，这种策略是为了提升得到锁和释放锁的效率。

自旋锁

线程的阻塞和唤醒须要CPU从用户态转为核心态，频繁的阻塞和唤醒对CPU来讲是一件负担很重的工做，势必会给系统的并发性能带来很大的压力。同时咱们发如今许多应用上面，对象锁的锁状态只会持续很短一段时间，为了这一段很短的时间频繁地阻塞和唤醒线程是很是不值得的。因此引入自旋锁。 
何谓自旋锁？ 
所谓自旋锁，就是让该线程等待一段时间，不会被当即挂起，看持有锁的线程是否会很快释放锁。怎么等待呢？执行一段无心义的循环便可（自旋）。 
自旋等待不能替代阻塞，先不说对处理器数量的要求（多核，貌似如今没有单核的处理器了），虽然它能够避免线程切换带来的开销，可是它占用了处理器的时间。若是持有锁的线程很快就释放了锁，那么自旋的效率就很是好，反之，自旋的线程就会白白消耗掉处理的资源，它不会作任何有意义的工做，典型的占着茅坑不拉屎，这样反而会带来性能上的浪费。因此说，自旋等待的时间（自旋的次数）必需要有一个限度，若是自旋超过了定义的时间仍然没有获取到锁，则应该被挂起。 
自旋锁在JDK 1.4.2中引入，默认关闭，可是可使用-XX:+UseSpinning开开启，在JDK1.6中默认开启。同时自旋的默认次数为10次，能够经过参数-XX:PreBlockSpin来调整； 
若是经过参数-XX:preBlockSpin来调整自旋锁的自旋次数，会带来诸多不便。假如我将参数调整为10，可是系统不少线程都是等你刚刚退出的时候就释放了锁（假如你多自旋一两次就能够获取锁），你是否是很尴尬。因而JDK1.6引入自适应的自旋锁，让虚拟机会变得愈来愈聪明。

适应自旋锁

JDK 1.6引入了更加聪明的自旋锁，即自适应自旋锁。所谓自适应就意味着自旋的次数再也不是固定的，它是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定。它怎么作呢？线程若是自旋成功了，那么下次自旋的次数会更加多，由于虚拟机认为既然上次成功了，那么这次自旋也颇有可能会再次成功，那么它就会容许自旋等待持续的次数更多。反之，若是对于某个锁，不多有自旋可以成功的，那么在之后要或者这个锁的时候自旋的次数会减小甚至省略掉自旋过程，以避免浪费处理器资源。 
有了自适应自旋锁，随着程序运行和性能监控信息的不断完善，虚拟机对程序锁的情况预测会愈来愈准确，虚拟机会变得愈来愈聪明。

1、自旋锁的概念
首先是一种锁，与互斥锁类似，基本做用是用于线程（进程）之间的同步。与普通锁不一样的是，一个线程A在得到普通锁后，若是再有线程B试图获取锁，那么这个线程B将会挂起（阻塞）；试想下，若是两个线程资源竞争不是特别激烈，而处理器阻塞一个线程引发的线程上下文的切换的代价高于等待资源的代价的时候（锁的已保持者保持锁时间比较短），那么线程B能够不放弃CPU时间片，而是在“原地”忙等，直到锁的持有者释放了该锁，这就是自旋锁的原理，可见自旋锁是一种非阻塞锁。
2、自旋锁可能引发的问题：
1.过多占据CPU时间：若是锁的当前持有者长时间不释放该锁，那么等待者将长时间的占据cpu时间片，致使CPU资源的浪费，所以能够设定一个时间，当锁持有者超过这个时间不释放锁时，等待者会放弃CPU时间片阻塞；
2.死锁问题：试想一下，有一个线程连续两次试图得到自旋锁（好比在递归程序中），第一次这个线程得到了该锁，当第二次试图加锁的时候，检测到锁已被占用（实际上是被本身占用），那么这时，线程会一直等待本身释放该锁，而不能继续执行，这样就引发了死锁。所以递归程序使用自旋锁应该遵循如下原则：递归程序决不能在持有自旋锁时调用它本身，也决不能在递归调用时试图得到相同的自旋锁。

锁消除

为了保证数据的完整性，咱们在进行操做时须要对这部分操做进行同步控制，可是在有些状况下，JVM检测到不可能存在共享数据竞争，这是JVM会对这些同步锁进行锁消除。锁消除的依据是逃逸分析的数据支持。 
若是不存在竞争，为何还须要加锁呢？因此锁消除能够节省毫无心义的请求锁的时间。变量是否逃逸，对于虚拟机来讲须要使用数据流分析来肯定，可是对于咱们程序员来讲这还不清楚么？咱们会在明明知道不存在数据竞争的代码块前加上同步吗？可是有时候程序并非咱们所想的那样？咱们虽然没有显示使用锁，可是咱们在使用一些JDK的内置API时，如StringBuffer、Vector、HashTable等，这个时候会存在隐形的加锁操做。好比StringBuffer的append()方法，Vector的add()方法：

public void vectorTest(){        Vector<String> vector = new Vector<String>();        for(int i = 0 ; i < 10 ; i++){            vector.add(i + "");        }         System.out.println(vector);    }

在运行这段代码时，JVM能够明显检测到变量vector没有逃逸出方法vectorTest()以外，因此JVM能够大胆地将vector内部的加锁操做消除。

锁粗化

咱们知道在使用同步锁的时候，须要让同步块的做用范围尽量小—仅在共享数据的实际做用域中才进行同步，这样作的目的是为了使须要同步的操做数量尽量缩小，若是存在锁竞争，那么等待锁的线程也能尽快拿到锁。 
在大多数的状况下，上述观点是正确的，LZ也一直坚持着这个观点。可是若是一系列的连续加锁解锁操做，可能会致使没必要要的性能损耗，因此引入锁粗话的概念。 
锁粗话概念比较好理解，就是将多个连续的加锁、解锁操做链接在一块儿，扩展成一个范围更大的锁。如上面实例：vector每次add的时候都须要加锁操做，JVM检测到对同一个对象（vector）连续加锁、解锁操做，会合并一个更大范围的加锁、解锁操做，即加锁解锁操做会移到for循环以外。

轻量级锁

引入轻量级锁的主要目的是在多没有多线程竞争的前提下，减小传统的重量级锁使用操做系统互斥量产生的性能消耗。当关闭偏向锁功能或者多个线程竞争偏向锁致使偏向锁升级为轻量级锁，则会尝试获取轻量级锁，其步骤以下： 
获取锁

1. 判断当前对象是否处于无锁状态（hashcode、0、01），如果，则JVM首先将在当前线程的栈帧中创建一个名为锁记录（Lock Record）的空间，用于存储锁对象目前的Mark Word的拷贝（官方把这份拷贝加了一个Displaced前缀，即Displaced Mark Word）；不然执行步骤（3）；
2. JVM利用CAS操做尝试将对象的Mark Word更新为指向Lock Record的指正，若是成功表示竞争到锁，则将锁标志位变成00（表示此对象处于轻量级锁状态），执行同步操做；若是失败则执行步骤（3）；
3. 判断当前对象的Mark Word是否指向当前线程的栈帧，若是是则表示当前线程已经持有当前对象的锁，则直接执行同步代码块；不然只能说明该锁对象已经被其余线程抢占了，这时轻量级锁须要膨胀为重量级锁，锁标志位变成10，后面等待的线程将会进入阻塞状态；

释放锁 
轻量级锁的释放也是经过CAS操做来进行的，主要步骤以下：

1. 取出在获取轻量级锁保存在Displaced Mark Word中的数据；
2. 用CAS操做将取出的数据替换当前对象的Mark Word中，若是成功，则说明释放锁成功，不然执行（3）；
3. 若是CAS操做替换失败，说明有其余线程尝试获取该锁，则须要在释放锁的同时须要唤醒被挂起的线程。

对于轻量级锁，其性能提高的依据是“对于绝大部分的锁，在整个生命周期内都是不会存在竞争的”，若是打破这个依据则除了互斥的开销外，还有额外的CAS操做，所以在有多线程竞争的状况下，轻量级锁比重量级锁更慢；

• • *

下图是轻量级锁的获取和释放过程 

偏向锁

引入偏向锁主要目的是：为了在无多线程竞争的状况下尽可能减小没必要要的轻量级锁执行路径。上面提到了轻量级锁的加锁解锁操做是须要依赖屡次CAS原子指令的。那么偏向锁是如何来减小没必要要的CAS操做呢？咱们能够查看Mark work的结构就明白了。只须要检查是否为偏向锁、锁标识为以及ThreadID便可，处理流程以下： 
获取锁

1. 检测Mark Word是否为可偏向状态，便是否为偏向锁1，锁标识位为01；
2. 若为可偏向状态，则测试线程ID是否为当前线程ID，若是是，则执行步骤（5），不然执行步骤（3）；
3. 若是线程ID不为当前线程ID，则经过CAS操做竞争锁，竞争成功，则将Mark Word的线程ID替换为当前线程ID，不然执行线程（4）；
4. 经过CAS竞争锁失败，证实当前存在多线程竞争状况，当到达全局安全点，得到偏向锁的线程被挂起，偏向锁升级为轻量级锁，而后被阻塞在安全点的线程继续往下执行同步代码块；
5. 执行同步代码块

释放锁 
偏向锁的释放采用了一种只有竞争才会释放锁的机制，线程是不会主动去释放偏向锁，须要等待其余线程来竞争。偏向锁的撤销须要等待全局安全点（这个时间点是上没有正在执行的代码）。其步骤以下：

1. 暂停拥有偏向锁的线程，判断锁对象石是否还处于被锁定状态；
2. 撤销偏向苏，恢复到无锁状态（01）或者轻量级锁的状态；

• • *

下图是偏向锁的获取和释放流程 

重量级锁

重量级锁经过对象内部的监视器（monitor）实现，其中monitor的本质是依赖于底层操做系统的Mutex Lock实现，操做系统实现线程之间的切换须要从用户态到内核态的切换，切换成本很是高。

参考资料

1. 周志明：《深刻理解Java虚拟机》
2. 方腾飞：《Java并发编程的艺术》
3. Java中synchronized的实现原理与应用

更多内容请关注微信公众号【Java技术江湖】

一位阿里 Java 工程师的技术小站。做者黄小斜，专一 Java 相关技术：SSM、SpringBoot、MySQL、分布式、中间件、集群、Linux、网络、多线程，偶尔讲点Docker、ELK，同时也分享技术干货和学习经验，致力于Java全栈开发！（关注公众号后回复”Java“便可领取 Java基础、进阶、项目和架构师等免费学习资料，更有数据库、分布式、微服务等热门技术学习视频，内容丰富，兼顾原理和实践，另外也将赠送做者原创的Java学习指南、Java程序员面试指南等干货资源）