怎么利用 continue 在多线程统计任务中过滤掉已由其他线程处理完毕的重复分片
在多线程分片统计任务里，经常遇到一个困惑：continue 这个关键字，真的能直接过滤掉已经被其他线程处理过的分片吗？其实不然。它本身只是一个流程控制指令，作用是跳过当前循环的剩余部分，直接进入下一次迭代。真正起到“过滤”作用的，是它前面那层**基于共享状态（比如原子标记、并发集合或者分布式锁）的判断逻辑**。换句话说，continue 是个执行层面的“配合动作”，你得先发现分片已被处理，然后才能用它来优雅地跳过，它本身并非并发控制机制。
用原子布尔数组标记分片状态
这个方法特别适合单机多线程、且分片总数固定、可以预先编号的场景，比如处理0到999号分片。具体怎么做呢？
首先，创建一个 AtomicBoolean[] processed = new AtomicBoolean[n] 数组，数组的每个位置对应一个分片，初始值都是 false。
- 当一个线程拿到分片编号
i后，第一步不是立刻干活，而是去调用processed[i].compareAndSet(false, true)。 - 如果这个方法返回
false，那就意味着已经有其他线程手更快，抢先一步把这个位置设置成了true。此时，这个分片已经被“认领”了，当前线程就该果断使用continue跳过它。 - 如果返回
true，恭喜，说明当前线程成功“抢”到了这个分片的处理权，接下来就可以安心执行具体的统计逻辑了。
用 ConcurrentHashMap 做去重登记
如果分片的标识不是简单的数字编号，而是字符串ID、复合键，甚至是动态生成的，那原子数组就不太适用了。这时候，ConcurrentHashMap 就该登场了。
可以声明一个 ConcurrentHashMap 来作为登记处。
- 对于每一个分片的唯一key（比如
"shard_20240515_user"），线程尝试调用claimed.putIfAbsent(key, true)。 - 如果这个方法的返回值是
null，说明key之前不存在，登记成功，线程获得处理权。 - 如果返回值不是
null（通常就是之前存入的true），那就表示这个分片已经被其他线程登记过了，当前线程应该执行continue跳过。 - 这里有个关键点要警惕：千万不要使用
containsKey检查再加put的组合，这两步操作不是原子的，在高并发下极有可能导致分片被重复处理。
避免常见陷阱
方案设计不好，continue 就形同虚设。下面这几个坑，可得留神：
陷阱一：依赖线程本地变量或普通boolean数组。 这是最典型的错误。多个线程之间的内存视图是隔离的，一个线程修改了普通变量，其他线程根本感知不到，continue 的判断依据完全是错的。
陷阱二：在锁外判断、锁内处理再用continue。 这种设计效率低下且不安全。线程在获取锁之前，分片状态可能已经改变，导致线程白白阻塞等待，拿到锁后才发现活已经被人干完了，只能无奈continue。更好的做法是尽量使用无锁的原子操作（如CAS）进行快速判别，抢到了再处理。
陷阱三：处理失败后忘记回滚标记。 如果线程在成功“认领”分片（将标记设为true或写入Map）后，处理过程中抛出了异常，那么这个分片就会永远处于“已处理”状态，数据就丢失了。因此，必须在异常处理逻辑中，记得调用 processed[i].set(false) 或 claimed.remove(key) 来回滚状态。
补充：分布式环境怎么办？
上面讨论的都是单机多线程的方案。一旦进入分布式环境，多个服务实例同时工作，内存级的共享状态就失效了。这时候，就需要请出外部协调服务：
- Redis：利用其 SET key value NX EX 30 命令尝试“占位”。设置成功则表示获得处理权，失败则说明分片已被其他实例处理，本实例应 continue。
- ZooKeeper：让所有实例在同一个ZNode下创建临时顺序节点。只有序号最小的节点（即最先创建的）去处理分片，其他实例监听并 continue。
- 数据库唯一约束：设计一张表，为分片ID字段建立唯一索引。处理前尝试INSERT一条记录，如果捕获到唯一键冲突异常，就说明分片已被处理，直接 continue 即可。
