聊聊Synchronize

Synchronize锁

一、概述

在多线程并发编程中 synchronized 一直是元老级角色，很多人都会称呼它为重量级锁。但是，随着 Java SE 1.6 对 synchronized 进行了各种优化之后，有些情况下它就并不那么重了。

本文详细介绍 Java SE 1.6 中为了减少获得锁和释放锁带来的性能消耗而引入的偏向锁和轻量级锁，以及升级过程。

二、实现同步的基础

Java 中的每个对象都可以作为锁，具体变现为以下3中形式：

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

指定加锁对象，对给定对象/类加锁。synchronized(this|object) 表示进入同步代码库前要获得给定对象的锁。synchronized(类.class) 表示进入同步代码前要获得 当前 class 的锁

synchronized(this) {
    //业务代码
}

一个线程试图访问同步代码块时，必须获取锁，在退出或者抛出异常时，必须释放锁。

三、实现方式

JVM 基于进入和退出 Monitor 对象来实现方法同步和代码块同步，但是两者的实现细节不一样。

1. 代码块同步：通过使用 monitorenter 和 monitorexit 指令实现的
2. 同步方法：ACC_SYNCHRONIZED 修饰

对象监视器 monitor（监视器）

monitorenter 指令是在编译后插入到同步代码块的开始位置，而 monitorexit 指令是在编译后插入到同步代码块的结束处或异常处，对于同步方法，个人觉得也是类似的原理，进入方法前添加一个 monitorenter 指令，退出方法后添加一个 monitorexit 指令。

为了证明 JVM 的实现方式，下面通过反编译代码来证明：

public class Demo {

    public void f1() {
        synchronized (Demo.class) {
            System.out.println("Hello World.");
        }
    }

    public synchronized void f2() {
        System.out.println("Hello World.");
    }

}

编译之后的字节码如下(只摘取了方法的字节码):

public void f1();
  descriptor: ()V
  flags: ACC_PUBLIC
  Code:
    stack=2, locals=3, args_size=1
       0: ldc           #2                  // class me/snail/base/Demo
       2: dup
       3: astore_1
       4: monitorenter
       5: getstatic     #3                  // Field java/lang/System.out:Ljava/io/PrintStream;
       8: ldc           #4                  // String Hello World.
      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
    LineNumberTable:
      line 6: 0
      line 7: 5
      line 8: 13
      line 9: 23
    StackMapTable: number_of_entries = 2
      frame_type = 255 /* full_frame */
        offset_delta = 18
        locals = [ class me/snail/base/Demo, class java/lang/Object ]
        stack = [ class java/lang/Throwable ]
      frame_type = 250 /* chop */
        offset_delta = 4

public synchronized void f2();
  descriptor: ()V
  flags: ACC_PUBLIC, ACC_SYNCHRONIZED
  Code:
    stack=2, locals=1, args_size=1
       0: getstatic     #3                  // Field java/lang/System.out:Ljava/io/PrintStream;
       3: ldc           #4                  // String Hello World.
       5: invokevirtual #5                  // Method java/io/PrintStream.println:(Ljava/lang/String;)V
       8: return
    LineNumberTable:
      line 12: 0
      line 13: 8

先说 f1() 方法，发现其中一个 monitorenter 对应了两个 monitorexit，这是不对的。但是仔细看 #15: goto 语句，直接跳转到了 #23: return 处，再看 #22: athrow 语句发现，原来第二个 monitorexit 是保证同步代码块抛出异常时锁能得到正确的释放而存在的，这就理解了。

综上：发现同步代码块是通过 monitorenter 和 monitorexit 来实现的，

同步方法是加了一个 ACC_SYNCHRONIZED 修饰来实现的。

不过两者的本质都是对对象监视器 monitor 的获取。

四、Java对象头（存储锁类型）

在 HotSpot 虚拟机中，对象在内存中的布局分为三块区域：对象头，实例数据和对齐填充。

对象头中包含两部分：MarkWord 和 类型指针。如果是数组对象的话，对象头还有一部分是存储数组的长度。

多线程下 Synchronized 的加锁就是对同一个对象的对象头中的 MarkWord 中的变量进行CAS操作。,即线程ID

MarkWord

Mark Word 用于存储对象自身的运行时数据，如 HashCode、GC分代年龄、锁状态标志、线程持有的锁、偏向线程ID等等。

锁的4种状态：无锁状态、偏向锁状态、轻量级锁状态、重量级锁状态（级别从低到高）

锁可以升级，但不能降级。即：无锁 -> 偏向锁 -> 轻量级锁 -> 重量级锁是单向的。

（1）偏向锁：

==偏向锁偏向于第一个获得它的线程，==如果在接下来的执行过程中，该锁没有被其他的线程获取，那么持有偏向锁的线程无需再进行同步（加锁）。很明显，当锁的竞争情况很少出现时，偏向锁就能提高性能，因为它比轻量级锁（如自旋锁）少了一步：CAS。

为什么要引入偏向锁？

因为经过HotSpot的作者大量的研究发现，大多数时候是不存在锁竞争的，常常是一个线程多次获得同一个锁，因此如果每次都要竞争锁会增大很多没有必要付出的代价，为了降低获取锁的代价，才引入的偏向锁。

偏向锁的升级

当线程1访问代码块并获取锁对象时，会在java对象头和栈帧中记录偏向的锁的threadID，因为偏向锁不会主动释放锁，因此以后线程1再次获取锁的时候，需要比较当前线程的threadID和Java对象头中的threadID是否一致，如果一致（还是线程1获取锁对象），则无需使用CAS来加锁、解锁；

如果不一致（其他线程，如线程2要竞争锁对象，而偏向锁不会主动释放因此还是存储的线程1的threadID），那么需要查看Java对象头中记录的线程1是否存活，如果没有存活，那么锁对象被重置为无锁状态，其它线程（线程2）可以竞争将其设置为偏向锁；

如果存活，那么立刻查找该线程（线程1）的栈帧信息，如果还是需要继续持有这个锁对象，那么暂停当前线程1，撤销偏向锁，升级为轻量级锁，如果线程1 不再使用该锁对象，那么将锁对象状态设为无锁状态，重新偏向新的线程。

简单来讲，就是，如果线程1获得了锁对象，这时如果有第二条线程来竞争，那么就撤销偏向锁，将锁升级为轻量级锁，即CAS来对锁对象进行竞争

（2）轻量级锁

为什么要引入轻量级锁？

轻量级锁考虑的是竞争锁对象的线程不多，而且线程持有锁的时间也不长的情景。因为阻塞线程需要CPU从用户态转到内核态（不了解。老老实实说），代价较大，如果刚刚阻塞不久这个锁就被释放了，那这个代价就有点得不偿失了，因此这个时候就干脆不阻塞这个线程，让它自旋这等待锁释放。

轻量级锁什么时候升级为重量级锁？

线程1还在执行，线程2还在自旋等待，这时又有一个线程3过来竞争这个锁对象，那么这个时候轻量级锁就会膨胀为重量级锁。重量级锁把除了拥有锁的线程都阻塞，防止CPU空转。