CyclicBarrier.reset() 是强制重置破损屏障的非线程安全方法，须在无等待线程且 isBroken() 为 true 时由单一协调线程调用；误用会导致 BrokenBarrierException 死循环。
CyclicBarrier.reset() 不是自动恢复开关，而是强制重建屏障的“重置键”。它只在屏障破损（BrokenBarrierException 抛出）后才真正需要，且必须确保没有线程正在 await() 中等待——否则会立即再次触发异常。
reset() 被误用的典型现象
常见错误是在线程还在阻塞时调用 reset()，比如主线程在子线程未完成前就执行重置，结果所有等待线程立刻收到 BrokenBarrierException，后续再调用 await() 仍抛该异常，形成死循环失败。
- 主线程调用
barrier.reset()时，至少一个子线程正卡在barrier.await() - 捕获到
BrokenBarrierException后仅打印日志，没检查barrier.isBroken()或调用reset() - 多个线程并发调用
reset()，但文档明确说明该方法不是线程安全的
阶段性失败时 reset() 的正确触发时机
reset() 应该只在确认所有参与线程已退出等待、且屏障处于破损状态后，由单一协调线程（如主线程或专用恢复线程）调用。关键判断依据是 barrier.isBroken() 返回 true，且无活跃等待线程。
- 在每个线程的
catch (BrokenBarrierException e)块中，先调用barrier.isBroken()确认状态 - 若为
true，可由第一个检测到的线程发起barrier.reset()（需加锁或用AtomicBoolean控制） - 重试前应清空上一轮残留状态（如共享缓存、临时文件），避免脏数据干扰下一阶段
带重试逻辑的 barrier.await() 封装示例
不要让业务线程裸调 await()，而应封装成带自恢复能力的调用：
private void awaitWithRetry(CyclicBarrier barrier, int maxRetries) throws InterruptedException {
int attempt = 0;
while (attempt < maxRetries) {
try {
barrier.await();
return; // 成功，退出
} catch (BrokenBarrierException e) {
if (barrier.isBroken()) {
barrier.reset(); // 仅在此处重置
attempt++;
if (attempt < maxRetries) {
Thread.sleep(100); // 避免忙等
}
}
}
}
throw new RuntimeException("Failed to await barrier after " + maxRetries + " retries");
}
注意：这个封装假设你控制所有参与线程的生命周期；如果某线程因异常提前退出，导致实际到达数永远小于 parties，重试也无效——这时必须检查线程启动逻辑是否完整。
最易被忽略的一点是：reset() 并不改变 parties 值，也无法修复因线程数不足造成的“假死锁”。它只负责把破损的屏障扳回可用状态，前提是下一轮真有足够数量的线程重新调用 await()。
