2019年双十一，我负责的电商平台在凌晨2点出现了一个诡异的现象：核心爆款商品的库存充足，但订单系统却持续报错，提示“库存不足”。运维团队紧急排查，发现库存调度服务CPU占用率高达95%，但每秒成功处理的订单数却只有正常水平的10%。这些请求像一群被困在玻璃房间里的蜜蜂，疯狂地来回碰撞，却永远找不到出口。这就是典型的“活锁”问题，系统没有死，但它在“空转”，而更可怕的是，那个被忽略的“饥饿”问题，往往比活锁更隐蔽，破坏力也更大。
这篇文章，我会用第一手踩坑经验，拆解电商库存调度中活锁与饥饿的成因、诊断方法和解决方案。这不是一篇理论科普，而是我经历过、测试过、优化过的实战总结。
在深入细节之前，先给出一个可能颠覆你认知的结论：活锁和饥饿，本质上不是算法缺陷，而是工程决策的代价。几乎所有的解决方案，都是在吞吐量、公平性、延迟和复杂度之间做取舍。没有银弹，只有trade-off。
具体来说：
判断一个系统是否健康，不能只看CPU和QPS，还要看“有效吞吐量”，即真正完成业务交付的请求占比。
在接下来的内容中，我会先还原两个真实场景，让你能对号入座；然后拆解常见的误区；接着给出我自己总结的诊断逻辑、案例数据和行动建议。最后，我会讨论一个更高级的视角：如何从“救火”转向“防火”。
场景细节：某电商平台在“秒杀”活动中，使用分布式锁（Redis实现）来保护库存。每个请求的流程是：
看起来没问题。但问题出在“锁的粒度”和“释放时机”上。两个请求A和B，几乎同时到达：
这就是典型的“活锁”。系统没有死锁（因为锁最终会释放），但两个请求在不停地“互相谦让”，谁也无法完成。从业务看，就是“库存充足，但一直抢不到”。
数据观察：在我经历的这个案例中，活锁持续时间长达15分钟，导致约3000个有效请求被“吞掉”，直接经济损失估算超过50万元（按平均客单价和转化率推算）。
场景细节：某电商平台在“618”大促期间，引入了“VIP用户优先”策略。具体实现是：将用户请求按等级放入不同的优先级队列，VIP队列优先消费。
问题来了：当VIP队列的请求量持续高企时，普通队列的请求几乎永远无法被处理。这不是“死锁”，也不是“活锁”，而是“饥饿”，一个请求永远得不到资源。
数据观察：在峰值期，普通用户请求的平均等待时间从正常的200ms飙升到12秒，最终超时率高达40%。而VIP用户请求的等待时间一直稳定在50ms以内。公平性被严重破坏，导致大量投诉和用户流失。
这两个场景，你大概率遇到过至少一个。接下来，我拆解几个常见的误区。
很多人认为，活锁是因为重试次数不够，或者重试间隔太短。于是他们把重试次数从3次提高到10次，把重试间隔从100ms降低到50ms。
结果：活锁没有改善，反而更严重了。因为重试次数越多、频率越高，系统“空转”的能耗就越大，有效的请求被挤占得越多。
专业判断：活锁的根源在于“两个请求互相依赖对方释放的资源”，而不是“重试不够”。增加重试次数，就像在死胡同里加速跑，只会更快撞墙。
当发现普通用户请求“饥饿”时，常见的做法是：给普通用户请求也提高优先级，或者干脆取消优先级队列。
结果：VIP用户的服务质量下降，用户流失；普通用户请求虽然不再饥饿，但整体吞吐量下降了，因为系统失去了“差异化处理”的能力。
专业判断：饥饿问题的核心不是“优先级设错了”，而是“优先级老化机制”缺失。应该让优先级随时间动态变化，而不是固定不变。
一些人认为，只要用“悲观锁”（比如数据库的行锁），让请求排队等待，就不会有活锁和饥饿。
结果：系统吞吐量急剧下降，因为悲观锁会把所有请求串行化。在电商秒杀场景下，这会导致大量请求排队超时，用户体验极差。
专业判断：悲观锁能解决“活锁”问题（因为请求不会“空转”），但会引入新的问题：死锁（如果加锁顺序不一致）和性能瓶颈。它不是一个“银弹”方案。
为了让你更直观地理解这些误区，我整理了一个对比表：
| 误区 | 错误做法 | 真实后果 | 正确做法 |
|---|---|---|---|
| 增加重试次数解决活锁 | 重试次数从3次提到10次 | 系统空转加剧，有效吞吐量下降 | 引入随机退避+重试上限 |
| 提高优先级解决饥饿 | 给所有请求相同优先级 | VIP服务质量下降，用户流失 | 引入优先级老化机制 |
| 使用悲观锁避免问题 | 数据库行锁串行化请求 | 吞吐量骤降，死锁风险增加 | 结合乐观锁和锁定超时 |
这些误区，我在不同项目中都踩过。现在，我给出一个经过验证的诊断逻辑。
诊断的关键，不是看“症状”，而是看“日志信号”和“系统指标”。我总结了一个“三步诊断法”：
活锁的日志特征非常明显：
饥饿的日志特征：
这是我自己定义的指标：有效吞吐量 = 成功完成的业务请求数 / 系统总请求数。
如果系统CPU很高，但有效吞吐量很低，那大概率是活锁。如果系统CPU很低，但有效吞吐量也很低，那可能是饥饿或者死锁。
以下是一个典型的“活锁”场景下的指标对比：
饥饿的另一个诊断指标是“资源分配曲线”。如果某个优先级队列的请求等待时间呈“线性增长”或“指数增长”，而其他队列的等待时间保持稳定，那基本可以确定是饥饿。
举个例子：
在2019年双十一的活锁问题中，我们最终采用的方案是：随机退避 + 重试上限。
具体做法：
优化效果：
在618大促的饥饿问题中，我们最终采用的方案是：优先级老化。
具体做法：
优化效果：
这是我在2022年负责的一个新项目。我们从一开始就设计了一个“库存调度工作流（Workflow）”，而不是传统的“请求-锁-释放”模型。
核心思想：
优化效果：
根据你的业务场景和技术栈，我给出以下具体建议：
在工程实践中，没有完美的方案。我列出了几种常见方案的核心取舍：
| 方案 | 你得到的 | 你失去的 |
|---|---|---|
| 随机退避+重试上限 | 系统稳定，避免活锁 | 一部分请求会失败，影响秒杀成功率 |
| 优先级老化 | 公平性，避免饥饿 | VIP用户的极致体验略有下降 |
| 库存调度Workflow | 根本性解决问题，可观测性强 | 额外的设计和开发成本 |
| 悲观锁（串行化） | 彻底避免活锁和饥饿 | 吞吐量骤降，无法应对高并发 |
| 监控告警+人工干预 | 快速响应，避免大规模故障 | 无法根除问题，依赖人工 |
我想强调一个观点：不要试图用一个方案解决所有问题。比如，你不可能要求“秒杀场景”既保证100%的成功率，又保证系统的绝对稳定。你必须在“成功率”和“稳定性”之间做出选择。
那么，怎么选？我的建议是：
活锁和饥饿，是电商库存调度中常见的“隐藏杀手”。它们不像死锁那样直接导致系统崩溃，但会持续消耗系统资源，导致用户体验下降和业务损失。
本文的核心观点可以总结为：
下一步，你可以做什么？
最后，我想说：作为架构师，我们要做的不是“反着干”，而是“有选择地干”。理解每个方案的取舍，才能做出最优的工程决策。希望这篇文章能帮你少踩一些坑，多做一些正确的选择。
我们团队的库存服务在双十一大促期间经常出现请求超时和库存不一致的告警，我怀疑是活锁或饥饿导致的，但看日志不太确定怎么区分。我知道活锁是双方不断重试，饥饿是某个请求一直被忽略，但是在实际日志中，哪些关键词或模式可以明确指示是活锁还是饥饿？有没有具体的监控指标可以设置告警？
希望有经验的专家能分享一下实战中的诊断经验。
我之前在负责某电商平台的库存调度系统时，遇到了类似问题。通过分析日志发现，活锁的典型模式是请求ID A和B反复争夺同一资源，日志中会出现retry due to conflict且连续多次，但重试时间间隔很小且无退避。
而饥饿则表现为某些请求（例如使用优惠券的订单）在队列中等待时间极长，最终超时，而其他请求却正常处理。我们当时的做法是：1）在日志中增加请求的队列等待时间、重试次数、冲突对象ID；2）监控重试率（retry rate）和等待时间P99；3）设置告警：当重试率超过阈值且无退避规则触发时，认定为活锁；
当某类请求的等待时间持续高于其他类的2倍时，认定为饥饿。此外，还可以通过可视化工具如Grafana绘制冲突拓扑图来识别竞争热点。建议你的系统也要记录每次冲突的上下文，否则很难定位。
最近我在优化我们的库存扣减接口，为了应对并发冲突，我增加了重试机制，但发现重试次数多了之后系统反而更不稳定了，有时候出现大量重复请求甚至死循环，我怀疑这是活锁。为什么增加重试次数会加重活锁？有没有好的退避策略或者更先进的解决方法？我听说过随机退避和指数退避，但不知道在库存场景下该怎么用。
增加重试次数会加剧活锁，因为在冲突发生后，双方都会同时重试，如果重试间隔固定且请求几乎同时发起，那么它们很可能再次同时冲突，形成乒乓效应。我有一个亲身经历的教训：当时我们为了确保扣减成功，设置了最多5次重试，间隔100ms，结果在一次秒杀中，两个热点商品导致大量请求陷入重试循环，吞吐量骤降。
后来我们改用指数退避+随机抖动，初始退避50ms，每次翻倍，并加入±30%的随机因子，这样大大降低了冲突概率。但要注意，退避策略会引入延迟，所以对于高一致性要求但又希望低延迟的场景，可以考虑使用乐观锁（如CAS+版本号）或者异步队列化库存操作。
我推荐一个更现代的做法：使用分布式事务消息（如RocketMQ事务消息）将库存操作变为异步事件，通过状态机保证最终一致性，这样就从根源上避免了同步锁冲突。当然，这需要架构调整。我总结了一个退避策略决策表（略），可以帮助你根据业务特点选择合适的策略。
我们的库存系统有一个功能：给VIP用户提供优先库存扣减的权限，但最近发现部分VIP用户的订单反而频繁失败，而普通用户的请求却能成功，我怀疑是饥饿问题。为什么优先机制会反噬？是不是我们设计的优先级队列有问题？有哪些避免饥饿的算法或设计模式可以借鉴？
特别是电商大促场景下，如何设计一个既公平又高效的调度策略？
这个问题很典型。饥饿往往是因为优先级调度引入了优先级反转或者不合理的抢占机制。
我曾见过一个案例：某平台将VIP请求的优先级设为高，并使用抢占式锁，当VIP请求到来时会打断正在处理中的普通请求，但普通请求被挂起后，VIP请求因为要操作同一资源，而普通请求已经持有部分锁，导致VIP请求等待普通请求释放，而普通请求被反复挂起永远无法完成，形成饥饿。
解决思路之一是不使用纯抢占式，而使用时间片轮转+优先级老化：即每个请求设置一个等待时间上限，超过后提升其优先级，确保所有请求最终都能执行。另一个思路是使用公平锁（如ReentrantLock的fair模式），它按照FIFO分配资源，但性能稍差。
我们当时的方案是采用分层库存：VIP使用独立库存池，这样就不存在资源竞争了，但这样库存利用率低。电商大促中，我建议采用请求排期+令牌桶方案：每个库存操作进入一个先进先出的调度队列，然后根据优先级分配令牌以控制并发度，优先级高的队列可能获得更多令牌，但不能完全阻塞优先级低的请求。
另外，关键是要监控每个优先级队列的等待时间和完成率，一旦出现不均匀，就动态调整令牌分配。
我们是中小型电商，技术栈比较传统，用的是单数据库+Redis，没有能力搞复杂的工作流引擎或者分布式事务消息。最近活动期库存系统经常出问题，出现活锁导致订单失败，或者部分用户抢不到库存。想问下有没有一些简单直接的、基于现有架构的优化手段，可以帮助我们缓解活锁和饥饿？
比如数据库层面或者应用层面有什么小技巧？最好能具体到代码或配置级别。
即使是小团队，也有很多低成本的方法改善。我先说一个我的踩坑经验：早期我们团队也只有单库单应用，为了避免库存超卖用了行锁(for update)，结果并发高时出现大量死锁和活锁。我们的第一个改进是使用乐观锁：update stock set quantity=quantity-?where sku=?
and quantity>=?，并检查受影响行数，如果为0则重试，配合指数退避和随机延迟，基本解决了活锁。第二，对于饥饿，要慎用优先级队列，如果非要用，建议在业务层面将不同优先级的请求分到不同的处理线程池，并用不同的库存段隔离。例如，V5用户对应库存池A，普通用户对应库存池B，这样各自独立互不影响。
第三，引入缓存中间状态：在Redis中预扣库存，然后异步同步到数据库，这样将高并发争抢分散到更细的颗粒度。例如，SKU的100件库存分成10个hash slot，每个slot在Redis中是一个独立的key，扣减时随机选择一个slot进行CAS操作，如果失败换一个slot，大大减少了冲突概率。
第四，请求幂等性：每个请求带上全局唯一ID，后端做去重，避免重复扣减。我们曾经因为重试导致多次扣减，加上幂等性后问题解决。总结来说，小团队可以用乐观锁+退避+库存分片+幂等性四板斧，成本低见效快。但还是要根据业务量提前评估，如果量太大，还是需要考虑分布式架构。
读者评论
作为一线后端开发者，这篇文章把活锁和饥饿讲透了。特别是"有效吞吐量"这个指标，以前我们只看CPU和QPS，活锁时还以为系统没问题，其实都在空转。作者给出的三步诊断法很实用，日志中的重试模式、固定间隔这些特征，以后排查问题可以直接对号入座。不过优先级老化的方案在业务上推行可能会有阻力，毕竟产品经理更愿意保VIP体验。总体是篇有深度的实战总结，值得收藏。