CountDownLatch在订单判定中不直接取消订单，而是协调库存、支付、风控等并行校验任务的同步等待：初始化计数器为3，各服务完成校验后调用countDown()，主线程通过await(5, SECONDS)阻塞等待全部完成或超时；返回后结合AtomicBoolean等共享状态判断是否触发取消，确保高并发下判定高效且资源安全。
Java中用CountDownLatch实现电商订单超时自动取消的并行判定，核心不是靠它“取消订单”，而是利用其同步等待特性，协调多个异步检查任务（如库存、支付、风控等）的完成，并在全部检查结束或超时后统一决策是否取消订单。
CountDownLatch在订单判定中的真实角色
CountDownLatch本身不执行业务逻辑，也不直接触发取消操作。它像一个“计数门栓”：初始化时设为需等待的任务数（比如3个校验服务），每个服务校验完调用countDown()，主线程调用await(timeout, unit)阻塞等待所有完成或超时。一旦await返回，就能根据是否超时、各任务结果，决定下一步动作。
典型并行判定流程设计
下单后启动多个独立校验任务（库存是否充足、用户信用是否达标、地址是否有效），它们并行执行、互不影响：
- 创建CountDownLatch latch = new CountDownLatch(3)
- 提交3个异步任务到线程池，每个任务执行完校验后调用latch.countDown()
- 主线程调用latch.await(5, TimeUnit.SECONDS)，最多等5秒
- 若返回true → 所有校验已完成，汇总结果；若返回false → 超时，视为校验失败，触发取消
配合共享状态完成取消决策
仅靠CountDownLatch无法知道每个任务成功与否，需配合线程安全的共享结构记录结果：
立即学习“Java免费学习笔记（深入）”；
- 用AtomicBoolean allPassed = new AtomicBoolean(true)初始设为true，任一校验失败就设为false
- 或用ConcurrentHashMap
results 存各任务ID与结果 - await返回后，检查共享状态：若超时或存在失败项，调用订单取消服务（如发MQ消息、更新订单状态为“已取消”）
注意点与常见误区
CountDownLatch是一次性组件，不可重置；超时判定是“整体耗时超限”，不是单个任务超时；真正的订单取消应由独立服务异步执行，避免阻塞判定主线程：
- 不要在countDown()里直接调用取消逻辑——破坏并行性
- 避免在await期间持有数据库连接或分布式锁——易引发资源泄漏
- 生产环境建议结合Redis过期监听或定时任务兜底，防止JVM重启导致漏处理
