杭州学网站建设,建卖手机网站,最新新闻热点事件看法,站酷魔方网站建设中多线程访问共享资源的时候#xff0c;避免不了资源竞争而导致数据错乱的问题#xff0c;所以我们通常为了解决这一问题#xff0c;都会在访问共享资源之前加锁。
最常用的就是互斥锁#xff0c;当然还有很多种不同的锁#xff0c;比如自旋锁、读写锁、乐观锁等#xff0…多线程访问共享资源的时候避免不了资源竞争而导致数据错乱的问题所以我们通常为了解决这一问题都会在访问共享资源之前加锁。
最常用的就是互斥锁当然还有很多种不同的锁比如自旋锁、读写锁、乐观锁等不同种类的锁自然适用于不同的场景。
如果选择了错误的锁那么在一些高并发的场景下可能会降低系统的性能这样用户体验就会非常差了。
所以为了选择合适的锁我们不仅需要清楚知道加锁的成本开销有多大还需要分析业务场景中访问的共享资源的方式再来还要考虑并发访问共享资源时的冲突概率。
对症下药才能减少锁对高并发性能的影响。
那接下来针对不同的应用场景谈一谈「互斥锁、自旋锁、读写锁、乐观锁、悲观锁」的选择和使用。
互斥锁与自旋锁谁更轻松自如
最底层的两种就是会「互斥锁和自旋锁」有很多高级的锁都是基于它们实现的你可以认为它们是各种锁的地基所以我们必须清楚它俩之间的区别和应用。
加锁的目的就是保证共享资源在任意时间里只有一个线程访问这样就可以避免多线程导致共享数据错乱的问题。
当已经有一个线程加锁后其他线程加锁则就会失败互斥锁和自旋锁对于加锁失败后的处理方式是不一样的
互斥锁加锁失败后线程会释放 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 就可以成功获取写锁。如下图 读优先锁对于读线程并发性更好但也不是没有问题。
我们试想一下如果一直有读线程获取读锁那么写线程将永远获取不到写锁这就造成了写线程「饥饿」的现象。
写优先锁可以保证写线程不会饿死但是如果一直有写线程获取写锁读线程也会被「饿死」。
既然不管优先读锁还是写锁对方可能会出现饿死问题那么我们就不偏袒任何一方搞个「公平读写锁」。
公平读写锁比较简单的一种方式是用队列把获取锁的线程排队不管是写线程还是读线程都按照先进先出的原则加锁即可这样读线程仍然可以并发也不会出现「饥饿」的现象。
互斥锁和自旋锁都是最基本的锁读写锁可以根据场景来选择这两种锁其中的一个进行实现。
乐观锁与悲观锁做事的心态有何不同
前面提到的互斥锁、自旋锁、读写锁都是属于悲观锁。
悲观锁做事比较悲观它认为多线程同时修改共享资源的概率比较高于是很容易出现冲突所以访问共享资源前先要上锁。
那相反的如果多线程同时修改共享资源的概率比较低就可以采用乐观锁。
乐观锁做事比较乐观它假定冲突的概率很低它的工作方式是先修改完共享资源再验证这段时间内有没有发生冲突如果没有其他线程在修改资源那么操作完成如果发现有其他线程已经修改过这个资源就放弃本次操作。
放弃后如何重试这跟业务场景息息相关虽然重试的成本很高但是冲突的概率足够低的话还是可以接受的。
可见乐观锁的心态是不管三七二十一先改了资源再说。另外你会发现乐观锁全程并没有加锁所以它也叫无锁编程。
这里举一个场景例子在线文档。
我们都知道在线文档可以同时多人编辑的如果使用了悲观锁那么只要有一个用户正在编辑文档此时其他用户就无法打开相同的文档了这用户体验当然不好了。
那实现多人同时编辑实际上是用了乐观锁它允许多个用户打开同一个文档进行编辑编辑完提交之后才验证修改的内容是否有冲突。
怎么样才算发生冲突这里举个例子比如用户 A 先在浏览器编辑文档之后用户 B 在浏览器也打开了相同的文档进行编辑但是用户 B 比用户 A 提交改动这一过程用户 A 是不知道的当 A 提交修改完的内容时那么 A 和 B 之间并行修改的地方就会发生冲突。
服务端要怎么验证是否冲突了呢通常方案如下
由于发生冲突的概率比较低所以先让用户编辑文档但是浏览器在下载文档时会记录下服务端返回的文档版本号当用户提交修改时发给服务端的请求会带上原始文档版本号服务器收到后将它与当前版本号进行比较如果版本号一致则修改成功否则提交失败。
实际上我们常见的 SVN 和 Git 也是用了乐观锁的思想先让用户编辑代码然后提交的时候通过版本号来判断是否产生了冲突发生了冲突的地方需要我们自己修改后再重新提交。
乐观锁虽然去除了加锁解锁的操作但是一旦发生冲突重试的成本非常高所以只有在冲突概率非常低且加锁成本非常高的场景时才考虑使用乐观锁。
总结
开发过程中最常见的就是互斥锁的了互斥锁加锁失败时会用「线程切换」来应对当加锁失败的线程再次加锁成功后的这一过程会有两次线程上下文切换的成本性能损耗比较大。
如果我们明确知道被锁住的代码的执行时间很短那我们应该选择开销比较小的自旋锁因为自旋锁加锁失败时并不会主动产生线程切换而是一直忙等待直到获取到锁那么如果被锁住的代码执行时间很短那这个忙等待的时间相对应也很短。
如果能区分读操作和写操作的场景那读写锁就更合适了它允许多个读线程可以同时持有读锁提高了读的并发性。根据偏袒读方还是写方可以分为读优先锁和写优先锁读优先锁并发性很强但是写线程会被饿死而写优先锁会优先服务写线程读线程也可能会被饿死那为了避免饥饿的问题于是就有了公平读写锁它是用队列把请求锁的线程排队并保证先入先出的原则来对线程加锁这样便保证了某种线程不会被饿死通用性也更好点。
互斥锁和自旋锁都是最基本的锁读写锁可以根据场景来选择这两种锁其中的一个进行实现。
另外互斥锁、自旋锁、读写锁都属于悲观锁悲观锁认为并发访问共享资源时冲突概率可能非常高所以在访问共享资源前都需要先加锁。
相反的如果并发访问共享资源时冲突概率非常低的话就可以使用乐观锁它的工作方式是在访问共享资源时不用先加锁修改完共享资源后再验证这段时间内有没有发生冲突如果没有其他线程在修改资源那么操作完成如果发现有其他线程已经修改过这个资源就放弃本次操作。
但是一旦冲突概率上升就不适合使用乐观锁了因为它解决冲突的重试成本非常高。
不管使用的哪种锁我们的加锁的代码范围应该尽可能的小也就是加锁的粒度要小这样执行速度会比较快。再来使用上了合适的锁就会快上加快了。
