【JavaEE初阶】 Synchronized 原理详解

本文详细解析了Java中的Synchronized关键字,包括其乐观锁到悲观锁的转变,轻量级锁与重量级锁的区别,以及锁消除和锁粗化的优化策略。通过实例和面试题说明了Synchronized复杂策略背后的原理和目的。
摘要由CSDN通过智能技术生成

🌲Synchronized关键字的基本特点

结合博主在《【JavaEE初阶】 常见的锁策略详解》里面的解释, 我们就可以总结出, Synchronized 具有以下特性(只考虑 JDK 1.8):

  1. 开始时是乐观锁, 如果锁冲突频繁, 就转换为悲观锁.

  2. 开始是轻量级锁实现, 如果锁被持有的时间较长, 就转换成重量级锁.

  3. 实现轻量级锁的时候大概率用到的自旋锁策略

  4. 是一种不公平锁

  5. 是一种可重入锁

  6. 不是读写锁

🎍Synchronized的加锁过程

JVM 将 synchronized 锁分为 无锁、偏向锁、轻量级锁、重量级锁 状态。会根据情况,进行依次升级
在这里插入图片描述

🚩无锁

无锁大家都能理解,大致意思是如果这个锁无人竞争,或者只有一个线程的时候,这时候不存在线程安全问题,Synchronized不会对其进行加锁

🚩偏向锁

第一个尝试加锁的线程, 优先进入偏向锁状态

  • 偏向锁不是真的 “加锁”, 只是给对象头中做一个 “偏向锁的标记”, 记录这个锁属于哪个线程.

  • 如果后续没有其他线程来竞争该锁, 那么就不用进行其他同步操作了(避免了加锁解锁的开销)

  • 如果后续有其他线程来竞争该锁(刚才已经在锁对象中记录了当前锁属于哪个线程了, 很容易识别
    当前申请锁的线程是不是之前记录的线程), 那就取消原来的偏向锁状态, 进入一般的轻量级锁状态.

  • 偏向锁本质上相当于 “延迟加锁” . 能不加锁就不加锁, 尽量来避免不必要的加锁开销.

  • 但是该做的标记还是得做的, 否则无法区分何时需要真正加锁

举个例子理解偏向锁:

假设男主是一个锁, 女主是一个线程. 如果只有这一个线程来使用这个锁, 那么男主女主即使不领证结婚(避免了高成本操作), 也可以一直幸福的生活下去.
但是女配出现了, 也尝试竞争男主, 此时不管领证结婚这个操作成本多高, 女主也势必要把这个动作完成了, 让女配死心.

可以理解为:非必要不加锁

🚩轻量级锁

随着其他线程进入竞争, 偏向锁状态被消除, 进入轻量级锁状态(自适应的自旋锁).

此处的轻量级锁就是通过 CAS 来实现

  • 通过 CAS 检查并更新一块内存 (比如 null => 该线程引用)

  • 如果更新成功, 则认为加锁成功

  • 如果更新失败, 则认为锁被占用, 继续自旋式的等待(并不放弃 CPU).

值得注意的是:

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

🚩重量级锁

如果竞争进一步激烈, 自旋不能快速获取到锁状态, 就会膨胀为重量级锁

此处的重量级锁就是指用到内核提供的 mutex .

  • 执行加锁操作, 先进入内核态.

  • 在内核态判定当前锁是否已经被占用

  • 如果该锁没有占用, 则加锁成功, 并切换回用户态.

  • 如果该锁被占用, 则加锁失败. 此时线程进入锁的等待队列, 挂起. 等待被操作系统唤醒.

  • 经历了一系列的沧海桑田, 这个锁被其他线程释放了, 操作系统也想起了这个挂起的线程, 于是唤醒
    这个线程, 尝试重新获取锁

🎋其他的优化操作

除上述的加锁过程中做的优化,Synchronized还有一些其他的优化措施

分别为:锁消除 和 锁粗化

🚩锁消除

锁消除的意思为:编译器+JVM 判断锁是否可消除. 如果可以, 就直接消除

比如:有些应用程序的代码中, 用到了 synchronized, 但其实没有在多线程环境下. (例如 StringBuffer)

StringBuffer sb = new StringBuffer();
sb.append("a");
sb.append("b");
sb.append("c");
sb.append("d");

此时每个 append 的调用都会涉及加锁和解锁. 但如果只是在单线程中执行这个代码, 那么这些加锁解锁操作是没有必要的, 白白浪费了一些资源开销.

🚩锁粗化

锁粗化的意思为:一段逻辑中如果出现多次加锁解锁, 编译器 + JVM 会自动进行锁的粗化

锁根据其加锁的代码量可以分为两类,我们用锁的粒度来表示,代码量越多,粒度越粗

锁的粒度: 粗和细
在这里插入图片描述
实际开发过程中, 使用细粒度锁, 是期望释放锁的时候其他线程能使用锁.

但是实际上可能并没有其他线程来抢占这个锁. 这种情况 JVM 就会自动把锁粗化, 避免频繁申请释
放锁.

这里再给大家举个例子深入理解一下:

春风老哥当了领导, 给下属交代工作任务:

  • 方式一:
    打电话, 交代任务1, 挂电话.
    打电话, 交代任务2, 挂电话.
    打电话, 交代任务3, 挂电话.
  • 方式二:
    打电话, 交代任务1, 任务2, 任务3, 挂电话.

显然, 方式二是更高效的方案

所以由此可看适当的锁粗化可以提升效率

🌳相关面试题

  1. 什么是偏向锁?

偏向锁不是真的加锁, 而只是在锁的对象头中记录一个标记(记录该锁所属的线程). 如果没有其他线程参与竞争锁, 那么就不会真正执行加锁操作, 从而降低程序开销. 一旦真的涉及到其他的线程竞争, 再取消偏向锁状态, 进入轻量级锁状态.

  1. synchronized 实现原理 是什么?

参考上面的 synchronized 原理 章节全部内容

⭕总结

我们可以看到, synchronized 的策略是比价复杂的, 在背后做了很多事情, 目的为了让程序猿哪怕啥都不懂,也不至于写出特别慢的程序

这都要感谢JVM 开发者为了 Java 程序猿操碎了心(大佬们太牛了)
在这里插入图片描述

1024程序节祝全体程序员万事如意、身体健康,节日快乐!

关于《【JavaEE初阶】 Synchronized 原理详解》就讲解到这儿,感谢大家的支持,欢迎各位留言交流以及批评指正,如果文章对您有帮助或者觉得作者写的还不错可以点一下关注,点赞,收藏支持一下!

  • 51
    点赞
  • 44
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 90
    评论
评论 90
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

遇事问春风乄

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值