彻底理解Synchronized底层实现原理

这篇文章会记录Synchronized的常用使用场景与Synchronized的底层实现原理。虽然我们平时经常会在多线程中使用Synchronized关键字，但可能对于这个我们很熟悉的关键字的底层到底是怎样实现的没有过多关注。作为开发者，既然使用到了，可以试着去一步一步揭开下它的底层面纱。

为什么要使用Synchronized？

首先我们来看下这段代码

 

public class Demo {
    private static int count=0;
    public /*synchronized*/ static void inc(){
        try {
            Thread.sleep(1);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        count++;
    }
    public static void main(String[] args) throws InterruptedException {
        for(int i=0;i<1000;i++){
            new Thread(()-> Demo.inc()).start();
        }
        Thread.sleep(3000);
        System.out.println("运行结果"+count);
    }
}

这段代码的运行结果：运行结果970。
在这段代码中，首先没有加synchronized关键字，我们使用了循环的方法用1000个线程去访问count这个变量，运行的结果告诉我们，这个共享变量的状态是线程不安全的（我们期望1000次的访问可以得到1000的结果）。要解决这个问题， Synchronized关键字就可以达到目的。

synchronized简介

在多线程并发编程中 synchronized 一直是元老级角色，很多人都会称呼它为重量级锁。但是，随着 Java SE 1.6 对synchronized 进行了各种优化之后，有些情况下它就并不那么重，Java SE 1.6 中为了减少获得锁和释放锁带来的性能消耗而引入的偏向锁和轻量级锁。这块在后续介绍中会慢慢引入。

synchronized的基本语法

synchronized 有三种方式来加锁，分别是

1. 修饰实例方法，作用于当前实例加锁，进入同步代码前要获得当前实例的锁
2. 静态方法，作用于当前类对象加锁，进入同步代码前要获得当前类对象的锁
3. 修饰代码块，指定加锁对象，对给定对象加锁，进入同步代码库前要获得给定对象的锁。

我在网上找了张图，大致也对应上面所说的。

 

Synchronized的使用场景

synchronized原理分析

Java对象头和monitor是实现synchronized的基础！下面就这两个概念来做详细介绍。

关于monitor，再来看一个小demo

 

package com.thread;

public class Demo1{

    private static int count = 0;

    public static void main(String[] args) {
        synchronized (Demo1.class) {
            inc();
        }

    }
    private static void inc() {
        count++;
    }
}

上面的代码demo使用了synchroized关键字，锁住的是类对象。编译之后，切换到Demo1.class的同级目录之后，然后用javap -v Demo1.class查看字节码文件：

 

public static void main(java.lang.String[]);
    descriptor: ([Ljava/lang/String;)V
    flags: ACC_PUBLIC, ACC_STATIC
    Code:
      stack=2, locals=3, args_size=1
         0: ldc           #2                  // class com/thread/SynchronizedDemo
         2: dup
         3: astore_1
         4: monitorenter       //注意这个
         5: invokestatic  #3                  // Method inc:()V
         8: aload_1
         9: monitorexit    //注意这个
        10: goto          18
        13: astore_2
        14: aload_1
        15: monitorexit   //注意这个
        16: aload_2
        17: athrow
        18: return

线程在获取锁的时候，实际上就是获得一个监视器对象(monitor) ,monitor 可以认为是一个同步对象，所有的Java 对象是天生携带 monitor。而monitor是添加Synchronized关键字之后独有的。synchronized同步块使用了monitorenter和monitorexit指令实现同步，这两个指令，本质上都是对一个对象的监视器(monitor)进行获取，这个过程是排他的，也就是说同一时刻只能有一个线程获取到由synchronized所保护对象的监视器。
线程执行到monitorenter指令时，会尝试获取对象所对应的monitor所有权，也就是尝试获取对象的锁，而执行monitorexit，就是释放monitor的所有权。

对象在内存中的布局

在 Hotspot 虚拟机中，对象在内存中的存储布局，可以分为三个区域:对象头(Header)、实例数据(Instance Data)、对齐填充(Padding)。一般而言，synchronized使用的锁对象是存储在Java对象头里。它是轻量级锁和偏向锁的关键。

 

image

Java对象头

对象头主要包括两部分数据：Mark Word（标记字段）、Klass Pointer（类型指针）。
Klass Point：是对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例;
Mark Word：用于存储对象自身的运行时数据，如哈希码（HashCode）、GC分代年龄、锁状态标志、线程持有的锁、偏向线程 ID、偏向时间戳等等,它是实现轻量级锁和偏向锁的关键.

加锁时MarkWord可能储存的四种状态

 

synchronized 锁的升级

在分析 markword 时，提到了偏向锁、轻量级锁、重量级锁。在分析这几种锁的区别时，我们先来思考一个问题使用锁能够实现数据的安全性，但是会带来性能的下降。不使用锁能够基于线程并行提升程序性能，但是却不能保证线程安全性。这两者之间似乎是没有办法达到既能满足性能也能满足安全性的要求。

hotspot 虚拟机的作者经过调查发现，大部分情况下，加锁的代码不仅仅不存在多线程竞争，而且总是由同一个线程多次获得。所以基于这样一个概率，是的 synchronized 在JDK1.6 之后做了一些优化，为了减少获得锁和释放锁来的性能开销，引入了偏向锁、轻量级锁的概念。因此大家会发现在 synchronized 中，锁存在四种状态分别是：无锁、偏向锁、轻量级锁、重量级锁； 锁的状态根据竞争激烈的程度从低到高不断升级。

偏向锁的基本原理

偏向锁的获取
前面说过，大部分情况下，锁不仅仅不存在多线程竞争，而是总是由同一个线程多次获得，为了让线程获取锁的代价更低就引入了偏向锁的概念。怎么理解偏向锁呢？当一个线程访问加了同步锁的代码块时，会在对象头中存储当前线程的 ID，后续这个线程进入和退出这段加了同步锁的代码块时，不需要再次加锁和释放锁。而是直接比较对象头里面是否存储了指向当前线程的偏向锁。如果相等表示偏向锁是偏向于当前线程的，就不需要再尝试获得锁了
偏向锁的撤销
偏向锁使用了一种等到竞争出现才释放锁的机制，所以当其他线程尝试竞争偏向锁时，持有偏向锁的线程才会释放锁。并且直接把被偏向的锁对象升级到被加了轻量级锁的状态。
对原持有偏向锁的线程进行撤销时，原获得偏向锁的线程有两种情况：

1. 原获得偏向锁的线程如果已经退出了临界区，也就是同步代码块执行完了，那么这个时候会把对象头设置成无锁状态并且争抢锁的线程可以基于 CAS 重新偏向但前线程
2. 如果原获得偏向锁的线程的同步代码块还没执行完，处于临界区之内，这个时候会把原获得偏向锁的线程升级为轻量级锁后继续执行同步代码块在我们的应用开发中，绝大部分情况下一定会存在 2 个以上的线程竞争，那么如果开启偏向锁，反而会提升获取锁的资源消耗。所以可以通过 jvm 参数UseBiasedLocking 来设置开启或关闭偏向锁

这是网上一张很经典的偏向锁流程图

 

偏向锁流程图

轻量级锁的基本原理

加锁

锁升级为轻量级锁之后，对象的 Markword 也会进行相应的的变化。升级为轻量级锁的过程：

1. 线程在自己的栈桢中创建锁记录 LockRecord。
2. 将锁对象的对象头中的MarkWord复制到线程的刚刚创建的锁记录中。
3. 将锁记录中的 Owner 指针指向锁对象。
4. 将锁对象的对象头的 MarkWord替换为指向锁记录的指针。

自旋锁

轻量级锁在加锁过程中，用到了自旋锁所谓自旋，就是指当有另外一个线程来竞争锁时，这个线程会在原地循环等待，而不是把该线程给阻塞，直到那个获得锁的线程释放锁之后，这个线程就可以马上获得锁的。注意，锁在原地循环的时候，是会消耗 cpu 的，就相当于在执行一个啥也没有的 for 循环。所以，轻量级锁适用于那些同步代码块执行的很快的场景，这样，线程原地等待很短的时间就能够获得锁了。自旋锁的使用，其实也是有一定的概率背景，在大部分同步代码块执行的时间都是很短的。所以通过看似无异议的循环反而能提升锁的性能。但是自旋必要有一定的条件控制，否则如果一个线程执行同步代码块的时间很长，那么这个线程不断的循环反而会消耗 CPU 资源。默认情况下自旋的次数是 10 次，可以通过 preBlockSpin 来修改在 JDK1.6 之后，引入了自适应自旋锁，自适应意味着自旋的次数不是固定不变的，而是根据前一次在同一个锁上自旋的时间以及锁的拥有者的状态来决定。如果在同一个锁对象上，自旋等待刚刚成功获得过锁，并且持有锁的线程正在运行中，那么虚拟机就会认为这次自旋也是很有可能再次成功，进而它将允许自旋等待持续相对更长的时间。如果对于某个锁，自旋很少成功获得过，那在以后尝试获取这个锁时将可能省略掉自旋过程，直接阻塞线程，避免浪费处理器资源。

解锁

轻量级解锁时，会使用原子的CAS操作将Displaced Mark Word替换回到对象头，如果成功，则表示没有竞争发生。如果失败，表示当前锁存在竞争，锁就会膨胀成重量级锁。

 

轻量级锁流程图

重量级锁

当轻量级锁膨胀到重量级锁之后，意味着线程只能被挂起阻塞来等待被唤醒了。

各种锁的比较

各种锁的比较

总结

JVM在运行过程会根据实际情况对添加了Synchronized关键字的部分进行锁自动升级来实现自我优化。以上就是Synchronized的实现原理和java1.6以后对其所做的优化以及在实际运行中可能遇到的锁升级原理。虽然大家都懂得使用synchronized这个关键字，但我觉得一步一步深入挖掘它的原理实现的过程也是一种乐趣。

1 ReentrantLock和synchronized区别

  (1) synchronized 是Java的一个内置关键字，而ReentrantLock是Java的一个类。
  (2) synchronized只能是非公平锁。而ReentrantLock可以实现公平锁和非公平锁两种。
  (3) synchronized不能中断一个等待锁的线程，而Lock可以中断一个试图获取锁的线程。
  (4) synchronized不能设置超时，而Lock可以设置超时。
  (5) synchronized会自动释放锁，而ReentrantLock不会自动释放锁，必须手动释放，否则可能会导致死锁。

2 公平锁和非公平锁的区别

  公平锁的获取锁的过程：

 

static final class FairSync extends Sync {
    final void lock() { // 1 注意对比公平锁和非公平锁的这个方法
        acquire(1);
    }
    public final void acquire(int arg) {
        if (!tryAcquire(arg) &&
            acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
            selfInterrupt();
    }
    protected final boolean tryAcquire(int acquires) {
        final Thread current = Thread.currentThread();
        int c = getState();
        if (c == 0) {
            // 2 和非公平锁相比，这里多了一个判断：是否有线程在等待
            if (!hasQueuedPredecessors() &&
                compareAndSetState(0, acquires)) {
                setExclusiveOwnerThread(current);
                return true;
            }
        }
        else if (current == getExclusiveOwnerThread()) {
            int nextc = c + acquires;
            if (nextc < 0)
                throw new Error("Maximum lock count exceeded");
            setState(nextc);
            return true;
        }
        return false;
    }
}

  非公平锁的获取锁的过程：

 

static final class NonfairSync extends Sync {
    final void lock() {
      //  1 和公平锁相比，这里会直接先进行一次CAS，如果当前正好没有线程持有锁，
      // 如果成功获取锁就直接返回了，就不用像公平锁那样一定要进行后续判断
        if (compareAndSetState(0, 1))
            setExclusiveOwnerThread(Thread.currentThread());
        else
            acquire(1);
    }
    public final void acquire(int arg) {
        if (!tryAcquire(arg) &&
            acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
            selfInterrupt();
    }
    protected final boolean tryAcquire(int acquires) {
        return nonfairTryAcquire(acquires);
    }
}

final boolean nonfairTryAcquire(int acquires) {
    final Thread current = Thread.currentThread();
    int c = getState();
    if (c == 0) {
        // 2 这里没有对阻塞队列进行判断
        if (compareAndSetState(0, acquires)) {
            setExclusiveOwnerThread(current);
            return true;
        }
    }
    else if (current == getExclusiveOwnerThread()) {
        int nextc = c + acquires;
        if (nextc < 0) // overflow
            throw new Error("Maximum lock count exceeded");
        setState(nextc);
        return true;
    }
    return false;
}

  从源码上看，可以看到公平锁和非公平锁的两个区别：

(1) 线程在获取锁调用lock()时，非公平锁首先会进行一次CAS尝试抢锁，如果此时没有线程持有锁或者正好此刻有线程执行完释放了锁（state == 0），那么如果CAS成功则直接占用锁返回。
(2) 如果非公平锁在上一步获取锁失败了，那么就会进入nonfairTryAcquire(int acquires)，在该方法里，如果state的值为0，表示当前没有线程占用锁或者刚好有线程释放了锁，那么就会CAS抢锁，如果抢成功了，就直接返回了，不管是不是有其他线程早就到了在阻塞队列中等待锁了。而公平锁在这里抢到锁了，会判断阻塞队列是不是空的，毕竟要公平就要讲先来后到，如果发现阻塞队列不为空，表示队列中早有其他线程在等待了，那么公平锁情况下线程会乖乖排到阻塞队列的末尾。
  如果非公平锁 (1)(2) 都失败了，那么剩下的过程就和非公平锁一样了。
(3) 从(1)(2) 可以看出，非公平锁可能导致线程饥饿，但是非公平锁的效率要高。