不止一次的提到过,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成功,锁释放完成;
  • 如果失败,将会释放锁并且唤醒被阻塞的线程
简要逻辑图如下
Synchronized锁性能优化偏向锁轻量级锁升级 多线程中篇(五)-LMLPHP  
对于轻量级锁,核心就是CAS操作,因为一旦出现竞争,Mark Down信息将会被修改,而CAS操作的原理就是新值与旧值的对比后再操作,所以CAS操作的成功与否,可以推断是否有竞争
有竞争那么就会升级为重量级锁,其他请求线程会被阻塞,该线程执行结束后会唤醒其他阻塞线程;否则无竞争就会释放退出
很显然,如果竞争激烈的场景,很快就会升级为重量级锁,而关于轻量级锁所有的一切都是徒劳的
不过幸运的是,实践表明,大多数场景并不会竞争激烈    

偏向锁

对于轻量级锁中,需要对Mark Down字段进行维护,以及复制Mark Down,以及多次CAS操作
但是事实上,不少场景中,也的确经常存在只有一个线程访问的情况
如果只有一个线程来回访问,那么轻量级锁的维护相对来说不也是没有必要的么,是否还可以进一步优化?偏向锁就是一种优化方案
偏向锁的提出就是针对于这种场景:
锁不仅不存在多线程竞争,而且总是由同一线程多次获得
所以偏向的概念,就是偏向这个线程,它的核心思想就是:
锁会偏向第一个获取它的线程,如果不存在竞争,只有一个线程,则持有偏向锁的线程永远不需要同步
如果没有竞争,可以看到出来,偏向锁的可以约等于是无锁的
核心原理:
当一个线程访问同步块并获取锁时,会记录存储锁偏向的线程ID
后续该线程在进入和退出同步块时不再需要CAS操作来加锁和解锁,只需简单地判断一下对象头的Mark Word里是否存储着指向当前线程的偏向锁
一个简要的逻辑如下图所示
Synchronized锁性能优化偏向锁轻量级锁升级 多线程中篇(五)-LMLPHP
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是重量级的,他可以“包治百病”,尽管性能或许没有你的期望那么好
另外有些优化比如偏向锁、轻量级锁,对场景是有要求的,如果不管三七二十一,也许并不一定会提高,反而更差,所以对于锁优化参数的开闭也需要参照场景
04-21 11:10