CyclicBarrier 的核心是 parties 与 generation 协同：parties 是每轮动态倒数的参与人数指标，count 减至 0 时触发放行与重置；generation 是轮次标识，通过引用变更隔离各轮等待状态，确保“等齐再走”可靠可重复。
初学者理解 CyclicBarrier，关键不是背概念，而是看清 parties 和 generation 怎么配合让“等齐再走”这件事既可靠又可重复。
parties 是本轮“人数指标”，不是全局常量
它只对当前这一轮有效，代表“这轮还差几个人才齐”。每次构造时传入的数值（比如 new CyclicBarrier(3)），只是初始化第一轮的 count 值。之后每调用一次 await()，count 就减 1。当 count 减到 0，说明本轮到齐了——但此时 parties 本身没变，变的是内部的 count 字段。它不是一成不变的门槛，而是一个动态倒数的计分牌。
- 线程 A 调用 await() → count 从 3 变成 2
- 线程 B 调用 await() → count 从 2 变成 1
- 线程 C 调用 await() → count 从 1 变成 0，触发放行 + 重置
generation 是“轮次身份证”，隔离上下两轮状态
如果没有 generation，上一轮被 signalAll 唤醒的线程，可能在下一轮还没开始等待时就误收到通知，导致提前“以为齐了”。generation 就是给每一轮打一个唯一标记：第一轮是 gen-1，第二轮是 gen-2……每个线程 await 前都会检查自己等的是否是当前 generation；唤醒时也只通知当前 generation 的等待者。它不存数字，而是一个对象引用（new Generation()），靠引用变化来区分轮次。
- count == 0 时，先执行 barrierAction，再调用 nextGeneration()
- nextGeneration() 会新建一个 Generation 实例，并把 count 重设回 parties 值
- 所有正在 await() 的线程，都带着对当前 generation 的引用进入等待
两者协作的真实流程：一次“到齐”的完整闭环
parties 定义目标，generation 管理生命周期。它们共同确保：每一轮的等待、判断、放行、重置，彼此不串场。
立即学习“Java免费学习笔记（深入）”；
- 线程调用 await() → 拿锁 → 检查当前 generation 是否 broken → count--
- 若 count != 0 → 把自己挂到当前 generation 的 condition 队列里等待
- 若 count == 0 → 执行 barrierAction → 创建新 generation → signalAll 当前队列 → 重置 count = parties
- 被唤醒的线程醒来后，会发现 generation 已变，自动进入下一轮逻辑
本质上，parties 是“量”，generation 是“序”——一个管齐不齐，一个管是不是同一拨人。不复杂，但容易忽略。
