CountDownLatch 在分布式下完全失效，因其依赖单 JVM 内存状态和 AQS，无法跨节点共享实例，导致 await() 卡死、通知丢失、无超时重试等问题；应改用 Redis + Lua 实现分布式计数门闩，并保障幂等性、高可用与状态清理。
CountDownLatch 无法直接用于分布式环境，它只在单 JVM 进程内有效；所谓“分布式并行数据清洗”必须换掉 CountDownLatch，改用分布式协调服务或幂等任务调度机制。
为什么 CountDownLatch 在分布式下完全失效
CountDownLatch 是基于内存状态（state 字段）和 AQS 实现的同步工具，所有线程必须共享同一个实例对象 —— 这在单机多线程中成立，但在分布式场景下，不同节点的 JVM 彼此隔离，countDown() 和 await() 调用根本不会跨网络传播。
常见错误现象包括：
- 本地测试时一切正常，一上 K8s 或多台机器就卡死在
await()不返回 - 部分节点提前完成却无法通知其他节点，清洗结果不完整或重复执行
- 节点宕机后没有超时或重试逻辑，整个清洗流程永久阻塞
替代方案：用 Redis + Lua 实现分布式计数门闩
核心思路是把 CountDownLatch 的语义迁移到 Redis 中：用一个 key 存剩余计数，用原子操作 DECR 模拟 countDown()，用轮询 + GET + 超时判断模拟 await()。
实操建议：
- 使用
redisTemplate.opsForValue().decrement("clean:task:123:remain")替代countDown()，确保每次调用都递减且返回新值 - 初始化时用
SET clean:task:123:remain 50 NX EX 300设置初始值和 5 分钟过期，防止残留 key 阻塞后续任务 - 等待方不要死循环
GET，应配合指数退避（如 100ms → 200ms → 400ms）和最大重试次数（如 300 次 ≈ 5 分钟） - 务必检查返回值是否为
0，而不是null或负数 —— 负数说明有节点重复调用了decrement，需排查任务是否被重复触发
自定义线程池如何适配分布式清洗任务
线程池本身仍是单机资源，但它的职责要从“协调全局进度”转变为“高效消费本地分片任务”。关键在于任务分发与状态上报解耦。
使用场景示例：清洗 100 万用户数据，按 user_id % 64 分成 64 个分片，每个分片由一个节点领取并处理。
实操建议：
- 线程池拒绝策略设为
DiscardPolicy或CallerRunsPolicy，避免因突发流量打满队列导致任务堆积失联 - 每个清洗线程完成分片后，必须调用一次
redisTemplate.opsForValue().decrement(...)，且该操作应包裹在try-finally中，防止异常跳过计数更新 - 线程池
corePoolSize建议设为 CPU 核数 × 2（IO 密集型清洗），maxPoolSize不宜超过 32，否则 Redis 压力陡增 - 禁止在线程池中直接调用
await()类同步方法 —— 它们会阻塞工作线程，导致吞吐骤降
真正需要关注的三个隐藏复杂点
分布式清洗最难的从来不是“怎么并行”，而是“怎么确定真的并行完了”。这三点容易被忽略：
- Redis 单点故障：必须配置哨兵或 Cluster 模式，且客户端启用重试（如 Lettuce 的
RetryPolicy） - 任务幂等性：同一分片可能被多个节点同时拉取（网络延迟+无锁竞争），清洗逻辑必须支持重复执行不破坏结果
- 清理滞后：Redis key 过期后，若仍有节点在 decrement，会得到负值 —— 此时不能简单认为“已完成”，而要查 DB 或日志确认各分片真实状态
