Java 9 的 List.of()、Set.of() 和 Map.of() 是接口定义的静态工厂方法，非 GoF 工厂方法模式；它们直接返回 JDK 内部优化的不可变实现类，构造时校验 null 和重复元素，适用于小型常量集合。
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") 为例，整个流程如下：
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
立即学习“Java免费学习笔记（深入）”；
- JVM 根据传入 2 个
String参数，匹配到List.of(E, E)重载方法（非 varargs 版本） - 该方法内部直接 new 出一个轻量级不可变实现类（如
ImmutableCollections.List2<string></string>），该类字段固定为两个元素，无动态数组、无扩容逻辑 - 构造时即校验：若任一参数为
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 状态码映射等
