当前位置:   article > 正文

【多线程】乐观/悲观锁、重量级/轻量级锁、挂起等待/自旋锁、公平/非公锁、可重入/不可重入锁、读写锁_线程 锁 可重入 自旋

线程 锁 可重入 自旋

:非常广义的概念,不是指某个具体的锁,所有的锁都可以往这些策略中套
synchronized:只是市面上五花八门的锁种,其中一种典型的实现,Java 内置的,推荐使用的锁

乐观锁和悲观锁

这两个词不是指某个具体的锁,而是锁的一种“特性”,描述了“一类”

乐观锁:加锁的时候,假设出现冲突的概率不大

  • 接下来围绕加锁要做的工作就会更少
    悲观锁:加锁的时候,假设出现锁冲突的概率很大
  • 接下来围绕加锁要做的工作就会更多

使用 synchronized,初始情况下,是乐观的(预估接下来锁冲突概率不大)

  • 同时会在背后偷偷地统计锁冲突了多少次
  • 如果发现锁冲突达到一定程度了,就会转变为“悲观的”
    乐观锁和悲观锁需要做的事情是不同的
  • 乐观做的事情少一点
  • 悲观做的事情往往更重量级

站在预测锁冲突的概率是否高
synchronized 是自适应的

重量级锁和轻量级锁

效果和悲观乐观是重叠的,只是站在的角度不一样

重量级锁:加锁的开销比较大,要做的工作更多

  • 往往悲观的时候,会做的
    轻量级锁:加锁的开销比较小,要做的工作相对更少
  • 往往乐观的时候,会做的
    但也不能认为是 100%等价,因为:
  • 乐观和悲观是站在“预估所冲突”角度
  • 重量轻量是站在“加锁开销“角度

站在加锁的开销角度
synchronized 也是自适应的

挂起等待锁和自旋锁

挂起等待锁:属于是悲观锁/重量级锁的一种典型实现
自旋锁乐观锁/轻量级锁的一种典型实现

比如:
你去追你的女神:
女神女神,我好喜欢你,

  • 你尝试对女神加锁
    女神表示:我有男朋友了

  • 女神表示她这把锁已经被别的线程给加了
    你就可以选择“等待”,等到女神锁被释放,比如:

  • 你选择每天仍然会给女神不停地问候“早安,午安…”,这里的行为称为“自旋锁

    • 这里的等待是“忙等”,等待的过程中 CPU 的资源不会释放
    • 某天女神和男朋友吵架了,不开心,你就立刻能感知到,机会来了。这样你就可以在女神锁释放的第一时间,立刻抓住机会,能够上位
    • 不停地,循环地检测锁是否被释放,一旦锁释放,就能立即有机会能获得锁
  • 你选择把女神拉黑,先不联系了,若干年后你从别人那里听说,女神分手了,你再去联络女神,这种行为就是“挂起等待锁

    • 不联系,就相当于“让出 CPU 资源”CPU 就可以去做别的事了
    • 不理女神之后,我们就可以有心思好好学习,好好敲代码,好好找工作了,在过程中做成更多的事情。过了一段时间后,我们通过一些途径听说女神分手了,再伺机而动,但“听说”的时效性很低,这个中间可能有很长的时间跨度。在这个时间跨度里,女神是否由谈了男朋友?分手了多少次?你是不知道的
    • 挂机时间更长,但能节省下 CPU 资源去做别的事情

注意:

  • 只有在假定锁冲突概率不高的情况下,才能“忙等”。如果好几个线程都在竞争同一个锁,一个线程拿到锁,其他的都在“忙等”,这样总的 CPU 消耗就会非常高
  • 而且,由于竞争太激烈,导致有些线程要等待很久才能拿到锁
  • 锁冲突很高的概率很高的话就不适合“自旋锁”方案

  • 挂起等待锁也就适合“悲观锁”这样的场景了
  • 锁竞争非常激烈,预测拿到锁的概率本身就不打,不放吧 CPU 让出来,充分的做其他事情

synchronized“自适应”

  • 轻量级锁就是基于自旋的方式实现的(JVM 内部,用户态代码实现)
  • 重量级锁就是基于挂起等待的方式实现的(调用操作系统 API,在内核中实现)
    纯用户态代码往往执行效率比内核态代码的高一些,总体来说,我们还是认为“自旋”的效率更高的,但是 CPU 开销更大
    挂起等待锁的操作虽然 CPU 开销变少了,但整体的等待时间更多

公平锁和非公平锁

日常生活中,说的公平可能有不同的含义


image.png|521
当女神分手了,该轮到谁上位呢?

公平锁: 在计算机中,约定“先来后到”为公平
image.png|556


非公平锁: 系统原生
image.png|365


synchronized 属于非公平锁

  • N 个线程竞争同一个锁,其中一个线程拿到锁了,后续该线程释放锁之后,剩下的 N-1 个线程,就要重新竞争锁,谁能拿到锁,就不一定了
  • 当然,也不能保证这些线程竞争中获取的概率一定是数学上的严格均等
    本身操作系统内核里针对锁的处理就是如此,synchronized 在系统内核的基础上,没有做啥额外的操作

如需要使用公平锁,就需要做额外的工作

  • 比如引入队列,记录每个线程加锁的顺序

可重入锁和不可重入锁

死锁问题:如果一个线程,针对同一把锁,连续加锁两次,就可能出现死锁,如果把锁设为“可重入”就可以避免死锁了

可重入:是专门的计算机术语,不要写作“可重复”这样的词

可重入锁

  • 会记录当前是哪个线程持有了这把锁
  • 在加锁的时候判定,当前申请锁的线程,是否就是锁的持有者
  • 计数器,记录加锁的次数,从而确定何时真正释放锁
    • 遇到一个 { 加一次锁,计数器加一
    • 遇到一个 } 解锁一次,计数器减一
    • 等到计数器为零,真正释放锁

读写锁

synchronized 并非是读写锁
所谓的读写锁,把“加锁操作”分为两种情况

  • 读加锁
  • 写加锁
    如果多个线程同时读这个变量,没有线程安全问题,但是
  • 一个线程读/一个线程写
  • 两个线程都写
    就会产生问题

在实际开发中,在大部分场景下,读操作的频次,本身就比写操作的频次高。所以就让读操作不产生锁冲突,这样就只有少数写操作会产生冲突,这样效率就高了


读写锁提供了两种加锁的 API,系统内置的锁,Java 标准库中的读写锁类为:ReentrantReadWriteLock

  • 加读锁
    • ReentrantReadWriteLock 的内部类 ReentrantReadWriteLock.ReadLock 表示加读锁,这个对象提供了 lock/unlock ⽅法进⾏加锁解锁
  • 加写锁
    • ReentrantReadWriteLock 的内部类 ReentrantReadWriteLock.WriteLock 表示加写锁,这个对象也提供了lock/unlock ⽅法进⾏加锁解锁
      解锁的 API 是一样的,就需要把 unlock 放到 finally 中,确保能够执行到
  • 如果两个线程都是按照读方式加锁,此时不会产生锁冲突;
  • 如果两个线程都是家写锁,此时会产生锁冲突
  • 如果一个线程读锁,一个线程写锁,也会产生冲突

相关面试题

image.png


image.png


image.png


image.png

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/繁依Fanyi0/article/detail/1012871
推荐阅读
相关标签
  

闽ICP备14008679号