JAVAEE多线程synchronized 优化过程

文章目录

  • synchronized 优化过程
    • 一、锁升级/锁膨胀
      • 1. 偏向锁
      • 2. 轻量级锁
      • 3. 重量级锁
    • 二、锁消除
    • 三、锁粗化
  • 总结


synchronized 优化过程

对于synchronized

1.既是乐观锁,也是悲观锁
2.既是轻量级锁,也是重量级锁
3.乐观锁的部分是基于自旋锁实现的,悲观锁的部分是基于挂起等待锁实现的
4.不是读写锁,普通互斥锁
5.是非公平锁
6.是可重入锁

synchronized是自适应的!!!
synchronized初始使用的时候,是 乐观锁/轻量级锁/自旋锁
如果锁竞争激烈,synchronized会自动升级成 悲观锁/重量级锁/挂起等待锁

JVM在实现synchronized的时候给我们提供自动优化的策略~
一个synchronized 自动适应多种不同的场景!!
JAVAEE多线程synchronized 优化过程_第1张图片

一、锁升级/锁膨胀

synchronized的效果是"加锁"

当两个线程针对同一个对象加锁的时候,就会出现锁竞争~
后来尝试加锁的线程就得阻塞等待,直到前一个线程释放锁~

synchronized加锁的具体过程:

  1. 偏向锁
  2. 轻量级锁
  3. 重量级锁

synchronized 更多的考虑到程序员的使用负担,内部就实现了"自适应"这样的操作.

如果当前场景中,锁竞争不激烈,则是以轻量级锁状态来进行工作(自旋,第一时间拿到锁)

如果当前场景中,锁竞争激烈,则是以重量级锁状态来进行工作(挂起等待,拿到锁没那么及时,但是节省了开销)

无竞争,偏向锁
有竞争,轻量级锁
竞争激烈,重量级锁

上述的变化就叫做锁升级/锁膨胀

JVM实现synchronized的时候,为了方便程序员使用,引入的一些优化机制~

在这里插入图片描述

1. 偏向锁

偏向锁的本质类似于懒汉模式~
必要的时候再加锁,能不加就不加~

比如我给某个线程加了个synchronized,但是这个代码实际执行过程中,不一定会触发锁竞争!
类似count++ :

如果两个线程本身调度的时候恰好错开了,此时t1t2的锁竞争并没有真的发生 如果不是真的发生了锁竞争,就没有必要真的加锁
JAVAEE多线程synchronized 优化过程_第2张图片
但是如果这种情况:
JAVAEE多线程synchronized 优化过程_第3张图片
如果没有t2的竞争,t1的锁就不生效,有了竞争才正式生效。
这种不是真实生效的状态,就叫偏向锁

偏向锁不是真加锁,而是只是设置了一个状态~
如果没有其他线程参与竞争锁, 那么就不会真正执行加锁操作, 从而降低程序开销.
一旦真的涉及到其他的线程竞争, 再取消偏向锁状态, 进入轻量级锁状态.

JAVAEE多线程synchronized 优化过程_第4张图片

2. 轻量级锁

随着其他线程进入竞争, 偏向锁状态被消除, 进入轻量级锁状态(自适应的自旋锁).
此处的轻量级锁就是通过 CAS 来实现

  • 通过 CAS 检查并更新一块内存 (比如 null => 该线程引用)
  • 如果更新成功, 则认为加锁成功
  • 如果更新失败, 则认为锁被占用, 继续自旋式的等待(并不放弃 CPU).

自旋操作是一直让 CPU 空转, 比较浪费 CPU 资源.
因此此处的自旋不会一直持续进行, 而是达到一定的时间/重试次数, 就不再自旋了.
也就是所谓的 “自适应

3. 重量级锁

如果竞争进一步激烈, 自旋不能快速获取到锁状态, 就会膨胀为重量级锁
此处的重量级锁就是指用到内核提供的 mutex .

  • 执行加锁操作, 先进入内核态.
  • 在内核态判定当前锁是否已经被占用
  • 如果该锁没有占用, 则加锁成功, 并切换回用户态.
  • 如果该锁被占用, 则加锁失败. 此时线程进入锁的等待队列, 挂起. 等待被操作系统唤醒.
  • 经历了一系列的沧海桑田, 这个锁被其他线程释放了, 操作系统也想起了这个挂起的线程, 于是唤醒这个线程, 尝试重新获取锁.

在这里插入图片描述

二、锁消除

JVM自动判定,发现这个地方的代码,不必加锁,如果写了synchronized,就会自动的把锁给去掉!!

举个例子:

比如我只有一个线程/或者有多个线程,多个线程不涉及修改同一个变量,如果代码中也写了synchronized,此时synchronized加锁操作,就会直接被JVM给干掉~

synchronized加锁应该是 先偏向锁 !

锁消除也是一种编译器优化的行为~
编译器的判定,不一定非常准!

因此如果代码的锁100%能消除, 就消除了.
如果这个代码的锁,判定不准能不能消除(判定80%的可能是可以消除,20%的可能不能消除),就还是不消除了

因此锁消除只是在编译器/JVM有十足的把握的时候才进行的!!

在这里插入图片描述

三、锁粗化

锁的粒度:
synchronized对应的代码块包含多少代码,包含的代码少,就叫粒度细,包含的代码多,就叫粒度粗~

锁粗化,就是把细粒度的加锁转化为粗粒度的加锁

比如下图:

JAVAEE多线程synchronized 优化过程_第5张图片
一开始加锁解锁很多次,锁粗化就直接把中间的全部清除,只留开头和结尾的加锁和解锁
因为每次解锁再加锁就会带来额外的锁竞争,带来更大的开销

粗化的前提是保证你的逻辑不变~
细化的时候代码是正确的,粗化之后代码还是正确的~

锁的粒度也不是越粗越好~
有的时候锁太粗不利于多线程并发,有悖于之前写多线程的初衷了…

总结

在这里插入图片描述

你可以叫我哒哒呀
本篇到此结束
“莫愁千里路,自有到来风。”
我们顶峰相见!

你可能感兴趣的:(jvm,java,面试)