假设我有一个方法可以返回成员列表的只读视图：
class Team {
private List<Player> players = new ArrayList<>();
// ...
public List<Player> getPlayers() {
return Collections.unmodifiableList(players);
}
}
进一步假设客户端只是立即一次性地迭代列表。可能是为了将玩家放入JList或类似的组件中。客户端不会存储对列表的引用以供以后查看！
考虑到这种常见情况，我应该返回一个流吗？
public Stream<Player> getPlayers() {
return players.stream();
}
在Java中，返回流是否不符合惯用方式？流是被设计为总是在创建它们的同一表达式中“终止”的吗？
答案总是“取决于”。这取决于返回的集合有多大，取决于结果是否随时间变化，以及返回结果的一致性有多重要。而且，这非常取决于用户可能如何使用答案。
首先，请注意您可以始终从Stream获取Collection，反之亦然：
// If API returns Collection, convert with stream()
getFoo().stream()...
// If API returns Stream, use collect()
Collection<T> c = getFooStream().collect(toList());
我有几个要补充的点，关于Brian Goetz优秀回答。 getter风格的方法调用返回Stream相当普遍。在Java 8 javadoc的Stream使用页面中查找“返回Stream的方法”（除了java.util.Stream），这些方法通常位于表示或包含多个值或聚合内容的类上。在这种情况下，API通常已经返回了集合或它们的数组。出于Brian在回答中提到的所有原因，添加返回Stream的方法非常灵活。许多这些类已经具有返回集合或数组的方法，因为这些类早于Streams API。如果你正在设计一个新的API，并且提供返回Stream的方法是有意义的，那么可能不需要再添加返回集合的方法。
Brian提到“材料化”值的成本。为了强调这一点，这里实际上有两个成本：将值存储在集合中的成本（内存分配和复制），以及首次创建值的成本。通过利用流的惰性行为，后者的成本通常可以降低或避免。一个很好的例子是java.nio.file.Files中的API：
static Stream<String> lines(path)
static List<String> readAllLines(path)
readAllLines不仅需要将整个文件内容保存在内存中以便将其存储到结果列表中，它还必须读取文件直到末尾才能返回列表。相反，lines方法可以在执行一些设置后立即返回，稍后再进行文件读取和行分割，或者根本不进行操作。例如，如果调用者只对前十行感兴趣，这将是一个巨大的优势：
try (Stream<String> lines = Files.lines(path)) {
List<String> firstTen = lines.limit(10).collect(toList());
}
如果调用者过滤流以仅返回与模式匹配的行，就可以节省相当多的内存空间。
一种看起来正在兴起的习惯用法是将返回流的方法命名为它所表示或包含的事物名称的复数形式，而不使用get前缀。此外，当存在多个可能返回的值集时，例如某些同时包含属性和元素的对象，stream()是一个合理的流返回方法名称，您可能会提供两个返回流的API：
Stream<Attribute> attributes();
Stream<Element> elements();
虽然一些知名回答者提供了很好的通用建议，但我惊讶地发现还没有人明确说明：
如果你已经手头有一个“实体化”的Collection（即在调用之前已经创建 - 如在给定示例中，它是一个成员字段），那么将其转换为Stream就没有意义。调用者可以轻松地自行完成这个过程。而如果调用者想要以原始形式消耗数据，则将其转换为Stream会强制他们进行冗余工作，重新实体化原始结构的副本。
流是否被设计为始终在创建它们的同一表达式中“终止”？
这是它们在大多数示例中使用的方式。
注意：返回流与返回迭代器并没有太大区别（尽管具有更多的表现力）。
在我看来，最好的解决方案是封装你所做的操作，并不返回集合。
例如：
public int playerCount();
public Player player(int n);
或者如果你想要对它们进行计数
public int countPlayersWho(Predicate<? super Player> test);
这些差异在集合中也存在，但它们是显而易见的契约的一部分：
/**
* [...] The returned stream encapsulates a Reader. If timely disposal of
* file system resources is required, the try-with-resources
* construct should be used to ensure that the stream's close
* method is invoked after the stream operations are completed.
*/
public static Stream<String> lines(Path path, Charset cs)
/**
* [...] no mention of closing even if this wraps the previous method
*/
public static Stream<String> lines(Path path)
当上述问题都不重要时，通常是在流的生产者和消费者在同一代码库中，并且所有消费者都已知的情况下，才能将Stream作为方法签名中的有效选择。
在方法签名中使用其他数据类型更安全，并且具有显式契约（并且没有涉及隐式线程池处理），这使得无法意外地使用错误的假设来处理有序性、大小或并行性（以及线程池使用）的数据。
我认为这取决于你的情况。如果你让你的Team实现Iterable<Player>，那可能就足够了。
for (Player player : team) {
System.out.println(player);
}
或者以函数式风格：
team.forEach(System.out::println);
但如果你想要一个更完整和流畅的API，那么流式处理可能是一个不错的解决方案。
stream.count() 也很容易），但那个数字对于除了调试或估计之外的任何事情都不是非常有意义的。 - Brian GoetzCollection，另一个方法返回Stream形式的集合。class Team
{
private List<Player> players = new ArrayList<>();
// ...
public List<Player> getPlayers()
{
return Collections.unmodifiableList(players);
}
public Stream<Player> getPlayerStream()
{
return players.stream();
}
}
这是两全其美的选择。客户端可以自行选择他们想要的 List 或 Stream，无需进行额外的对象创建来复制列表以获取 Stream。
这样也只会在 API 中添加一种方法，因此您不必过多地拥有太多方法。
players.stream()就是一个返回流给调用者的方法。真正的问题是，你是否想限制调用者只能遍历一次，并且阻止他通过CollectionAPI 访问你的集合？也许调用者只想将其addAll到另一个集合中？ - Marko Topolnik