多线程 互斥锁、自旋锁、读写锁、乐观锁、悲观锁

1，为什么要加锁？

多线程访问共享资源的时候，避免不了资源竞争而导致数据错乱的问题，

所以我们通常为了解决这一问题，都会在访问共享资源之前加锁。

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

2，有哪些锁？

互斥锁、自旋锁、读写锁、乐观锁、悲观锁

3，如何定义这些锁？

3.1 互斥锁、

---

互斥锁加锁失败后，线程会释放 CPU 给其他线程；

比如当线程 A 加锁成功后，此时互斥锁已经被线程 A 独占了，

只要线程 A 没有释放手中的锁，线程 B 加锁就会失败，

于是就会释放 CPU 让给其他线程，线程 B 加锁的代码就会被阻塞。

---

对于互斥锁加锁失败而阻塞的现象，是由操作系统内核实现的。

当加锁失败时，内核会将线程置为「睡眠」状态，等到锁被释放后，

内核会在合适的时机唤醒线程，当这个线程成功获取到锁后，于是就可以继续执行。

那这个开销成本是什么呢？

会有两次线程上下文切换的成本：

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

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

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

当两个线程是属于同一个进程，因为虚拟内存是共享的，

所以在切换时，虚拟内存这些资源就保持不动，只需要切换线程的私有数据、寄存器等不共享的数据。

个人理解：

我要加锁，好啊，锁被别人拿去用了，那行，我先离开cpu去睡一觉，过会管理锁的工作人员叫醒我，

说锁已经可以用了，好嘛，我就去拿锁，然后到cpu中去执行我的任务。

3.2 自旋锁、

CAS 函数：比较并替换，比较两次，两次结果一样，执行替换操作

自旋锁是通过 CPU 提供的 CAS 函数（Compare And Swap），在「用户态」完成加锁和解锁操作

加锁过程具有原子性，要么全执行，要么都不执行

一般加锁的过程，包含两个步骤：

第一步，查看锁的状态，如果锁是空闲的，

第二步，将锁设置为当前线程持有；

个人理解：

我要加锁，好啊，锁被别人拿去用了，那行，我在cpu这等，等锁释放，什么时候释放了锁，我拿到了锁，执行了任务，我就离开cpu

3.3 读写锁、

由「读锁」和「写锁」两部分构成

如果只读取共享资源用「读锁」加锁，读锁是共享锁，因为读锁可以被多个线程同时持有

如果要修改共享资源则用「写锁」加锁，写锁是独占锁，因为任何时刻只能有一个线程持有写锁

读写锁的工作原理是：

当没有写锁的时候，自然就不涉及到共享资源的修改，多个线程能够并发地持有读锁，如此一来，大大提高了共享资源的访问效率

但是，当有写锁参与后，读锁和写锁的操作过程都会被阻塞

「读优先锁」和「写优先锁」

「读优先锁」：

1，线程A获取读锁，

2，线程B获取写锁，（那不行，不让他获取）

3，线程C获取读锁（ok）

4，线程A，C都释放完读锁

5，线程B想，好嘛，读锁都工作完了，这下我可以工作了吧，可以把写锁给我使用了吧，锁管理员点了点头，表示ok

「写优先锁」

1，线程A获取读锁，

2，线程B获取写锁，（那不行，不让他获取，去睡觉）

3，线程C获取读锁（那不行，不让他获取，去睡觉）

4，线程A都释放完读锁

5，内核说，线程B醒醒，A都工作完了，你可以开始拿写锁工作了，
优先读写锁弊端：

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

排队工作，先到先得

3.4 乐观锁、

最好的情况考虑问题，秉承着一种先斩后奏的态度解决问题

管你多线程访问共享资源会不会有冲突，先改了再说，

再验证这段时间内有没有发生冲突，如果没有其他线程在修改资源，那么操作完成，

如果发现有其他线程已经修改过这个资源，就放弃本次操作

3.5 悲观锁

以最坏的情况考虑问题

多线程同时修改共享资源的概率比较高，容易出现冲突，所以访问共享资源前，先要上锁。

例子：在线文档

一份文档，多个用户读写操作

悲观锁做法：

用户A在操作文档，其他用户不能打开文档

乐观锁操作：

所有用户都可以操作文档，编辑完提交文档的时候再验证用户们的操作有没有冲突，没有冲突就修改完成。

验证冲突：

1， 用户从服务端获取文档时，浏览器会获取文档版本号

2，用户修改完毕，提交请求，将版本号和修改内容发送给服务端，

3，服务器收到，比较两个版本号，一致，修改成功，否则失败

4，不同锁的适用哪些场景？

互斥锁「线程切换」

如果你能确定被锁住的代码执行时间很长，线程切换比你锁住的代码执行时间还要短，应该选用互斥锁

自旋锁「忙等待」

如果你能确定被锁住的代码执行时间很短，应该选用自旋锁，自旋锁开销少，适合异步、协程等在用户态切换请求的编程方式

读写锁、

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

乐观锁、

乐观锁虽然去除了加锁解锁的操作，但是一旦发生冲突，重试的成本非常高，

所以只有在冲突概率非常低，且加锁成本非常高的场景时，才考虑使用乐观锁。

悲观锁

多线程同时修改共享资源的概率比较高，于是很容易出现冲突

# 5，总结

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

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

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

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

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

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

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

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