前阵子做代码评审看到一个典型的锁叠锁案例热点商品的库存扣减接口为了防超卖方法上加了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 的间隙锁挡住尽管 id150 这条记录根本不存在。这种锁空气的行为在高并发批量插入场景下会严重拖垮吞吐量——因为所有插入都在互相等间隙。解决思路通常有几种一是确认业务能不能接受读已提交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说明版本对不上或库存不足业务层决定报错或重试。这是一种 CASCompare 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 30NX 保证只有键不存在时才能写入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 end4.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去掉先查后改。改造后压测数据如下方案平均耗时p99 耗时QPS三层锁原方案48ms210ms82去掉 synchronized19ms88ms240去掉 Redis 锁主链路12ms45ms510原子 UPDATE 分桶6ms22ms1100这套对比里最刺痛人的是第一步仅仅删掉一个看似无害的synchronized吞吐量就翻了接近三倍。它告诉大家一个事实——你加锁时觉得多一层保险多一分安全但每一层锁都不是免费保险它都在用吞吐量支付保费。真正专业的做法是先精确识别出哪一层锁在保护哪条不变量再把不需要的那几层毫不犹豫地减掉。5.4 锁的最终归宿把锁从流程控制变成兜底阀做了这么多优化之后我对锁的定位变成了一句话锁应该是系统的兜底阀而不是主流程。主流程尽量设计成无锁或短锁路径让吞吐量跑起来锁只在那里盯住边界违规的情况——比如任务节点同时被两个调度器抢到、状态机出现异常回退、分布式补偿重复触发。拿分布式事务一致性来说真正承载一致性的不是锁而是事务消息、补偿机制、幂等表、状态机这些长链条组件。锁在其中扮演的角色只是防止两个线程同时执行同一条补偿路径。把锁从主角降级为配角系统的吞吐和稳定性反而都会更好。我在实际项目里最后养成了一个习惯每次写完一个并发修改的代码先问自己三个问题——如果不加这把锁最坏会发生什么这个最坏情况能不能用幂等或唯一约束消化掉如果能那这把锁就是多余的。如果确实不能再问下一句这把锁的临界区能不能再短一点粒度能不能再小一点这两个问题问下来大部分无意义的锁根本活不到代码评审环节。压测数据永远是最诚实的裁判。锁与吞吐量的摩擦靠直觉和文档都说不清多跑几轮压测让数据替你做决策才是长久的解法。