活锁是线程持续运行但业务无进展的状态，表现为反复trylock失败后主动让出并重试，如迎面行人不断侧身却无法错开；其根源在于对称退避逻辑导致负反馈循环，需通过随机退避、重试上限和使用jdk并发工具来破局。
活锁是什么：线程没卡死，但一直在“礼貌让路”
活锁不是死锁，线程始终在运行、CPU 占用可能很高，但业务逻辑毫无进展——典型表现是多个线程反复 tryLock() 失败后主动让出、重试、再让出，像两个迎面走路的人不停侧身却始终无法错开。
它常出现在基于“试探-回退”策略的并发控制中，比如手动实现的无锁队列、资源争抢时的退避逻辑、或过度依赖 Thread.yield() / Lock.tryLock(0, TimeUnit.NANOSECONDS) 的场景。
- 和死锁不同：所有线程都处于
RUNNABLE状态，jstack里看不到WAITING或BLOCKED，容易误判为“性能差”而非“逻辑僵住” - 触发条件隐蔽：往往只在高并发+特定调度顺序下复现，本地压测难稳定捕获
- 根本原因不是锁没释放，而是释放时机和重试逻辑形成负反馈循环
怎么确认是活锁：别只看线程状态
光看 jstack 输出不够。要抓三个信号：
- 线程堆栈高频重复出现同一段重试逻辑（比如反复调用
attemptTransfer()→backOff()→retry()） -
top -H显示对应线程 CPU 使用率持续 >80%，但业务指标（如 QPS、处理数）几乎为零 - 加入日志埋点后，发现某类操作的日志行以毫秒级频率刷屏，且参数/路径高度相似（例如连续打印
"Retrying transfer from A to B, attempt=127"）
这时候基本可以锁定：不是慢，是原地打转。
立即学习“Java免费学习笔记（深入）”；
破局关键：打破对称性与确定性退避
活锁本质是多个线程行为太“一致”。解决方案核心就两条：加扰动、设上限。
- 用随机退避时间替代固定休眠：
Thread.sleep(ThreadLocalRandom.current().nextLong(1, 10))，避免集体同步重试 - 限制最大重试次数，超限直接抛异常或降级（比如改用阻塞式
lock()）：if (retries++ > MAX_RETRY) throw new LivelockException(); - 避免纯响应式设计：不要写“对方释放我就立刻重试”，改成“我释放后等一个抖动窗口再检查对方状态”
- 优先使用 JDK 自带的并发工具：比如
StampedLock的乐观读、ConcurrentLinkedQueue的 CAS 操作，它们内部已规避常见活锁模式
真实踩坑点：你以为的“优雅”恰恰是导火索
很多活锁来自过度工程化的“礼貌”设计：
- 在
finally块里无条件调用lock.unlock()，但解锁前又去调用另一个可能失败的notifyAll()，导致解锁被延迟，下游线程反复tryLock()失败 - 用
ReentrantLock.tryLock(1, TimeUnit.MILLISECONDS)配合 while 循环，但超时值设得太小（如 1ms），在高负载下几乎必失败，退化成忙等 - 分布式场景下，把本地活锁逻辑照搬到 Redis 分布式锁里：多个客户端同时
GETSET失败→删 key→重试，网络延迟放大后形成集群级震荡
真正难的不是写出让线程“动起来”的代码，而是写出让线程“动对方向”的代码——活锁问题往往藏在你最想显得聪明的那几行退避逻辑里。
