锁的代价：从三层锁到1100 QPS的性能优化实践

前阵子做代码评审，看到一个典型的"锁叠锁"案例：热点商品的库存扣减接口，为了防超卖，方法上加了synchronized，方法内部又套了一层 Redis 分布式锁，直连数据库时还顺手写了SELECT ... FOR UPDATE。三层锁叠完，接口确实安全了，安全到压测 QPS 从八百多直接掉到八十几。

这件事让我反复想一个问题：很多人加锁，到底是真想保证一致性，还是只是"怕出事"？锁这个东西，真实成本从来不在写锁那行代码上，而在排队、等待、重试和锁超时带来的一系列连锁反应里。这篇文章就围绕这个灵魂拷问展开，把互斥锁、MySQL 锁机制、乐观锁悲观锁、分布式锁这几块掰开揉碎讲清楚，同时回答一个在职级晋升和面试里都很烫手的问题：你费劲加的锁，到底是在兜底一致性，还是在把吞吐量按在地上摩擦。

1. 锁的"一致性"承诺到底是什么——先搞清楚你在保护什么

1.1 一致性不是一个"状态"，是一组不变量

很多同学一开口就是"加锁保证数据一致性"，但你追问他一句"你要保证的到底是哪条一致性？"，他就开始支支吾吾。这是加锁领域最普遍的误区：把"一致性"当成一个模糊的大帽子，而不是一组可以被精确表述的业务不变量。

拿库存扣减举例。你要保证的不变量其实是两条：第一，库存不允许减成负数；第二，同一用户、同一订单的扣减不能重复生效。这两条不变量明确了，你才能判断要不要用锁、用哪种锁、锁的粒度该划在哪。如果只说"我要保证一致性"，那你大概率会在所有写路径上无脑加锁，因为你不确定到底该保护什么，只能全保护。

在数据库理论里，一致性（ACID 的 C）指的是事务执行前后，数据库从一个合法状态迁移到另一个合法状态，中间任何时刻都不会被中间产物污染。而并发场景下的"一致"，落实到工程上就是让并发操作的效果等价于某种串行顺序。这里的关键词是"等价于"，不是"真的串行执行"。很多锁实现的是后者——真的串行了，吞吐量当然就没了。

我自己的经验是，动手加锁之前先写一行注释："本锁保护的不变量是：库存字段 stock >= 0，且扣减记录唯一。"写不出来这行注释，说明你自己都没想明白锁的意义，这时候最该做的不是加锁，而是回去梳理业务流程。

1.2 加锁不是唯一路径：MVCC 和原子操作也在保一致性

另一个容易忽略的点是，一致性不一定靠"锁住数据不让别人碰"来实现。MySQL InnoDB 的 MVCC（多版本并发控制）就是个典型例子：读操作走快照读，读到的是一致性的历史版本，根本不需要加锁阻塞写操作。这也是为什么在高并发下，纯查询接口只要隔离级别设计得当，能维持很高的吞吐——因为大家根本不在同一条资源上互相等待。

再看原子操作。数据库里UPDATE inventory SET stock = stock - 1 WHERE id = ? AND stock > 0这条 SQL，本身就是原子操作，它在引擎层用排他锁只锁了那一行索引记录，执行完立刻释放。它同样保证了"库存不能为负"这条不变量，但锁持有时间只有几毫秒，比你在应用层synchronized包里三层外三层的方案，吞吐量高一个量级。

面试里常考的"MySQL 锁原理"，很多人背了一堆行锁、表锁、共享锁、排他锁的定义，却回答不了一个最基础的问题：同一条更新语句，为什么不同写法锁的范围能差出几百倍？这背后就是锁的粒度与访问路径的关系。所以看锁，永远不能只看"有没有锁"，要看"锁了什么范围、持有多久、什么时候释放"。

1.3 面试题最常见的误区：一上来就答"加锁"

跟"数据库并发锁"相关的面试题，十个人里七八个人的第一反应是"加锁解决并发冲突"。但面试官真正想听的恰恰是分层思考：先考虑能不能用无锁语义（幂等键、唯一索引、原子条件更新）把冲突从根上消掉；不行再想锁的选择——悲观锁还是乐观锁，数据库锁还是分布式锁；最后才落到锁的调优，比如缩小临界区、调整隔离级别、处理死锁重试。

这不是说锁不重要，而是说锁应该是你工具箱里最后一件武器，不能是唯一一件。判断一个人是不是真的懂并发，不是看他能不能背出synchronized和ReentrantLock的区别，而是看他面对一个具体业务场景时，能不能回答出"我加这把锁，是为了把哪条不变量维持住，为此愿意付多少吞吐量的代价"。

2. MySQL 锁机制里的吞吐量账本：行锁、间隙锁与锁等待

2.1 行锁不是"锁一行"，是"锁索引记录"

InnoDB 行锁的实现细节，是摩擦吞吐量的头号元凶。很多人以为行锁就是只锁那一条数据，实际 InnoDB 的锁对象挂在索引记录上——也就是说，你的 WHERE 条件能不能命中索引，直接决定锁的范围。

假设有张订单表，更新条件是UPDATE orders SET status = 'PAID' WHERE user_id = 123，而user_id列没有索引。这时候 InnoDB 会对主键聚簇索引里的每一条满足条件的记录加锁。更糟的是，在锁定位过程中扫描到的其他记录也可能被锁住。换句话说，你本想锁一个用户的订单，结果把扫描路径上所有无关的记录都拖进了锁集合里。

我处理过一个线上事故：某报表系统定时任务全表更新一批订单状态，一条不带索引条件的UPDATE，直接把正在进行的用户下单接口全部堵死，耗时从 20ms 飙到 8 秒。后来给过滤列补了索引，锁范围从全表骤降到十几行，接口耗时立刻恢复。

所以调 MySQL 锁的第一步，不是调参数，而是检查EXPLAIN的type列是不是ref或range。一旦出现ALL（全表扫描），你写的行锁在引擎层实际退化成近乎表锁的效果，吞吐量自然被按在地上摩擦。

这里补充一个热词里很常见的面试点："MySQL 锁表"。很多人把"锁表"理解成"执行了LOCK TABLE"，但生产环境里真正坑人的锁表，绝大多数是长事务持有行锁 + 事务迟迟不提交，导致其他事务的同一条记录更新一直等待，从业务视角看就像整张表被锁死了。排查手法我后面会专门讲。

2.2 间隙锁与临键锁：防幻读背后的并发代价

在可重复读（REPEATABLE READ）隔离级别下，InnoDB 为了防幻读引入了间隙锁和临键锁。间隙锁锁的是记录之间的空隙，临键锁则是记录锁 + 间隙锁的合体。它们存在的意义是阻止并发事务向某个区间插入新数据，以保证范围查询两次结果一致。

问题在于，间隙锁和行锁不一样：行锁冲突只发生在同一行，间隙锁一旦建立，任何想往这个间隙插入的会话都得排队。看一个极端例子：

-- 事务 A SELECT * FROM orders WHERE id BETWEEN 100 AND 200 FOR UPDATE; -- 事务 B（同时执行） INSERT INTO orders (id, status) VALUES (150, 'NEW');

事务 B 的插入会被事务 A 的间隙锁挡住，尽管 id=150 这条记录根本不存在。这种"锁空气"的行为，在高并发批量插入场景下会严重拖垮吞吐量——因为所有插入都在互相等间隙。

解决思路通常有几种：一是确认业务能不能接受读已提交（READ COMMITTED）隔离级别，它只有行锁没有间隙锁，能显著降低插入阻塞；二是把范围更新的 WHERE 条件改得足够精确，压缩锁定的间隙范围；三是对低频写、高频读的报表类查询使用快照读（普通SELECT，不加FOR UPDATE），根本不触发行锁和间隙锁。

顺带一提，这也是"数据库乐观锁、悲观锁的实现原理和适用场景"这类面试题的深层考点。乐观锁之所以在互联网场景里被广泛使用，不只是少了一次锁等待，而是它完全不依赖数据库的锁机制——版本号比对失败就放弃或重试，压根不给间隙锁上场的机会。

2.3 死锁、锁等待与事务长度：三个吞吐量杀手

MySQL 里和锁相关的三个性能杀手，按危害程度排序：长事务 > 死锁 > 普通锁等待。

长事务是隐形的。一个事务从开启到提交，中间如果夹着远程调用、等待用户输入、复杂的业务计算，那它手里的行锁就会一直攥着不放。其他会话更新同一行就得排队，而且 InnoDB 的锁等待有一个innodb_lock_wait_timeout默认 50 秒的超时，业务请求等不到就直接报Lock wait timeout exceeded。我在生产排查中见过最离谱的案例是：一个事务里嵌了 HTTP 调外部支付接口，对方接口超时 30 秒，结果这个事务把热销商品的库存行锁了整整 30 秒以上，期间所有售卖请求全部被挡在后面。

死锁则是互相持有对方要的资源。解决死锁的唯一可靠路径是：所有事务以相同的顺序访问资源，并且让业务层捕获死锁异常（报错码 1213）做有限次重试。很多人写代码只处理Duplicate entry，不处理死锁，结果半夜被报警叫醒。

至于事务长度，我的铁律是：事务里只放"必需的数据库写操作 + 极短的读校验"，任何远程调用、消息发送、复杂计算都必须挪到事务外面。这比对锁本身调优有效十倍。

2.4 怎么判断到底是锁在"摩擦"吞吐量

高端局里，你不能靠感觉判断"是不是锁拖累了吞吐量"，得有工具。我自己排障的一套组合拳是这样的：

• 先用SHOW ENGINE INNODB STATUS\G看LATEST DETECTED DEADLOCK和TRANSACTIONS段，能直接看到当前持锁、等锁的事务 SQL。
• 再用performance_schema.data_lock_waits和sys.innodb_lock_waits视图，查当前锁等待的阻塞链，定位谁是源头事务。
• 配合SHOW PROCESSLIST看会话状态，State列出现updating或Sleep且事务开启时间很久，就是长事务的直接证据。
• 应用层用监控埋点统计 SQL 耗时的 p99 和锁等待占比，如果 p99 尖刺出现的时间和慢事务的时间窗口重合，基本就能坐实。

顺便提一句"数据库查询是否锁表"这个热词。很多人查锁直接用SHOW PROCESSLIST只看 Sleep 和 Query，其实更准的是查performance_schema下的三张锁相关表。步骤不复杂，但每一次排障都按这个链路走，就能少走弯路。

3. 乐观锁与悲观锁：不是二选一，是两个成本模型

3.1 悲观锁的成本结构：等待、排队与上下文切换

悲观锁的思路是"我怀疑你会来抢，所以我先把门锁上"。数据库层表现是SELECT ... FOR UPDATE，应用层表现是synchronized、ReentrantLock。实现简单、正确性强，但成本是让并发请求在锁上排队。

排队这件事看着简单，实际开销很大：线程挂起与唤醒涉及操作系统上下文切换，锁竞争激烈时，CPU 大量时间花在调度而不是执行业务代码上；数据库事务层面，等待中的查询会占用连接池连接，连接一占满，整个服务的线程池也跟着堵。这就是为什么锁竞争一高，吞吐量不是线性下降，而是断崖式崩塌。

有一个直观的类比：悲观锁是单行道收费站，一次只放一辆车过去，车多了全部堵在入口，连隔壁车道的车也被连带堵住。而乐观锁更像自助结账通道，每个人都拿着自己的购物清单快速结算，遇到冲突（版本对不上）再回头处理那一个人的问题。

3.2 乐观锁的核心：版本号与 CAS 重试

乐观锁在数据库里的经典实现是版本号字段：

-- 扣减库存：版本号 + 条件更新 UPDATE inventory SET stock = stock - 1, version = version + 1 WHERE sku_id = ? AND version = ? AND stock > 0;

执行后检查影响行数，如果为 0，说明版本对不上或库存不足，业务层决定报错或重试。这是一种 CAS（Compare And Swap）思想：先比对再更新，数据库引擎保证这一条 UPDATE 本身是原子的。

它的核心优势是：锁资源只在最终的原子写那一瞬间被占用，而不是在整个"读-判断-写"过程中占住。冲突概率高的时候，大量 UPDATE 会失败需要重试，这时候吞吐量也不好看；但冲突概率低的时候，乐观锁几乎没有锁等待成本，吞吐量远胜悲观锁。

还有一个细节容易被忽略：乐观锁一定要搭配"条件中包含库存余额或状态约束"一起用，否则版本号只能防更新冲突，防不了业务上的非法状态迁移。比如库存扣减只比对 version，不判断 stock > 0，那并发扣到负数就兜不住，这是"乐观锁没有锁对业务规则"的典型翻车现场。

3.3 什么场景选哪个——一张表说清楚

我整理了一张选型表，可以当作保守的起步参考：

注意，这张表不是用来一刀切的，而是帮你评估"如果这批请求全来了，我的系统是排队更难受，还是失败重试更难受"。资金类操作为什么多是悲观锁？因为重试资金操作容易引发重复支付、账不平，宁可排队，不可出错。库存类为什么偏爱乐观锁？因为扣减失败顶多让用户再点一次，重试成本低，而排队会把所有用户都挡在门外。

3.4 乐观锁不是没有锁，是把冲突延迟到了更新那一刻

这里想澄清一个高频误解：乐观锁不是"不加锁"。它只是不在读阶段加锁，把冲突检测和解决压缩到最后一条 UPDATE。数据库引擎在更新那一瞬间，仍然会对记录加行锁。区别在于这个锁的持有窗口极短，通常只有几毫秒，且不随事务里其他业务操作而延长。

认清这一点很重要，否则你会踩一个很隐蔽的坑：把乐观锁放进一个超长事务里，前面读了一大堆数据，最后才执行那条版本号 UPDATE。这时候事务持有行锁的时间被拉长，和悲观锁犯的错一模一样。乐观锁的优势永远是"短事务 + 短临界区"，一旦违背这两个前提，它和悲观锁一样能把吞吐量拖垮。

4. 分布式锁：从 Redis 到 ZK，一致性代价对比

4.1 Redis 分布式锁为什么"快"，又为什么"危险"

单机时代结束，锁就分散到了不同进程之间。Redis 分布式锁是现在最流行的方案，热词里的"redis分布式锁"和"分布式锁使用场景"几乎成了面试必考。它的核心实现是一条命令：

SET lock:order:123 uuid_value NX EX 30

NX 保证只有键不存在时才能写入，EX 30 设置 30 秒过期，value 用 UUID 是为了释放时校验身份，防止误删别人的锁。这套方案快，因为 Redis 是纯内存操作，单次加锁不到一毫秒。

但它的危险也藏在"快"背后。最经典的问题是锁的过期时间：如果业务执行超过 30 秒，锁自动释放了，另一个线程立刻拿到锁进入临界区，于是同一份数据被两个线程同时操作，"一致性保护"在这一刻失效。解决方案是给锁续期（看门狗），但续期机制在 Java 的 Redisson 里是默认行为，很多赶工的方案压根没续期，只靠一个裸过期时间硬扛。

更隐蔽的风险是误删锁。如果释放锁时没校验 value，一个线程的锁过期后被另一个线程拿到，前一个线程执行完直接 DEL，把后者的锁删了。正确写法必须用 Lua 脚本保证"比对 UUID + 删除"的原子性：

if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end

4.2 Redlock 的争议到底在争什么

说到 Redis 分布式锁，绕不开 Redlock 和那场著名论战。Redlock 的设想是向多个 Redis 节点同时加锁，超过半数成功才算加锁成功，以此降低单点故障的影响。

但分布式系统领域的专家 Martin Kleppmann 写过一篇文章，核心批评是：分布式锁的正确性不能单靠"排他"保证，因为即使 Redlock 做到了同一时刻只有一个客户端持有锁，持有锁的客户端也可能因为 GC 停顿、网络延迟、时钟跳变等意外，在锁过期后继续执行一段"过期后的操作"，从而污染数据。他开出的药方是 fencing token——每次加锁拿到一个单调递增的 token，写数据时带上 token，服务端拒绝旧 token 的写入。这本质上是把"锁提供的互斥"降级为"锁只是协商机制，最终一致性要由数据端校验来兜底"。

Redis 作者对这场论战的长文回应也值得读，但落到工程实践，我的结论简单粗暴：如果你的数据允许"锁过期后短暂的并发写入"且业务层能用幂等或唯一约束兜底，Redlock 完全够用；如果你的数据要求绝对不允许并发写（比如账户余额变更），那就别指望 Redis 锁，改用数据库唯一约束或 ZK/etcd 这类带权威语义的锁。

热词里的"分布式锁面试题"如今基本都在考这套论战逻辑。面试官其实不指望你站队谁，而是看你能不能把话说清楚：分布式锁能阻止互斥，但阻止不了持有者被延迟或时钟跳变之后产生的"僵尸执行"。

4.3 分布式锁解决不了的问题：幂等与状态机才是终极兜底

另一个常被忽视的点是，分布式锁解决的是"并发互斥"，解决不了"重复提交"和"无效状态迁移"。很多业务问题本质上是幂等问题和状态机问题，用锁属于杀鸡用牛刀，而且牛刀还会误伤吞吐量。

以支付回调为例，真正可靠的方案不是加锁，而是两层组合：

• 数据库层给唯一业务单号加唯一索引，重复插入会直接报Duplicate entry，天然去重；
• 业务状态机校验，例如只有状态 = 待支付时才允许流转到已支付，其他状态直接拒绝。

这种方案的吞吐量远高于锁方案，因为唯一索引在全表里做一次 O(1) 级别的唯一性检查，几乎不阻塞其他写入；状态机条件更新则只锁单行，极短。分布式事务一致性这个热词背后，很多厂商宣传的"分布式锁保一致"，实际大多都是在为不良设计找补。分布式一致性更可靠的底座，永远是把业务语义设计成可幂等的操作。

4.4 ZK/etcd 锁：慢但更可靠的取舍

ZooKeeper 或 etcd 实现的分布式锁，依赖临时顺序节点 + Watch 机制。加锁过程是创建一个带序号的节点，然后检查自己的序号是不是最小，不是则监听前一个节点，前一个释放后自己再尝试。

这个方案比 Redis 可靠的地方在于：临时节点与会话绑定，客户端崩溃后锁会自动释放；节点序号天然提供了排队顺序，没有过期时间导致锁被偷的问题；并且可以设计出 fencing token 语义，配合业务校验构成可靠的互斥。

代价是延迟。一次 ZK 加锁往往要经过网络往返 + 节点创建 + Watch 通知等多次交互，平均耗时几十毫秒，比 Redis 的亚毫秒慢一个数量级。高 QPS 场景下用 ZK 锁，本身就是把吞吐量往摩擦。所以我的建议是：能不用分布式锁就不用，必须用时，流量高峰场景选 Redis 锁 + 幂等兜底，低频关键场景（如定时任务抢单、迁移任务互斥）选 ZK/etcd 锁，可靠性优先。

5. 把吞吐量从锁手里"抠"出来：临界区压缩与无锁路径

5.1 缩小临界区：能少锁就少锁，能短锁就短锁

前面讲了那么多，核心就一句话：锁的成本 = 临界区长度 × 竞争程度。要么降低竞争程度，要么缩短临界区长度，两条路都可以让吞吐量回来。

降低竞争的第一招是分桶。库存从单一字段拆成多个槽位（比如 10 个库存桶），每次扣减按用户 ID 哈希选一个桶，桶内自减。这样同一时刻最多只有 1/10 的并发请求竞争同一个锁，冲突率大幅下降。缺点是编码复杂度上升，且每个桶的库存可能出现不均衡，需要定期做桶间调拨。

缩短临界区的最经典操作是"先更新后校验"：把"读库存 -> 判断库存是否够 -> 扣减"三步改成一条原子 UPDATE，加锁窗口从三步缩小到一步。对应到代码就是：

UPDATE inventory_sku_bucket SET stock = stock - 1 WHERE bucket_id = ? AND stock > 0;

影响行数为 0 时再走补偿逻辑（提示库存不足或换桶重试）。这个手法把锁的持有时间从毫秒级压到亚毫秒级，吞吐量几乎不受锁竞争影响。

5.2 原子操作与无锁队列的使用边界

热词里的"无锁队列"和"无锁编程"，属于更进阶的玩法。原子类（如 Java 的AtomicLong、LongAdder）、CAS 自旋、环形缓冲区（Disruptor 风格）确实能在特定场景下甩开锁几条街。但我的经验是，无锁方案在业务系统里性价比普遍不高，因为：

• 无锁不免费，它把复杂度从"阻塞"转移到了"内存模型、ABA 问题、Cache Line 伪共享"这些更难查的问题上；
• 业务系统 90% 的并发瓶颈不在数据结构内部，而在数据库行锁和跨服务调用上，你用无锁队列优化了内存计算，数据库一锁照样全堵。

所以我通常只在两类地方用无锁：一是埋点计数、指标统计这类高并发、高冲突、允许丢一点精度的场景，用LongAdder做统计聚合；二是单机内的消息分发管道，用有界环形队列加 CAS 替代put/take阻塞。至于业务数据本身的读写，一律老老实实走数据库锁或分布式锁，然后用缩小临界区的方式提升吞吐，而不是强行上无锁。

5.3 一例锁优化压测复盘：从 80 QPS 到 1100 QPS

回到开头那个案例。库存扣减接口原来的实现是synchronized+ Redis 锁 +FOR UPDATE三层保险，压测结果 QPS 稳定在 80 左右。我接手后做了一次减法：

第一层减法：删掉方法级的synchronized。应用层的互斥对库存扣减没有任何意义，真正保证不卖超的是数据库的条件更新语义，synchronized只起到了把同一实例内所有请求串行化的效果，是最大的吞吐瓶颈。

第二层减法：Redis 锁只保留在"防缓存击穿 + 防两次异步补偿在同一桶库存上叠加扣减"的场景，正常下单主链路不碰分布式锁，锁只在分布式补偿任务中用于抢任务，不用于扣库存。

第三层减法：数据库扣减改成单条原子 UPDATE，去掉先查后改。

改造后压测数据如下：

这套对比里最刺痛人的是第一步：仅仅删掉一个看似无害的synchronized，吞吐量就翻了接近三倍。它告诉大家一个事实——你加锁时觉得"多一层保险多一分安全"，但每一层锁都不是免费保险，它都在用吞吐量支付保费。真正专业的做法，是先精确识别出哪一层锁在保护哪条不变量，再把不需要的那几层毫不犹豫地减掉。

5.4 锁的最终归宿：把锁从"流程控制"变成"兜底阀"

做了这么多优化之后，我对锁的定位变成了一句话：锁应该是系统的"兜底阀"，而不是"主流程"。主流程尽量设计成无锁或短锁路径，让吞吐量跑起来；锁只在那里盯住边界违规的情况——比如任务节点同时被两个调度器抢到、状态机出现异常回退、分布式补偿重复触发。

拿"分布式事务一致性"来说，真正承载一致性的不是锁，而是事务消息、补偿机制、幂等表、状态机这些长链条组件。锁在其中扮演的角色，只是防止两个线程同时执行同一条补偿路径。把锁从主角降级为配角，系统的吞吐和稳定性反而都会更好。

我在实际项目里最后养成了一个习惯：每次写完一个并发修改的代码，先问自己三个问题——如果不加这把锁，最坏会发生什么？这个最坏情况能不能用幂等或唯一约束消化掉？如果能，那这把锁就是多余的。如果确实不能，再问下一句：这把锁的临界区能不能再短一点，粒度能不能再小一点？这两个问题问下来，大部分无意义的锁根本活不到代码评审环节。

压测数据永远是最诚实的裁判。锁与吞吐量的摩擦，靠直觉和文档都说不清，多跑几轮压测，让数据替你做决策，才是长久的解法。