Javadoc of Collector展示了如何将流的元素收集到新的List中。是否有一个单行程序将结果添加到现有的ArrayList中？
注意：nosid's answer显示如何使用forEachOrdered()添加到现有集合。这是一种用于改变现有集合的有用且有效的技术。我的回答解决了为什么你不应该使用Collector来改变现有的集合。
简短的答案是，至少，不是一般，你不应该使用Collector来修改现有的集合。
原因是收集器旨在支持并行性，即使是非线程安全的集合也是如此。他们这样做的方法是让每个线程独立地在其自己的中间结果集合上运行。每个线程获得自己的集合的方式是调用每次都返回一个新集合所需的Collector.supplier()。
然后，这些中间结果集合再次以线程限制的方式合并，直到存在单个结果集合。这是collect()操作的最终结果。
来自Balder和assylias的几个回答建议使用Collectors.toCollection()，然后通过一个返回现有列表而不是新列表的供应商。这违反了供应商的要求，即每次返回一个新的空集合。
这将适用于简单的案例，如其答案中的示例所示。但是，它会失败，特别是如果流并行运行。 （未来版本的库可能会以某种无法预料的方式发生变化，导致它失败，即使在顺序情况下也是如此。）
我们举一个简单的例子：
List<String> destList = new ArrayList<>(Arrays.asList("foo"));
List<String> newList = Arrays.asList("0", "1", "2", "3", "4", "5");
newList.parallelStream()
.collect(Collectors.toCollection(() -> destList));
System.out.println(destList);
当我运行这个程序时，我经常得到一个ArrayIndexOutOfBoundsException。这是因为多个线程在ArrayList上运行，List<String> destList =
Collections.synchronizedList(new ArrayList<>(Arrays.asList("foo")));
是一个线程不安全的数据结构。好的，让它同步：
[foo, 0, 1, 2, 3]
这将不再失败，但有例外。但不是预期的结果：
[foo, 2, 3, foo, 2, 3, 1, 0, foo, 2, 3, foo, 2, 3, 1, 0, foo, 2, 3, foo, 2, 3, 1, 0, foo, 2, 3, foo, 2, 3, 1, 0]
它给出了这样奇怪的结果：
List.addAll()这是我在上面描述的线程限制的累积/合并操作的结果。使用并行流，每个线程都会调用供应商以获取其自己的集合以进行中间累积。如果您传递返回相同集合的供应商，则每个线程会将其结果附加到该集合。由于线程之间没有排序，因此结果将以某种任意顺序附加。
然后，当合并这些中间集合时，这基本上将列表与其自身合并。使用ArrayList.addAll()合并列表，其中表示如果在操作期间修改源集合，则结果未定义。在这种情况下，stream.collect(Collectors.toCollection(() -> existingList))
执行数组复制操作，因此它最终会复制自身，这是人们所期望的那种，我想。 （请注意，其他List实现可能具有完全不同的行为。）无论如何，这解释了目标中的奇怪结果和重复元素。
您可能会说，“我只是确保按顺序运行我的流”并继续编写这样的代码
sequential()无论如何。我建议不要这样做。如果您控制流，当然，您可以保证它不会并行运行。我希望在流式传输而不是集合的情况下会出现一种编程风格。如果有人给你一个流并且你使用这个代码，那么如果流恰好是并行的话它将会失败。更糟糕的是，有人可能会给你一个顺序流，这段代码可以正常运行一段时间，通过所有测试等等。然后，一些任意的时间后，系统中其他地方的代码可能会更改为使用并行流，这将导致您的代码打破。
好的，那么请确保在使用此代码之前记得在任何流上调用stream.sequential().collect(Collectors.toCollection(() -> existingList))
：
List<String> source = ...;
List<Integer> target = ...;
source.stream()
.map(String::length)
.forEachOrdered(target::add);
当然，你会记得每次都这样做，对吗？ :-)假设你这样做。然后，性能团队将会想知道为什么他们所有精心设计的并行实现都没有提供任何加速。再一次，他们会将其追溯到您的代码，这会强制整个流按顺序运行。
不要这样做。
据我所知，到目前为止所有其他答案都使用了一个收集器来向现有流添加元素。但是，有一个更短的解决方案，它适用于顺序和并行流。您可以简单地将方法forEachOrdered与方法引用结合使用。
Functional Programming
唯一的限制是，源和目标是不同的列表，因为只要处理了流，就不允许对流的源进行更改。
请注意，此解决方案适用于顺序和并行流。但是，它并没有从并发中受益。传递给forEachOrdered的方法引用将始终按顺序执行。
简短的回答是否定的（或者应该是否定的）。编辑：是的，这是可能的（见下面的assylias'答案），但继续阅读。编辑2：但看到斯图尔特马克斯的回答是另一个原因，你仍然不应该这样做！
答案越长：
Java 8中这些结构的目的是将final List<Integer> newList = list.stream()
.filter(n -> n % 2 == 0)
.collect(Collectors.toList());
的一些概念引入该语言;在功能编程中，通常不会修改数据结构，而是通过诸如map，filter，fold / reduce等许多其他变换来创建新的数据结构。
如果必须修改旧列表，只需将映射的项目收集到一个新的列表中：
list.addAll(newList)再做list - 再次：如果你真的必须。
（或构建一个连接旧的和新的列表的新列表，并将其分配回addAll变量 - 这比FP的精神更多一点，而不是Erik Allik）
至于API：即使API允许它（再次，请参阅assylias的答案），你应该尽量避免这样做，至少在一般情况下如此。最好不要对抗范式（FP）并尝试学习它而不是对抗它（即使Java通常不是FP语言），并且只有在绝对需要时才采用“更脏”的策略。
非常长的答案:(即如果你包括按照建议实际查找和阅读FP介绍/书籍的努力）
要找出为什么修改现有列表通常是一个坏主意并导致可维护性较低的代码 - 除非您修改局部变量并且您的算法很短和/或微不足道，这超出了代码可维护性问题的范围 - 找到功能编程的好介绍（有数百个）并开始阅读。一个“预览”的解释是这样的：它在数学上更合理，更容易推理不修改数据（在程序的大多数部分）并导致更高级别和更少技术（以及更人性化，一旦你的大脑转变远离旧式命令式思维）程序逻辑的定义。
Stuart Marks已经给出了很好的理由，为什么你很可能不想将流的元素收集到现有的List中。
无论如何，如果你真的需要这个功能，你可以使用以下单行。
但正如list.stream().collect(Collectors.toCollection(() -> myExistingList));
在他的回答中解释的那样，如果流可能是并行流，你就不应该这样做 - 使用风险自负......
Collectors.toList()您只需要将原始列表引用为import java.util.Arrays;
import java.util.List;
import java.util.stream.Collectors;
public class Reference {
public static void main(String[] args) {
List<Integer> list = Arrays.asList(1, 2, 3, 4, 5);
System.out.println(list);
// Just collect even numbers and start referring the new list as the original one.
list = list.stream()
.filter(n -> n % 2 == 0)
.collect(Collectors.toList());
System.out.println(list);
}
}
返回的列表。
这是一个演示：
List<Integer> list = ...;
// add even numbers from the list to the list again.
list.addAll(list.stream()
.filter(n -> n % 2 == 0)
.collect(Collectors.toList())
);
以下是您可以在一行中将新创建的元素添加到原始列表中的方法。
qazxswpoi
这就是这种功能编程范例所提供的。