Synchronized 关键字使用、底层原理、JDK1.6 以后的底层优化以及 和ReenTrantLock 的对比

【强烈推荐！非广告！】阿里云双11褥羊毛活动： https://m.aliyun.com/act/team1111/#/share?params=N.FF7yxCciiM.hf47liqn 差很少一折，不过仅限阿里云新人购买，不是新人的朋友本身找方法买哦！

Github 地址：https://github.com/Snailclimb/JavaGuide/edit/master/Java相关/synchronized.md

synchronized关键字最主要的三种使用方式的总结

• 修饰实例方法，做用于当前对象实例加锁，进入同步代码前要得到当前对象实例的锁
• 修饰静态方法，做用于当前类对象加锁，进入同步代码前要得到当前类对象的锁 。也就是给当前类加锁，会做用于类的全部对象实例，由于静态成员不属于任何一个实例对象，是类成员（ static 代表这是该类的一个静态资源，无论new了多少个对象，只有一份，因此对该类的全部对象都加了锁）。因此若是一个线程A调用一个实例对象的非静态 synchronized 方法，而线程B须要调用这个实例对象所属类的静态 synchronized 方法，是容许的，不会发生互斥现象，由于访问静态 synchronized 方法占用的锁是当前类的锁，而访问非静态 synchronized 方法占用的锁是当前实例对象锁。
• 修饰代码块，指定加锁对象，对给定对象加锁，进入同步代码库前要得到给定对象的锁。 和 synchronized 方法同样，synchronized(this)代码块也是锁定当前对象的。synchronized 关键字加到 static 静态方法和 synchronized(class)代码块上都是是给 Class 类上锁。这里再提一下：synchronized关键字加到非 static 静态方法上是给对象实例上锁。另外须要注意的是：尽可能不要使用 synchronized(String a) 由于JVM中，字符串常量池具备缓冲功能！

下面我已一个常见的面试题为例讲解一下 synchronized 关键字的具体使用。

面试中面试官常常会说：“单例模式了解吗？来给我手写一下！给我解释一下双重检验锁方式实现单利模式的原理呗！”

双重校验锁实现对象单例（线程安全）

public class Singleton {

    private volatile static Singleton uniqueInstance;

    private Singleton() {
    }

    public static Singleton getUniqueInstance() {
       //先判断对象是否已经实例过，没有实例化过才进入加锁代码
        if (uniqueInstance == null) {
            //类对象加锁
            synchronized (Singleton.class) {
                if (uniqueInstance == null) {
                    uniqueInstance = new Singleton();
                }
            }
        }
        return uniqueInstance;
    }
}

另外，须要注意 uniqueInstance 采用 volatile 关键字修饰也是颇有必要。

uniqueInstance 采用 volatile 关键字修饰也是颇有必要的， uniqueInstance = new Singleton(); 这段代码实际上是分为三步执行：

1. 为 uniqueInstance 分配内存空间
2. 初始化 uniqueInstance
3. 将 uniqueInstance 指向分配的内存地址

可是因为 JVM 具备指令重排的特性，执行顺序有可能变成 1->3->2。指令重排在单线程环境下不会出先问题，可是在多线程环境下会致使一个线程得到尚未初始化的实例。例如，线程 T1 执行了 1 和 3，此时 T2 调用 getUniqueInstance() 后发现 uniqueInstance 不为空，所以返回 uniqueInstance，但此时 uniqueInstance 还未被初始化。

使用 volatile 能够禁止 JVM 的指令重排，保证在多线程环境下也能正常运行。

synchronized 关键字底层原理总结

synchronized 关键字底层原理属于 JVM 层面。

① synchronized 同步语句块的状况

public class SynchronizedDemo {
    public void method() {
        synchronized (this) {
            System.out.println("synchronized 代码块");
        }
    }
}

经过 JDK 自带的 javap 命令查看 SynchronizedDemo 类的相关字节码信息：首先切换到类的对应目录执行 javac SynchronizedDemo.java 命令生成编译后的 .class 文件，而后执行javap -c -s -v -l SynchronizedDemo.class。

从上面咱们能够看出：

synchronized 同步语句块的实现使用的是 monitorenter 和 monitorexit 指令，其中 monitorenter 指令指向同步代码块的开始位置，monitorexit 指令则指明同步代码块的结束位置。 当执行 monitorenter 指令时，线程试图获取锁也就是获取 monitor(monitor对象存在于每一个Java对象的对象头中，synchronized 锁即是经过这种方式获取锁的，也是为何Java中任意对象能够做为锁的缘由) 的持有权.当计数器为0则能够成功获取，获取后将锁计数器设为1也就是加1。相应的在执行 monitorexit 指令后，将锁计数器设为0，代表锁被释放。若是获取对象锁失败，那当前线程就要阻塞等待，直到锁被另一个线程释放为止。

② synchronized 修饰方法的的状况

public class SynchronizedDemo2 {
    public synchronized void method() {
        System.out.println("synchronized 方法");
    }
}

synchronized 修饰的方法并无 monitorenter 指令和 monitorexit 指令，取得代之的确实是 ACC_SYNCHRONIZED 标识，该标识指明了该方法是一个同步方法，JVM 经过该 ACC_SYNCHRONIZED 访问标志来辨别一个方法是否声明为同步方法，从而执行相应的同步调用。

在 Java 早期版本中，synchronized 属于重量级锁，效率低下，由于监视器锁（monitor）是依赖于底层的操做系统的 Mutex Lock 来实现的，Java 的线程是映射到操做系统的原生线程之上的。若是要挂起或者唤醒一个线程，都须要操做系统帮忙完成，而操做系统实现线程之间的切换时须要从用户态转换到内核态，这个状态之间的转换须要相对比较长的时间，时间成本相对较高，这也是为何早期的 synchronized 效率低的缘由。庆幸的是在 Java 6 以后 Java 官方对从 JVM 层面对synchronized 较大优化，因此如今的 synchronized 锁效率也优化得很不错了。JDK1.6对锁的实现引入了大量的优化，如自旋锁、适应性自旋锁、锁消除、锁粗化、偏向锁、轻量级锁等技术来减小锁操做的开销。

JDK1.6 以后的底层优化

JDK1.6 对锁的实现引入了大量的优化，如偏向锁、轻量级锁、自旋锁、适应性自旋锁、锁消除、锁粗化等技术来减小锁操做的开销。

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

①偏向锁

引入偏向锁的目的和引入轻量级锁的目的很像，他们都是为了没有多线程竞争的前提下，减小传统的重量级锁使用操做系统互斥量产生的性能消耗。可是不一样是：轻量级锁在无竞争的状况下使用 CAS 操做去代替使用互斥量。而偏向锁在无竞争的状况下会把整个同步都消除掉。

偏向锁的“偏”就是偏爱的偏，它的意思是会偏向于第一个得到它的线程，若是在接下来的执行中，该锁没有被其余线程获取，那么持有偏向锁的线程就不须要进行同步！关于偏向锁的原理能够查看《深刻理解Java虚拟机：JVM高级特性与最佳实践》第二版的13章第三节锁优化。

可是对于锁竞争比较激烈的场合，偏向锁就失效了，由于这样场合极有可能每次申请锁的线程都是不相同的，所以这种场合下不该该使用偏向锁，不然会得不偿失，须要注意的是，偏向锁失败后，并不会当即膨胀为重量级锁，而是先升级为轻量级锁。

② 轻量级锁

假若偏向锁失败，虚拟机并不会当即升级为重量级锁，它还会尝试使用一种称为轻量级锁的优化手段(1.6以后加入的)。轻量级锁不是为了代替重量级锁，它的本意是在没有多线程竞争的前提下，减小传统的重量级锁使用操做系统互斥量产生的性能消耗，由于使用轻量级锁时，不须要申请互斥量。另外，轻量级锁的加锁和解锁都用到了CAS操做。 关于轻量级锁的加锁和解锁的原理能够查看《深刻理解Java虚拟机：JVM高级特性与最佳实践》第二版的13章第三节锁优化。

轻量级锁可以提高程序同步性能的依据是“对于绝大部分锁，在整个同步周期内都是不存在竞争的”，这是一个经验数据。若是没有竞争，轻量级锁使用 CAS 操做避免了使用互斥操做的开销。但若是存在锁竞争，除了互斥量开销外，还会额外发生CAS操做，所以在有锁竞争的状况下，轻量级锁比传统的重量级锁更慢！若是锁竞争激烈，那么轻量级将很快膨胀为重量级锁！

③ 自旋锁和自适应自旋

轻量级锁失败后，虚拟机为了不线程真实地在操做系统层面挂起，还会进行一项称为自旋锁的优化手段。

互斥同步对性能最大的影响就是阻塞的实现，由于挂起线程/恢复线程的操做都须要转入内核态中完成（用户态转换到内核态会耗费时间）。

通常线程持有锁的时间都不是太长，因此仅仅为了这一点时间去挂起线程/恢复线程是得不偿失的。 因此，虚拟机的开发团队就这样去考虑：“咱们能不能让后面来的请求获取锁的线程等待一会而不被挂起呢？看看持有锁的线程是否很快就会释放锁”。为了让一个线程等待，咱们只须要让线程执行一个忙循环（自旋），这项技术就叫作自旋。

百度百科对自旋锁的解释：

何谓自旋锁？它是为实现保护共享资源而提出一种锁机制。其实，自旋锁与互斥锁比较相似，它们都是为了解决对某项资源的互斥使用。不管是互斥锁，仍是自旋锁，在任什么时候刻，最多只能有一个保持者，也就说，在任什么时候刻最多只能有一个执行单元得到锁。可是二者在调度机制上略有不一样。对于互斥锁，若是资源已经被占用，资源申请者只能进入睡眠状态。可是自旋锁不会引发调用者睡眠，若是自旋锁已经被别的执行单元保持，调用者就一直循环在那里看是否该自旋锁的保持者已经释放了锁，"自旋"一词就是所以而得名。

自旋锁在 JDK1.6 以前其实就已经引入了，不过是默认关闭的，须要经过--XX:+UseSpinning参数来开启。JDK1.6及1.6以后，就改成默认开启的了。须要注意的是：自旋等待不能彻底替代阻塞，由于它仍是要占用处理器时间。若是锁被占用的时间短，那么效果固然就很好了！反之，相反！自旋等待的时间必需要有限度。若是自旋超过了限定次数任然没有得到锁，就应该挂起线程。自旋次数的默认值是10次，用户能够修改--XX:PreBlockSpin来更改。

另外,在 JDK1.6 中引入了自适应的自旋锁。自适应的自旋锁带来的改进就是：自旋的时间不在固定了，而是和前一次同一个锁上的自旋时间以及锁的拥有者的状态来决定，虚拟机变得愈来愈“聪明”了。

④ 锁消除

锁消除理解起来很简单，它指的就是虚拟机即便编译器在运行时，若是检测到那些共享数据不可能存在竞争，那么就执行锁消除。锁消除能够节省毫无心义的请求锁的时间。

⑤ 锁粗化

原则上，咱们再编写代码的时候，老是推荐将同步快的做用范围限制得尽可能小——只在共享数据的实际做用域才进行同步，这样是为了使得须要同步的操做数量尽量变小，若是存在锁竞争，那等待线程也能尽快拿到锁。

大部分状况下，上面的原则都是没有问题的，可是若是一系列的连续操做都对同一个对象反复加锁和解锁，那么会带来不少没必要要的性能消耗。

Synchronized 和 ReenTrantLock 的对比

① 二者都是可重入锁

二者都是可重入锁。“可重入锁”概念是：本身能够再次获取本身的内部锁。好比一个线程得到了某个对象的锁，此时这个对象锁尚未释放，当其再次想要获取这个对象的锁的时候仍是能够获取的，若是不可锁重入的话，就会形成死锁。同一个线程每次获取锁，锁的计数器都自增1，因此要等到锁的计数器降低为0时才能释放锁。

② synchronized 依赖于 JVM 而 ReenTrantLock 依赖于 API

synchronized 是依赖于 JVM 实现的，前面咱们也讲到了 虚拟机团队在 JDK1.6 为 synchronized 关键字进行了不少优化，可是这些优化都是在虚拟机层面实现的，并无直接暴露给咱们。ReenTrantLock 是 JDK 层面实现的（也就是 API 层面，须要 lock() 和 unlock 方法配合 try/finally 语句块来完成），因此咱们能够经过查看它的源代码，来看它是如何实现的。

③ ReenTrantLock 比 synchronized 增长了一些高级功能

相比synchronized，ReenTrantLock增长了一些高级功能。主要来讲主要有三点：①等待可中断；②可实现公平锁；③可实现选择性通知（锁能够绑定多个条件）

• ReenTrantLock提供了一种可以中断等待锁的线程的机制，经过lock.lockInterruptibly()来实现这个机制。也就是说正在等待的线程能够选择放弃等待，改成处理其余事情。
• ReenTrantLock能够指定是公平锁仍是非公平锁。而synchronized只能是非公平锁。所谓的公平锁就是先等待的线程先得到锁。 ReenTrantLock默认状况是非公平的，能够经过 ReenTrantLock类的ReentrantLock(boolean fair)构造方法来制定是不是公平的。
• synchronized关键字与wait()和notify/notifyAll()方法相结合能够实现等待/通知机制，ReentrantLock类固然也能够实现，可是须要借助于Condition接口与newCondition() 方法。Condition是JDK1.5以后才有的，它具备很好的灵活性，好比能够实现多路通知功能也就是在一个Lock对象中能够建立多个Condition实例（即对象监视器），线程对象能够注册在指定的Condition中，从而能够有选择性的进行线程通知，在调度线程上更加灵活。 在使用notify/notifyAll()方法进行通知时，被通知的线程是由 JVM 选择的，用ReentrantLock类结合Condition实例能够实现“选择性通知” ，这个功能很是重要，并且是Condition接口默认提供的。而synchronized关键字就至关于整个Lock对象中只有一个Condition实例，全部的线程都注册在它一个身上。若是执行notifyAll()方法的话就会通知全部处于等待状态的线程这样会形成很大的效率问题，而Condition实例的signalAll()方法 只会唤醒注册在该Condition实例中的全部等待线程。

若是你想使用上述功能，那么选择ReenTrantLock是一个不错的选择。

④ 性能已不是选择标准

在JDK1.6以前，synchronized 的性能是比 ReenTrantLock 差不少。具体表示为：synchronized 关键字吞吐量岁线程数的增长，降低得很是严重。而ReenTrantLock 基本保持一个比较稳定的水平。我以为这也侧面反映了， synchronized 关键字还有很是大的优化余地。后续的技术发展也证实了这一点，咱们上面也讲了在 JDK1.6 以后 JVM 团队对 synchronized 关键字作了不少优化。JDK1.6 以后，synchronized 和 ReenTrantLock 的性能基本是持平了。因此网上那些说由于性能才选择 ReenTrantLock 的文章都是错的！JDK1.6以后，性能已经不是选择synchronized和ReenTrantLock的影响因素了！并且虚拟机在将来的性能改进中会更偏向于原生的synchronized，因此仍是提倡在synchronized能知足你的需求的状况下，优先考虑使用synchronized关键字来进行同步！优化后的synchronized和ReenTrantLock同样，在不少地方都是用到了CAS操做。