活锁现象怎么一眼认出来
程序没卡死，线程都在跑，CPU 占用正常，但业务逻辑就是不往前走——比如两个线程反复回退重试、互相谦让资源，Thread.getState() 一直显示 RUNNABLE，日志里却不断刷出“重试第 1 次”“重试第 2 次”……这不是死锁，是典型的活锁。
常见于基于乐观锁的重试逻辑，比如用 AtomicInteger.compareAndSet() 或 JPA 的 @Version 字段更新失败后立刻重试，又没加延迟或退避机制。
为什么固定间隔重试反而加剧活锁
多个线程在相同节奏下竞争同一资源，就像两辆车在窄桥两端同时进退：你退我进、我退你进，永远错不开。固定间隔（比如每次 Thread.sleep(10)）会让它们很快重新对齐节奏，冲突概率不降反升。
关键点在于：活锁不是并发量太大导致的，而是重试行为本身形成了可预测的同步模式。
立即学习“Java免费学习笔记（深入）”；
- 固定间隔 → 线程重试时间点高度一致 → 冲突复现率高
- 随机化 + 指数退避 → 打散重试时机 → 大幅降低重复碰撞概率
- 注意：
Random实例不能在多线程间共享且未加锁，否则可能产生相似随机序列（尤其用默认种子时）
如何安全实现随机化重试间隔
核心是两点：用线程本地的 Random，叠加基础退避 + 随机扰动。别直接用 Math.random()，它底层共享一个 Random 实例，高并发下随机性坍塌。
long baseDelay = (long) Math.pow(2, attempt); // 指数增长 Random localRandom = ThreadLocal.withInitial(() -> new Random()).get(); long jitter = localRandom.nextLong(baseDelay / 2); // 最大扰动为一半 Thread.sleep(baseDelay + jitter);
说明：
-
attempt从 0 开始计数，第一次重试基线是 1ms，第二次是 2ms，依此类推 -
jitter是正向扰动，避免出现 0 延迟（否则退化成无延迟重试） - 最大等待时间控制在 500ms 内较稳妥，超时应抛异常或降级，而不是无限重试
- 如果用 Spring Retry，配置
RandomBackOffPolicy时务必确认random属性设为true（默认是 false）
哪些场景不适合纯随机重试
不是所有重试都适合加随机延迟。比如实时性要求极高的内部服务调用，或已知失败是瞬时网络抖动（持续时间
- 数据库主键冲突、唯一索引违例：这类错误不可重试，加随机没意义，应直接返回或转换逻辑
- 下游服务明确返回
429 Too Many Requests：该按响应头Retry-After执行，而非自行随机 - 分布式锁续期失败：需结合租约时间和心跳机制，单纯随机 sleep 可能导致锁提前释放
真正需要随机化重试的，是那些「大概率能成功、但需错开时间窗口」的竞争型操作，比如库存扣减、积分变更、状态机跃迁。
活锁最难调试，因为不报错、不阻塞、不超时，只悄悄吞掉业务进展。随机化只是表象，背后是对重试时机与系统节奏的重新建模——漏掉这一点，哪怕用了 Random，也还是在原地打转。
