CountDownLatch 不支持分布式场景，因其仅限单JVM内有效；应改用Redis+Lua原子脚本或ZooKeeper/etcd等分布式协调服务实现跨节点计数与通知。
CountDownLatch 本身不支持分布式场景
直接用 CountDownLatch 等待远程节点信号是行不通的。它只在单 JVM 进程内有效，所有 countDown() 和 await() 调用必须发生在同一个内存空间里。如果你把多个服务实例（比如部署在不同机器上的 Spring Boot 应用）当成“节点”，它们各自持有一个 CountDownLatch 实例，彼此完全隔离——一个节点调用 countDown() 对其他节点的 await() 零影响。
替代方案：用 Redis + Lua 或分布式锁协调计数
真正可行的做法是把“计数器”放到共享存储中，常见选择是 Redis。你需要一个带原子性的递减+检查操作，避免竞态条件。推荐用 Redis 的 DECR 配合 GET，或更稳妥地封装成 Lua 脚本：
if redis.call("GET", KEYS[1]) == ARGV[1] then
local cnt = tonumber(redis.call("DECR", KEYS[1]))
if cnt <p>Java 侧配合 <code>RedisTemplate</code> 调用该脚本，每个节点完成任务后执行一次，返回 1 表示已满足阈值、可以唤醒等待方。</p>
- 等待方不能傻等
await()，得轮询或监听 Redis 的发布订阅（如PUBLISH / SUBSCRIBE） - 必须设超时机制，否则某个节点宕机可能导致永久阻塞
- 注意 Redis key 的生命周期：用
EXPIRE设置合理过期时间，防止残留计数干扰下一轮
ZooKeeper 或 etcd 更适合强一致性要求
如果业务对顺序、节点存活感知、严格一次性有要求（比如金融类汇总），CountDownLatch 的语义在分布式下根本无法对齐，这时应换用协调服务：
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- ZooKeeper 可用临时顺序节点 + Watcher 实现“所有子节点创建完毕”事件
- etcd 的
Watch接口配合前缀监听，能实时感知到指定路径下节点数量达标 - 两者都天然支持会话失效自动清理，比纯 Redis 方案更鲁棒
但代价是引入新组件、增加运维复杂度，小规模或容忍短暂不一致的场景没必要上。
Spring Cloud Alibaba 的 ApplicationReadyEvent 不解决跨进程问题
有人试图用 Spring 的生命周期事件（如 ApplicationReadyEvent）+ 全局 Map 记录节点就绪状态，这依然卡死在单 JVM。即使你用 Redis 存 Map，也得自己实现广播、去重、幂等、超时清理——本质上又回到了上面说的 Redis 方案，只是多绕了一层。
真正的难点从来不在“怎么减一”，而在于“谁来确认这一减是合法且最终一致的”。跨网络的每一次通信都可能失败、重复、延迟，CountDownLatch 的线性模型在这里彻底失效。别试图给它套分布式外壳，直接换语义匹配的工具。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
