Collections.nCopies用于创建包含n个相同元素的不可变列表，所有元素共享同一对象引用，适用于生成默认值、占位符或测试数据等场景。
Collections.nCopies
方法提供了一种非常简洁的方式，来创建一个固定大小、内容完全相同的不可变列表。简单来说，它能让你生成一个包含指定数量相同元素的列表，而且这个列表一旦生成就不能再添加、删除或修改元素。在我看来，它更像是一个“模板列表”或者“占位符列表”的快速生成器。
解决方案
Collections.nCopies(int n, T o)
方法是
java.util.Collections
工具类中的一个静态方法，它的核心作用就是生成一个由
n
个相同对象
o
组成的列表。
具体来说：
参数解释：
n
：表示你希望列表中包含多少个
o
的副本。如果
n
为 0，它会返回一个空的不可变列表。但如果
n
是负数，你就会得到一个
IllegalArgumentException
。
o
：就是你想要重复填充到列表中的那个对象。这个对象可以是任何类型，包括
null
。
核心特性：
不可变性（Immutability）：这是
nCopies
最重要的一个特点。它返回的列表是一个特殊的、不可修改的列表。这意味着你不能调用
add()
、
remove()
或
set()
方法来改变列表的结构或内容。任何尝试都会导致
UnsupportedOperationException
。这一点在使用时必须牢记，它和我们平时用的
ArrayList
行为大相径庭。固定大小（Fixed Size）：列表的大小在创建时就确定了，就是你传入的
n
。浅拷贝（Shallow Copy）：这里有个非常关键的细节，也是很多开发者容易踩坑的地方。
nCopies
并不是创建了
n
个
o
的全新实例。相反，列表中的所有元素都只是对 同一个
o
对象的引用。这意味着，如果
o
是一个可变对象（比如
StringBuilder
或者你自己定义的一个类实例），并且你在创建列表之后修改了
o
的内部状态，那么列表中的所有元素都会“同步”地反映出这个修改。
何时使用：
当你需要一个包含大量相同默认值或占位符的列表时。当你明确需要一个不可变的列表，且所有元素都相同。在某些测试场景下，快速生成大量相同数据的集合。在某些特定场景下，它可能比循环填充
ArrayList
更高效，因为它背后有专门的优化实现。
让我用一段代码来直观地展示一下：
import java.util.Collections;import java.util.List;import java.util.ArrayList; // 引入ArrayList以便对比public class NCopiesApplication { public static void main(String[] args) { // 示例1: 创建一个包含5个null的列表 List
Collections.nCopies
与
ArrayList
循环填充有何本质区别？我该如何选择？
在我看来，这两种方式虽然都能生成包含多个元素的列表，但它们的哲学和应用场景是截然不同的。
核心区别点：
可变性与不可变性：
Collections.nCopies
生成的是一个不可变的列表。一旦创建，你无法改变它的元素数量，也无法替换其中的元素。这就像是刻在石头上的契约，一旦写好就不能再改。
ArrayList
循环填充（例如，
for (int i = 0; i < n; i++) { list.add(obj); }
）生成的是一个可变的列表。你可以随意添加、删除、修改元素，它的行为更灵活，更像是一个可以随意增减内容的活页夹。
内存与性能：
nCopies
内部实现通常非常高效。它不需要真的创建
n
个独立的列表节点或者数组元素来存储
n
个引用，而是通过一个特殊的内部类来“模拟”这个行为。对于非常大的
n
值，这可以节省大量的内存开销。
ArrayList
循环填充，特别是当每次循环都
new
一个新对象时，会实实在在地创建
n
个对象实例（或者
n
个引用），并分配
ArrayList
内部数组的空间。虽然现代 JVM 优化很厉害，但在极端情况下，
nCopies
在内存和初始化速度上可能有优势。
元素引用行为：
nCopies
是浅拷贝。列表中的所有元素都指向内存中的同一个对象。这意味着如果这个对象是可变的，你修改了它，列表中的所有“副本”都会同时改变。
ArrayList
循环填充，如果你每次都
add(new Object())
，那么列表中的每个元素都是一个独立的新对象。如果你
add(sameObject)
，那行为就和
nCopies
类似了，但列表本身依然是可变的。
我该如何选择？
这取决于你的具体需求和对“相同”的定义：
选择
Collections.nCopies
的场景：
你需要一个不可变的列表：比如作为某个方法的返回结果，你不希望调用方修改这个列表。所有元素确实需要是同一个对象：比如，你正在初始化一个包含多个“空”状态或“默认”状态的列表，而这些状态都指向同一个共享的常量对象。作为占位符：比如在 UI 渲染前，你快速生成一个包含多个
null
或特定占位符的列表，稍后异步填充真实数据，但在此期间列表结构不能变。性能考量（针对大量相同、不可变元素）：当你需要成千上万个完全相同的字符串或数字列表时，
nCopies
可能是更优解。
选择
ArrayList
循环填充（或
Stream.generate
）的场景：
你需要一个可变的列表：这是最常见的情况，你后续需要添加、删除或修改列表中的元素。你需要
n
个独立的、可变的对象实例：例如，你需要创建 10 个独立的
User
对象，每个对象都有自己的生命周期和状态，即使它们初始值相同。这时，你通常会用
for (int i = 0; i < 10; i++) { list.add(new User()); }
或者
Stream.generate(User::new).limit(10).collect(Collectors.toList());
。你对列表的结构和内容有复杂的初始化逻辑：循环可以让你在每次添加元素时执行更复杂的逻辑。
总结一下，如果你的需求是“给我一个包含
n
个相同东西的、不能被修改的列表”，那么
nCopies
是你的首选。如果你的需求是“给我一个可以灵活操作的列表，里面先放
n
个东西”，那么
ArrayList
循环填充或者 Stream API 会更合适。
使用
Collections.nCopies
时需要注意哪些“坑”？
经验告诉我，任何看似简洁的工具，背后往往都有一些需要理解的细节，否则就容易掉进“坑”里。
Collections.nCopies
也不例外。
可变对象的“浅拷贝”陷阱：
这绝对是新手最容易犯错的地方。我前面已经提到了，
nCopies
列表中的所有元素都指向同一个对象。如果你复制的是一个可变对象（比如
Date
、
StringBuilder
、自定义的
POJO
），然后你在列表创建后修改了这个“原始”对象，那么列表中的 所有 元素都会跟着一起变。这往往不是你期望的行为。例子：如果你
List list = Collections.nCopies(3, new MyObject("initial"));
，然后你
list.get(0).setName("changed");
，实际上你是在修改
new MyObject("initial")
这个唯一的实例，所以
list.get(1)
和
list.get(2)
也会看到这个改变。避免方法：如果你需要
n
个独立的、可变的实例，请不要使用
nCopies
。老老实实地用
for
循环或者
Stream.generate(() -> new MyObject()).limit(n).collect(Collectors.toList())
来创建独立的实例。
列表的不可变性导致
UnsupportedOperationException
：
这是
nCopies
的设计初衷，但如果你习惯了
ArrayList
的灵活，可能会不小心尝试去修改这个列表。常见操作：
list.add(...)
、
list.remove(...)
、
list.set(...)
都会抛出
UnsupportedOperationException
。解决方法：如果你确实需要一个可变的列表，但又想用
nCopies
快速初始化，你可以这样做：
new ArrayList(Collections.nCopies(n, obj))
。这样，你会得到一个由
nCopies
初始化的、但本身是可变的
ArrayList
。不过，请注意，即使这样转换了，如果你复制的是可变对象，浅拷贝的问题依然存在。
对
null
元素的处理：
nCopies
完全支持复制
null
。这本身不是一个“坑”，但如果你不清楚，可能会对结果感到意外。一个包含
n
个
null
的列表在很多场景下都很有用，比如作为占位符或者初始化一个稀疏数组的结构。例子：
List emptySlots = Collections.nCopies(10, null);
这是一个完全有效的操作。
固定大小，无法动态调整：
虽然和不可变性是同一回事，但值得单独提一下。如果你需要一个列表，在创建后可能还需要根据业务逻辑增减元素，那么
nCopies
返回的列表就无法满足需求。它就是个死板的固定大小列表。
理解这些特性和潜在的“坑”，能帮助我们更准确、更安全地使用
Collections.nCopies
。它是一个强大的工具，但前提是你得知道它的脾气。
Collections.nCopies
在实际项目中有哪些典型应用场景？
在实际开发中，
Collections.nCopies
往往出现在一些比较特定的场景下，它能让代码变得更简洁、意图更明确。
初始化固定大小的默认值列表：
场景：比如你在开发一个游戏，需要初始化一个 3×3 的棋盘，每个格子默认都是“空”状态。或者一个库存管理系统，需要一个表示 10 个货架的列表，每个货架初始状态都是“未占用”。代码示例：
// 假设 Cell.EMPTY 是一个不可变的常量对象List board = Collections.nCopies(9, Cell.EMPTY);// 或者初始化一个容量为10，所有位置都是0的列表List zeroFilledList = Collections.nCopies(10, 0);
我的思考：这种场景下，我们通常不希望这些默认值被意外修改，而且它们确实是同一个“空”或“0”的概念，用
nCopies
就非常贴切。
作为占位符或填充物：
场景：在前端或后端数据处理中，有时我们需要一个列表来表示某个固定数量的 UI 元素，或者在数据不足时填充一些默认的“加载中”或“空”状态。
代码示例：
// UI层，显示5个“加载中”的占位卡片，直到真实数据返回List loadingCards = Collections.nCopies(5, "Loading...");// 在处理分页数据时，如果返回的数据不足一页，用null填充到满页// 注意：这里可能需要先转成ArrayList再操作List data = fetchData(page, size);if (data.size() < size) { List paddedData = new ArrayList(data); paddedData.addAll(Collections.nCopies(size - data.size(), null)); return paddedData;}return data;
我的思考：这种“填充”或者“占位”的语义，
nCopies
表达得非常清晰。尤其是在异步操作中，先给用户一个视觉反馈，等数据来了再替换。
测试数据生成：
场景：在编写单元测试或集成测试时，我们经常需要模拟大量相同的数据来测试某个逻辑的性能或正确性。
代码示例：
// 假设 User 是一个不可变类 (e.g., record or final fields)User defaultUser = new User("test", "password");List testUsers = Collections.nCopies(100, defaultUser);// 或者测试一个方法处理大量相同字符串的情况List largeStringList = Collections.nCopies(10000, "sample_data");
我的思考：这里需要特别注意，如果
User
是可变的，那么这种方式就不合适了，因为所有
testUsers
都指向同一个
defaultUser
实例。但如果
User
是一个不可变的数据类，那么这是一种非常高效且安全的测试数据生成方式。
与
Stream.concat
结合使用：
场景：当你需要将一个现有的流与一些重复的元素流连接起来时。
代码示例：
import java.util.stream.Stream;import java.util.Collections;import java.util.List;import java.util.stream.Collectors;Stream existingItems = Stream.of("ItemA", "ItemB");Stream fillerItems = Collections.nCopies(3, "Filler").stream();List combinedList = Stream.concat(existingItems, fillerItems) .collect(Collectors.toList());System.out.println("合并列表: " + combinedList); // 输出: [ItemA, ItemB, Filler, Filler, Filler]
我的思考：这展示了
nCopies
如何无缝地融入到 Java 8+ 的 Stream API 中，提供了一种灵活的流构建方式。
总的来说，
Collections.nCopies
是一个专门用于创建固定大小、内容统一的不可变列表的工具。它的价值在于简洁和高效，但前提是你需要清楚它的“浅拷贝”特性和不可变性约束。一旦掌握了这些，它就能在特定场景下成为你代码库中的一把利器。
以上就是Collections.nCopies方法的应用的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/69284.html
微信扫一扫 
支付宝扫一扫 
