Synchronized锁性能优化偏向锁轻量级锁升级 多线程中篇（五）

不止一次的提到过，synchronized是Java内置的机制，是JVM层面的，而Lock则是接口，是JDK层面的

尽管最初synchronized的性能效率比较差，可是随着版本的升级，synchronized已经变得原来越强大了

这也是为何官方建议使用synchronized的缘由

毕竟，他是一个关键字啊，这才是亲儿子，Lock，终归差了一点

简单看下，synchronized大体都通过了哪些重要的变革

重量级锁

对于最原始的synchronized关键字，锁被称之为重量级锁

由于底层依赖监视器，监视器又依赖操做系统底层的互斥锁，java的线程是内核映射的

若是获取不到锁，那么就必然会发生内核态与用户态的转换，成本很高，因此效率比较低

全部的优化，其实都是为了将原来的重量级锁的“重量”变轻...

在如今的版本中，锁的状态总共有四种：

• 无锁状态
• 偏向锁
• 轻量级锁
• 重量级锁

很显然锁的“重量”从左到右，依次递增

无所状态很好理解，新增长的偏向锁与轻量级锁，其实就是尽量的将重量级锁往“无锁”的方向靠拢，尽量的减小重量

减小重量的思路就是，经过必定的逻辑处理与判断，若是不须要加锁，那么我就少加一点锁

继续以前先介绍两个概念，Mark Word和CAS

Mark Word

对于每一个对象，都有一个对象头，这部分存储了对象的必要信息

对象头中有一个主要区域被称之为Mark Word（其实就是那一段地址保存的数据的统称）

其实能够简单理解为一个数据结构，里面保存了一些必要的数据信息

为了节省空间，并非每一个字段都有空间，不一样的锁状态，有不一样的字段含义，好比说32位，这几位作什么，那几位作什么，了解过class字节码文件的话应该很容易理解这种思惟

与本文相关的有下面这些，暂时能够不去思考如何保存的问题，就只须要知道有这么些字段便可（你简单理解为一个结构体，每一个字段都有空间表示也不影响理解此处的叙述）

• 锁标志位（什么类型的锁），他的标志包括：无锁、轻量级锁、重量级锁、偏向锁
• 轻量级锁时会记录：指向栈中锁记录的指针
• 重量级锁时会记录：指向互斥量（重量级锁）的指针
• 偏向锁时会记录：线程ID   

CAS

再简单提一个概念CAS

compareAndSwap，比较并替换，是一种实现并发算法时经常使用到的技术

CAS须要有3个操做数：内存地址V，旧的预期值A，即将要更新的目标值B

好比你要操做一个变量，他的值为A，你但愿将他修改成B，这期间不会进行加锁，当你在修改的时候，你发现值仍旧是A，而后将它修改成B，若是此时值被其余线程修改了，变成了C，那么将不会进行值B的写入操做，这就是CAS的核心理论，经过这样的操做能够实现逻辑上的一种“加锁”，避免了真正去加锁  

轻量级锁  

轻量级锁本质是借助于CAS操做，对于竞争不激烈的场景下，能够减小重量级锁的使用

线程须要访问同步代码体时，会判断当前状态是不是无锁状态

若是无锁，将会尝试经过CAS操做，复制一份Mark Down 而且将Mark Down中的字段指向该线程栈中锁记录的指针

• 成功说明没有竞争，那么执行同步代码体；
• 失败说明存在竞争，那么锁会升级为重量级锁，Mark Down字段修改成指向重量级锁指针，而且请求锁的线程会被阻塞

当持有线程执行结束后，会尝试借助于CAS操做恢复Mark Down

若是有竞争会升级为重量级锁，Mark Down字段会被修改，CAS操做会失败，因此：

• 若是这次CAS成功，锁释放完成；
• 若是失败，将会释放锁而且唤醒被阻塞的线程

简要逻辑图以下

  

对于轻量级锁，核心就是CAS操做，由于一旦出现竞争，Mark Down信息将会被修改，而CAS操做的原理就是新值与旧值的对比后再操做，因此CAS操做的成功与否，能够推断是否有竞争

有竞争那么就会升级为重量级锁，其余请求线程会被阻塞，该线程执行结束后会唤醒其余阻塞线程；不然无竞争就会释放退出

很显然，若是竞争激烈的场景，很快就会升级为重量级锁，而关于轻量级锁全部的一切都是徒劳的

不过幸运的是，实践代表，大多数场景并不会竞争激烈    

偏向锁

对于轻量级锁中，须要对Mark Down字段进行维护，以及复制Mark Down，以及屡次CAS操做

可是事实上，很多场景中，也的确常常存在只有一个线程访问的状况

若是只有一个线程来回访问，那么轻量级锁的维护相对来讲不也是没有必要的么，是否还能够进一步优化？偏向锁就是一种优化方案

偏向锁的提出就是针对于这种场景：

锁不只不存在多线程竞争，并且老是由同一线程屡次得到

因此偏向的概念，就是偏向这个线程，它的核心思想就是：

锁会偏向第一个获取它的线程，若是不存在竞争，只有一个线程，则持有偏向锁的线程永远不须要同步

若是没有竞争，能够看到出来，偏向锁的能够约等因而无锁的

核心原理：

当一个线程访问同步块并获取锁时，会记录存储锁偏向的线程ID

后续该线程在进入和退出同步块时再也不须要CAS操做来加锁和解锁，只需简单地判断一下对象头的Mark Word里是否存储着指向当前线程的偏向锁

一个简要的逻辑以下图所示

ps:

上图中若是线程ID不是当前线程的话，也会继续进行CAS操做的，一旦CAS失败，才会须要升级，若是成功了，仍是执行同步代码块

对于偏向锁，核心针对一般只有一个线程执行同步代码的场景

经过记录偏向锁ID，对于同一线程，若是无锁状态获取偏向锁成功或者是偏向锁，且为该线程，后续的进出无需额外的同步操做：

可是一旦出现竞争，那么就会进行锁升级，升级为轻量级锁

小结

轻量级锁和偏向锁都是借助于CAS，若是出现问题，将会进行锁的升级，升级是不可逆的，也就是说只能从低到高，也就是偏向-->轻量级-->重量级，不可以降级

偏向锁是对于轻量级锁的更进一步优化，固然这是有前提的，那就是“场景”

很显然，对于偏向锁和轻量级锁，若是不是同一线程或者线程竞争激烈，将会迅速的从偏向锁升级为轻量级锁，而后迅速变为重量级锁，而偏向锁和轻量级锁带来的一切开销，都将是额外的开销，因此两者的开启与否要根据业务来，不一样版本的JDK开启状态有所不一样

自旋，适应性自旋

在锁分类一文中，对自旋的概念进行了简单介绍

再次说下，所谓自旋，不是获取不到就阻塞，而是在原地等待一下子，再次尝试（固然次数或者时长有限），他是以牺牲CPU为代价来换取内核状态切换带来的开销

适应性自旋是针对于自旋的限制，好比次数（时长）的一种优化，若是本次成功下次多等待几回，若是常常失败，可能就不自旋了

借助于适应性自旋，能够在CPU时间片的损耗和内核状态的切换开销之间相对的找到一个平衡，进而可以提升性能

从原来的一旦获取不到就阻塞、状态切换，转变为在有的时候能够借助于较小的CPU浪费避免状态切换的开销，因此显然能够提高性能

锁消除

锁消除，就是消除锁

但是，难道好好地一个synchronized方法，最后JVM会把关键字去掉吗？显然不是这个意思

他指的是删除非必要的同步

根据代码逃逸技术，若是判断到一段代码中，堆上的数据不会逃逸出当前线程，那么能够认为这段代码是线程安全的，没必要要加锁

什么是逃逸，好比A方法，调用B方法，B方法将内部建立的一个局部对象，返回给了A，那么这个B中的变量就属于逃逸了，就存在被其余线程访问的可能

简单说除了你写代码以外，Java底层包括从编译器到JVM还有不少工做人员在忙活，人家经过算法一看，你这根本就没有必要使用同步，就会在实际执行的时候把你的同步去掉

你可能觉得，我本身哪有写不少synchronized修饰的方法？

可是你仔细想一下，你即便不写，代码中JDK提供的方法、别人提供的Jar包中的方法，他们用了多少synchronized？

最终不都会进入到你的方法中么？

因此实际代码中的synchronized（同步）远比你想象到的要多得多

因此若是能够消除没必要要的同步，岂不是性能会有所提高？

锁粗化（锁膨胀）

仍是以方法调用为例，假如一个A方法，中有三个对象b,c,d，分别调用他们的方法并且都是同步方法

void A（）{

b.function();

c.function();

d.function();

}

每一个方法都加锁解锁，是否是很烦很费电？

若是碰巧他们用的都是同一把锁呢？是否是能够尝试进行合并？

也就是说，虚拟机检测到有一系列连串的对同一个对象加锁和解锁操做，就会将其合并成一次范围更大的加锁和解锁操做

多个加锁解锁操做，转变为一次的加锁和解锁

加锁解锁必然会消耗性能，若是能够进行合并，显然能够提升性能

小结

以上为大体的synchronized优化过的点

面对一个蒸蒸日上的努力小青年，并且还有那么多自身具备的优点（隐式锁相对于显式锁，对开发者来讲友好了不少，毕竟若是能够，你们都不喜欢多操心的）

有什么理由必定要放弃他呢？

因此除非场景特殊，或者对程序分析后，业务适合，不然尽量的选择synchronized吧

synchronized是重量级的，他能够“包治百病”，尽管性能或许没有你的指望那么好

另外有些优化好比偏向锁、轻量级锁，对场景是有要求的，若是无论三七二十一，也许并不必定会提升，反而更差，因此对于锁优化参数的开闭也须要参照场景

原文地址:Synchronized锁性能优化偏向锁轻量级锁升级 多线程中篇（五）