个人中心
gpt4 book ai didi

Java多线程揭秘之synchronized工作原理

转载 作者：qq735679552 更新时间：2022-09-28 22:32:09 31 4
gpt4 key购买 nike

CFSDN坚持开源创造价值，我们致力于搭建一个资源共享平台，让每一个IT人在这里找到属于你的精彩世界.

这篇CFSDN的博客文章Java多线程揭秘之synchronized工作原理由作者收集整理，如果你对这篇文章有兴趣，记得点赞哟.

在学习本篇文章时，如果有不太懂的地方，大家也可以先看看博主上一篇文章，锁的这部分内容是面试中很常见的问题，多学学对自己是非常有帮助的。同时，朋友们如果有什么问题都可以随时和我探讨，大家一起进步！ 。

一. 特性

这部分内容在上篇文章中的 synchronized充当了哪些锁部分已经介绍过了哦，没有看的小伙伴可以去看看synchronized的特性 。

二. 加锁过程（锁升级/锁膨胀）

在Java中JVM虚拟机将synchronized锁分为无锁、偏向锁、轻量级锁、重量级锁状态。会根据不同的情况，进行不同的升级操作 。

Java多线程揭秘之synchronized工作原理

1. 无锁状态

此状态理解起来较为简单，没有进行线程任务时最开始的状态就是无锁状态.

2. 偏向锁

  • 偏向锁类似于一种乐观锁，当一个线程在执行任务时，偏向锁会给这个线程设定一个标记（并不是真正地加锁），如果后续没有其他线程来竞争这个锁，那么这个偏向锁就不会再进行其他的任何操作了，有效避免了因为加锁过程而产生的内存开销问题
  • 若有其他线程也竞争这把锁，那么此时第一个线程会立马把锁拿到（因为之前第一个线程已经有了偏向锁标记，所以很容易拿到）然后进入轻量级锁的状态

偏向锁的大体思路是能不加锁就尽量不加锁避免内存开销，只做上标记即可，但如果实在要加锁，也会因为标记的存在而立马把锁拿到（类似于高考填志愿保底心态） 。

3. 轻量级锁

当进入轻量级锁锁状态（自适应自旋锁）后，是完全在用户态上实现的，且是基于CAS来完成的操作，因为这个状态不涉及到内核态和用户态的切换，也不涉及到线程的阻塞和调度过程。所以并不会对系统的内存有着过于高的开销，因此可以保证更高效地获取到锁（一个线程释放锁后，另一个线程会马上获取到锁） 。

具体步骤 。

  • 通过 CAS 检查并更新一块内存 (比如 null => 该线程引用)
  • 如果更新成功, 则认为加锁成功
  • 如果更新失败, 则认为锁被占用, 继续自旋式的等待(并不放弃 CPU)由于自旋操作可能会一直让CPU 空转，比较浪费 CPU 资源，因此此处的自旋不会一直持续进行，而是达到一定的时间（重试）次数，就不再自旋了，也就是所谓的 “自适应”（根据情况来）

4. 重量级锁

当锁的竞争变得非常激烈时，如果再按照之前自旋的方式，那么对于CPU的开销是非常高的，而且此时自旋还不能快速地获取到锁的状态，那么此时就会变成重量级锁（挂起等待锁），对于挂起等待锁来说，锁的等待过程是释放CPU的过程，此时会节省CPU的开销，但付出的代价是引入了线程的阻塞和调度的开销（以CPU资源换取性能） 具体过程 此处的重量级锁就是用到了内核提供的mutex，要执行加锁操作，首先会进入内核态，在内核态判定当前的锁是否已经被占用，若该锁没有被占用，则加锁成功，切换回用户态；若该锁被占用，则加锁失败，此时线程进入锁的等待队列去挂起等待，直到锁被其他线程释放后，操作系统才会唤醒挂起等待锁的这个线程，最后这个线程才会获取到锁 。

5. 总结

  • 锁升级（锁膨胀）的过程完全是synchronized内部自适应完成的，即根据不同的情况（即锁冲突的高或低状态）来升级或降级成对应的状态，不需要用户或者程序员去干预，因此使用起来会比较方便。
  • 注意， synchronized在有些JVM版本上是可以同时实现降级和升级的自适应的，但在有些JVM上只能实现升级的自适应。

三. 锁优化

1. 锁消除

JVM和编译器提供了一个很好的功能，能判断某段代码是否有加锁的必要（根据情况选择是否需要加锁），以防开发人员加错锁而造成无缘无故开销很大系统内存的情况。 例子 Java提供了两个类，StringBuilder和StringBuffer，其中，前者不会考虑线程安全问题，而后者中的每个方法都带有了synchronized以确保线程安全。但我们平常在单线程下，这个加锁是没有必要的，会白白浪费很多内存资源，这时候，如果开发人员不小心在单线程中使用了StringBuffer，那么编译器和JVM也会对其进行一定的优化，去把这个锁消除。 注意，编译器的判断也不是每次完全都是正确的，不会每次都会锁消除，因此，还是要提醒大家在写代码过程中自己还是要尽量避免出现此类错误 。

2. 锁粗化

介绍锁粗化之前，首先大家得知道锁的粗细的含义:

  • 如果synchronized代码块中包含的代码比较多，则认为锁比较粗
  • 如果synchronized代码块中包含的代码比较少，则认为锁比较细

那么实际开发中，到底是锁粗一点好还是细一点好呢？这个还是根据情况来决定的，虽然当锁里面的代码量少时会减少线程之间的锁冲突概率，但是有的情况下，反而当锁里面的代码量较多时，运行效率才会更高:

?
1
2
3
4
5
6
7
8
9
10
11
void func(){
         synchronized ( this ){
             //任务1
         }
         synchronized ( this ){
             //任务2
         }
         synchronized ( this ){
             //任务3
         }
     }

大家先来看一看这段代码，这段代码是细锁的情况（一个锁中的代码量较少），那么其执行效率怎么样呢？显然是不太高的，每次加一次锁都会进行一定的内存开销，因此我们很有必要对其进行一定地改进，让锁粗化:

?
1
2
3
4
5
6
7
void func(){
         synchronized ( this ){
             //任务1
             //任务2
             //任务3
         }
     }

可以看出来，当锁粗化的时候，会大大提高代码的执行效率 就好比出门买物品A和物品B，我们通常会尽可能地出一次门，将二者一块买好再回家，而不是先把物品A买好放到家里再出门买物品B，这样显然效率是非常低的，而且还很浪费体力 。

到此这篇关于Java多线程揭秘之synchronized工作原理的文章就介绍到这了,更多相关Java synchronized内容请搜索我以前的文章或继续浏览下面的相关文章希望大家以后多多支持我！ 。

原文链接：https://blog.csdn.net/Mubei1314/article/details/120795468 。

最后此篇关于Java多线程揭秘之synchronized工作原理的文章就讲到这里了,如果你想了解更多关于Java多线程揭秘之synchronized工作原理的内容请搜索CFSDN的文章或继续浏览相关文章，希望大家以后支持我的博客！ 。

31 4 0
文章推荐： C#文件流读写和进度回调示例详解
文章推荐： 我劝你谨慎使用Spring中的@Scheduled注解
文章推荐： Java面试最容易被刷的重难点之锁的使用策略
文章推荐： Java中的函数式编程
qq735679552
个人简介

我是一名优秀的程序员,十分优秀！

滴滴打车优惠券免费领取
滴滴打车优惠券
全站热门文章
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com