由浅到深分析Synchronized,完全理解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原理分析

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对象头里。它是轻量级锁和偏向锁的关键。

Java对象头

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

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这个关键字，但我以为一步一步深刻挖掘它的原理实现的过程也是一种乐趣。