本文属于专栏《构建工业级QPS百万级服务》系列简介-CSDN博客
“锁”，在新华字段的解释是“加在门、箱子、抽屉等物体上的封缄器，要用专用的钥匙才能打开”。在计算机领域，可以抽象为：主体A，在物品W上，附加物品S（锁），让其他主体不能完整地使用。
所以我们在理解一个锁时，不管它是语言层面的如：C++、Java、Python，还是软件层面的如：数据库、内核，还是硬件层面的如：多核CPU。这些都可以抽象为上面这句话，只要理解的谁是主体A，谁是物品W，以及“不完整使用”到达什么程度，就能理解锁的作用。
在计算机领域，锁的实现都是底层硬件支持，是通过缓存一致率协议，而该协议底层逻辑依然是“单写”。这很重要，不仅是计算机领域，在整个信息领域，要保证并发时数据不冲突，唯一的办法是，明确的界限内，只有单写。这个再深层的根本原因是，信息传递是有速度的。同理，如果信息传递是不需要时间的，且我们认为时间是离散的，那就不再需要锁，比如量子计算机，就是一个不需要锁的计算机，不过这不在我们讨论范围中。
当理解了，锁的作用，以及锁的实现本质。计算机领域的一切锁，理解起来就十分轻松了。我会在软件层面、硬件层面举一些锁的例子，以及为了性能而添加的锁的附加工具。这里还有一个可以断言的，所有锁的附加工具，都是为了提高系统并发性能，注意这里的性能问题不是加锁和释放锁本身耗费资源太多，而是加锁之后业务代码持有时间太长，对其他线程阻塞导致的，以c++互斥锁为例，这个用户态的锁，在现代计算机，平均一次获取仅需要5-15ns。
语言层的锁都是内核层的锁的封装，没有本质的区别，所以我们不再单独拿一个语言的锁来描述。软件层，我以内核和Mysql为例。
- 内核层面：
- 互斥锁：
- 范式说明
- 主体：线程
- 物品：一个权限（用一个标识表示，如std::atomic_flag）
- 不完整使用：一个主体获得该权限后，其他主体不再能获得
- 附加解释：这里的权限，是业务逻辑的约定，比如约定获得这个权限的主体，可以修改变量a，那权限相应的命名为mutex_a。而这里的约定是编码者要遵守的，而不是编译器或者内核遵守的，也就是没有获取mutex_a的主体，修改a，编译器和内核都不会报错，但是这样的程序，运行起来，就像一个定时炸弹，随时出现意想不到的结果。
- 作用：一个线程获取权限时，其他线程一定获取不了，且获取是同步阻塞的。注意这里阻塞时，会调用系统接口，把线程挂起
- 常见附加工具
- 条件变量
- 场景：线程A获取锁，发现不满足处理条件，如果一直等待，那么线程B会阻塞。所以当不满足条件时，线程A释放锁，并将线程A挂起，当条件满足时，再将线程A放到 ready队列。
- 条件变量
- 实现：内核也是由硬件提供的原子操作集的指令支持
- 范式说明
- 读写锁：
- 范式说明
- 主体：线程
- 物品：两个权限，共享权限，和独有权限（用两个标识表示，如两个原子变量）
- 不完整使用：
- 有主体“获取独有权限，或者已经发起独有权限申请”之后，其他主体不能获取共享权限
- 没有主体“获取独有权限，或者已经发起独有权限申请”时，其他主体可以获取共享权限
- 如果有主体A“获得了共享权限”，而主体B申请“获得独有权限”，需要等待A释放权限之后
- 附加解释：读-写锁命名并不准确，这里要得不是读/写的权限，而是共享和独享的权限。
- 作用：将权限分离，核心是在共享权限场景下，增加使用主体，从而增加了系统并行性
- 实现：基于互斥锁，再加上内核提供接口支持，而内核也是由硬件提供的原子操作集的指令支持
- 范式说明
- 自旋锁：
- 范式说明：与互斥锁完全一致。唯一的差别是互斥锁，获取不到时，线程被挂起等待通知。而自旋锁，是持续占有cpu，并尝试获取锁
- 互斥锁：
- Mysql数据库
- 排他锁（排的是行/表/页/意向）
- 范式说明
- 主体：事务
- 物品：行/表/页/意向的读写权限
- 不完整使用：
- 在读已提交的隔离级别下（Mysql默认隔离级别）。一个事务在获取“行/表/页/意向”锁之后，其他事务将不能读或写这段数据
- 附加解释：这里和内核的互斥锁没有本质的区别。只是这里的权限，是行/表/页/意向的读写权，而内核中的权限是对一个标识的权限，而这个标识可以绑定可操作的任意的资源
- 作用：一个事务执行时，阻止其他事务对指定数据的读写
- 范式说明
- 共享锁（享的是行/表/页/表中某个范围）
- 范式说明
- 主体：事务
- 物品：行/表/页/意向的读写权限
- 不完整使用：
- 在读已提交的隔离级别下（Mysql默认隔离级别）。一个事务在获取“行/表/页/意向”锁之后，其他事务将不能写这段数据
- 附加解释：这里可以理解为当前事务占有了，这部分数据的写权限，但没有占有读权限
- 范式说明
- 排他锁（排的是行/表/页/意向）
- 其他：
- 乐观锁
- 说明：乐观锁本质不是一把锁，而是“锁的方式”。核心思想是，主体先在数据A的副本上操作，操作完成判断有没有其他主体在过去一段时间也对数据A有操作，如果没有，就用副本替换原数据。这里要关注的是判断这个动作，是需要加锁的，无论是使用互斥锁，还是直接使用互斥锁的底层接口CAS，没有本质的区别，都是硬件层面提供的支持。
- 无锁队列
- 说明：部分语言或者三方库提供无锁队列，这里只是没有互斥锁，但是CAS是必须有的。所以所谓的无锁队列，多少有些噱头。还是那句话，多主体写，必须加锁，而保证锁的一致性，必须单写，所以性能也必受影响。
- 乐观锁
前面描述了锁的作用，虽然锁的形态有所差异，但是基于这个范式，对作用的理解就不会有偏差。
最后我们说说锁的实现。锁的支持来源于硬件层面，那硬件层面是如果支持锁的。硬件支持锁，本质就是，在CPU系统中，如何保证一个表示权限的变量，一定时间界限内，只被一个CPU核写入，且下一个CPU在写时，保证已经获取到最新的数值。那么这里有两个难点，怎么保证只有一个写，以及怎么保证每次写都是基于最新的值，这些都是缓存一致性协议完成的。
缓存一致性本身是硬件层面的协议，它也经过几个版本的迭代，为了性能也迭代了规则。对于平时的软件开发，我们不需要去理解它所有的细节。只需要理解到，其核心思想是，当一个CPU核A写数据时，会广播信息告诉其他CPU，不要再写了，同时收集所有CPU中最新的值。等其他CPU反馈已经收到核A的信息后，核A才会基于最新的数据去写。而复杂，也是复杂在如何基于这个方式修改，提高性能，如果不是做这个层面的研究，倒是没有必要细枝末节都去熟悉。同样是分布式节点的一致性，对于软件开发者，花费精力去学习raft，倒是一个更划算的事。
