1 基本概念
1.1 定义
活锁是并发系统和分布式系统中一种典型的非前进状态。系统里的多个执行单元都处于可运行或持续响应的状态，表面上不断产生动作，实际上却始终无法把任务推进到完成阶段。与“完全停住”的情形不同，活锁更像是一种持续活动但没有结果的循环。
1.2 核心特征
活锁通常具有几个共同特征：参与者一直在响应环境变化，状态不断更新，但整体目标始终没有达成。它的外观往往比死锁更“热闹”，因为系统没有静止下来，而是不断发生让步、重试、撤销或切换。
1.2.1 持续响应
在活锁中，执行单元通常不会沉默或挂起，而是持续对外界刺激作出反应。它们可能不断检查条件、重试请求、重新协商资源，或反复执行某个恢复动作，因此系统看起来仍在活跃运行。
1.2.2 无法推进
虽然系统一直在工作，但关键状态始终无法越过某个门槛，任务也就无法完成。这里的“无法推进”不是因为没有动作，而是因为每次动作都被对方行为抵消，或者在策略上被迫回到起点。
1.2.3 状态反复变化
活锁中的状态往往在若干值之间来回摆动，例如线程反复改变让步顺序，节点不断切换重试角色，或协议双方不停重新发起协商。状态变化本身并不罕见，问题在于这种变化缺乏累积效果。
1.3 与死锁的区别
死锁强调的是彼此等待、互相占住资源而停止前进；活锁则不同，相关执行单元通常并未卡死，而是仍在运行，只是持续做出会抵消彼此效果的动作。前者更像“谁都不动”，后者更像“都在动，但没人到达终点”。
1.4 与饥饿的区别
饥饿通常指某个执行单元长期得不到资源或调度机会，导致自身进展受阻；活锁则常见于多个执行单元都在活跃运行，但由于反复让步、冲突或重试，系统整体无法完成目标。饥饿偏向“一个人长期被忽略”，活锁偏向“大家都很积极，却总是白忙”。
2 形成原因
2.1 资源竞争
当多个执行单元同时争夺有限资源时，如果竞争策略缺乏稳定性，就可能出现反复抢占、反复释放的循环。每一方都试图避免冲突，结果却使冲突持续存在，最终形成活锁。
2.2 过度礼让与回避策略
某些协议或算法为了避免碰撞，会设计让步、后退或撤销机制。如果参与者都过于“懂事”，总是在对方动作后主动退回，系统就可能陷入互相迁就却谁也不先前进的局面。
2.3 重试机制设计不当
重试是提高可靠性的常见手段，但若重试间隔过短、条件判断过于宽松，或者缺少上限控制，就容易让系统在失败后迅速回到同一尝试路径。结果是错误被不断重复处理，进展却没有真正发生。
2.4 调度与优先级问题
调度策略不均衡、优先级设置不合理，或者多个实体在相同优先级下频繁抢占，都可能诱发活锁。特别是在存在协作和相互通知的场景中，调度结果会影响参与者的行为顺序，进而改变系统是否能够持续推进。
3 典型场景
3.1 多线程并发控制
在多线程环境里，活锁常常出现在共享资源访问、同步协作和冲突解决过程中。线程并没有被完全阻塞，而是不断重试、让出或重新检查条件，导致整体进展极慢。
3.1.1 自旋与让步
某些线程会采用自旋等待或短暂让步的方式来争取资源。如果多个线程同时采取相似策略，就可能在“我先让一下”和“你先来吧”的循环中反复切换，始终没有线程真正进入临界区。
3.1.2 锁竞争下的反复重试
在高竞争场景中，线程可能先尝试获取锁，失败后立即释放其他已持有资源，再次尝试进入。若所有线程都以相同方式行动，锁竞争就会演变成持续失败、持续重试的循环。
3.2 分布式系统交互
分布式系统中，各节点之间通过消息、协商和状态同步来达成一致。若协议缺乏明确终止条件，或者双方都在等待对方先改变状态，就容易出现循环性的协商失败。
3.2.1 节点间协商失败
在协商资源分配、主从切换或状态同步时，如果多个节点都不断回避冲突并重新发起协商，系统可能长期停留在“准备就绪但尚未达成”的阶段，看似活跃，实则没有收敛。
3.2.2 消息重发与冲突消解
消息传递过程中，重复发送、重复确认和冲突消解策略若设计不当，可能让双方持续进入同一处理路径。消息虽然不停流动，但冲突始终未被真正解决。
3.3 网络与通信协议
通信协议中常见退避、重传、握手等机制，它们用于提高可靠性，却也可能因为逻辑不稳而触发活锁。尤其在双方策略高度对称时，问题更容易出现。
3.3.1 拥塞控制中的反复退避
网络拥塞控制往往通过退避来减少冲突，但若多个发送方同步退避、同步恢复，就会形成反复波动的模式。发送端持续调整节奏，却始终无法稳定进入有效传输状态。
3.3.2 握手流程中的循环等待
在某些握手协议里，双方都期待对方先完成特定步骤。如果每次检测到冲突就重新开始，流程可能陷入不断重启的循环，始终无法完成建立连接。
4 识别与诊断
4.1 观察系统行为
诊断活锁时，最直观的线索往往来自运行状态。系统可能一直很“忙”，但任务完成率却极低，动作数量多，产出结果少。
4.1.1 CPU占用与活跃度异常
活锁环境中，CPU 占用可能保持较高水平，线程状态也经常处于运行或可运行状态。然而，这种高活跃度并不对应有效进展，反而常说明程序在循环处理同一类事件。
4.1.2 任务长时间无完成
如果某些任务持续存在响应、不断重试，却迟迟没有完成，便应怀疑是否发生活锁。尤其当任务日志显示大量相似步骤重复出现时，这种迹象更为明显。
4.2 日志与监控分析
日志和监控数据往往能揭示系统内部的反复行为。通过观察状态转换、失败率和重试模式，可以判断系统是否陷入了没有终点的循环。
4.2.1 重试次数异常增多
当同一操作的失败重试次数显著增加，而成功率长期偏低时，说明系统可能在重复执行同一流程。若重试之间没有引入新的状态变化，活锁风险就会升高。
4.2.2 状态切换频繁但无结果
若监控中看到多个状态在短时间内频繁往返切换，却始终没有进入完成态，这通常是活锁的重要信号。状态变化越密集，越需要检查其是否只是“表面推进”。
4.3 与性能问题的区分
活锁与一般性能下降有时外观相似，都会表现为响应变慢或资源消耗升高。但性能问题通常还能产生一定结果，只是效率不佳；活锁则更接近“持续消耗却几乎没有有效产出”。区分二者有助于选择正确的排查方向。
5 解决思路
5.1 引入随机退避
在冲突高发场景中，加入随机化退避可以打破参与者动作同步的问题。不同的等待时间有助于错开竞争窗口，减少大家同时重试、同时失败的概率。
5.2 调整优先级与调度策略
通过优化调度顺序、设置更合理的优先级或引入公平性约束，可以降低系统长期处于相同竞争模式的可能。更稳定的调度通常能帮助某一方先获得推进机会，从而打破循环。
5.3 减少不必要的让步
让步机制虽然能缓解冲突，但若使用过度，就容易造成双方持续后退。适当减少撤销、回避和重复确认动作，往往有助于减少互相抵消的情况。
5.4 使用公平锁或仲裁机制
公平锁、令牌机制或集中仲裁器能够明确资源获取顺序，避免参与者长期围绕同一资源反复竞争。只要规则足够清晰，系统就更容易从反复试探转向实际推进。
5.5 降低冲突概率
减少共享点、缩小竞争范围，是降低活锁风险的有效方式。冲突越少，参与者就越不需要依赖频繁的让步与重试。
5.5.1 拆分临界区
将较大的临界区拆分为更小的操作单元，可以缩短资源占用时间，也能减少多个执行单元同时碰撞的机会。这样既能提升并行度，也能缓和竞争强度。
5.5.2 细化资源粒度
把粗粒度资源拆成多个更细的部分，有助于降低单点争用。资源粒度越细，冲突往往越局部，系统越不容易因为某个共享点而反复回绕。
6 预防方法
6.1 设计稳定的并发协议
在协议设计阶段就应明确状态转换条件、终止条件和冲突处理方式。一个稳定的协议应当保证在一定条件下能够收敛，而不是允许参与者长期围绕同一状态打转。
6.2 限制无穷重试
任何重试策略都应设置合理上限，避免错误条件下无限循环。若多次失败后仍未恢复，系统应转入降级、报警或人工介入路径，而不是继续机械重复。
6.3 增加超时与失败回退
超时机制能够防止流程无限等待，失败回退则可在重试无效时切换到备用方案。通过这两类设计，可以在卡住之前主动跳出循环，避免局部问题拖累整体进展。
6.4 引入状态一致性检查
在关键步骤加入状态校验，有助于确认当前操作是否真的带来了有效变化。若发现状态来回摆动但无累计收益，就可以及时中止流程并调整策略。
6.5 压测与并发测试
通过压力测试、竞争测试和高并发场景模拟，可以更早暴露潜在活锁。此类测试能帮助开发者观察系统在极端条件下是否会出现反复重试、持续让步或协商失败。
7 工程实践中的相关问题
7.1 锁与无锁编程中的活锁风险
锁机制容易因争用而出现反复等待，无锁编程则可能因 CAS 失败、重试过密或版本冲突导致活锁。两类方案各有优势，但都需要配套的冲突控制与退避策略。
7.2 线程池与任务调度中的间接影响
当线程池中的任务彼此依赖，或调度策略让相关任务反复占用同一批执行资源时，也可能间接形成活锁。此时问题不一定出在任务本身，而可能出在任务编排方式。
7.3 重试风暴与级联退避
在大规模系统中，如果一个环节失败后触发大量同步重试，可能引发“重试风暴”。各组件若又采用相同的退避节奏，就会把局部冲突放大为级联性的循环失效。
7.4 幽默化现象与“假忙碌”描述
在工程交流中，活锁常被形容为“大家都很忙，但谁也没干成活”“系统在认真摸鱼”之类的说法。这类表达带有一定幽默感，便于快速传达问题特征，也能帮助团队直观理解程序的“假忙碌”状态。