java并发之synchronized

synchronized，在java并发编程中它一直都是元老级的角色。但是在大多数时候，如果能使用Lock大家可能都不会使用它，因为它是个重量级锁。但是随着jdk6引入偏向锁和轻量级锁，对它进行了各种优化之后，在一些情况下它并不是那么重了。本文将结合HotSpot 1.7源码，详细分析jdk6做出的相关优化。

synchronized实现分析

在开始分析synchronized具体实现之前，先了解一下java同步的基础。

Java同步基础

在java中，每一个对象其实都可以作为锁：

• 对于同步方法，锁就是当前的实例对象；

• 对于静态同步方法，锁就是当前对象的Class对象；

• 对于同步方法块，锁是synchronized括号里的对象。

当一个线程尝试去访问同步代码块儿时，首先需要干的事儿就是得到锁，然后在程序执行完毕或者抛出异常时释放锁，那么现在问题就来了，锁存放在哪里呢？锁需要存储什么信息呢？

synchronized字节码分析

javap命令反编译后的字节码：

从上图可以看出，字节码中包含指令monitorenter和moniterexit。synchronized关键字基于这两个指令实现了代码同步块锁的获取和释放。

注：在JVM规范中，代码块同步是使用指令monitorenter和moniterexit实现，而方法同步是使用另外一种方式实现，具体的实现细节JVM规范没有做详细说明。monitorenter指令是在编译后插入到同步代码块的开始位置，moniterexit指令是插入到同步代码快结束和异常出，JVM要保证每个monitorenter指令都必须有moniterexit指令与之配对。JVM中的任何对象都有一个monitor与之关联，当有一个monitor被持有后，它将处于锁定状态，而线程执行到monitorenter指令时，将会尝试获取对象对应的monitor的所有权，这个过程也就是所谓的尝试获取对象的锁。

monitorenter实现

整个monitorenter主要干了这些事儿：

1. 将入参JavaThread thread指向当前线程；

2. 初始化当前线程的对象头；

3. 判断当前虚拟机是否开启偏向锁功能，如果开启，调用fast_enter方法，否则，调用slow_enter方法。

Java对象头

monitorenter中很重要的一步就是构造Java对象头h_obj，同时，在后续的fast_enter或者slow_enter中，h_obj都作为一个入参参与到具体的逻辑中，锁其实就存储在Java对象头中。

对象头组成部分
如果对象类型是数组，虚拟机用3个Word存储对象头，如果对象类型是非数组类型，用2个Word存储对象头，接下来看看这几个Word都用来干什么。

1. Mark Word：主要用来存储对象的hashCode、锁标记位、分代年龄等等，占用内存大小为1个Word；

2. Class Metadata Address：主要用来存储对象类型数据的指针，占用内存大小为1个Word；

3. Array Length：存储数组的长度，这部分只有在当前对象类型为数组时才存在，同样，占用内存大小也为1个Word。

接下来就详细了解与synchronized息息相关的Mark Word的相关内容。

HotSpot的Mark Word
HotSpot通过markOop.hpp实现了Mark Word。由于对象头需要存储的数据类型较多，充分考虑到内存的复用，markOop被设计成一个非固定的数据结构，可以根据标志位的变化而转变成不同类型的数据。

• 32位虚拟机markOop实现
  

  • hash：对象hashCode；
  • age：对象的分代年龄；
  • biased_lock：是否是偏向锁；
  • lock：锁标志位；
  • JavaThread*：持有偏向锁的线程ID；
  • epoch：偏向锁时间戳

  在运行期间，随着锁标志位的变化，Mark Word可以变化成以下几种类型的数据：
  

• 64虚拟机markOop实现
  
  在32位虚拟的markOop基础上增加了unused，同样的，在运行期间，随着标志位的变化Mark Work也会随之改变，在这里我就不做详细赘述了。

锁的升级

jdk 6为了减少获得锁和释放锁带来的性能消耗，引入了偏向锁和轻量级锁，换句话说，在jdk 6及以后版本，锁一共有四种状态：无锁状态、偏向锁状态、轻量级锁状态和重量级锁状态，它会随着竞争情况逐渐升级。但是，锁一旦升级之后就不能降级，当然，不能降级也是为了提高获得锁和释放锁的效率。

偏向锁

引入偏向锁是为了让线程获取锁的代价更低。当一个线程访问同步代码块并且获取锁时，会在对象头和栈帧中的锁记录中存储偏向锁偏向的线程ID，以后该线程在进入和退出同步块时不需要花费CAS操作来加锁和解锁，只需要校验对象头Mark Work中是否存储指向当前线程的偏向锁即可，节省了一部分CAS操作的性能消耗。不过，当多个线程竞争偏向锁时，需要撤销偏向锁，如果撤销偏向锁的性能消耗大于之前节省下来的那部分CAS操作的性能消耗，就得不偿失了。在jdk 6和jdk 7中，偏向锁默认是启用的，但是它在应用程序启动几秒钟之后才激活，当然，如果不想偏向锁延迟激活，可以使用JVM参数-XX：BiasedLockingStartupDelay = 0来关闭延迟。当然，也可以用过JVM参数-XX:-UseBiasedLocking=false来关闭偏向锁，这时候，默认的锁状态是轻量级锁。

在HosSpot中，偏向锁的入口为synchronizer.cpp的fast_enter方法：

偏向锁的获取

注：偏向锁获取代码过长，在这里就不贴代码了，有兴趣的可以去openjdk对照相应的源码看看。

偏向锁的获取的实现逻辑如下：

1. 获取对象头Mark Word mark；

2. 判断对象头mark是否为可偏向状态，也就是判断mark的偏向锁biased_lock是否为1，lock状态是否为01；

3. 判断对象头mark中的JavaThread* thread：

   • null == thread || thread == Thread.current，跳转到步骤4；

   • 否则，跳转到步骤5；

4. 调用CAS指令设置mark中的JavaThread为当前线程：

   • 调用CAS成功，返回BIAS_REVOKED，锁获取成功，线程可以执行同步代码块；

   • 调用CAS失败，跳转到步骤5；

5. 当调用CAS失败时，表明当前存在多个线程竞争锁，当达到safepoint时，挂起已获得偏向锁的线程，撤销偏向锁，并且调用slow_enter方法将当前锁升级为轻量级锁，获取到轻量级锁之后，唤醒被阻塞在safepoint的线程，线程继续执行同步代码块。

偏向锁的撤销

具体执行流程如下：

1. 校验当前是否到达safepoint；

2. 暂停已获取到偏向锁的线程；

3. 撤销偏向锁，恢复锁标志位为01（无锁状态）或者00（轻量级锁状态）。

轻量级锁

注：轻量级锁的引入在一定程度上减少了锁的性能消耗，但是如果多个线程竞争时，轻量级锁还是会膨胀成重量级锁，所以，轻量级锁以及偏向锁的出现并不是想要替代重量级锁。

轻量级锁的获取
在HotSpot中，轻量级锁的入口为synchronizer.cpp的slow_enter方法：

具体执行流程如下：

1. 获取对象头mark；

2. 调用方法is_neutral()判断当前对象是否为无锁状态（mark的biased_lock为0，lock为01）：

   • 无锁状态，跳转到步骤5；

   • 否则，跳转到步骤4；

3. 调用set_displaced_header方法将对象头mark复制到锁记录中；

4. 调用CAS指令尝试将对象头mark替换为指向锁记录的指针，如果成功，当前线程获取到锁，可以执行同步代码块，否则，跳转到步骤5；

5. 如果对象头mark处于加锁状态，并且mark的锁记录指针指向当前线程，当前线程获取到锁，可以执行同步代码块，否则，当前存在多个线程竞争，调用inflate方法膨胀成重量级锁。

轻量级锁的释放
轻量级锁的释放是通过synchronizer.cpp的fast_exit完成的：

具体执行流程如下：

1. 校验当前对象头mark是否不处于偏向锁状态：

   • 处于偏向锁状态，校验不通过，程序不往下执行；
   • 不处于偏向锁状态，校验通过，跳转到步骤2；

2. 获取保存在BasicLock对象中的对象头dhw；

3. 尝试使用CAS操作将dhw替换到当前对象头，如果替换成功，表示没有竞争发生，轻量级锁释放成功，否则，当前锁存在竞争，调用inflate方法膨胀成重量级锁。

到这里为止，就jdk 6对synchronized关键字做出的相关优化分析就告一段落了，synchronized还有一部分有关重量级锁的实现也会在后文做相应的介绍分析。希望对大家就synchronized关键词理解有所帮助。