Java锁机制——互斥锁,自旋锁,读写锁,悲观锁和乐观锁

2021/8/15 22:05:52

本文主要是介绍Java锁机制——互斥锁,自旋锁,读写锁,悲观锁和乐观锁,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

以下文章源于小林coding
在这里插入图片描述

1.概述

在多线程并发的场景下,不可以避免的一个问题就是共享资源的竞争问题,那么最熟悉、常见的方法就是在访问共享资源之前加锁。
最常用的就是互斥锁,当然还有很多种不同的锁,比如自旋锁、读写锁、乐观锁等,不同种类的锁自然适用于不同的场景。

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

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

互斥锁与自旋锁

最底层的两种就是会**「互斥锁和自旋锁」**,有很多高级的锁都是基于它们实现的,你可以认为它们是各种锁的地基,所以我们必须清楚它俩之间的区别和应用。
加锁的目的就是在任意的时间段里只有一个线程可以访问共享资源,这样就可以并发情况下出现的数据错乱问题
当已经有一个线程加锁后,其他线程加锁则就会失败,互斥锁和自旋锁对于加锁失败后的处理方式是不一样的:

  • 互斥锁加锁失败之后,线程会释放CPU给其他线程,然后阻塞
  • 自旋锁加锁失败之后,线程会忙等待(自旋),直到它拿到锁

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

互斥锁加锁失败阻塞线程是由操作系统内核控制的,当加锁失败时,内核会调用阻塞原语将线程置为「睡眠」状态,等到锁被释放后,内核会在合适的时机调用唤醒原语唤醒线程,当这个线程成功获取到锁后,于是就可以继续执行。如下图:
在这里插入图片描述
所以,互斥锁加锁失败时,会从用户态陷入到内核态,让内核帮我们切换线程,虽然简化了使用锁的难度,但是存在一定的性能开销成本。

这个开销成本是什么呢?——系统会存在两次线程上下文切换

  • 当线程加锁失败,操作系统将线程由运行态转换成阻塞态,并释放CPU给其他线程运行
  • 当锁被释放之后,之前阻塞态的线程会变成就绪状态,然后操作系统内核会在合适的时候分配CPU给线程运行

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

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

所以如果你能确定你要锁住的代码块执行时间很短,就应该使用自旋锁,否则使用互斥锁

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

使用自旋锁的时候,会有两个步骤:

  • 第一步:检查锁的状态,如果锁是空闲的,执行第二步
  • 第二步:将锁设置为当前线程持有

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

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

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

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

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

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

读写锁——读和写还有优先级之分??

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

所以读写锁适用于读操作和写操作明确区分的场景。

读写锁的工作原理是:

  • 当写锁没有被持有时,多个线程可以并发的持有读锁,这大大提高了共享资源的访问效率,因为读锁只是读取共享资源,所以多个线程持有读锁也不会破坏共享资源的数据
  • 当写锁被线程持有时,读线程获取读锁的操作会被阻塞,而且其他线程获取写锁的操作也会被阻塞

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

知道了读写锁的工作原理我们可以推断——在读多写少的业务场景中,读写锁有着很大的优势

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

读优先锁期望的是,读锁能被更多的线程持有,以便提高读线程的并发性,它的工作方式是:当读线程 A 先持有了读锁,写线程 B 在获取写锁的时候,会被阻塞,并且在阻塞过程中,后续来的读线程 C 仍然可以成功获取读锁,最后直到读线程 A 和 C 释放读锁后,写线程 B 才可以成功获取读锁。如下图:在这里插入图片描述
写优先锁是优先服务写线程,其工作方式是:当读线程 A 先持有了读锁,写线程 B 在获取写锁的时候,会被阻塞,并且在阻塞过程中,后续来的读线程 C 获取读锁时会失败,于是读线程 C 将被阻塞在获取读锁的操作,这样只要读线程 A 释放读锁后,写线程 B 就可以成功获取读锁。如下图:
在这里插入图片描述
读优先锁对于读线程并发性更好,但也不是没有问题。我们试想一下,如果一直有读线程获取读锁,那么写线程将永远获取不到写锁,这就造成了写线程「饥饿」的现象。

写优先锁可以避免写线程的饥饿现象,但是如果一直有写线程获取写锁,那么读线程也会被饿死。

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

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

互斥锁和自旋锁都是最基本的锁实现方式,而读写锁可以根据业务场景来选择其中一个进行实现。

乐观锁和悲观锁——做事的心态有何不同?

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

悲观锁做事比较悲观——它认为多线程同时修改共享资源的概率比较高,所以很容易发送冲突,所以线程访问共享资源之前,一定要先上锁。

而乐观锁做事就比较乐观,它假设发生冲突的概率较低——它的工作方式是先修改完共享资源,再验证这段时间有没有发送冲突,如果没有别的线程修改资源,那么操作完成;如果有其他线程修改资源,就放弃这次的修改操作

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

可以发现乐观锁的工作方式是不管会不会有冲突,先修改共享资源再说。而且乐观锁虽然带一个锁字,但是并没有涉及到加锁,所以乐观锁其实也叫做无锁编程

举一个例子——在线编辑文档

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

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

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

那么服务器怎么验证是否发生了冲突呢?

  • 由于发送冲突的概率较低,所以先让用户编辑文档,但是浏览器在下载文档的时候会记录下服务器返回的文档版本号
  • 当用户提交修改的时候,发给服务器的请求会带上对应的文档版本号,服务器收到后将它和当前文档的版本号比较,如果版本号一致就修改成功,否则修改失败。

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

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

总结

开发过程中,最常见的就是互斥锁了,互斥锁加锁失败时,会使用线程切换将线程从运行态转换成阻塞态,当锁被释放后操作系统再唤醒线程获取锁,分配CPU运行。所以会有两次线程的上下文切换,性能损耗比较大

那如果我们明确知道要锁住的代码块运行时间比较短,那么我们就应该使用自旋锁来替换互斥锁,因为当自旋锁加锁失败时,会使用忙等待来应对,而不是线程切换。这样系统的开销就会比较小,而且如果锁住的代码块执行时间短,自旋的次数也会很少。

如果遇到读操作和写操作明确区分的业务场景,那么读写锁就有很大的优势了,它允许多个线程并发持有读锁,提高了读操作的并发性。根据偏袒的是读操作还是写操作,可以区分为读优先锁和写优先锁,读优先锁并发性强,但是写线程容易饿死,写优先锁会优先服务写线程,那么读线程也容易饿死。所以为了避免这种问题,就有了公平读写锁,使用队列把请求锁的线程排队,按照先进先出(FIFO)的原则对线程加锁,避免了饥饿现象,通用性也更好。

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

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

相反的,如果访问共享资源时发生冲突的可能性较低,我们可以使用乐观锁,它的工作方式是,在访问共享资源时不用先加锁,而是在修改完成之后再验证这段时间内有没有发生冲突,如果没有则操作完成,如果发生冲突就放弃本次操作。

但是如果冲突概率升高,乐观锁就不适用了,因为它重试的成本很高

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



这篇关于Java锁机制——互斥锁,自旋锁,读写锁,悲观锁和乐观锁的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!


扫一扫关注最新编程教程