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 <= 0 then return 1 end
end
return 0
Java 侧配合 RedisTemplate 调用该脚本，每个节点完成任务后执行一次，返回 1 表示已满足阈值、可以唤醒等待方。
- 等待方不能傻等
await()，得轮询或监听 Redis 的发布订阅（如PUBLISH / SUBSCRIBE） - 必须设超时机制，否则某个节点宕机可能导致永久阻塞
- 注意 Redis key 的生命周期：用
EXPIRE设置合理过期时间，防止残留计数干扰下一轮
ZooKeeper 或 etcd 更适合强一致性要求
如果业务对顺序、节点存活感知、严格一次性有要求（比如金融类汇总），CountDownLatch 的语义在分布式下根本无法对齐，这时应换用协调服务：
将后端 Java 接口文档转换为前端 TypeScript 类型定义（interface / type）。输入：飞书文档、Spring Boot 接口文档、Swagger/OpenAPI、手写 API 文档等。输出：包含请求参数与响应结果的 .md 文件，含完整 JSDoc 注释。触发关键词：Java 转 TS、接口转换、生成前端类型、接口文档转 TypeScript、DTO/VO/BO 转 interface、后端文档转前端类型、生成接口类型、类型定义生成。
立即学习“Java免费学习笔记（深入）”；
- ZooKeeper 可用临时顺序节点 + Watcher 实现“所有子节点创建完毕”事件
- etcd 的
Watch接口配合前缀监听，能实时感知到指定路径下节点数量达标 - 两者都天然支持会话失效自动清理，比纯 Redis 方案更鲁棒
但代价是引入新组件、增加运维复杂度，小规模或容忍短暂不一致的场景没必要上。
Spring Cloud Alibaba 的 ApplicationReadyEvent 不解决跨进程问题
有人试图用 Spring 的生命周期事件（如 ApplicationReadyEvent）+ 全局 Map 记录节点就绪状态，这依然卡死在单 JVM。即使你用 Redis 存 Map，也得自己实现广播、去重、幂等、超时清理——本质上又回到了上面说的 Redis 方案，只是多绕了一层。
真正的难点从来不在“怎么减一”，而在于“谁来确认这一减是合法且最终一致的”。跨网络的每一次通信都可能失败、重复、延迟，CountDownLatch 的线性模型在这里彻底失效。别试图给它套分布式外壳，直接换语义匹配的工具。
