Collections.singleton 返回复用的不可变单元素Set，高频创建或静态常量场景可省内存；但Java 9+优先用Set.of(x)，需可变时应选HashSet或自定义类。
Collections.singleton 是 Java 中一个轻量级工具方法，返回一个只含单个元素的不可变集合（类型为 Set）。它不创建新对象实例，而是复用内部静态单例（如 SingletonSet），因此在特定场景下确实能节省内存。但它的收益不是普适的，需结合使用模式判断。
适合 singleton 的典型内存节省场景
以下情况使用 Collections.singleton(x) 比新建 new HashSet(Collections.singletonList(x)) 或 Set.of(x)（Java 9+）更省空间或更合适：
-
高频创建单元素不可变 Set：例如在缓存键计算、过滤条件封装、策略路由中反复生成“仅匹配某一项”的集合。每次调用
singleton几乎不分配堆内存（仅返回引用），而HashSet至少需分配哈希表数组 + 节点对象（通常 3~5 个对象）。 -
大量长期存活的单元素 Set 实例：比如配置类中定义几十个
public static final Set。这些静态字段指向同一内部单例对象（内容相同时），避免重复对象膨胀堆内存。ALLOWED_ROLES = Collections.singleton("admin"); -
与 Collections.unmodifiableXXX 等组合使用且无需泛型擦除开销时：虽然
singleton返回的是Serializable且线程安全的不可变集，但比手写包装类或 Guava 的ImmutableSet.of(x)更轻——后者虽也优化，但仍有独立类加载和少量元数据开销。
不节省甚至反增开销的场景
盲目替换未必有益，尤其当语义或行为不匹配时：
-
需要可变集合或后续 add/remove：
singleton返回的是不可变集，强行转型或修改会抛UnsupportedOperationException，此时用new HashSet()是唯一选择，谈不上节省。 -
频繁调用但元素不同且生命周期极短：JVM 对象分配已高度优化（TLAB），新建一个轻量
HashSet（尤其空构造后 add）可能比方法调用+类型检查+引用返回的综合开销更低；此时内存差异微乎其微，GC 压力也不显著。 -
使用 Java 9+ 且只需不可变集：推荐优先用
Set.of(x)。它同样复用单例（对单元素情形），但 API 更现代、支持 null 检查、且编译期常量折叠更友好；Collections.singleton在这类场景无优势。
如何验证是否真省内存
不能只看理论，建议结合工具实测：
- 用 JOL（Java Object Layout）查看对象大小：
new HashSet(Arrays.asList(x))通常占 40~64 字节（取决于 JVM 版本和元素类型），而Collections.singleton(x)的实例本身是共享的，实际每个引用仅消耗 4/8 字节（指针大小）。 - 在压测中对比堆直方图（
jmap -histo）：若发现大量java.util.Collections$SingletonSet实例，说明未复用成功（可能是不同泛型参数导致类型擦除后无法共享）；理想情况应只有极少数该类实例。 - 注意逃逸分析：局部变量中的
singleton引用若未逃逸，JIT 可能完全消除对象访问，此时内存差异归零。
替代方案与取舍建议
根据 JDK 版本和需求权衡：
- JDK 9+：优先
Set.of(x)（不可变）、Set.ofEntries(Map.entry(k,v))（如需 Map 视角）；语义清晰，性能不输且更安全。 - 需兼容老 JDK 或必须用 Set 接口且接受不可变性：保留
Collections.singleton，它是经过充分验证的零成本抽象。 - 需要可变 + 单元素常见操作：考虑自定义轻量包装类（如只持一个字段 + 朴素 contains/add 实现），比通用集合更省内存。
