Java 17中5种高效复制List的方法对比（附性能测试）

Java 17中5种高效复制List的方法对比（附性能测试）

在日常开发中，我们经常需要复制一个列表。这看似简单的操作，背后却隐藏着性能、内存、线程安全乃至代码可读性的多重考量。尤其是在处理大数据量、高并发或对响应时间有严格要求的场景下，选择不当的复制方法，可能会成为系统性能的隐形瓶颈。很多开发者习惯性地使用new ArrayList<>(originalList)，这确实在大多数情况下没问题，但你是否考虑过，当列表元素是复杂对象时，这真的是“复制”吗？或者，当你需要一个完全隔离的、不可变的副本时，哪种方式最优雅？

本文将跳出简单的API罗列，深入对比Java 17环境下五种主流的List复制策略。我们不仅会通过实际的微基准测试（Microbenchmark）来量化它们的性能差异，更会剖析其内在原理、内存行为以及各自最匹配的应用场景。无论你是正在优化一个核心服务的性能，还是仅仅想写出更健壮、更地道的代码，相信这篇深度分析都能给你带来新的启发。

1. 理解“复制”：浅拷贝与深拷贝的基石

在深入方法之前，我们必须厘清一个核心概念：对于包含对象的List，绝大多数复制方法进行的都是“浅拷贝”（Shallow Copy）。

这意味着，新列表（副本）持有的是对原列表中相同对象引用的拷贝，而非对象本身的新实例。两个列表是独立的集合对象，但它们内部的元素指向内存中的同一批对象。

// 示例：浅拷贝的直观体现 List<Person> originalList = new ArrayList<>(); originalList.add(new Person("Alice")); List<Person> copiedList = new ArrayList<>(originalList); // 浅拷贝 // 修改副本列表中第一个Person对象的属性 copiedList.get(0).setName("Bob"); System.out.println(originalList.get(0).getName()); // 输出：Bob // 原列表中的对象也被修改了！

为什么重要？如果你期望得到一个完全独立、修改副本不影响原始数据的列表，那么仅进行集合层面的拷贝是不够的，你需要“深拷贝”（Deep Copy）。深拷贝需要递归地复制每个对象，对于复杂对象图，这可能非常昂贵且复杂。

注意：本文重点讨论的是List容器本身的复制性能。当你的业务逻辑要求元素对象也完全独立时，你需要额外实现元素的深拷贝逻辑，这通常会成为性能的主要开销，远超容器复制本身。

下表概括了浅拷贝与深拷贝在List复制语境下的关键区别：

明确了这一点后，我们就可以专注于评估各种浅拷贝方法的效率了。接下来的性能测试，均基于元素为简单对象（如String、Integer）的列表，以排除深拷贝带来的干扰，纯粹比较容器操作的性能。

2. 五种复制方法深度解析与性能实测

我们将使用JMH (Java Microbenchmark Harness)进行基准测试。JMH是Oracle官方推荐的Java微基准测试框架，它能有效避免JVM的JIT编译、垃圾回收等因素对测试结果造成的干扰。测试环境为Java 17，列表元素为Integer，测试不同列表大小（10， 10，000， 1，000，000）下的表现。

2.1new ArrayList<>(Collection): 经典构造器

这是最直接、最被广泛认知的方法。通过ArrayList的拷贝构造器创建新实例。

原理浅析：ArrayList的拷贝构造器内部会调用Arrays.copyOf（对于集合是Collection.toArray()的结果），这是一个原生系统级别的数组拷贝操作，效率极高。

// ArrayList源码片段 (Java 17) public ArrayList(Collection<? extends E> c) { Object[] a = c.toArray(); if ((size = a.length) != 0) { if (c.getClass() == ArrayList.class) { elementData = a; } else { elementData = Arrays.copyOf(a, size, Object[].class); } } else { elementData = EMPTY_ELEMENTDATA; } }

性能测试结果摘要（单位：操作/毫秒，越高越好）：

注：Collections.copy的测试包含了初始化目标列表（Collections.nCopies）的开销，这在实际使用中是不可或缺的步骤，因此其数值显著低于其他方法。

优点：

• 代码极其简洁，意图明确。
• 性能卓越，在大多数场景下都是最快或接近最快的选择。
• 生成的列表是完全可变的。

缺点：

• 就是标准的浅拷贝。
• 如果源集合不是基于随机访问的（如LinkedList），toArray()调用可能会带来额外遍历开销。

适用场景：绝大多数需要可变列表副本的情况。它是默认的首选方案。

2.2List.copyOf(): 不可变副本的现代之选

Java 10引入的List.copyOf静态工厂方法，用于创建给定集合的不可修改的副本。

List<String> original = ...; List<String> immutableCopy = List.copyOf(original); // immutableCopy.add("new"); // 抛出 UnsupportedOperationException

原理与性能： 它的实现会检查输入集合是否已经是不可修改的List（并且是信任的），如果是，则可能直接返回输入本身或其内部数组的视图，避免拷贝。否则，它会将元素拷贝到一个新的内部数组中。因此，在源列表已经是不可变列表时，它可能达到O(1)的“复制”性能。在我们的测试中，由于源列表是ArrayList，它需要进行拷贝，性能略低于new ArrayList<>()，但差异在微秒级，对于绝大多数应用可忽略不计。

优点：

• 语义清晰：明确声明我需要一个不可变的副本。
• 潜在的零拷贝优化。
• 遵循不可变集合的最佳实践，有助于提高代码的健壮性。

缺点：

• 结果是不可变的，无法添加、删除或修改元素。

适用场景：当你需要传递一个列表，但希望确保接收方无法修改它时（例如作为方法的返回值或缓存键）。这是防御性编程和函数式风格的理想选择。

2.3addAll(Collection): 灵活但稍显冗长

先创建一个空列表，然后使用addAll方法添加所有元素。

List<String> copiedList = new ArrayList<>(); copiedList.addAll(originalList);

性能分析：addAll内部同样会调用toArray()和数组扩容/拷贝逻辑。其性能与new ArrayList<>(originalList)非常接近，但在小数据量时，由于多了一次方法调用和可能的空列表初始化检查，会稍慢一点点，如基准测试所示。

优点：

• 在需要向一个已存在的非空集合追加另一个集合时，这是唯一的选择。
• 逻辑清晰，分步操作。

缺点：

• 用于纯复制时，代码比构造器方式冗长。
• 性能略逊于拷贝构造器。

适用场景：

1. 合并多个集合时。
2. 目标列表已经存在且需要追加内容时。
3. 在一些需要显式分步操作的框架或模板代码中。

2.4Collections.copy(List dest, List src): 被误解的“高效”方法

这个方法常被误认为是高效的复制工具，但它有一个严格的前提：目标列表dest的大小必须至少等于源列表src的大小。

List<String> srcList = Arrays.asList("A", "B", "C"); List<String> destList = new ArrayList<>(Collections.nCopies(srcList.size(), null)); Collections.copy(destList, srcList);

性能陷阱： 从上表可以看出，它的性能表现是最差的。原因有二：

1. 初始化开销：你必须先准备一个大小合适且已填充（即使是null）的目标列表。Collections.nCopies本身会创建一个不可变列表，再用其构造ArrayList，这带来了额外开销。
2. 元素级赋值：Collections.copy内部使用迭代器遍历，并对目标列表的每个位置进行set操作，这比直接的数组内存拷贝（System.arraycopy）要慢。

优点：

• 可以将源列表内容覆盖式地复制到一个已存在且大小固定的列表的相应位置。

缺点：

• API笨拙，容易用错（IndexOutOfBoundsException）。
• 性能最低，不适用于常规的列表复制需求。

适用场景：极其有限。主要用于需要复用某个固定大小的列表对象，并将其内容整体替换为另一个等长列表内容的特定场景，例如在某些复用缓冲区的算法中。

2.5 Stream API (collect(Collectors.toList())): 函数式风格

使用Stream的collect操作来创建新列表。

List<String> copiedList = originalList.stream() .collect(Collectors.toList()); // 在Java 16+中，更推荐使用toList()，它返回一个不可变列表 List<String> immutableCopy = originalList.stream() .toList();

性能分析： Stream API带来了强大的表达能力和链式操作的可能性，但其抽象也带来了额外的开销（创建流对象、迭代器、收集器等）。我们的测试显示，在纯复制场景下，它的性能是几种方法中最慢的，尤其是数据量较大时，差距明显。

优点：

• 表达力强，易于在复制前后插入filter、map等中间操作。
• stream().toList()（Java 16+）是获取不可变副本的另一种清晰方式。

缺点：

• 性能开销最大，不适合对性能敏感的纯复制操作。
• 对于不熟悉函数式编程的开发者，可读性可能稍差。

适用场景：

• 需要在复制过程中同步进行数据转换、过滤或处理时。这时，Stream将多个操作合并为一次遍历，其综合效率可能反而高于先复制再单独遍历处理。
• 代码库整体采用函数式编程风格，以保持一致性。

3. 内存占用与垃圾回收影响分析

性能不仅仅是速度，内存使用效率同样关键，它直接影响GC的频率和停顿时间。

• new ArrayList<>()和addAll：会创建一个新的ArrayList对象及其底层数组。新数组的长度通常就是源列表的大小（ArrayList构造器）或经过计算（addAll可能会稍微扩容）。这是标准的内存开销。
• List.copyOf()：同样创建新数组。但如果源列表已经是不可变列表且数据可信，可能共享数据，内存占用最优。
• Collections.copy：需要预先分配一个大小完全匹配的目标列表，内存占用与new ArrayList<>()类似，但多了一个Collections.nCopies创建的临时不可变列表对象（很快会被回收）。
• Stream API：开销最大。除了最终的结果列表，在流水线执行过程中还会产生Stream对象、Spliterator、可能的中断操作容器以及收集器内部的中间状态对象。这些都会增加短生命周期对象的数量，给年轻代GC带来压力。

简单结论：从内存和GC角度，List.copyOf（在理想条件下）和new ArrayList<>()是更优的选择。在循环或高频调用的热路径中，应避免使用Stream API进行单纯的复制。

4. 实战场景选择指南与进阶技巧

了解了原理和性能后，如何选择？下面这个决策流程图可以帮你快速判断：

是否需要列表副本？ | ├── 需要【可变】副本 │ | │ ├── 纯复制，无其他处理 -> **首选 `new ArrayList<>(src)`** │ │ │ └── 需要向现有集合追加 -> **使用 `destList.addAll(srcList)`** │ └── 需要【不可变】副本 | ├── Java 10+， 明确需要不可变语义 -> **首选 `List.copyOf(src)`** │ └── Java 16+， 且可能在Stream链中 -> **使用 `srcList.stream().toList()`**

进阶技巧与避坑指南：

1. 并行流（Parallel Stream）复制是大忌：

   // 错误示范！性能极差！ List<String> badCopy = originalList.parallelStream().collect(Collectors.toList());

   对于toList()这种简单的归约操作，并行化的开销（线程拆分、结果合并）远大于收益，且会引入不必要的线程安全问题。

2. 复制List<List>等嵌套集合： 记住，这只是第一层容器的浅拷贝。内部的子列表仍然是共享的。

   List<List<String>> matrix = ...; List<List<String>> shallowCopy = new ArrayList<>(matrix); // 修改 shallowCopy.get(0).add("new") 会影响原始的 matrix.get(0)

3. 使用第三方库（如Hutool的BeanUtil.copyToList）： 这完全是另一种维度的工作。它用于不同类型对象间属性的拷贝（Bean映射），而不是List容器的复制。其性能开销主要来自反射和对象创建，比任何容器拷贝都要高几个数量级。切勿将其用于同类型对象的列表复制。

   // Hutool - 用于对象转换，非列表复制 List<SourceDTO> sourceList = ...; List<TargetVO> targetList = BeanUtil.copyToList(sourceList, TargetVO.class);

4. 针对LinkedList等非随机访问列表： 所有基于toArray()的方法（new ArrayList<>(),List.copyOf,addAll）都会先遍历LinkedList将其转换为数组。如果复制的目的就是为了随机访问，那么转换成ArrayList是合理的。如果仍需保留LinkedList特性，手动遍历创建新LinkedList可能更合适，但需测试性能。

最终，在我的大部分项目实践中，new ArrayList<>(originalList)因其简单、快速和清晰的语义，覆盖了90%以上的可变副本需求。而在设计API或返回内部数据时，List.copyOf()已成为我确保不可变性的标准工具。性能测试数据为我们提供了坚实的依据，但真正的选择，永远要结合具体的业务场景、代码上下文和可维护性要求来综合判断。