如何利用Collections.nCopies()高效创建内存节省的不可变重复元素视图？

本文共计837个文字，预计阅读时间需要4分钟。

Collections.nCopies(n, element) 是 Java 中一个轻量级工具方法，它并不真正创建包含 n 个重复元素的集合，而是返回一个 n 个元素的不可变列表视图。底层只保存一个元素引用和数量，内存占用恒定（O(1)），特别适合需要逻辑上重复多次但无需实际复制数据的场景。

它返回的是什么？

返回一个实现了 List 接口的私有静态内部类（CopiesList），具备以下关键特性：

• 支持 get(index)、size()、contains()、indexOf() 等只读操作
• 所有 get(i) 都直接返回同一份元素引用（即传入的 element）
• 不支持修改操作：调用 add()、set()、remove() 等会立即抛出 UnsupportedOperationException
• 不是深拷贝：若元素是可变对象，所有“位置”看到的是同一个实例

典型适用场景

当你需要“看起来像有多个相同元素”，但又不想浪费空间或时间去复制时：

• 初始化固定大小的只读配置列表（如 Collections.nCopies(1000, "DEFAULT")）
• 作为 Arrays.asList(...) 的替代，避免创建中间数组
• 在函数式编程中配合 Stream.generate() 或集合操作做占位填充（例如补零、补空字符串）
• 单元测试中快速构造预期的重复结果（如断言返回了 5 个相同的 DTO）

使用时要注意什么？

几个容易踩坑的关键点：

• 不可变性是硬限制：不能把它传给期望可变 List 的 API（比如某些老框架的 setter），否则运行时报错
• 引用共享需谨慎：如果传入的是可变对象（如 new ArrayList<>()），所有索引都指向同一个实例，list.get(0).add("x") 会影响“所有位置”——这不是 bug，是设计使然
• 不适用于泛型类型擦除敏感场景：返回的 List 类型是 List<T>，但编译期无法推断具体 T；必要时显式指定类型（如 Collections.<String>nCopies(3, "a")）
• 不要用于大 n + 频繁随机访问：虽然内存省，但每次 get() 是 O(1) 计算，无实际数组跳转开销；不过若 n 极大（如亿级）且反复遍历，仍建议用真正数组或流式生成

一个实用小技巧：安全地转成可变副本

如果后续确实需要修改，可以低成本转为真实可变 List：

// 创建虚拟视图（零内存复制）
List<String> view = Collections.nCopies(100000, "init");
// 按需转为可变 ArrayList（仅当真要改时才分配内存）
List<String> mutable = new ArrayList<>(view);