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

锁：非常广义的概念，不是指某个具体的锁，所有的锁都可以往这些策略中套

synchronized：只是市面上五花八门的锁种，其中一种典型的实现，Java 内置的，推荐使用的锁

乐观锁和悲观锁

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

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

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

使用 synchronized，初始情况下，是乐观的（预估接下来锁冲突概率不大）

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

站在预测锁冲突的概率是否高

synchronized 是自适应的

重量级锁和轻量级锁

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

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

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

站在加锁的开销角度

synchronized 也是自适应的

挂起等待锁和自旋锁

挂起等待锁：属于是悲观锁/重量级锁的一种典型实现

自旋锁：乐观锁/轻量级锁的一种典型实现

比如：

你去追你的女神：

女神女神，我好喜欢你，你尝试对女神加锁 女神表示：我有男朋友了 女神表示她这把锁已经被别的线程给加了 你就可以选择“等待”，等到女神锁被释放，比如： 你选择每天仍然会给女神不停地问候“早安，午安.....”，这里的行为称为“自旋锁” - 这里的等待是“忙等”，等待的过程中 CPU 的资源不会释放 - 某天女神和男朋友吵架了，不开心，你就立刻能感知到，机会来了。这样你就可以在女神锁释放的第一时间，立刻抓住机会，能够上位 - 不停地，循环地检测锁是否被释放，一旦锁释放，就能立即有机会能获得锁 你选择把女神拉黑，先不联系了，若干年后你从别人那里听说，女神分手了，你再去联络女神，这种行为就是“挂起等待锁”

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

注意：

• 只有在假定锁冲突概率不高的情况下，才能“忙等”。如果好几个线程都在竞争同一个锁，一个线程拿到锁，其他的都在“忙等”，这样总的 CPU 消耗就会非常高undefined
• 而且，由于竞争太激烈，导致有些线程要等待很久才能拿到锁
• 锁冲突很高的概率很高的话就不适合“自旋锁”方案
• 挂起等待锁也就适合“悲观锁”这样的场景了
• 锁竞争非常激烈，预测拿到锁的概率本身就不打，不放吧 CPU 让出来，充分的做其他事情

synchronized“自适应”

轻量级锁就是基于自旋的方式实现的（JVM 内部，用户态代码实现）

重量级锁就是基于挂起等待的方式实现的（调用操作系统 API，在内核中实现）

纯用户态代码往往执行效率比内核态代码的高一些，总体来说，我们还是认为“自旋”的效率更高的，但是 CPU 开销更大

挂起等待锁的操作虽然 CPU 开销变少了，但整体的等待时间更多

公平锁和非公平锁

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

当女神分手了，该轮到谁上位呢？

公平锁： 在计算机中，约定“先来后到”为公平

非公平锁： 系统原生

synchronized 属于非公平锁

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

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

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

可重入锁和不可重入锁

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

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

可重入锁

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

读写锁

synchronized 并非是读写锁

所谓的读写锁，把“加锁操作”分为两种情况

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

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

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

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

相关面试题