活锁是线程或goroutine处于RUNNABLE状态、CPU持续高占用但任务原地打转；因无延迟忙等待、互相响应式退让或确定性重试导致无限循环，需用随机退避、最大重试限制和条件等待来解决。
活锁是什么，为什么它会让CPU飙到100%
活锁不是死锁，它不会报 fatal error: all goroutines are asleep - deadlock!，而是所有 goroutine 都在“忙等”——反复尝试获取资源、失败、重试、再失败。没有线程真正阻塞，但也没有一个能推进任务，CPU 持续满载做无用功。
典型场景是多个 goroutine 同时争抢分布式锁或本地互斥资源时，未引入退避机制，导致无限重试循环。比如用 for { if tryLock() { break } } 而不加 time.Sleep 或随机抖动，就是活锁温床。
用带退避的重试代替裸循环重试
裸 for 循环重试是活锁头号诱因。必须让每次失败后主动让出时间片，并逐步拉长等待间隔。
- 永远不要写
for { if lock() { break } } - 改用指数退避（Exponential Backoff）：初始 1ms，每次翻倍，上限设为 100ms 左右
- 加上随机抖动（Jitter），避免所有 goroutine 同步重试：用
time.Sleep(time.Duration(rand.Int63n(int64(base)))) - 务必限制最大重试次数，防止无限卡住
示例片段：
func acquireWithBackoff(mu *sync.Mutex, maxRetries int) bool {
base := time.Millisecond
for i := 0; i < maxRetries; i++ {
if mu.TryLock() {
return true
}
jitter := time.Duration(rand.Int63n(int64(base)))
time.Sleep(base + jitter)
base *= 2 // 指数增长
}
return false
}TryLock + channel 组合比纯忙等更可控
sync.Mutex 本身不支持 TryLock，但你可以用 sync.RWMutex 的读锁模拟，或更稳妥地借助 select + time.After 实现带超时的非阻塞尝试。
- 用
select配合time.After替代轮询，避免 CPU 空转 - 把锁请求封装成 channel 操作，配合
default分支实现“尝试一次，不等”语义 - 对高竞争资源，考虑用分片锁（shard lock）或原子计数器（
sync/atomic）替代全局锁
例如：
ch := make(chan struct{}, 1)
go func() {
mu.Lock()
defer mu.Unlock()
ch <- struct{}{}
}()
select {
case <-ch:
// 成功拿到锁
case <-time.After(10 * time.Millisecond):
// 超时放弃，避免死等
}监控活锁迹象比修复更早一步
活锁难调试，因为程序不崩溃、日志没报错、pprof 看起来像“全是调度热点”。要靠指标提前识别：
- 观察
runtime.NumGoroutine()是否稳定，但runtime.ReadMemStats().NumGC却异常低——说明没做实际工作，只是空转 - 用
go tool pprof抓 profile，如果火焰图里大量堆栈集中在runtime.futex、runtime.ossemacquire或time.now，基本就是活锁信号 - 检查 goroutine 堆栈：
curl http://localhost:6060/debug/pprof/goroutine?debug=2，若看到成百上千个 goroutine 停留在同一段重试逻辑里，就是活锁实锤
真正棘手的不是写错重试逻辑，而是把“锁竞争”误判为“业务慢”，结果在错误方向上加缓存、扩容、拆服务，越优化越卡。活锁必须从重试模型和资源争用设计层根除，而不是靠加机器扛。
