共计 4693 个字符，预计需要花费 12 分钟才能阅读完成。
前言
生存中用到的锁，用处都比较简单粗犷，上锁根本是为了避免外人进来、电动车被偷等等。
但生存中也不是没有 BUG 的，比方加锁的电动车在「广西 – 窃·格瓦拉」背后，锁就是形同虚设，只有他违心，他就能够轻轻松松地把你电动车给「顺走」，不然打工怎么会是他这辈子不可能的事件呢？牛逼之人，必有牛逼之处。
那在编程世界里，「锁」更是形形色色，多种多样，每种锁的加锁开销以及利用场景也可能会不同。
如何用好锁，也是程序员的根本素养之一了。
高并发的场景下，如果选对了适合的锁，则会大大提高零碎的性能，否则性能会升高。
所以，晓得各种锁的开销，以及利用场景是很有必要的。
接下来，就谈一谈常见的这几种锁：
注释
多线程访问共享资源的时候，防止不了资源竞争而导致数据错乱的问题，所以咱们通常为了解决这一问题，都会在访问共享资源之前加锁。
最罕用的就是互斥锁，当然还有很多种不同的锁，比方自旋锁、读写锁、乐观锁等，不同品种的锁天然实用于不同的场景。
如果抉择了谬误的锁，那么在一些高并发的场景下，可能会升高零碎的性能，这样用户体验就会十分差了。
所以，为了抉择适合的锁，咱们不仅须要分明晓得加锁的老本开销有多大，还须要剖析业务场景中拜访的共享资源的形式，再来还要思考并发访问共享资源时的抵触概率。
隔靴搔痒，能力缩小锁对高并发性能的影响。
那接下来，针对不同的利用场景，谈一谈「互斥锁、自旋锁、读写锁、乐观锁、乐观锁」的抉择和应用。
互斥锁与自旋锁：谁更轻松自如？
最底层的两种就是会「互斥锁和自旋锁」，有很多高级的锁都是基于它们实现的，你能够认为它们是各种锁的地基，所以咱们必须分明它俩之间的区别和利用。
加锁的目标就是保障共享资源在任意工夫里，只有一个线程拜访，这样就能够防止多线程导致共享数据错乱的问题。
当曾经有一个线程加锁后，其余线程加锁则就会失败，互斥锁和自旋锁对于加锁失败后的解决形式是不一样的：
- 互斥锁 加锁失败后，线程会 开释 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 也是用了乐观锁的思维，先让用户编辑代码，而后提交的时候，通过版本号来判断是否产生了抵触，产生了抵触的中央，须要咱们本人批改后，再从新提交。
乐观锁尽管去除了加锁解锁的操作，然而一旦发生冲突，重试的老本十分高，所以 只有在抵触概率非常低，且加锁老本十分高的场景时，才思考应用乐观锁。
总结
开发过程中，最常见的就是互斥锁的了，互斥锁加锁失败时，会用「线程切换」来应答，当加锁失败的线程再次加锁胜利后的这一过程，会有两次线程上下文切换的老本，性能损耗比拟大。
如果咱们明确晓得被锁住的代码的执行工夫很短，那咱们应该抉择开销比拟小的自旋锁，因为自旋锁加锁失败时，并不会被动产生线程切换，而是始终忙期待，直到获取到锁，那么如果被锁住的代码执行工夫很短，那这个忙期待的工夫绝对应也很短。
如果能辨别读操作和写操作的场景，那读写锁就更适合了，它容许多个读线程能够同时持有读锁，进步了读的并发性。依据偏袒读方还是写方，能够分为读优先锁和写优先锁，读优先锁并发性很强，然而写线程会被饿死，而写优先锁会优先服务写线程，读线程也可能会被饿死，那为了防止饥饿的问题，于是就有了偏心读写锁，它是用队列把申请锁的线程排队，并保障先入先出的准则来对线程加锁，这样便保障了某种线程不会被饿死，通用性也更好点。
互斥锁和自旋锁都是最根本的锁，读写锁能够依据场景来抉择这两种锁其中的一个进行实现。
另外，互斥锁、自旋锁、读写锁都属于乐观锁，乐观锁认为并发访问共享资源时，抵触概率可能十分高，所以在访问共享资源前，都须要先加锁。
相同的，如果并发访问共享资源时，抵触概率非常低的话，就能够应用乐观锁，它的工作形式是，在访问共享资源时，不必先加锁，批改完共享资源后，再验证这段时间内有没有发生冲突，如果没有其余线程在批改资源，那么操作实现，如果发现有其余线程曾经批改过这个资源，就放弃本次操作。
然而，一旦抵触概率回升，就不适宜应用乐观锁了，因为它解决抵触的重试老本十分高。
不论应用的哪种锁，咱们的加锁的代码范畴应该尽可能的小，也就是加锁的粒度要小，这样执行速度会比拟快。再来，应用上了适合的锁，就会快上放慢了。