synchronized 概述

synchronized关键字提供了一种独占式的加锁方式，用来控制多个线程对共享资源的互斥访问。它可以保证在同一时刻只有一个线程在执行该段代码，同时它还可以保证共享变量的内存可见性。

互斥性：同一时刻只允许一个线程持有某个对象锁，一次实现对共享资源的互斥访问。

可见性：确保在锁释放前，对共享变量做的修改，对随后获得该锁的另一个线程是可见的。

synchronized的获取和释放锁由JVM实现，用户不需要显示的获取和释放锁，非常方便。但是当线程尝试获取锁的时候，如果获取不到锁该线程会一直阻塞。

在早期版本中，synchronized是一个重量级锁，效率低下。但从JDK1.6开始，从JVM层面对synchronized引入了各种锁优化技术，例如：自旋锁、适应性自旋锁、锁消除、锁粗化、轻量级锁和偏向锁等，大大减少了锁操作的开销。

使用方式

1.同步代码块

2.同步方法

3.同步静态方法

使用方式

如上图

来逐个分析

首先看一下上面代码反编译输出

我们输入javap -c -v SynchronizedTest

类信息

方法信息

代码块方法信息

如上图,可以看到用synchronized修饰方法之后的反编译结果里面，重点是出现了ACC_SYNCHRONIZED。

ACC_SYNCHRONIZED代表此方法是同步方法，如果是静态方法，则多一个ACC_STATIC，代表是静态同步方法，区别就是静态同步方法是针对Class进行同步的，普通方法是针对类实例进行同步的，在new出两个对象的时候，实例就属于不同的实例，此时synchronized修饰的普通方法就会失去同步的作用。

而代码块修饰的结果是出现了三行monitor相关指令，一行monitorenter与两行monitorexit。

这里的原理在于monitor对象，每一个对象都会有一个专属的monitor监视对象。

至于monitorexit为什么会出现两次，第二次是针对异常的处理指令，保证异常退出的时候也会执行到exit。

所以综述如下：

Java 虚拟机中的同步(Synchronization)基于进入和退出管程(Monitor)对象实现， 无论是显式同步(有明确的 monitorenter 和 monitorexit 指令,即同步代码块)还是隐式同步都是如此。在 Java 语言中，同步用的最多的地方可能是被 synchronized 修饰的同步方法。同步方法 并不是由 monitorenter 和 monitorexit 指令来实现同步的，而是由方法调用指令读取运行时常量池中方法的 ACC_SYNCHRONIZED 标志来隐式实现的，关于这点，稍后详细分析。下面先来了解一个概念Java对象头，这对深入理解synchronized实现原理非常关键。

原理理论基础

在JVM中，对象在内存中的布局分为三块区域：对象头、实例数据和对齐填充。如下

对象头

实例变量：存放类的属性数据信息，包括父类的属性信息，如果是数组的实例部分还包括数组的长度，这部分内存按4字节对齐。

填充数据：由于虚拟机要求对象起始地址必须是8字节的整数倍。填充数据不是必须存在的，仅仅是为了字节对齐，这点了解即可。

而对于顶部，则是Java头对象，它实现synchronized的锁对象的基础，这点我们重点分析它，一般而言，synchronized使用的锁对象是存储在Java对象头里的，jvm中采用2个字来存储对象头(如果对象是数组则会分配3个字，多出来的1个字记录的是数组长度)，其主要结构是由Mark Word 和 Class Metadata Address 组成，其结构说明如下表：

其中Mark Word在默认情况下存储着对象的HashCode、分代年龄、锁标记位等以下是32位JVM的Mark Word默认存储结构

由于对象头的信息是与对象自身定义的数据没有关系的额外存储成本，因此考虑到JVM的空间效率，Mark Word 被设计成为一个非固定的数据结构，以便存储更多有效的数据，它会根据对象本身的状态复用自己的存储空间，如32位JVM下，除了上述列出的Mark Word默认存储结构外，还有如下可能变化的结构：

其中轻量级锁和偏向锁是Java 6 对 synchronized 锁进行优化后新增加的，稍后我们会简要分析。这里我们主要分析一下重量级锁也就是通常说synchronized的对象锁，锁标识位为10，其中指针指向的是monitor对象（也称为管程或监视器锁）的起始地址。每个对象都存在着一个 monitor 与之关联，对象与其 monitor 之间的关系有存在多种实现方式，如monitor可以与对象一起创建销毁或当线程试图获取对象锁时自动生成，但当一个 monitor 被某个线程持有后，它便处于锁定状态。在Java虚拟机(HotSpot)中，monitor是由ObjectMonitor实现的，其主要数据结构如下（位于HotSpot虚拟机源码ObjectMonitor.hpp文件，C++实现的）

ObjectMonitor

ObjectMonitor中有两个队列，_WaitSet 和 _EntryList，用来保存ObjectWaiter对象列表( 每个等待锁的线程都会被封装成ObjectWaiter对象)，_owner指向持有ObjectMonitor对象的线程，当多个线程同时访问一段同步代码时，首先会进入 _EntryList 集合，当线程获取到对象的monitor 后进入 _Owner 区域并把monitor中的owner变量设置为当前线程同时monitor中的计数器count加1，若线程调用 wait() 方法，将释放当前持有的monitor，owner变量恢复为null，count自减1，同时该线程进入 WaitSe t集合中等待被唤醒。若当前线程执行完毕也将释放monitor(锁)并复位变量的值，以便其他线程进入获取monitor(锁)。如下图所示

由此看来，monitor对象存在于每个Java对象的对象头中(存储的指针的指向)，synchronized锁便是通过这种方式获取锁的，也是为什么Java中任意对象可以作为锁的原因，同时也是notify/notifyAll/wait等方法存在于顶级对象Object中的原因(关于这点稍后还会进行分析)，ok~，有了上述知识基础后，下面我们将进一步分析synchronized在字节码层面的具体语义实现。

同步块修饰详细原理

从上面反编译结果图中可知同步语句块的实现使用的是monitorenter 和 monitorexit 指令，其中monitorenter指令指向同步代码块的开始位置，monitorexit指令则指明同步代码块的结束位置，当执行monitorenter指令时，当前线程将试图获取 objectref(即对象锁) 所对应的 monitor 的持有权，当 objectref 的 monitor 的进入计数器为 0，那线程可以成功取得 monitor，并将计数器值设置为 1，取锁成功。如果当前线程已经拥有 objectref 的 monitor 的持有权，那它可以重入这个 monitor (关于重入性稍后会分析)，重入时计数器的值也会加 1。倘若其他线程已经拥有 objectref 的 monitor 的所有权，那当前线程将被阻塞，直到正在执行线程执行完毕，即monitorexit指令被执行，执行线程将释放 monitor(锁)并设置计数器值为0 ，其他线程将有机会持有 monitor 。值得注意的是编译器将会确保无论方法通过何种方式完成，方法中调用过的每条 monitorenter 指令都有执行其对应 monitorexit 指令，而无论这个方法是正常结束还是异常结束。为了保证在方法异常完成时 monitorenter 和 monitorexit 指令依然可以正确配对执行，编译器会自动产生一个异常处理器，这个异常处理器声明可处理所有的异常，它的目的就是用来执行 monitorexit 指令。从字节码中也可以看出多了一个monitorexit指令，它就是异常结束时被执行的释放monitor 的指令。

方法修饰详细原理

synchronized修饰的方法并没有monitorenter指令和monitorexit指令，取得代之的确实是ACC_SYNCHRONIZED标识，该标识指明了该方法是一个同步方法，JVM通过该ACC_SYNCHRONIZED访问标志来辨别一个方法是否声明为同步方法，从而执行相应的同步调用。这便是synchronized锁在同步代码块和同步方法上实现的基本原理。同时我们还必须注意到的是在Java早期版本中，synchronized属于重量级锁，效率低下，因为监视器锁（monitor）是依赖于底层的操作系统的Mutex Lock来实现的，而操作系统实现线程之间的切换时需要从用户态转换到核心态，这个状态之间的转换需要相对比较长的时间，时间成本相对较高，这也是为什么早期的synchronized效率低的原因。庆幸的是在Java 6之后Java官方对从JVM层面对synchronized较大优化，所以现在的synchronized锁效率也优化得很不错了，Java 6之后，为了减少获得锁和释放锁所带来的性能消耗，引入了轻量级锁和偏向锁，接下来我们将简单了解一下Java官方在JVM层面对synchronized锁的优化。

底层优化

JDK1.6对锁引入了大量的优化，如自旋锁、自适应自旋锁、锁消除、锁粗化、轻量级锁、偏向锁等技术来减少锁操作的开销。

自旋锁和自适应自旋

在实现同步互斥时，如果获取锁失败，就会使当前线程阻塞，但线程的挂起和恢复都需要在内核态和用户态之间转换，对系统的性能影响很大。许多情况下共享数据的锁定状态持续时间不会很长，切换线程不值得。

自旋锁就是让线程在请求共享数据的锁时执行一个忙循环（自旋），如果能够很快获得锁，就避免其进入阻塞状态。

自旋等待虽然避免了线程切换的开销，但它要求多处理器，而且要占用处理器时间。如果锁占用时间过长，那么反而会消耗更多的资源。因此，对自旋等待的时间必须进行限制，另外自旋的次数也不能过多，默认为10次，可使用-XX:PreBlockSpin参数修改。

JDK1.6中引入了自适应的自旋锁，它的自旋时间由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定。

锁消除

锁消除是指虚拟机的即时编译器在运行时，如果代码要求同步，但检测发现不可能存在共享数据竞争时，那么就进行锁消除。

锁消除主要根据逃逸分析，如果判断在一段代码中，堆上的所有数据都不会逃逸出去，那就可以将它们认为是线程私有的，也就无须进行同步加锁。

锁粗化

如果一系列的连续操作都对同一个对象反复加锁和解锁，甚至加锁也是出现循环体中，那么即使没有数据竞争，频繁地加锁解锁也会导致不必须的性能消耗。

锁粗化指的就是如果虚拟机探测到这样的情况，那就将加锁同步的范围扩展（粗化）到整个操作序列的外部。

偏向锁

偏向锁是在无竞争的情况下消除整个同步，也就是减少同一线程获取锁的代价。它的思想是这个锁会偏向于第一个获得它的线程，如果接下来该锁没有被其他的线程获取，则持有偏向锁的线程将永远不需要再进行同步。

当锁对象第一次被线程获取时，锁进入偏向模式，同时 Mard Word 的结构也变为偏向锁结构。锁标志位为“01”，同时使用CAS操作把获取到这个锁的线程的ID记录在对象的Mark Word中，如果CAS操作成功，这个线程以后每次进入这个锁相关的同步块时，都可以不用再进行任何同步操作。

不适用于锁竞争比较激烈的多线程场合。

当有另外一个线程去尝试获取这个锁对象时，偏向状态就宣告结束。根据锁对象目前是否处于被锁定的状态，撤销偏向后恢复到未锁定状态或者轻量级锁状态。

轻量级锁

倘若偏向锁失败，虚拟机并不会立即升级为重量级锁，它还会尝试使用一种称为轻量级锁的优化手段(1.6之后加入的)，此时Mark Word 的结构也变为轻量级锁的结构。轻量级锁能够提升程序性能的依据是“对绝大部分的锁，在整个同步周期内都不存在竞争”，注意这是经验数据。需要了解的是，轻量级锁所适应的场景是线程交替执行同步块的场合，如果存在同一时间访问同一锁的场合，就会导致轻量级锁膨胀为重量级锁。