Java高效生成重复列表技巧

Java 的 Collections.nCopies 是一个高效但易被误解的工具：它不真正创建 n 个独立对象，而是返回一个共享同一值的不可变列表视图，因此直接调用 add、remove 或 set 会抛出 UnsupportedOperationException；正确用法是在只读场景（如参数传递、Stream 源）中直接使用以节省内存，而需修改时必须显式包装为 new ArrayList(Collections.nCopies(n, value))；尤其注意它绝不适用于可变对象（如 new HashMap()），否则所有元素将指向同一实例引发隐蔽 bug，同时 null 元素完全合法可靠——理解其“逻辑复用”本质，而非“物理复制”，才是安全高效使用它的关键。

为什么 Collections.nCopies 生成的列表不能直接 add/remove

因为 Collections.nCopies 返回的是不可变视图——它不创建新对象，只是用一个固定值“假装”有 n 个副本。底层共享同一份数据，所以调用 add()、remove() 或 set() 会立刻抛出 UnsupportedOperationException。

常见错误现象：Exception in thread "main" java.lang.UnsupportedOperationException，尤其在你把它当作普通 ArrayList 接着操作时。

• 如果真需要可修改的重复列表，必须显式拷贝：用 new ArrayList(Collections.nCopies(n, value))
• 只读场景（比如传参、校验、Stream 源）可以直接用，省内存又快
• 注意：即使你用 Arrays.asList() 包一层，也改不了它的不可变性——它和 nCopies 一样是 unmodifiable

用 Collections.nCopies 初始化 List 的正确写法

它不是构造器，而是工厂方法，返回 List，但类型擦除后容易误判。最安全的初始化方式是带泛型声明或明确接收类型。

使用场景：批量填充默认值、测试数据构造、函数式编程中作为固定输入源。

• ✅ 推荐：List list = new ArrayList(Collections.nCopies(3, "abc"));
• ⚠️ 危险：List list = Collections.nCopies(3, "abc"); —— 看似没问题，但后续任何修改都失败
• ⚠️ 隐患：var list = Collections.nCopies(3, "abc"); —— var 推导为不可变 ImmutableCollections.ListN，IDE 可能不报错，运行时才翻车

Collections.nCopies 和 Arrays.fill / 循环初始化比有什么区别

核心差异在语义和开销：nCopies 是逻辑复用，Arrays.fill 是内存填充，循环是逐个新建对象。

性能影响明显：对不可变对象（如 String、Integer 常量），nCopies 几乎零分配；对可变对象（如 new HashMap()），它会重复引用同一个实例——这往往是 bug 而非特性。

• ✅ 安全用于：基本类型包装类、字符串、枚举等不可变值
• ❌ 绝对避免用于：自定义对象、new ArrayList()、任何需要独立副本的可变类型
• 对比 Arrays.fill：后者只适用于数组，且要求目标数组已存在；nCopies 返回的是 List，更契合 Collection API 流程

当元素是 null 时，Collections.nCopies 行为是否可靠

完全可靠。null 是合法元素值，Collections.nCopies(5, null) 会生成含 5 个 null 的列表，既不会 NPE，也不影响不可变性约束。

但要注意：如果你后续用 new ArrayList(...) 包装它，得到的就是含 5 个 null 引用的可修改列表，可以正常 set(0, "x") 或 add(...)。

• 常见误判：以为 null 会导致方法抛异常——实际不会
• 兼容性无问题：Java 5+ 全版本支持 null 元素
• 真正要小心的是下游代码是否允许 null，比如某些集合工具类（如 Guava 的 ImmutableList 构造）会拒绝 null，但 nCopies 本身不管这个

以上就是《Java高效生成重复列表技巧》的详细内容，更多关于的资料请关注golang学习网公众号！