synchronized 的实现与原理

synchronized 给人的印象一直是并发编程中的元老级角色但是其比较重，并称之为重量级锁，但是事实真的是这样吗？其实随着 Java SE 1.6 对 synchronized 进行了各种优化，随着 JDK 的升级对 synchronized 的优化是持续进行的，因此对于 synchronized 的使用及理解就变得非常重要了，本文就对 synchronized 的原理进行一些介绍。

先来看一下利用 synchronized 实现同步的基础。Java 中的每一个对象都可以作为锁。具体表现为 3 种形式。

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

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

从 JVM 规范中可以看到 synchronized 在 JVM 里的实现原理， JVM 基于进入和退出 Monitor 对象来实现方法同步和代码块同步。方法同步和代码块同步是使用 monitorenter 和 monitorexit 指令实现的。 monitorenter 指令是在编译后插入到同步代码块的开始位置，而 monitorexit 是插入到代码块结束处和异常处， JVM 要保证每个 monitorenter 必须有对应的 monitorexit 与之配对。任何对象都有一个 monitor 与之关联，并且一个 monitor 被持有后，它将处于锁定状态。线程执行到 monitorenter 指令时，将会尝试获取对象对应的 monitor 的所有权，即尝试获得对象的锁。 例如对于如下简单的代码，编译出成字节码之后再通过 javap -c 命令进行反汇编便可以看到 monitorenter 和 monitorexit 指令。

public class SynchronizedTest {
    public static void main(String[] args) {
        synchronized (SynchronizedTest.class) {
            System.out.println("synchronized...");
        }
    }
}

Compiled from "SynchronizedTest.java"
public class com.weiqiang.SynchronizedTest {
  public com.weiqiang.SynchronizedTest();
    Code:
       0: aload_0
       1: invokespecial #1                  // Method java/lang/Object."<init>":()V
       4: return

  public static void main(java.lang.String[]);
    Code:
       0: ldc           #2                  // class com/weiqiang/SynchronizedTest
       2: dup
       3: astore_1
       4: monitorenter
       5: getstatic     #3                  // Field java/lang/System.out:Ljava/io/PrintStream;
       8: ldc           #4                  // String synchronized...
      10: invokevirtual #5                  // Method java/io/PrintStream.println:(Ljava/lang/String;)V
      13: aload_1
      14: monitorexit
      15: goto          23
      18: astore_2
      19: aload_1
      20: monitorexit
      21: aload_2
      22: athrow
      23: return
    Exception table:
       from    to  target type
           5    15    18   any
          18    21    18   any
}

Java 对象头

synchronized 用的锁是存在 Java 对象头里的。如果对象是数组类型，则虚拟机用 3 个字宽存储对象头，如果对象是非数组类型，则用 2 个字宽存储对象头。

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

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

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

锁的升级与对比

Java SE 1.6 为了减少获得锁和释放锁带来的性能消耗，引入了 偏向锁 和 轻量级锁 ，在 Java SE 1.6 中，锁一共有 4 种状态，级别从低到高依次是：无锁状态、偏向锁状态、轻量级锁状态和重量级锁状态，这几个状态会随着竞争情况逐渐升级。锁可以升级但不能降级，意味着偏向锁升级成轻量级锁之后便不能再降级成偏向锁。

偏向锁

JVM 的作者经过研究发现，大多数情况下，锁不仅不存在多线程竞争，而且总是由同一线程多次获得，为了让线程获得锁的代价更低而引入了偏向锁。当一个线程访问同步代码时，会在对象头和栈帧中的锁记录里存储锁偏向的线程 ID，以后该线程在进入和退出同步代码时不需要进行 CAS 操作来加锁和解锁，只需简单的测试一下对象头的 Mark Word 里是否存储着指向当前线程的偏向锁。如果测试成功，表示线程已经获得了锁，如果测试失败，则需要再测试一下 Mark Word 中偏向锁的标识是否设置成 1 (表示当前是偏向锁)，如果没有设置，则使用 CAS 竞争锁；如果设置了，则尝试使用 CAS 将对象头的偏向锁指向当前线程。

• 偏向锁的撤销
  偏向锁使用了一种等到竞争出现才释放锁的机制，所以当其他线程尝试竞争偏向锁时，持有偏向锁的线程才会释放锁。偏向锁的撤销，需要等待全局安全点（在这个时间点上没有正在执行的字节码）。它会暂停拥有锁的线程，然后检查持有偏向锁的线程是否活着，如果线程不处于活动状态，则将对象头设置成无锁状态；如果线程任然活着，拥有偏向锁的栈会被执行，遍历偏向对象的锁记录，栈中的锁记录和对象头的 Mark Word 要么重新偏向与其他线程，要么恢复到无锁活着标记对象不适合作为偏向锁，最后唤醒暂停的线程。

轻量级锁

• 轻量级锁加锁
  线程在执行同步代码块之前， JVM 会先在当前线程的栈帧中创建用于存储锁记录的空间，并将对象头中的 Mark Word 复制到锁记录中，然后线程尝试使用 CAS 将对象头中的 Mark Word 替换为指向锁记录的指针。如果成功，当前线程获得锁，如果失败，表示其他线程竞争锁，当前线程便尝试使用自旋来获取锁。
• 轻量级锁解锁
  轻量级锁解锁时，会使用原子的 CAS 操作将锁记录中的 Mardk Word 替换会到对象头，如果成功，则表示没有竞争发生。如果失败，表示当前锁存在竞争，锁就会膨胀成重量级锁。
  因为自旋会消耗 CPU ，为了避免无用的自旋，一旦锁升级成重量级锁，就不会再恢复到轻量级锁状态。当锁处于这个状态下，其他线程试图获取锁时都会被阻塞住，当持有锁的线程释放锁之后会唤醒这些线程，被唤醒的线程会进行新一轮的夺锁之争。

锁的优缺点对比

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

完