Synchronized原理解析

一、为什么出现synchronized

    对于程序员而言，不管是在平常的工作中还是面试中，都会经常用到或者被问到synchronized。在多线程并发编程中，synchronized早已是元老级的角色了，很多人都称其为重量级锁，但是随着Java SE 1.6对其进行各种优化之后，便显得不再是那么的重了，原因下面就讲。

正是因为多线程并发的出现，便产生了线程安全这样的问题，对于线程安全的主要原因如下：

• 存在共享数据（也称临界资源）；
• 存在多条线程共同操作这些共享数据。

    而对于解决这样的一个问题的办法是：同一时刻有且只有一条线程在操作共享数据，其他线程必须等待该线程处理完数据后再对共享数据进行操作。

此时便产生了互斥锁，互斥锁的特性如下：

• 互斥性：即在同一时刻只允许一个线程持有某个对象锁，通过这种特性来实现多线程协调机制，这样在同一时刻只有一个线程对所需要的同步的代码块（复合操作）进行访问。互斥性也成为了操作的原子性。
• 可见性：必须确保在锁释放之前，对共享变量所做的修改，对于随后获得该锁的另一个线程可见（即在获得锁时应获得最新共享变量的值），否则另一个线程可能是在本地缓存的某个副本上继续操作，从而引起数据不一致。

二、实现原理

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

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

• 普通同步方法，锁是当前实例对象；
• 静态同步方法，锁是当前类的class对象；
• 同步方法块，锁是括号里面的对象。

    当一个线程试图访问同步代码块时，它首先必须得到锁，退出或者抛出异常时必须释放锁，那么锁存在哪里呢？我们先来看一段代码：

public class SyncBlockTest {
     
    public void syncsTask() {
     
        synchronized (this) {
     
            System.out.println("Hello");
        }
    }
 
    public synchronized void syncTask() {
     
        System.out.println("Hello Baby");
    }
}

    在使用javac工具把上面代码变异成class，然后使用javap工具查看编译好的class文件，如下：

  public com.interview.javabasic.thread.SyncBlockTest();
    descriptor: ()V
    flags: ACC_PUBLIC
    Code:
      stack=1, locals=1, args_size=1
         0: aload_0
         1: invokespecial #1                  // Method java/lang/Object."":()V
         4: return
      LineNumberTable:
        line 8: 0
 
  public void syncsTask();
    descriptor: ()V
    flags: ACC_PUBLIC
    Code:
      stack=2, locals=3, args_size=1
         0: aload_0
         1: dup
         2: astore_1
         3: monitorenter             //-------here
         4: getstatic     #2                  // Field java/lang/System.out:Ljava/io/PrintStream;
         7: ldc           #3                  // String Hello
         9: invokevirtual #4                  // Method java/io/PrintStream.println:(Ljava/lang/String;)V
        12: aload_1
        13: monitorexit             //-------here
        14: goto          22
        17: astore_2
        18: aload_1
        19: monitorexit
        20: aload_2
        21: athrow
        22: return
      Exception table:
         from    to  target type
             4    14    17   any
            17    20    17   any
      LineNumberTable:
        line 10: 0
        line 11: 4
        line 12: 12
        line 13: 22
      StackMapTable: number_of_entries = 2
        frame_type = 255 /* full_frame */
          offset_delta = 17
          locals = [ class com/interview/javabasic/thread/SyncBlockTest, class java/lang/Object ]
          stack = [ class java/lang/Throwable ]
        frame_type = 250 /* chop */
          offset_delta = 4
 
  public synchronized void syncTask();
    descriptor: ()V
    flags: ACC_PUBLIC, ACC_SYNCHRONIZED       //-------here
    Code:
      stack=2, locals=1, args_size=1
         0: getstatic     #2                  // Field java/lang/System.out:Ljava/io/PrintStream;
         3: ldc           #5                  // String Hello Baby
         5: invokevirtual #4                  // Method java/io/PrintStream.println:(Ljava/lang/String;)V
         8: return
      LineNumberTable:
        line 16: 0
        line 17: 8
}

同步代码块

    从上面的字节码中可以看出，同步语句块的实现是使用monitorenter和monitorexit指令的，monitorenter指向同步代码块的开始位置，它首先去获取PrintStream这个类，然后传入“Hello”这个参数，然后再调用PrintStream中的println()方法去打印，monitorexit指明同步代码块的结束位置，当执行到monitorenter时，当前线程将试图获取对象锁所对应的monitor的持有权。

同步方法

    从上面代码的syncTask()方法字节码中看，这里面并没monitorenter和monitorexit，且字节码较短，其实这里方法的同步是隐式的，是无需通过字节码指令控制，在上面可以看到一个“ACC_SYNCHRONIZED”这样的一个访问标志，用来区分一个方法是否是同步方法。当方法调用时，调用指令将会检查ACC_SYNCHRONIZED是否被设置，如果被设置，当前线程将会持有monitor，然后再执行方法，最后不管方法是否正常完成都会释放monitor。

三、实现synchronized的基础

Java对象头和monitor是实现synchronized的基础。

Java 对象的内存布局

hotspot虚拟机中，对象在内存的布局分布分为3个部分：对象头，实例数据和对齐填充。

对象头

虚拟机位数	头对象结构	说明
32/64 bit	Mark Word	默认存储对象的hashCode，分代年龄，锁类型，锁标志位等信息
32/64 bit	Class Metadata	类型指针指向对象的类元数据，JVM通过这个指针确定该对象是哪个类型的数据
32/64 bit	Array length	数组的长度（如果当前的对象是数组）

实例数据

    实例数据，即对象真正存储的有效信息，也是程序代码中所定义的各种类型的字段内容。无论是从父类继承下来的，还是子类中定义的，都需要记录起来。这部分的存储顺序会受到虚拟机分配策略参数和字段在Java源码中定义顺序的影响。

对齐填充
    对齐填充并不是必然存在的，也没有特别的含义，它仅仅起着占位符的作用。比如HotSpot VM的自动内存管理系统要求对象必须是8字节的整数倍，而对象头部分正好是8字节的整数倍，那么，当实例数据部分没有对齐时，就需要通过对齐填充来补全。

Mark Word

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

    在运行期间，Mark Word里存储的数据会随着锁标志位的变化而变化。Mark Word可能变化为存储以下4种数据，如表2-4所示。

    在64位虚拟机下，Mark Word是64bit大小的，其存储结构如表2-5所示。

monitor

    每个Java对象天生就自带了一把看不见的锁，它可以视为是一种同步工具或者是一种同步机制，monitor还是线程私有的数据结构，每一个线程都有一个可用monitor 列表，同时还有一个全局的可用列表，如上面所说每一个被锁住的对象都会持有一个monitor。结构如下所示：

• Owner：初始时为NULL表示当前没有任何线程拥有该monitor record，当线程成功拥有该锁后保存线程唯一标识，当锁被释放时又设置为NULL；
• EntryQ:关联一个系统互斥锁（semaphore），阻塞所有试图锁住monitor record失败的线程；
• RcThis:表示blocked或waiting在该monitor record上的所有线程的个数；
• Nest:用来实现重入锁的计数；
• HashCode:保存从对象头拷贝过来的HashCode值（可能还包含GC age）；
• Candidate:用来避免不必要的阻塞或等待线程唤醒，因为每一次只有一个线程能够成功拥有锁，如果每次前一个释放锁的线程唤醒所有正在阻塞或等待的线程，会引起不必要的上下文切换（从阻塞到就绪然后因为竞争锁失败又被阻塞）从而导致性能严重下降。Candidate只有两种可能的值：0-表示没有需要唤醒的线程，1-表示要唤醒一个继任线程来竞争锁。

四、锁优化

    Java6以后，对锁进行了大量的优化，例如：自适应自旋、锁消除、锁粗化、轻量级、偏向锁等等。

    锁主要存在四中状态，依次是：无锁状态、偏向锁状态、轻量级锁状态、重量级锁状态，他们会随着竞争的激烈而逐渐升级。注意锁可以升级不可降级，这种策略是为了提高获得锁和释放锁的效率。

自旋锁

引入自旋锁的原因
    线程的阻塞和唤醒需要CPU从用户态转为核心态，频繁的阻塞和唤醒对CPU来说是一件负担很重的工作，势必会给系统的并发性能带来很大的压力。同时我们发现在许多应用上面，对象锁的锁状态只会持续很短一段时间，为了这一段很短的时间频繁地阻塞和唤醒线程是非常不值得的。所以引入自旋锁。

何谓自旋锁？
    所谓自旋锁，就是让该线程等待一段时间，不会被立即挂起，看持有锁的线程是否会很快释放锁。怎么等待呢？执行一段无意义的循环即可（自旋）。

    自旋等待不能替代阻塞，先不说对处理器数量的要求（多核，貌似现在没有单核的处理器了），虽然它可以避免线程切换带来的开销，但是它占用了处理器的时间。如果持有锁的线程很快就释放了锁，那么自旋的效率就非常好，反之，自旋的线程就会白白消耗掉处理的资源，它不会做任何有意义的工作，典型的占着茅坑不拉屎，这样反而会带来性能上的浪费。所以说，自旋等待的时间（自旋的次数）必须要有一个限度，如果自旋超过了定义的时间仍然没有获取到锁，则应该被挂起。

适应自旋锁

    JDK 1.6引入了更加聪明的自旋锁，即自适应自旋锁。所谓自适应就意味着自旋的次数不再是固定的，它是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定。它怎么做呢？线程如果自旋成功了，那么下次自旋的次数会更加多，因为虚拟机认为既然上次成功了，那么此次自旋也很有可能会再次成功，那么它就会允许自旋等待持续的次数更多。反之，如果对于某个锁，很少有自旋能够成功的，那么在以后要或者这个锁的时候自旋的次数会减少甚至省略掉自旋过程，以免浪费处理器资源。

锁消除

    为了保证数据的完整性，我们在进行操作时需要对这部分操作进行同步控制，但是在有些情况下，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内部的加锁操作消除。

锁粗化

    锁粗话概念比较好理解，就是将多个连续的加锁、解锁操作连接在一起，扩展成一个范围更大的锁。如上面实例：vector每次add的时候都需要加锁操作，JVM检测到对同一个对象（vector）连续加锁、解锁操作，会合并一个更大范围的加锁、解锁操作，即加锁解锁操作会移到for循环之外。

轻量级锁

    顾名思义，轻量级锁是相对于重量级锁而言的。使用轻量级锁时，不需要申请互斥量，仅仅将Mark Word中的部分字节CAS更新指向线程栈中的Lock Record，如果更新成功，则轻量级锁获取成功，记录锁状态为轻量级锁；否则，说明已经有线程获得了轻量级锁，目前发生了锁竞争（不适合继续使用轻量级锁），接下来膨胀为重量级锁。

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

获取锁

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

释放锁

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实现，操作系统实现线程之间的切换需要从用户态到内核态的切换，切换成本非常高。