Java9List.of方法使用详解

Java 9 引入的 List.of()、Set.of() 和 Map.of() 并非传统设计模式中的工厂方法，而是接口内置的静态工厂方法，它们通过 JDK 高度优化的私有不可变实现类（如 List2、SetN）直接构造轻量、安全、语义清晰的小型常量集合，在创建时即严格校验 null 和重复元素，兼顾性能、安全与可读性；但其适用场景明确受限于元素数量、不可变性及序列化兼容性，是为配置数据、枚举集合等静态场景量身打造的现代 Java 集合构建利器。

Java 9 的 List.of()、Set.of() 和 Map.of() 不是传统设计模式意义上的“工厂方法模式”，而是接口中定义的静态工厂方法——它们不涉及继承体系或子类重写，也不返回抽象类型由子类决定具体实现，而是由 JDK 内部根据参数数量和类型，直接选择最合适的不可变集合实现类并返回实例。

静态工厂方法 vs 工厂方法模式

工厂方法模式（GoF）强调“定义创建对象的接口，让子类决定实例化哪一个类”，核心是延迟到子类决定具体类型。而 List.of() 是 List 接口自身提供的 static 方法，调用时立即执行、无多态分发、不依赖继承结构。它属于“静态工厂”（Static Factory），是 Java 中一种常见的对象构造惯用法，而非 GoF 模式。

关键区别：

• 没有抽象工厂类或工厂接口，也无需实现类去“实现创建逻辑”
• 不面向扩展开放，而是面向使用优化：JDK 自行控制内部实现（如 ImmutableCollections.List12、ImmutableCollections.SetN 等专用紧凑类）
• 调用者只看到接口类型（List），实际返回的是私有静态嵌套类，完全封装细节

实例生成过程：从调用到对象落地

以 List.of("a", "b") 为例，整个流程如下：

• JVM 根据传入 2 个 String 参数，匹配到 List.of(E, E) 重载方法（非 varargs 版本）
• 该方法内部直接 new 出一个轻量级不可变实现类（如 ImmutableCollections.List2），该类字段固定为两个元素，无动态数组、无扩容逻辑
• 构造时即校验：若任一参数为 null，立即抛出 NullPointerException
• 返回的对象实现了 List 接口，但所有修改方法（add、set、clear 等）均抛 UnsupportedOperationException

类似地，Set.of(1, 2, 3) 会去重并检查重复键；Map.of("k1", "v1", "k2", "v2") 要求键唯一，否则抛 IllegalArgumentException。

为什么不用 new？优势在哪

静态工厂方法绕过 public 构造器，带来三方面实质收益：

• 可控返回类型：可返回任意实现了接口的具体类（包括私有类），甚至对相同参数返回不同实现（如 0 元素 → ImmutableCollections.List0，1 元素 → List1，2–10 元素 → List2…List10，超 10 个才用 varargs + 数组封装的 ListN）
• 无需重复构造开销：比如 List.of() 返回的是共享的空列表单例（ImmutableCollections.EMPTY_LIST），不是每次 new
• 语义清晰 + 安全前置：方法名即意图（of 表示“由这些元素构成”），且在构造阶段就拒绝 null、重复键等非法输入，错误更早暴露

注意事项：不是万能构造器

这些静态工厂方法有明确适用边界：

• 仅适用于小型、已知元素的集合（Map.of() 最多支持 10 个键值对，更多需用 Map.ofEntries() 或 Map.copyOf()）
• 不支持 null 元素（List/Set）或 null 键/值（Map），这是强制契约，不是可选配置
• 返回对象不可序列化兼容性受限：虽然多数实现了 Serializable，但其内部类非 public，跨 JDK 版本反序列化可能失败，不建议持久化存储
• 无法替代需要动态变更的集合场景——它天生为“常量数据”而生，比如配置项、枚举标签、HTTP 状态码映射等

本篇关于《Java9List.of方法使用详解》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！