(学习笔记-进程管理)什么是悲观锁、乐观锁?

这篇具有很好参考价值的文章主要介绍了(学习笔记-进程管理)什么是悲观锁、乐观锁?。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

互斥锁与自旋锁

最底层的两种就是 [互斥锁和自旋锁],有很多高级的锁都是基于它们实现的。可以认为它们是各种锁的地基,所以我们必须清楚它们之间的区别和应用。

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

当已经有一个线程加锁后,其他线程加锁就会失败,互斥锁盒自旋锁对于加锁失败后的处理方式是不一样的:

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

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

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

(学习笔记-进程管理)什么是悲观锁、乐观锁?,操作系统,学习,笔记

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

那这个开销成本是什么呢?会有两次线程上下文切换的成本

  • 当线程加锁失败时,内核会把线程的状态从 [运行] 状态设置为 [睡眠] 状态,然后把 CPU切换给其他线程运行;
  • 接着,当锁被释放时,之前 [睡眠] 状态的线程会变为 [就绪] 状态,然后内核会在合适的时间吧CPU切换给该线程运行。

线程的上下文切换是什么?

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

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

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

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

一般加锁的过程,包含两个步骤:

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

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

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

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

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

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

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


读写锁

读写锁从字面意思就是由 [读锁] 和 [写锁] 两部分组成,如果只读取共享资源用 [读锁] 加锁,如果需要修改共享资源则用 [写锁] 加锁。

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

读写锁的工作原理是:

  • 当 [写锁] 没有被线程持有时,多个线程能够并发地持有读锁,这大大提高了共享资源的访问效率,因为 [读锁] 是用于读取共享资源的场景,所以多个线程同时持有读锁也不会破坏共享资源的数据。
  • 但是,一旦 [写锁] 被线程持有后,读线程的获取读锁的操作会被阻塞,而且其他写线程的获取写锁的操作也会被阻塞。

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

读写锁在读多写少的场景能发挥出优势

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

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

(学习笔记-进程管理)什么是悲观锁、乐观锁?,操作系统,学习,笔记

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

(学习笔记-进程管理)什么是悲观锁、乐观锁?,操作系统,学习,笔记

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

写优先锁可以保证写线程不会饿死,但是如果一直有写线程获取写锁,读线程也会被 [饿死]。

公平读写锁:用队列把获取锁的线程排队,不管是写线程还是读线程都按照先进先出的原则加锁即可,这样读线程仍然可以并发,也不会出现 [饿死] 现象。

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


乐观锁和悲观锁

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

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

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

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

虽然重试的成本很高,但是冲突的概率足够低的话,还是可以接受的。

另外,可以发现乐观锁是没有加锁,所以它也叫无锁编程

举一个场景例子:在线文档。

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

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

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

服务端要怎么验证是否冲突了呢?通常方案如下:

  • 由于发生冲突的概率比较低,所以先让用户编辑文档,但是浏览器在下载文档时会记录下服务端返回的文档版本号;
  • 当用户提交修改时,发给服务端的请求会带上原始文档版本号,服务器收到后将它与当前版本号进行比较,如果版本号不一致则提交失败,如果版本号一致则修改成功,然后服务端版本号更新到最新的版本号。

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

乐观锁虽然去除了加锁解锁的操作,但是一旦发生冲突,重试的成本非常高,所以只有在冲突概率非常低,且加锁成本非常高的场景时,才考虑使用乐观锁。文章来源地址https://www.toymoban.com/news/detail-665320.html


到了这里,关于(学习笔记-进程管理)什么是悲观锁、乐观锁?的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • [锁]:乐观锁与悲观锁

    摘要:乐观锁;悲观锁;实现方法;本地锁;分布式锁;死锁;行级锁;表级锁 问题 : ① 在多个线程访问共享资源时,会发生线程安全问题,例如:在根据订单号生成订单时,若用户第一次由于某种原因(网络连接不稳定)请求失败,则会再次发生请求,此时便会产生同一

    2024年02月08日
    浏览(33)
  • 悲观锁和乐观锁、缓存

    悲观锁: 悲观锁的实现通常依赖于数据库提供的机制,在整个处理的过程中数据处于锁定状态,session的load方法有一个重载方法,该重载方法的第三个参数可以设置锁模式,load(object.class , int id,LockMode.?),该方法的?就是具体的锁模式。 乐观锁: 乐观锁使用版本号或者时间戳

    2024年02月09日
    浏览(41)
  • 悲观锁和乐观锁(易懂)

    这里可以把悲观锁看作悲观的人,啥事都往最坏的方向想。乐观锁看作乐观的人,啥事都往最好的方向想。 首先,说一下悲观锁。 悲观锁就是假设并发情况下一定会有其他线程来修改数据,因此在处理数据之前,先将数据锁住,确保其他线程不能进行修改 。感觉像一个过于

    2024年02月08日
    浏览(36)
  • MySQL乐观锁与悲观锁

    遇见并发情况,需要保证数据的准确性,也就是与正确的预期一致,此时就会用到锁。 锁是在并发下控制程序的执行逻辑,以此来保证数据按照预期变动。 如果不加锁,并发情况下的可能数据不一致的情况,这是个概率问题。 乐观锁很乐观,假设数据一般情况不会造成冲突

    2024年01月23日
    浏览(31)
  • [锁]:乐观锁、悲观锁与死锁

    摘要:乐观锁;悲观锁;实现方法;本地锁;分布式锁;死锁;行级锁;表级锁 问题 : ① 在多个线程访问共享资源时,会发生线程安全问题,例如:在根据订单号生成订单时,若用户第一次由于某种原因(网络连接不稳定)请求失败,则会再次发生请求,此时便会产生同一

    2024年02月08日
    浏览(35)
  • redis实战---乐观锁与悲观锁

    最近一直在研究Redis,今天学习到了乐观锁与悲观锁的部分,在这里进行总结。 Redis是一个内存中的键值存储系统,支持多种数据结构,如字符串、哈希、列表等。 Redis提供了两种锁机制,即乐观锁和悲观锁。 乐观锁是一种乐观的并发控制策略,它认为数据在大多数情况下

    2023年04月09日
    浏览(36)
  • mybatis使用乐观锁和悲观锁

    悲观锁和乐观锁的概念: 悲观锁:就是独占锁,不管读写都上锁了。传统的关系型数据库里边就用到了很多这种锁机制,比如行锁,表锁等,读锁,写锁等,都是在做操作之前先上锁。Java中synchronized和ReentrantLock等独占锁就是悲观锁思想的实现。 乐观锁:不上锁,读取的时候

    2024年02月10日
    浏览(33)
  • Java并发(十四)----悲观互斥与乐观重试

    1. 悲观互斥 互斥实际是悲观锁的思想 例如,有下面取款的需求 用互斥来保护 2. 乐观重试 另外一种是乐观锁思想,它其实不是互斥

    2024年02月15日
    浏览(40)
  • Redis:事务操作以及监控(悲观锁,乐观锁)

    事务操作是指:在一组操作中,有很多的命令,如果在这组操作时,有一个命令出现的了bug,那么这组这组操作会进行回滚,将环境还原成没有开始这组操作时的状态。在MySQL等关系型数据库中事务操作可能会出现这种结果,但是在redis则也可能出现其他的错误,那就是语法问

    2024年02月05日
    浏览(37)
  • 【Redis】秒杀业务设计、悲观锁与乐观锁

    一些情境下,使用数据库的ID自增将会产生一些问题。 一方面,自增ID规律性明显,可能被猜测出来并产生一些漏洞 另一方面,当数据量很大很大很大时,单表数据量可能会受到限制,需要分表,多个表之间的ID自增策略受限 测试: Runnable接口是一个函数式接口,即只有一个

    2024年02月13日
    浏览(32)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包