该用 Collections.synchronizedSet 时：低并发、需快速包装已有 HashSet、允许 null；该用 ConcurrentHashMap.newKeySet() 时：高吞吐多线程读写、禁止 null、需弱一致性迭代器，但注意其不可序列化、非 SortedSet、反射兼容性差。
什么时候该用 Collections.synchronizedSet 而不是 ConcurrentHashMap.newKeySet()
二者都返回线程安全的 Set，但底层机制完全不同：Collections.synchronizedSet 是对普通 HashSet 加了对象锁，所有方法串行执行；ConcurrentHashMap.newKeySet() 底层是并发哈希表的 key 视图，支持真正的多线程并发读写。
如果你的场景是「低并发、简单同步、已有 HashSet 实例需快速包装」，选 Collections.synchronizedSet 更轻量；如果是「高吞吐、多线程频繁 add/remove/contains」，必须用 ConcurrentHashMap.newKeySet()，否则会成为性能瓶颈。
-
Collections.synchronizedSet(new HashSet())的迭代器不是线程安全的，遍历时必须手动同步外部synchronized(set) -
ConcurrentHashMap.newKeySet()的迭代器弱一致性，不抛ConcurrentModificationException，但可能看不到最新写入的元素 - 前者允许
null元素（取决于底层Set），后者不允许null（抛NullPointerException）
ConcurrentHashMap.newKeySet() 的常见误用：当成普通 Set 直接传参就完事？
它返回的是 KeySetView，不是独立的 Set 实现。很多开发者以为「线程安全 = 可以随便塞进任何方法」，结果在某些框架或工具类中出问题。
- 不能直接用于需要
TreeSet语义（如排序）的场景，它不实现SortedSet - 不能传给期望可序列化的 API（
KeySetView默认不可序列化，JDK 17+ 才部分支持） - 如果用作 Spring Bean 或配置属性，注意它的类型是
ConcurrentHashMap.KeySetView，不是Set接口的通用实现，反射或泛型推导可能失败 - 它不支持
removeIf的强一致性语义：操作期间其他线程插入的元素可能被漏删
Collections.synchronizedSet 的锁粒度陷阱
它把整个 Set 当成一个锁对象，所有方法（add、remove、contains、size）都竞争同一把锁。哪怕只是查一个元素，也会阻塞其他线程的写操作。
立即学习“Java免费学习笔记（深入）”；
- 高并发下，
contains频率远高于add时，这种粗粒度锁会严重拖慢读性能 - 和
ConcurrentHashMap的分段锁或 CAS 操作比，吞吐量通常低 5–10 倍（实测 JDK 11+） - 若你只想要线程安全的
contains+addIfAbsent，其实更推荐ConcurrentHashMap.putIfAbsent(key, dummyValue)+keySet()，比包装HashSet更高效
兼容性与 JDK 版本要注意什么
ConcurrentHashMap.newKeySet() 是 JDK 8 引入的，但早期版本行为有差异；Collections.synchronizedSet 虽然古老，但某些老项目里仍可能遇到它包装的 TreeSet 导致死锁风险。
- JDK 8–10：
newKeySet()返回的KeySetView不支持stream()并行操作（会退化为顺序流） - JDK 11+：支持并行流，但注意其
spliterator()是弱一致性的，不能保证覆盖全部当前元素 -
Collections.synchronizedSet(new TreeSet(comparator))在多线程下add可能触发ConcurrentModificationException（因为TreeSet内部结构修改未被同步封装） - Android（API newKeySet()，只能用
Collections.synchronizedSet或第三方库如CopyOnWriteArraySet（适合读多写少）
真正难的不是选哪个 API，而是意识到「线程安全的 Set」这个需求背后往往藏着更具体的访问模式——是读多写少？是否需要迭代一致性？要不要 null 支持？不拆开看这些，光套 API 很容易在线上压测时突然卡住。
