多层购物车对账采用CyclicBarrier分轮淘洗：第一轮查支付状态，第二轮核验优惠一致性，第三轮汇总结果；每轮动态设parties，原子计数器仅协调屏障，屏障回调只读结果并触发下轮或标记完成。
在多层购物车结算交互中，用 CyclicBarrier 结合原子计数器精准控制第三方支付对账的“多轮淘洗”，关键不是堆砌并发工具，而是把“阶段同步”和“状态归集”拆清楚——每轮淘洗对应一次屏障触发，每笔子订单的对账结果必须隔离写入、统一读取。
明确淘洗轮次与屏障结构
多层购物车（如主订单含多个子订单，子订单又关联优惠券、积分、分账通道）导致对账需分层验证。不能等全部子订单查完再统一比对，而应按逻辑层级划分淘洗轮次：
- 第一轮：所有子订单调用第三方支付接口查询实时状态（异步并行发起），各自将响应结果（成功/失败/待确认）写入线程安全槽位
- 第二轮：基于第一轮结果，触发优惠核销一致性校验（例如积分是否被重复扣减），仅对状态为“待确认”的子订单重试或打标
- 第三轮：汇总各子订单最终状态，生成对账摘要（如“3笔成功、1笔冲正、0笔异常”），写入全局对账结果容器
每轮使用同一个 CyclicBarrier 实例，parties 设为参与该轮淘洗的子订单数（动态计算，非固定值）；轮次间通过 barrier 自动重置衔接，无需重建对象。
原子计数器只用于协调，不存业务数据
AtomicInteger 或 AtomicIntegerArray 不用来存对账结果，而是辅助屏障管理：
- 用 AtomicIntegerArray resultsSlot = new AtomicIntegerArray(numSubOrders) 存各子订单本轮淘洗结果码（如 0=未开始，1=成功，2=失败，3=需重试）
- 用 AtomicInteger activeCount = new AtomicInteger() 在每轮开始前记录实际参与子订单数（过滤掉已终态、跳过淘洗的订单），传给新 barrier 构造（
new CyclicBarrier(activeCount.get(), ...)） - 禁止用 AtomicInteger 做“累加对账金额”——金额必须由 barrier 回调里遍历 resultsSlot + 对应的 volatile double[] 金额数组完成，避免竞态
屏障回调中做唯一可信汇总
barrierAction 是整套机制的“可信根”，必须满足三个条件：
- 只读不写业务状态：回调内只从 resultsSlot 和预分配的 volatile Object[] 中读取各子订单结果，不做任何远程调用或锁等待
- 写入终局结果一次：将本轮汇总结论（如“子订单ID-12345状态升级为冲正”）写入 AtomicReference<Map<String, String>> 或 ConcurrentHashMap，供后续轮次或审计线程消费
- 触发下一轮条件判断：检查本轮汇总中是否有“需重试”项，若有，则构造新 barrier 启动第二轮淘洗；否则标记该主订单淘洗完成
防中断与异常传播设计
支付对账场景中网络抖动常见，await() 超时必须可控：
- 每轮 barrier.await(30, TimeUnit.SECONDS)，超时抛 BrokenBarrierException 后，主动调用 barrier.reset() 清理残态，避免卡死
- 子线程内捕获 InterruptedException 后，立即设置自身槽位为“中断态”（如 resultsSlot.set(idx, -1)），确保回调仍能感知缺失方
- 回调中发现任一槽位为 -1 或超时未写入，不跳过，而是将该子订单标记为“人工介入”，进入差异库，不阻塞其他子订单进入下一轮
不复杂但容易忽略
