面试官：你说说互斥锁、自旋锁、读写锁、悲观锁、乐观锁的应用场景？

前言

生活中用到的锁&＃xff0c;用途都比较简单粗暴&＃xff0c;上锁基本是为了防止外人进来、电动车被偷等等。

但生活中也不是没有 BUG 的&＃xff0c;比如加锁的电动车在「广西 - 窃·格瓦拉」面前&＃xff0c;锁就是形同虚设&＃xff0c;只要他愿意&＃xff0c;他就可以轻轻松松地把你电动车给「顺走」&＃xff0c;不然打工怎么会是他这辈子不可能的事情呢&＃xff1f;牛逼之人&＃xff0c;必有牛逼之处。

那在编程世界里&＃xff0c;「锁」更是五花八门&＃xff0c;多种多样&＃xff0c;每种锁的加锁开销以及应用场景也可能会不同。

如何用好锁&＃xff0c;也是程序员的基本素养之一了。

高并发的场景下&＃xff0c;如果选对了合适的锁&＃xff0c;则会大大提高系统的性能&＃xff0c;否则性能会降低。

所以&＃xff0c;知道各种锁的开销&＃xff0c;以及应用场景是很有必要的。

接下来&＃xff0c;就谈一谈常见的这几种锁&＃xff1a;

正文

多线程访问共享资源的时候&＃xff0c;避免不了资源竞争而导致数据错乱的问题&＃xff0c;所以我们通常为了解决这一问题&＃xff0c;都会在访问共享资源之前加锁。

最常用的就是互斥锁&＃xff0c;当然还有很多种不同的锁&＃xff0c;比如自旋锁、读写锁、乐观锁等&＃xff0c;不同种类的锁自然适用于不同的场景。

如果选择了错误的锁&＃xff0c;那么在一些高并发的场景下&＃xff0c;可能会降低系统的性能&＃xff0c;这样用户体验就会非常差了。

所以&＃xff0c;为了选择合适的锁&＃xff0c;我们不仅需要清楚知道加锁的成本开销有多大&＃xff0c;还需要分析业务场景中访问的共享资源的方式&＃xff0c;再来还要考虑并发访问共享资源时的冲突概率。

对症下药&＃xff0c;才能减少锁对高并发性能的影响。

那接下来&＃xff0c;针对不同的应用场景&＃xff0c;谈一谈「互斥锁、自旋锁、读写锁、乐观锁、悲观锁」的选择和使用。

互斥锁与自旋锁&＃xff1a;谁更轻松自如&＃xff1f;

最底层的两种就是会「互斥锁和自旋锁」&＃xff0c;有很多高级的锁都是基于它们实现的&＃xff0c;你可以认为它们是各种锁的地基&＃xff0c;所以我们必须清楚它俩之间的区别和应用。

加锁的目的就是保证共享资源在任意时间里&＃xff0c;只有一个线程访问&＃xff0c;这样就可以避免多线程导致共享数据错乱的问题。

当已经有一个线程加锁后&＃xff0c;其他线程加锁则就会失败&＃xff0c;互斥锁和自旋锁对于加锁失败后的处理方式是不一样的&＃xff1a;

• 互斥锁加锁失败后&＃xff0c;线程会释放 CPU &＃xff0c;给其他线程&＃xff1b;

• 自旋锁加锁失败后&＃xff0c;线程会忙等待&＃xff0c;直到它拿到锁&＃xff1b;

互斥锁是一种「独占锁」&＃xff0c;比如当线程 A 加锁成功后&＃xff0c;此时互斥锁已经被线程 A 独占了&＃xff0c;只要线程 A 没有释放手中的锁&＃xff0c;线程 B 加锁就会失败&＃xff0c;于是就会释放 CPU 让给其他线程&＃xff0c;既然线程 B 释放掉了 CPU&＃xff0c;自然线程 B 加锁的代码就会被阻塞。

对于互斥锁加锁失败而阻塞的现象&＃xff0c;是由操作系统内核实现的。当加锁失败时&＃xff0c;内核会将线程置为「睡眠」状态&＃xff0c;等到锁被释放后&＃xff0c;内核会在合适的时机唤醒线程&＃xff0c;当这个线程成功获取到锁后&＃xff0c;于是就可以继续执行。如下图&＃xff1a;

所以&＃xff0c;互斥锁加锁失败时&＃xff0c;会从用户态陷入到内核态&＃xff0c;让内核帮我们切换线程&＃xff0c;虽然简化了使用锁的难度&＃xff0c;但是存在一定的性能开销成本。

那这个开销成本是什么呢&＃xff1f;会有两次线程上下文切换的成本&＃xff1a;

• 当线程加锁失败时&＃xff0c;内核会把线程的状态从「运行」状态设置为「睡眠」状态&＃xff0c;然后把 CPU 切换给其他线程运行&＃xff1b;

• 接着&＃xff0c;当锁被释放时&＃xff0c;之前「睡眠」状态的线程会变为「就绪」状态&＃xff0c;然后内核会在合适的时间&＃xff0c;把 CPU 切换给该线程运行。

线程的上下文切换的是什么&＃xff1f;当两个线程是属于同一个进程&＃xff0c;因为虚拟内存是共享的&＃xff0c;所以在切换时&＃xff0c;虚拟内存这些资源就保持不动&＃xff0c;只需要切换线程的私有数据、寄存器等不共享的数据。

上下切换的耗时有大佬统计过&＃xff0c;大概在几十纳秒到几微秒之间&＃xff0c;如果你锁住的代码执行时间比较短&＃xff0c;那可能上下文切换的时间都比你锁住的代码执行时间还要长。

所以&＃xff0c;如果你能确定被锁住的代码执行时间很短&＃xff0c;就不应该用互斥锁&＃xff0c;而应该选用自旋锁&＃xff0c;否则使用互斥锁。

自旋锁是通过 CPU 提供的 CAS 函数&＃xff08;Compare And Swap&＃xff09;&＃xff0c;在「用户态」完成加锁和解锁操作&＃xff0c;不会主动产生线程上下文切换&＃xff0c;所以相比互斥锁来说&＃xff0c;会快一些&＃xff0c;开销也小一些。

一般加锁的过程&＃xff0c;包含两个步骤&＃xff1a;

• 第一步&＃xff0c;查看锁的状态&＃xff0c;如果锁是空闲的&＃xff0c;则执行第二步&＃xff1b;

• 第二步&＃xff0c;将锁设置为当前线程持有&＃xff1b;

CAS 函数就把这两个步骤合并成一条硬件级指令&＃xff0c;形成原子指令&＃xff0c;这样就保证了这两个步骤是不可分割的&＃xff0c;要么一次性执行完两个步骤&＃xff0c;要么两个步骤都不执行。

使用自旋锁的时候&＃xff0c;当发生多线程竞争锁的情况&＃xff0c;加锁失败的线程会「忙等待」&＃xff0c;直到它拿到锁。这里的「忙等待」可以用 while 循环等待实现&＃xff0c;不过最好是使用 CPU 提供的 PAUSE 指令来实现「忙等待」&＃xff0c;因为可以减少循环等待时的耗电量。

自旋锁是最比较简单的一种锁&＃xff0c;一直自旋&＃xff0c;利用 CPU 周期&＃xff0c;直到锁可用。需要注意&＃xff0c;在单核 CPU 上&＃xff0c;需要抢占式的调度器&＃xff08;即不断通过时钟中断一个线程&＃xff0c;运行其他线程&＃xff09;。否则&＃xff0c;自旋锁在单 CPU 上无法使用&＃xff0c;因为一个自旋的线程永远不会放弃 CPU。

自旋锁开销少&＃xff0c;在多核系统下一般不会主动产生线程切换&＃xff0c;适合异步、协程等在用户态切换请求的编程方式&＃xff0c;但如果被锁住的代码执行时间过长&＃xff0c;自旋的线程会长时间占用 CPU 资源&＃xff0c;所以自旋的时间和被锁住的代码执行的时间是成「正比」的关系&＃xff0c;我们需要清楚的知道这一点。

自旋锁与互斥锁使用层面比较相似&＃xff0c;但实现层面上完全不同&＃xff1a;当加锁失败时&＃xff0c;互斥锁用「线程切换」来应对&＃xff0c;自旋锁则用「忙等待」来应对。

它俩是锁的最基本处理方式&＃xff0c;更高级的锁都会选择其中一个来实现&＃xff0c;比如读写锁既可以选择互斥锁实现&＃xff0c;也可以基于自旋锁实现。

读写锁&＃xff1a;读和写还有优先级区分&＃xff1f;

读写锁从字面意思我们也可以知道&＃xff0c;它由「读锁」和「写锁」两部分构成&＃xff0c;如果只读取共享资源用「读锁」加锁&＃xff0c;如果要修改共享资源则用「写锁」加锁。

所以&＃xff0c;读写锁适用于能明确区分读操作和写操作的场景。

读写锁的工作原理是&＃xff1a;

• 当「写锁」没有被线程持有时&＃xff0c;多个线程能够并发地持有读锁&＃xff0c;这大大提高了共享资源的访问效率&＃xff0c;因为「读锁」是用于读取共享资源的场景&＃xff0c;所以多个线程同时持有读锁也不会破坏共享资源的数据。

• 但是&＃xff0c;一旦「写锁」被线程持有后&＃xff0c;读线程的获取读锁的操作会被阻塞&＃xff0c;而且其他写线程的获取写锁的操作也会被阻塞。

所以说&＃xff0c;写锁是独占锁&＃xff0c;因为任何时刻只能有一个线程持有写锁&＃xff0c;类似互斥锁和自旋锁&＃xff0c;而读锁是共享锁&＃xff0c;因为读锁可以被多个线程同时持有。

知道了读写锁的工作原理后&＃xff0c;我们可以发现&＃xff0c;读写锁在读多写少的场景&＃xff0c;能发挥出优势。

另外&＃xff0c;根据实现的不同&＃xff0c;读写锁可以分为「读优先锁」和「写优先锁」。

读优先锁期望的是&＃xff0c;读锁能被更多的线程持有&＃xff0c;以便提高读线程的并发性&＃xff0c;它的工作方式是&＃xff1a;当读线程 A 先持有了读锁&＃xff0c;写线程 B 在获取写锁的时候&＃xff0c;会被阻塞&＃xff0c;并且在阻塞过程中&＃xff0c;后续来的读线程 C 仍然可以成功获取读锁&＃xff0c;最后直到读线程 A 和 C 释放读锁后&＃xff0c;写线程 B 才可以成功获取读锁。如下图&＃xff1a;

而写优先锁是优先服务写线程&＃xff0c;其工作方式是&＃xff1a;当读线程 A 先持有了读锁&＃xff0c;写线程 B 在获取写锁的时候&＃xff0c;会被阻塞&＃xff0c;并且在阻塞过程中&＃xff0c;后续来的读线程 C 获取读锁时会失败&＃xff0c;于是读线程 C 将被阻塞在获取读锁的操作&＃xff0c;这样只要读线程 A 释放读锁后&＃xff0c;写线程 B 就可以成功获取读锁。如下图&＃xff1a;

读优先锁对于读线程并发性更好&＃xff0c;但也不是没有问题。我们试想一下&＃xff0c;如果一直有读线程获取读锁&＃xff0c;那么写线程将永远获取不到写锁&＃xff0c;这就造成了写线程「饥饿」的现象。

写优先锁可以保证写线程不会饿死&＃xff0c;但是如果一直有写线程获取写锁&＃xff0c;读线程也会被「饿死」。

既然不管优先读锁还是写锁&＃xff0c;对方可能会出现饿死问题&＃xff0c;那么我们就不偏袒任何一方&＃xff0c;搞个「公平读写锁」。

公平读写锁比较简单的一种方式是&＃xff1a;用队列把获取锁的线程排队&＃xff0c;不管是写线程还是读线程都按照先进先出的原则加锁即可&＃xff0c;这样读线程仍然可以并发&＃xff0c;也不会出现「饥饿」的现象。

互斥锁和自旋锁都是最基本的锁&＃xff0c;读写锁可以根据场景来选择这两种锁其中的一个进行实现。

乐观锁与悲观锁&＃xff1a;做事的心态有何不同&＃xff1f;

前面提到的互斥锁、自旋锁、读写锁&＃xff0c;都是属于悲观锁。

悲观锁做事比较悲观&＃xff0c;它认为多线程同时修改共享资源的概率比较高&＃xff0c;于是很容易出现冲突&＃xff0c;所以访问共享资源前&＃xff0c;先要上锁。

那相反的&＃xff0c;如果多线程同时修改共享资源的概率比较低&＃xff0c;就可以采用乐观锁。

乐观锁做事比较乐观&＃xff0c;它假定冲突的概率很低&＃xff0c;它的工作方式是&＃xff1a;先修改完共享资源&＃xff0c;再验证这段时间内有没有发生冲突&＃xff0c;如果没有其他线程在修改资源&＃xff0c;那么操作完成&＃xff0c;如果发现有其他线程已经修改过这个资源&＃xff0c;就放弃本次操作。

放弃后如何重试&＃xff0c;这跟业务场景息息相关&＃xff0c;虽然重试的成本很高&＃xff0c;但是冲突的概率足够低的话&＃xff0c;还是可以接受的。

可见&＃xff0c;乐观锁的心态是&＃xff0c;不管三七二十一&＃xff0c;先改了资源再说。另外&＃xff0c;你会发现乐观锁全程并没有加锁&＃xff0c;所以它也叫无锁编程。

这里举一个场景例子&＃xff1a;在线文档。

我们都知道在线文档可以同时多人编辑的&＃xff0c;如果使用了悲观锁&＃xff0c;那么只要有一个用户正在编辑文档&＃xff0c;此时其他用户就无法打开相同的文档了&＃xff0c;这用户体验当然不好了。

那实现多人同时编辑&＃xff0c;实际上是用了乐观锁&＃xff0c;它允许多个用户打开同一个文档进行编辑&＃xff0c;编辑完提交之后才验证修改的内容是否有冲突。

怎么样才算发生冲突&＃xff1f;这里举个例子&＃xff0c;比如用户 A 先在浏览器编辑文档&＃xff0c;之后用户 B 在浏览器也打开了相同的文档进行编辑&＃xff0c;但是用户 B 比用户 A 提交改动&＃xff0c;这一过程用户 A 是不知道的&＃xff0c;当 A 提交修改完的内容时&＃xff0c;那么 A 和 B 之间并行修改的地方就会发生冲突。

服务端要怎么验证是否冲突了呢&＃xff1f;通常方案如下&＃xff1a;

• 由于发生冲突的概率比较低&＃xff0c;所以先让用户编辑文档&＃xff0c;但是浏览器在下载文档时会记录下服务端返回的文档版本号&＃xff1b;

• 当用户提交修改时&＃xff0c;发给服务端的请求会带上原始文档版本号&＃xff0c;服务器收到后将它与当前版本号进行比较&＃xff0c;如果版本号一致则修改成功&＃xff0c;否则提交失败。

实际上&＃xff0c;我们常见的 SVN 和 Git 也是用了乐观锁的思想&＃xff0c;先让用户编辑代码&＃xff0c;然后提交的时候&＃xff0c;通过版本号来判断是否产生了冲突&＃xff0c;发生了冲突的地方&＃xff0c;需要我们自己修改后&＃xff0c;再重新提交。

乐观锁虽然去除了加锁解锁的操作&＃xff0c;但是一旦发生冲突&＃xff0c;重试的成本非常高&＃xff0c;所以只有在冲突概率非常低&＃xff0c;且加锁成本非常高的场景时&＃xff0c;才考虑使用乐观锁。

总结

开发过程中&＃xff0c;最常见的就是互斥锁的了&＃xff0c;互斥锁加锁失败时&＃xff0c;会用「线程切换」来应对&＃xff0c;当加锁失败的线程再次加锁成功后的这一过程&＃xff0c;会有两次线程上下文切换的成本&＃xff0c;性能损耗比较大。

如果我们明确知道被锁住的代码的执行时间很短&＃xff0c;那我们应该选择开销比较小的自旋锁&＃xff0c;因为自旋锁加锁失败时&＃xff0c;并不会主动产生线程切换&＃xff0c;而是一直忙等待&＃xff0c;直到获取到锁&＃xff0c;那么如果被锁住的代码执行时间很短&＃xff0c;那这个忙等待的时间相对应也很短。

如果能区分读操作和写操作的场景&＃xff0c;那读写锁就更合适了&＃xff0c;它允许多个读线程可以同时持有读锁&＃xff0c;提高了读的并发性。根据偏袒读方还是写方&＃xff0c;可以分为读优先锁和写优先锁&＃xff0c;读优先锁并发性很强&＃xff0c;但是写线程会被饿死&＃xff0c;而写优先锁会优先服务写线程&＃xff0c;读线程也可能会被饿死&＃xff0c;那为了避免饥饿的问题&＃xff0c;于是就有了公平读写锁&＃xff0c;它是用队列把请求锁的线程排队&＃xff0c;并保证先入先出的原则来对线程加锁&＃xff0c;这样便保证了某种线程不会被饿死&＃xff0c;通用性也更好点。

互斥锁和自旋锁都是最基本的锁&＃xff0c;读写锁可以根据场景来选择这两种锁其中的一个进行实现。

另外&＃xff0c;互斥锁、自旋锁、读写锁都属于悲观锁&＃xff0c;悲观锁认为并发访问共享资源时&＃xff0c;冲突概率可能非常高&＃xff0c;所以在访问共享资源前&＃xff0c;都需要先加锁。

相反的&＃xff0c;如果并发访问共享资源时&＃xff0c;冲突概率非常低的话&＃xff0c;就可以使用乐观锁&＃xff0c;它的工作方式是&＃xff0c;在访问共享资源时&＃xff0c;不用先加锁&＃xff0c;修改完共享资源后&＃xff0c;再验证这段时间内有没有发生冲突&＃xff0c;如果没有其他线程在修改资源&＃xff0c;那么操作完成&＃xff0c;如果发现有其他线程已经修改过这个资源&＃xff0c;就放弃本次操作。

但是&＃xff0c;一旦冲突概率上升&＃xff0c;就不适合使用乐观锁了&＃xff0c;因为它解决冲突的重试成本非常高。

不管使用的哪种锁&＃xff0c;我们的加锁的代码范围应该尽可能的小&＃xff0c;也就是加锁的粒度要小&＃xff0c;这样执行速度会比较快。再来&＃xff0c;使用上了合适的锁&＃xff0c;就会快上加快了。


往期推荐


双“11”搞促销&＃xff1f;用贪心算法来盘他&＃xff01;

25 张图&＃xff0c;1.4 w字&＃xff01;彻底搞懂分布式事务原理

嗯&＃xff0c;查询滑动窗口最大值的这4种方法不错....

关注我&＃xff0c;每天陪你进步一点点&＃xff01;