死磕Synchronized实现原理

时间  2019-11-15
标签 synchronized 实现 原理 栏目 Java 繁體版
原文   原文链接

上篇文章咱们已经讲了Java Lock类，有兴趣的能够看看：深刻Java Lock锁，今天咱们来学一下Synchronized，主要有如下知识点：java

  • 基本使用
  • 同步原理
  • Java对象头
  • Monitor监视器
  • 锁分类
  • 锁优化

前言

咱们知道在JDK1.5以前synchronized是一个重量级锁，相对于j.u.c.Lock，它会显得那么笨重，以致于咱们认为它不是那么的高效而慢慢摒弃它。segmentfault

不过，随着Javs SE 1.6对synchronized进行的各类优化后，synchronized并不会显得那么重了。下面来一块儿探索synchronized的基本使用、实现机制、Java是如何对它进行了优化、锁优化机制、锁的存储结构等升级过程。数组

基本使用

Synchronized的做用主要有两个:安全

  • 原子性：确保线程互斥的访问同步代码；
  • 可见性：保证共享变量的修改可以及时可见，实际上是经过Java内存模型中的 “对一个变量unlock 操做以前，必需要同步到主内存中；若是对一个变量进行lock操做，则将会清空工做内存 中此变量的值，在执行引擎使用此变量前，须要从新从主内存中load操做或assign操做 初始化变量值” 来保证的；

注意，synchronized 内置锁 是一种 对象锁（锁的是对象而非引用变量），做用粒度是对象 ，能够用来实现对 临界资源的同步互斥访问 ，是可重入的。其可重入最大的做用是避免死锁。数据结构

从语法上讲，Synchronized能够把任何一个非null对象做为"锁"，在HotSpot JVM实现中，锁有个专门的名字：对象监视器（Object Monitor）。多线程

同步原理

当一个线程访问同步代码块时，首先是须要获得锁才能执行同步代码，当退出或者抛出异常时必需要释放锁，那么它是如何来实现这个机制的呢？咱们先看一段简单的代码：并发

public class SynchronizedDemo {
    public void method() {
        synchronized (this) {
            System.out.println("Method 1 start");
        }
    }
}

查看反编译结果app

image

  1. monitorenter：每一个对象都是一个监视器锁（monitor）。当monitor被占用时就会处于锁定状态，线程执行monitorenter指令时尝试获取monitor的全部权，过程以下：异步

    1. 若是monitor的进入数为0，则该线程进入monitor，而后将进入数设置为1，该线程即为monitor的全部者；
    2. 若是线程已经占有该monitor，只是从新进入，则进入monitor的进入数加1；
    3. 若是其余线程已经占用了monitor，则该线程进入阻塞状态，直到monitor的进入数为0，再从新尝试获取monitor的全部权；

  2. monitorexit：执行monitorexit的线程必须是objecter所对应的monitor的全部者。指令执行时，monitor的进入数减1，若是减1后进入数为0，那线程退出monitor，再也不是这个monitor的全部者。其余被这个monitor阻塞的线程能够尝试去获取这个 monitor 的全部权。布局

    monitorexit指令出现了两次，第1次为同步正常退出释放锁；第2次为发生异步退出释放锁；

经过上面两段描述，咱们应该能很清楚的看出Synchronized的实现原理，Synchronized的语义底层是经过一个monitor的对象来完成，其实wait/notify等方法也依赖于monitor对象，这就是为何只有在同步的块或者方法中才能调用wait/notify等方法，不然会抛出java.lang.IllegalMonitorStateException的异常的缘由。

再来看看同步方法

public class SynchronizedMethod {
    public synchronized void method() {
        System.out.println("Hello World!");
    }
}

查看反编译结果

image

从编译的结果来看，方法的同步并无经过指令 monitorenter 和 monitorexit 来完成（理论上其实也能够经过这两条指令来实现），不过相对于普通方法，其常量池中多了 ACC_SYNCHRONIZED 标示符。JVM就是根据该标示符来实现方法的同步的：

当方法调用时， 调用指令将会检查方法的 ACC_SYNCHRONIZED 访问标志是否被设置，若是设置了， 执行线程将先获取monitor，获取成功以后才能执行方法体， 方法执行完后再释放monitor。在方法执行期间，其余任何线程都没法再得到同一个monitor对象。

两种同步方式本质上没有区别，只是方法的同步是一种隐式的方式来实现，无需经过字节码来完成。两个指令的执行是JVM经过调用操做系统的互斥原语mutex来实现，被阻塞的线程会被挂起、等待从新调度，会致使“用户态和内核态”两个态之间来回切换，对性能有较大影响。

实现机制

Java对象头

在JVM中，对象在内存中的布局分为三块区域：对象头、实例数据和对齐填充。以下图所示：

image

  • 实例数据：存放类的属性数据信息，包括父类的属性信息；
  • 对齐填充：因为虚拟机要求 对象起始地址必须是8字节的整数倍。填充数据不是必须存在的，仅仅是为了字节对齐；
  • 对象头：Java对象头通常占有2个机器码（在32位虚拟机中，1个机器码等于4字节，也就是32bit，在64位虚拟机中，1个机器码是8个字节，也就是64bit），可是 若是对象是数组类型，则须要3个机器码，由于JVM虚拟机能够经过Java对象的元数据信息肯定Java对象的大小，可是没法从数组的元数据来确认数组的大小，因此用一块来记录数组长度。

Synchronized用的锁就是存在Java对象头里的，那么什么是Java对象头呢？Hotspot虚拟机的对象头主要包括两部分数据：Mark Word（标记字段）、Class Pointer（类型指针）

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

image

监视器

任何一个对象都有一个Monitor与之关联，当且一个Monitor被持有后，它将处于锁定状态。Synchronized在JVM里的实现都是 基于进入和退出Monitor对象来实现方法同步和代码块同步，虽然具体实现细节不同，可是均可以经过成对的MonitorEnter和MonitorExit指令来实现。

  • MonitorEnter指令：插入在同步代码块的开始位置，当代码执行到该指令时，将会尝试获取该对象Monitor的全部权，即尝试得到该对象的锁；
  • MonitorExit指令：插入在方法结束处和异常处，JVM保证每一个MonitorEnter必须有对应的MonitorExit；

Monitor是由ObjectMonitor实现的，其主要数据结构以下（位于HotSpot虚拟机源码ObjectMonitor.hpp文件，C++实现的）：

ObjectMonitor() {
    _header       = NULL;
    _count        = 0; // 记录个数
    _waiters      = 0,
    _recursions   = 0;
    _object       = NULL;
    _owner        = NULL;
    _WaitSet      = NULL; // 处于wait状态的线程，会被加入到_WaitSet
    _WaitSetLock  = 0 ;
    _Responsible  = NULL ;
    _succ         = NULL ;
    _cxq          = NULL ;
    FreeNext      = NULL ;
    _EntryList    = NULL ; // 处于等待锁block状态的线程，会被加入到该列表
    _SpinFreq     = 0 ;
    _SpinClock    = 0 ;
    OwnerIsThread = 0 ;
  }

ObjectMonitor中有两个队列，_WaitSet 和 _EntryList，用来保存ObjectWaiter对象列表（ 每一个等待锁的线程都会被封装成ObjectWaiter对象 ），_owner指向持有ObjectMonitor对象的线程，当多个线程同时访问一段同步代码时：

  • 首先会进入 _EntryList 集合，当线程获取到对象的monitor后，进入 _Owner区域并把monitor中的owner变量设置为当前线程，同时monitor中的计数器count加1；
  • 若线程调用 wait() 方法，将释放当前持有的monitor，owner变量恢复为null，count自减1，同时该线程进入 WaitSet集合中等待被唤醒；
  • 若当前线程执行完毕，也将释放monitor（锁）并复位count的值，以便其余线程进入获取monitor(锁)；

锁的优化

从JDK6开始，就对synchronized的实现机制进行了较大调整，包括使用JDK5引进的CAS自旋以外，还增长了自适应的CAS自旋、锁消除、锁粗化、偏向锁、轻量级锁这些优化策略。因为此关键字的优化使得性能极大提升，同时语义清晰、操做简单、无需手动关闭，因此推荐在容许的状况下尽可能使用此关键字，同时在性能上此关键字还有优化的空间。

锁主要存在四种状态，依次是：无锁状态、偏向锁状态、轻量级锁状态、重量级锁状态，锁能够从偏向锁升级到轻量级锁，再升级的重量级锁。可是锁的升级是单向的，也就是说只能从低到高升级，不会出现锁的降级。

自旋锁

线程的阻塞和唤醒须要CPU从用户态转为核心态，频繁的阻塞和唤醒对CPU来讲是一件负担很重的工做，势必会给系统的并发性能带来很大的压力。同时咱们发如今许多应用上面，对象锁的锁状态只会持续很短一段时间，为了这一段很短的时间频繁地阻塞和唤醒线程是很是不值得的。

因此引入自旋锁，何谓自旋锁？

所谓自旋锁，就是指当一个线程尝试获取某个锁时， 若是该锁已被其余线程占用，就一直循环检测锁是否被释放，而不是进入线程挂起或睡眠状态。

自旋锁适用于锁保护的临界区很小的状况，临界区很小的话，锁占用的时间就很短。自旋等待不能替代阻塞，虽然它能够避免线程切换带来的开销，可是它占用了CPU处理器的时间。若是持有锁的线程很快就释放了锁，那么自旋的效率就很是好，反之，自旋的线程就会白白消耗掉处理的资源，它不会作任何有意义的工做，典型的占着茅坑不拉屎，这样反而会带来性能上的浪费。因此说，自旋等待的时间（自旋的次数）必需要有一个限度，若是自旋超过了定义的时间仍然没有获取到锁，则应该被挂起。

自旋锁在JDK1.6中默认开启。同时自旋的默认次数为10次，能够经过参数-XX:PreBlockSpin来调整。

若是经过参数-XX:PreBlockSpin来调整自旋锁的自旋次数，会带来诸多不便。假如将参数调整为10，可是系统不少线程都是等你刚刚退出的时候就释放了锁（假如多自旋一两次就能够获取锁），是否是很尴尬。因而JDK1.6引入自适应的自旋锁，让虚拟机会变得愈来愈聪明。

适应性自旋锁

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循环以外。

偏向锁

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

偏向锁是在单线程执行代码块时使用的机制，若是在多线程并发的环境下（即线程A还没有执行完同步代码块，线程B发起了申请锁的申请），则必定会转化为轻量级锁或者重量级锁。

在JDK5中偏向锁默认是关闭的，而到了JDK6中偏向锁已经默认开启。

引入偏向锁主要目的是：为了在没有多线程竞争的状况下尽可能减小没必要要的轻量级锁执行路径。由于轻量级锁的加锁解锁操做是须要依赖屡次CAS原子指令的，而偏向锁只须要在置换ThreadID的时候依赖一次CAS原子指令（因为一旦出现多线程竞争的状况就必须撤销偏向锁，因此偏向锁的撤销操做的性能损耗也必须小于节省下来的CAS原子指令的性能消耗）。

轻量级锁是为了在线程交替执行同步块时提升性能，而偏向锁则是在只有一个线程执行同步块时进一步提升性能。

那么偏向锁是如何来减小没必要要的CAS操做呢？

如今几乎全部的锁都是可重入的，即已经得到锁的线程能够屡次锁住/解锁监视对象，按照以前的HotSpot设计，每次加锁/解锁都会涉及到一些CAS操做（好比对等待队列的CAS操做）， CAS操做会延迟本地调用，所以偏向锁的想法是 一旦线程第一次得到了监视对象，以后让监视对象“偏向”这个线程，以后的屡次调用则能够避免CAS操做，说白了就是置个变量，若是发现为true则无需再走各类加锁/解锁流程。

当一个线程访问同步块并获取锁时，会在对象头和栈帧中的锁记录里存储锁偏向的线程ID，之后该线程进入和退出同步块时不须要花费CAS操做来争夺锁资源，只须要检查是否为偏向锁、锁标识为以及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. 判断锁对象是否还处于被锁定状态，否，则恢复到无锁状态，以容许其他线程竞争。是，则挂起持有锁的当前线程，并将指向当前线程的锁记录地址的指针放入对象头Mark Word，升级为轻量级锁状态（00），而后恢复持有锁的当前线程，进入轻量级锁的竞争模式；

注意：此处将 当前线程挂起再恢复的过程当中并无发生锁的转移，仍然在当前线程手中，只是穿插了个 “将对象头中的线程ID变动为指向锁记录地址的指针” 这么个事。

轻量级锁

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

在代码进入同步块的时候，若是此同步对象没有被锁定（锁标志位为“01”状态），虚拟机首先将在当前线程的栈帧中创建一个名为锁记录（Lock Record）的空间，用于存储锁对象目前的 Mark Word 的拷贝 （官方把这份拷贝加了一个 Displaced 前辙，即Displaced Mark Word ），这时候线程堆栈与对象头的状态如图所示：

image

而后，虚拟机将使用CAS操做尝试将对象的 Mark Word 更新为指向 Lock Record 的指针。若是这个更新动做成功了，那么这个线程就拥有了该对象的锁，而且对象 Mark Word 的锁标志位（Mark Word 的最后 2bit ）将转变为 “00”，即表示此对象处于轻量级锁定状态，这时候线程堆栈与对象头的状态如图所示：

image

若是这个更新操做失败了，虚拟机首先会检查对象的Mark Word是否指向当前线程的栈帧，若是是说明当前线程已经拥有了这个对象的锁，那就能够直接进入同步块继续执行，不然说明这个锁对象已经被其余线程抢占了。若是有两条以上的线程争用同一个锁，那轻量级锁就再也不有效，要膨胀为重量级锁，锁标志的状态值变为“10”，Mark Word 中存储的就是指向重量级锁（互斥量）的指针，后而等待锁的线程也要进入阻塞状态。

对于轻量级锁，其性能提高的依据是 “对于绝大部分的锁，在整个生命周期内都是不会存在竞争的”，若是打破这个依据则除了互斥的开销外，还有额外的CAS操做，所以在有多线程竞争的状况下，轻量级锁比重量级锁更慢。

轻量级锁所适应的场景是线程交替执行同步块的状况，若是存在同一时间访问同一锁的状况，必然就会致使轻量级锁膨胀为重量级锁。

重量级锁

Synchronized是经过对象内部的一个叫作 监视器锁（Monitor）来实现的。可是监视器锁本质又是依赖于底层的操做系统的Mutex Lock来实现的。而操做系统实现线程之间的切换这就须要从用户态转换到核心态，这个成本很是高，状态之间的转换须要相对比较长的时间，这就是为何Synchronized效率低的缘由。所以，这种依赖于操做系统Mutex Lock所实现的锁咱们称之为 “重量级锁”。

锁的优劣

各类锁并非相互代替的，而是在不一样场景下的不一样选择，绝对不是说重量级锁就是不合适的。每种锁是只能升级，不能降级，即由偏向锁->轻量级锁->重量级锁，而这个过程就是开销逐渐加大的过程。

  • 若是是单线程使用，那偏向锁毫无疑问代价最小，而且它就能解决问题，连CAS都不用作，仅仅在内存中比较下对象头就能够了；
  • 若是出现了其余线程竞争，则偏向锁就会升级为轻量级锁；
  • 若是其余线程经过必定次数的CAS尝试没有成功，则进入重量级锁；

image

总结

有关Synchronized的知识点暂时先到这里，后面咱们会学习其余关键字如volatile等。

参考
啃碎并发(七)：深刻分析Synchronized原理

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程