学习笔记三：Synchronized实现原理与应用

时间 2019-11-10

原文原文链接

一、Synchronized实现同步基础

java中的每个对象均可以做为锁，根据Synchronized用的位置能够有这些使用场景：java

对于普通同步方法，锁是当前实例对象。

对于静态同步方法，锁是当前类的class对象。

对于同步方法块，锁是Synchronized括号里配置的对象。

二、Synchronized实现原理

2.1对象锁（monitor）机制

Synchronized在JVM里的实现原理，JVM基于进入和退出Monitor对象来实现方法同步和代码块同步，但二者的实现细节不同。数据库

咱们先来看看synchronized的具体底层实现。先写一个简单的demo：编程
public class SynchronizedJavapv {
    public static void main(String[] args) {
        synchronized (SynchronizedJavapv.class){
            System.out.println("对SynchronizedJavapv对象进行加锁");
        }
        m();
    }
    public static synchronized void m(){
        System.out.println("静态同步方法，对SynchronizedJavapv对象进行加锁");
    }
}
编译以后，切换到SynchronizedJavapv.class的同级目录以后，而后用javap -v SynchronizedJavapv.class查看字节码文件，分析实现细节：安全

monitorenter指令是在编译后插入到同步代码块的开始位置，而monitorexit是插入到方法结束和异常处.
代码块同步时使用monitorenter和monitorexit指令实现，方法同步则是依赖方法修饰符ACC_SYNCHRONIZED来完成。
不管采用哪一种方式，本质是对一个对象的监视器（monitor）进行获取，而这个过程是排他的，也就是同一时刻只有一个线程获取到由synchronized所保护对象的监视器。多线程

Synchronized先天具备重入性。每一个对象拥有一个计数器，当线程获取该对象锁后，计数器就会加一，释放锁后就会将计数器减一。并发

任意一个对象都拥有本身的监视器，当这个对象由同步块或者这个对象的同步方法调用时，执行方法的线程必须先获取该对象的监视器才能进入同步块和同步方法，若是没有获取到监视器的线程将会被阻塞在同步块和同步方法的入口处，进入到BLOCKED状态。app

下图表现了对象，对象监视器，同步队列以及执行线程状态之间的关系：ide

该图能够看出，任意线程对Object的访问，首先要得到Object的监视器，若是获取失败，该线程就进入同步状态，线程状态变为BLOCKED，当Object的监视器占有者释放后，在同步队列中得线程就会有机会从新获取该监视器。性能

2.2 synchronized的happens-before关系

在上一篇文章中讨论过happens-before规则，咱们如今来看一看Synchronized的happens-before规则，即监视器锁规则：对同一个监视器的解锁，happens-before于对该监视器的加锁。继续来看代码：学习
public class MonitorDemo {
   private int a = 0;

   public synchronized void writer() {     // 1
       a++;                                // 2
   }                                       // 3

   public synchronized void reader() {    // 4
       int i = a;                         // 5
   }                                      // 6
}
该代码的happens-before关系如图所示：

在图中每个箭头链接的两个节点就表明之间的happens-before关系，黑色的是经过程序顺序规则推导出来，红色的为监视器锁规则推导而出：线程A释放锁happens-before线程B加锁，蓝色的则是经过程序顺序规则和监视器锁规则推测出来happens-befor关系，经过传递性规则进一步推导的happens-before关系。如今咱们来重点关注2 happens-before 5，经过这个关系咱们能够得出什么？

根据happens-before的定义中的一条:若是A happens-before B，则A的执行结果对B可见，而且A的执行顺序先于B。线程A先对共享变量A进行加一，由2 happens-before 5关系可知线程A的执行结果对线程B可见即线程B所读取到的a的值为1。

2.3 锁获取和锁释放的内存语义

在上一篇文章提到过JMM核心为两个部分：happens-before规则以及内存抽象模型。咱们分析完Synchronized的happens-before关系后，仍是不太完整的，咱们接下来看看基于java内存抽象模型的Synchronized的内存语义。

废话很少说依旧先上图。

从上图能够看出，线程A会首先先从主内存中读取共享变量a=0的值而后将该变量拷贝到本身的本地内存，进行加一操做后，再将该值刷新到主内存，整个过程即为线程A 加锁-->执行临界区代码-->释放锁相对应的内存语义。

线程B获取锁的时候一样会从主内存中共享变量a的值，这个时候就是最新的值1,而后将该值拷贝到线程B的工做内存中去，释放锁的时候一样会重写到主内存中。

从总体上来看，线程A的执行结果（a=1）对线程B是可见的，实现原理为：释放锁的时候会将值刷新到主内存中，其余线程获取锁时会强制从主内存中获取最新的值。另外也验证了2 happens-before 5，2的执行结果对5是可见的。

从横向来看，这就像线程A经过主内存中的共享变量和线程B进行通讯，A 告诉 B 咱们俩的共享数据如今为1啦，这种线程间的通讯机制正好吻合java的内存模型正好是共享内存的并发模型结构。

三、synchronized优化

经过上面的讨论如今咱们对Synchronized应该有所印象了，它最大的特征就是在同一时刻只有一个线程可以得到对象的监视器（monitor），从而进入到同步代码块或者同步方法之中，即表现为互斥性（排它性）。

这种方式确定效率低下，每次只能经过一个线程，既然每次只能经过一个，这种形式不能改变的话，那么咱们能不能让每次经过的速度变快一点了。

打个比方，去收银台付款，以前的方式是，你们都去排队，而后去纸币付款收银员找零，有的时候付款的时候在包里拿出钱包再去拿出钱，这个过程是比较耗时的，而后，支付宝解放了你们去钱包找钱的过程，如今只须要扫描下就能够完成付款了，也省去了收银员跟你找零的时间的了。

一样是须要排队，但整个付款的时间大大缩短，是否是总体的效率变高速率变快了？这种优化方式一样能够引伸到锁优化上，缩短获取锁的时间，伟大的科学家们也是这样作的，使人钦佩，毕竟java是这么优秀的语言（微笑脸）。

在聊到锁的优化也就是锁的几种状态前，有两个知识点须要先关注：（1）CAS操做（2）Java对象头，这是理解下面知识的前提条件

3.1 CAS操做

3.1.1 什么是CAS?

使用锁时，线程获取锁是一种悲观锁策略，即假设每一次执行临界区代码都会产生冲突，因此当前线程获取到锁的时候同时也会阻塞其余线程获取该锁。而CAS操做（又称为无锁操做）是一种乐观锁策略，它假设全部线程访问共享资源的时候不会出现冲突，既然不会出现冲突天然而然就不会阻塞其余线程的操做。

所以，线程就不会出现阻塞停顿的状态。那么，若是出现冲突了怎么办？无锁操做是使用**CAS(compare and swap)**又叫作比较交换来鉴别线程是否出现冲突，出现冲突就重试当前操做直到没有冲突为止。

3.1.2 CAS的操做过程

CAS比较交换的过程能够通俗的理解为CAS(V,O,N)，包含三个值分别为：V 内存地址存放的实际值；O 预期的值（旧值）；N 更新的新值。当V和O相同时，也就是说旧值和内存中实际的值相同代表该值没有被其余线程更改过，即该旧值O就是目前来讲最新的值了，天然而然能够将新值N赋值给V。

反之，V和O不相同，代表该值已经被其余线程改过了则该旧值O不是最新版本的值了，因此不能将新值N赋给V，返回V便可。当多个线程使用CAS操做一个变量是，只有一个线程会成功，并成功更新，其他会失败。失败的线程会从新尝试，固然也能够选择挂起线程。

CAS的实现须要硬件指令集的支撑，在JDK1.5后虚拟机才可使用处理器提供的CMPXCHG指令实现。

Synchronized VS CAS

元老级的Synchronized(未优化前)最主要的问题是：在存在线程竞争的状况下会出现线程阻塞和唤醒锁带来的性能问题，由于这是一种互斥同步（阻塞同步）。而CAS并非武断的将线程挂起，当CAS操做失败后会进行必定的尝试，而非进行耗时的挂起唤醒的操做，所以也叫作非阻塞同步。这是二者主要的区别。

3.1.3 CAS的应用场景

在J.U.C包中利用CAS实现类有不少，能够说是支撑起整个concurrency包的实现，在Lock实现中会有CAS改变state变量，在atomic包中的实现类也几乎都是用CAS实现，关于这些具体的实现场景在以后会详细聊聊，如今有个印象就行了（微笑脸）。

3.1.4 CAS的问题

ABA问题

由于CAS会检查旧值有没有变化，这里存在这样一个有意思的问题。好比一个旧值A变为了成B，而后再变成A，恰好在作CAS时检查发现旧值并无变化依然为A，可是实际上的确发生了变化。

解决方案能够沿袭数据库中经常使用的乐观锁方式，添加一个版本号能够解决。原来的变化路径A->B->A就变成了1A->2B->3C。java这么优秀的语言，固然在java 1.5后的atomic包中提供了AtomicStampedReference来解决ABA问题，解决思路就是这样的。

自旋时间过长

使用CAS时非阻塞同步，也就是说不会将线程挂起，会自旋（无非就是一个死循环）进行下一次尝试，若是这里自旋时间过长对性能是很大的消耗。若是JVM能支持处理器提供的pause指令，那么在效率上会有必定的提高。

只能保证一个共享变量的原子操做

当对一个共享变量执行操做时CAS能保证其原子性，若是对多个共享变量进行操做,CAS就不能保证其原子性。有一个解决方案是利用对象整合多个共享变量，即一个类中的成员变量就是这几个共享变量。而后将这个对象作CAS操做就能够保证其原子性。atomic中提供了AtomicReference来保证引用对象之间的原子性。

3.2 Java对象头

在同步的时候是获取对象的monitor,即获取到对象的锁。那么对象的锁怎么理解？无非就是相似对对象的一个标志，那么这个标志就是存放在Java对象的对象头。Java对象头里的Mark Word里默认的存放的对象的Hashcode,分代年龄和锁标记位。32为JVM Mark Word默认存储结构为（注:java对象头以及下面的锁状态变化摘自《java并发编程的艺术》一书，该书我认为写的足够好，就没在本身组织语言班门弄斧了）：

如图在Mark Word会默认存放hasdcode，年龄值以及锁标志位等信息。

Java SE 1.6中，锁一共有4种状态，级别从低到高依次是：无锁状态、偏向锁状态、轻量级锁状态和重量级锁状态，这几个状态会随着竞争状况逐渐升级。锁能够升级但不能降级，意味着偏向锁升级成轻量级锁后不能降级成偏向锁。这种锁升级却不能降级的策略，目的是为了提升得到锁和释放锁的效率。对象的MarkWord变化为下图：

3.3 偏向锁

HotSpot的做者通过研究发现，大多数状况下，锁不只不存在多线程竞争，并且老是由同一线程屡次得到，为了让线程得到锁的代价更低而引入了偏向锁。

偏向锁的获取

当一个线程访问同步块并获取锁时，会在对象头和栈帧中的锁记录里存储锁偏向的线程ID，之后该线程在进入和退出同步块时不须要进行CAS操做来加锁和解锁，只需简单地测试一下对象头的Mark Word里是否存储着指向当前线程的偏向锁。若是测试成功，表示线程已经得到了锁。

若是测试失败，则须要再测试一下Mark Word中偏向锁的标识是否设置成1（表示当前是偏向锁）：若是没有设置，则使用CAS竞争锁；若是设置了，则尝试使用CAS将对象头的偏向锁指向当前线程

偏向锁的撤销

偏向锁使用了一种等到竞争出现才释放锁的机制，因此当其余线程尝试竞争偏向锁时，持有偏向锁的线程才会释放锁。

如图，偏向锁的撤销，须要等待全局安全点（在这个时间点上没有正在执行的字节码）。它会首先暂停拥有偏向锁的线程，而后检查持有偏向锁的线程是否活着，若是线程不处于活动状态，则将对象头设置成无锁状态；

若是线程仍然活着，拥有偏向锁的栈会被执行，遍历偏向对象的锁记录，栈中的锁记录和对象头的Mark Word要么从新偏向于其余线程，要么恢复到无锁或者标记对象不适合做为偏向锁，最后唤醒暂停的线程。

下图线程1展现了偏向锁获取的过程，线程2展现了偏向锁撤销的过程。

如何关闭偏向锁

偏向锁在Java 6和Java 7里是默认启用的，可是它在应用程序启动几秒钟以后才激活，若有必要可使用JVM参数来关闭延迟：-XX:BiasedLockingStartupDelay=0。若是你肯定应用程序里全部的锁一般状况下处于竞争状态，能够经过JVM参数关闭偏向锁：-XX:-UseBiasedLocking=false，那么程序默认会进入轻量级锁状态

3.3 轻量级锁

加锁

线程在执行同步块以前，JVM会先在当前线程的栈桢中建立用于存储锁记录的空间，并将对象头中的Mark Word复制到锁记录中，官方称为Displaced Mark Word。而后线程尝试使用CAS将对象头中的Mark Word替换为指向锁记录的指针。若是成功，当前线程得到锁，若是失败，表示其余线程竞争锁，当前线程便尝试使用自旋来获取锁。

解锁

轻量级解锁时，会使用原子的CAS操做将Displaced Mark Word替换回到对象头，若是成功，则表示没有竞争发生。若是失败，表示当前锁存在竞争，锁就会膨胀成重量级锁。下图是两个线程同时争夺锁，致使锁膨胀的流程图。

由于自旋会消耗CPU，为了不无用的自旋（好比得到锁的线程被阻塞住了），一旦锁升级成重量级锁，就不会再恢复到轻量级锁状态。当锁处于这个状态下，其余线程试图获取锁时，都会被阻塞住，当持有锁的线程释放锁以后会唤醒这些线程，被唤醒的线程就会进行新一轮的夺锁之争。

3.5 各类锁的比较

四、一个例子

通过上面的理解，咱们如今应该知道了该怎样解决了。更正后的代码为：
public class SynchronizedDemo implements Runnable {
   private static int count = 0;

   public static void main(String[] args) {
       for (int i = 0; i < 10; i++) {
           Thread thread = new Thread(new SynchronizedDemo());
           thread.start();
       }
       try {
           Thread.sleep(500);
       } catch (InterruptedException e) {
           e.printStackTrace();
       }
       System.out.println("result: " + count);
   }

   @Override
   public void run() {
       synchronized (SynchronizedDemo.class) {
           for (int i = 0; i < 1000000; i++)
               count++;
       }
   }
}
开启十个线程，每一个线程在原值上累加1000000次，最终正确的结果为10X1000000=10000000，这里可以计算出正确的结果是由于在作累加操做时使用了同步代码块，这样就能保证每一个线程所得到共享变量的值都是当前最新的值，若是不使用同步的话，就可能会出现A线程累加后，而B线程作累加操做有多是使用原来的就值，即“脏值”。

这样，就致使最终的计算结果不是正确的。而使用Syncnized就可能保证内存可见性，保证每一个线程都是操做的最新值。这里只是一个示例性的demo，聪明的你，还有其余办法吗？

上一篇：学习笔记二：Java内存模型以及happens-before规则

下一篇：学习笔记四：初识线程