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

admin管理员组

文章数量:1794759

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

乐观锁和悲观锁

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

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

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

使用 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

本文参与 腾讯云自媒体同步曝光计划，分享自作者个人站点/博客。 原始发表：2024-08-11，如有侵权请联系 cloudcommunity@tencent 删除前往查看内核线程效率多线程工作

本文标签： 多线程乐观悲观锁重量级轻量级锁挂起等待自旋锁公平非公锁可重入不可重入锁读写锁