countdownlatch 的核心作用是同步等待而非控制线程执行顺序：主线程 await() 阻塞，直到所有子线程调用 countdown() 将计数器减至 0；它仅确保“全部完成”，不干预启动时机与执行速度。
理解 CountDownLatch 的核心作用
CountDownLatch 不是用来“保证线程执行顺序”的，而是用来做**同步等待**：主线程调用 await() 阻塞，直到所有参与任务的子线程调用 countDown() 将计数器减到 0。它不控制线程何时启动、执行多快，只管“是否全部完成”。在并行审计场景中，它的价值在于——让主流程能精准知道“所有审计项已跑完”，避免提前汇总或漏统计。
为什么必须搭配自定义线程工厂
默认线程池（如 Executors.newFixedThreadPool）创建的线程名无意义（如 pool-1-thread-1），一旦审计任务出错或超时，日志里根本分不清是哪个审计维度（比如“用户余额校验”还是“订单状态一致性”）卡住了。自定义线程工厂能为每个线程赋予**业务语义化名称**，例如：
audit-balance-check-1
audit-order-consistency-2
这样配合 JStack、Arthas 或日志 traceId，可瞬间定位问题线程归属的审计模块。
实战代码关键点（精简可复用）
以下是一个生产可用的组合写法，重点在命名、异常兜底和资源释放：
- 用 ThreadFactoryBuilder（Guava）或手写实现，确保线程名含审计类型 + 序号
- 每个审计子任务用 try-finally 包裹，必须在 finally 里调用 countDown()，防止因异常跳过导致 await 永久阻塞
- 主线程 await 时设超时（如 30 秒），超时后主动中断未完成线程，并记录未完成项清单
- 线程池 submit 任务时，不要直接传 Runnable，而应封装成带审计上下文的 Callable，便于结果收集与错误归因
对齐不是靠“同时开始”，而是靠“统一出口”
所谓“绝对对齐”，本质是结果层面的一致性：所有审计维度在同一时间窗口内完成采集、不遗漏、不重复、可追溯。CountDownLatch + 自定义线程工厂只是支撑手段。真正保障对齐还需：
- 所有审计任务共享同一份时间戳（如 Instant.now() 在主线程生成，透传给各子任务）
- 审计数据源使用相同快照（如数据库加读一致性事务，或缓存统一打点版本号）
- CountDownLatch await 返回后，再统一触发校验逻辑（如比对各维度的总数、checksum、异常率阈值）
