Java并发处理指南：CopyOnWriteArraySet使用详解

CopyOnWriteArraySet 是为“读多写少、迭代频繁、容忍短暂最终一致性”场景量身定制的线程安全集合，其核心优势在于读操作无锁、迭代器免锁且不抛并发修改异常，但代价是每次写操作（add/remove）都要复制整个底层数组，导致O(n)时间复杂度和显著内存开销——10万元素下一次添加可能触发几MB分配与拷贝，GC压力陡增；遍历时调用remove看似生效实则无效，易引发“假删除”或逻辑错误；它不适用于高写入频率、强实时一致性或需排序的场景，此时ConcurrentHashMap.keySet()、synchronizedSet或ConcurrentSkipListSet往往是更优选择——理解其设计边界，才能避免在高并发系统中因误用而埋下性能与语义隐患。

CopyOnWriteArraySet 写操作为什么慢得明显

因为每次 add、remove 都会复制整个底层数组 —— 它底层用的是 CopyOnWriteArrayList，而数组复制是 O(n) 操作。写少读多的场景才适合它，比如监听器列表、配置白名单缓存。

• 10 万元素时一次 add 可能触发几 MB 内存分配 + 数组拷贝，GC 压力肉眼可见
• 写操作期间不阻塞读，但新写入的内容对「正在执行的迭代器」不可见（迭代器基于快照）
• 如果写操作频繁（比如每秒上百次），不如换成 ConcurrentHashMap + keySet() 模拟 Set 语义

遍历时修改导致的“假删除”或“漏遍历”

用增强 for 或 iterator() 遍历 CopyOnWriteArraySet 时，调用 remove 不会抛 ConcurrentModificationException，但也不会影响当前迭代器——因为迭代器在构造时已持有数组快照。

• 现象：循环中写 set.remove(x)，看似删了，但下一轮迭代仍可能看到 x（其实是旧快照里的残留）
• 正确做法：不要边遍历边改；真要过滤，先收集待删项，遍历完再批量 removeAll
• 错误示例：

  for (String s : set) { if (s.startsWith("tmp")) set.remove(s); }

  → 这段代码逻辑上想删，实际无效

和 Collections.synchronizedSet 的关键区别在哪

两者都线程安全，但锁粒度和行为完全不同：Collections.synchronizedSet 是方法级 synchronized，读写都串行；CopyOnWriteArraySet 读无锁、写独占、迭代免锁。

• 读多写少且迭代频繁 → 选 CopyOnWriteArraySet
• 写稍多、或需强一致性（比如要求迭代器立刻反映最新状态）→ 选 synchronizedSet 或 ConcurrentSkipListSet
• size() 在 CopyOnWriteArraySet 中返回的是快照大小，但写操作刚完成时，它未必等于「当前真实元素数」（因写操作尚未完成复制）——不过这个误差仅存在于写操作执行中的极短窗口，通常可忽略

初始化时传入 ArrayList 为什么可能丢数据

CopyOnWriteArraySet(Collection) 构造函数内部会调用 addAll，而 addAll 对传入集合逐个 add —— 如果源集合本身含重复元素，会被自动去重；但如果源集合是未排序的 ArrayList，且你依赖插入顺序做后续处理，那要注意：它底层转成数组后不再维护原始顺序语义（虽然巧合下常一致，但不保证）。

• 常见误用：new CopyOnWriteArraySet(Arrays.asList("a", "b", "a")) → 结果只有 2 个元素，不是 3 个
• 若必须保序且去重，先用 LinkedHashSet 做预处理：new CopyOnWriteArraySet(new LinkedHashSet(list))
• 别指望它替代 TreeSet：不支持排序，也不实现 NavigableSet

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~