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

Posted 2021-02-12 noteless

不止一次的提到过，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锁性能优化偏向锁轻量级锁升级 多线程中篇（五）