应使用 Collections.singleton 而非 new HashSet 或 Arrays.asList：当需不可变单元素集合时，它内存零开销、线程安全；而后者分别存在哈希表冗余和可修改缺陷。
什么时候该用 Collections.singleton 而不是 new HashSet 或 Arrays.asList
当你只需要一个不可变的、只含单个元素的集合时，Collections.singleton 是最轻量且语义最明确的选择。它返回的是一个私有静态内部类实例，底层不分配额外数组或哈希表结构，内存占用几乎为零，且线程安全（因为不可变）。
常见错误是用 new HashSet(Arrays.asList(x)) 或 Arrays.asList(x) 代替——前者多出哈希表开销和扩容逻辑，后者返回的是可变的 ArrayList 子类（虽然长度固定，但允许 set(0, y) 修改），不符合“只读单例”的本意。
- 适用场景：作为方法返回值兜底（如找不到配置时返回
Collections.singleton(DEFAULT)）、Map 的 value（避免为单值新建集合容器）、Stream.collect 的默认 fallback - 不适用场景：需要后续 add/remove、要序列化（它没实现
Serializable，某些框架会报NotSerializableException）、需兼容 Android API - 注意：它返回的是
Set，不是List；若需要单元素列表，得用Collections.singletonList，二者行为不互通
Collections.singleton 返回的集合到底能不能修改
不能。任何试图修改的操作都会立刻抛出 UnsupportedOperationException。
这不是靠文档约定，而是实现在类内部直接 throw 异常：add、remove、clear、iterator().remove() 全部挂掉。连 toArray() 返回的数组也是新拷贝的，原集合状态完全隔离。
- 典型错误现象：
set.add(x)看似没报错？其实是调用了父类AbstractCollection.add，而它默认就 throw —— 所以一定报错，不会静默失败 - 性能影响：无迭代开销，
size()直接 return 1，contains(x)就是Objects.equals(this.element, x)，比 HashMap 查找还快 - 对比
Collections.unmodifiableSet(new HashSet(...))：后者仍需构造 HashSet 实例，内存和初始化成本高得多
为什么 Collections.singleton 不支持泛型推导（Java 7/8 下常报错）
因为它是普通静态方法，不是泛型类的静态工厂，编译器无法从上下文自动推断类型参数，尤其在方法调用链中容易丢失类型信息。
比如 processSet(Collections.singleton("a"))，如果 processSet 参数是 Set<string></string>，Java 7/8 可能推成 Set<object></object>，导致后续 stream().map(...) 编译失败。
- 解决办法：显式指定类型参数，写成
Collections.<string>singleton("a")</string> - Java 10+ 局部变量类型推导（
var s = Collections.singleton("a")）能缓解，但传参时仍建议显式 - 别依赖 IDE 自动补全的「推导」——它有时会补错，尤其是嵌套泛型场景（如
Map<k set>></k>中塞 singleton）
替代方案选哪个：singleton / singletonList / Set.of()（Java 9+）
Java 9 引入的 Set.of() 和 List.of() 是更现代的替代，但行为有关键差异。
Set.of(x) 也返回不可变 Set，但它是空实现（无字段），且支持 null 检查（传 null 直接抛 NullPointerException）；而 Collections.singleton(null) 是合法的，返回一个含 null 元素的 Set。
- 如果项目已用 Java 9+ 且不需要 null 元素，优先用
Set.of(x)：它更短、更通用（支持多元素）、序列化友好（实现了Serializable） - 如果必须支持 null，或需兼容 Java 8 及以下，只能用
Collections.singleton -
Collections.singletonList和List.of(x)同理，但注意List.of在 Java 14+ 才支持 null，之前版本传 null 会炸
真正容易被忽略的是序列化兼容性——Collections.singleton 的实例在跨 JVM 版本反序列化时可能失败，尤其涉及不同 JDK 厂商（如 OpenJDK vs Zulu）时，它的私有类名和字段布局不是公开契约。真要持久化，先转成 Arrays.asList(x) 再序列化，或者用 JSON。
