Java Streams，第 1 部分: java.util.stream 库简介

最新推荐文章于 2024-01-15 16:39:23 发布

weixin_33716154

最新推荐文章于 2024-01-15 16:39:23 发布

阅读量119

点赞数

文章标签： java 数据结构与算法 python

原文链接：https://my.oschina.net/CasparLi/blog/825661

版权

2019独角兽企业重金招聘Python工程师标准>>>

java.util.stream包简介

在集合类及其他数据集上执行函数式查询

Java SE 8 中主要的新语言特性是lambda表达式。可以将lambda表达式想作一种匿名方法；像方法一样，lambda表达式具有带类型的参数、主体和返回类型。但真正的亮点不是lambda表达式本身，而是它们所实现的功能。lambda表达式使得 将行为表达为数据 变得很容易，从而使开发具有更强表达能力、更强大的库成为可能。

Java SE 8 中引入的一个这样的库是 java.util.stream 包 (Streams)，它有助于为各种数据源上的可能的并行批量操作建立简明的、声明性的表达式。较早的 Java 版本中也编写过像 Streams 这样的库，但没有紧凑的“行为即数据”语言特性，而且它们的使用很麻烦，以至于没有人愿意使用它们。您可以将 Streams 视为 Java 中第一个充分利用了lambda表达式的强大功能的库，但它没有什么特别奇妙的地方（尽管它被紧密集成到核心 JDK 库中）。Streams 不是该语言的一部分 ———— 它是一个精心设计的库，充分利用了一些较新的语言特性。

本文是一个深入探索 java.util.stream 库的系列的第一部分。本期向你介绍该库，并概述它的优势和设计原理。在后续几期中，您将学习如何使用流来聚合和汇总数据，了解该库的内部原理和性能优化。

使用流的查询

steam（流）的最常见用法之一是表示对集合中的数据的查询。清单 1 给出了一个简单的流管道示例。该管道获取一个在买家和卖家之间模拟购买的交易集合，并计算生活在纽约的卖家的交易总价值。

清单1. 一个简单的流管道

int totalSalesFromNY = txns.stream()
                           .filter(t -> t.getSeller().getAddr().getState().equals("NY"))
                           .mapToInt(t -> t.getAmount())
                           .sum();

流利用了最强大的计算原理：组合。

filter() 操作仅选择与来自纽约的卖家进行的交易。mapToInt() 操作选择所关注交易的交易金额。最终的 sum() 操作将对这些金额求和。

这个例子非常容易理解，即使批评者可能会指出这个查询的命令版本（for 循环）也非常简单，而且只需要更少的代码行即可表达。为了体现流方法的好处，示例问题没有必要变得过于复杂。流利用了这种最强大的计算原理：组合。通过使用简单的构建块（过滤filtering、映射mapping、排序sorting、聚合aggregation）来组合复杂的操作，在问题变得比相同数据源上更加临时的计算更复杂时（as the problem gets complicated than are more ad-hoc computations on the same data sources），流查询更可能保留写入和读取的简单性。

作为来自清单 1 中的相同领域的更复杂查询，考虑 “并按姓名排序并打印与年龄超过 65 岁的买家进行交易的卖家姓名。”以旧式的（命令式）方式编写此查询可能会得到类似清单 2 的结果。

清单2. 对一个集合的临时查询 (Ad-hoc query over a collection)

Set<Seller> sellers = new HashSet<>();
for (Txn t : txns) {
  if (t.getBuyer().getAge() >= 65){
    sellers.add(t.getSeller());
  }
}
List<Seller> sorted = new ArrayList<>(sellers);
Collections.sort(sorted, new Comparator<Seller>() {
  public int compare(Seller a, Seller b) {
    return a.getName().compareTo(b.getName());
  }
});
for (Seller s : sorted){
  System.out.println(s.getName());
}

尽管此查询只比第一个查询稍微复杂一点，但很明显采用命令式方法的代码的组织和可读性已开始下降。读者首先看到的不是计算的起点和终点；而是一个个一次性中间结果的声明。要阅读此代码，您需要在头脑中缓存大量上下文，然后才能明白代码的实际用途。清单 3 展示了可以如何使用 Streams 重写此查询。

清单3. 使用 Streams 表达的清单 2 中的查询

txns.stream()
    .filter(t -> t.getBuyer().getAge() >= 65)
    .map(Txn::getSeller)
    .distinct()
    .sorted(comparing(Seller::getName))
    .map(Seller::getName)
    .forEach(System.out::println);

清单 3 中的代码更容易阅读，因为用户既没有被 “垃圾” 变量（比如 sellers 和 sorted）分心，也不需要在阅读代码的同时跟踪记录大量上下文；而且代码看起来几乎就像问题陈述一样。可读性更强的代码也更不容易出错，因为维护者更容易一眼就看出代码在做什么。

像Streams 这类的库所采用的设计方法导致了实际的关注点分离。客户端负责指定计算的是 “什么”，而库负责控制 “如何做”。这种分离倾向于与专家经验的分发平行进行；客户端编写者通常能够更好地了解问题域，而库编写者通常拥有所执行的算法属性的更多专业技能。编写允许这种关注点分离的库的主要推动力是，能够像传递数据一样轻松地传递行为，这反过来使API能够让调用者描述复杂计算的结构，然后离开，让库来选择执行策略。

流管道剖析

所有流计算都有一种共同的结构：它们具有一个 流来源、0 或多个 中间操作，以及一个 终止操作。流的元素可以是对象引用 (Stream<String>)，也可以是原始整数 (IntStream)、长整型 (LongStream) 或双精度 (DoubleStream)。

因为 Java 程序使用的大部分数据都已存储在集合中，所以许多流计算使用集合作为它们的来源。JDK 中的 Collection 实现都已被增强，可充当高效的流来源。但是，还存在其他可能的流来源，比如数组、生成器函数（generator functions）或内置的工厂（比如数字范围），而且（如本系列中的第 3 期所示）可以编写自定义的流适配器，以便可以将任意数据源充当流来源。表 1 给出了 JDK 中的一些流生成方法。

表1. JDK 中的流来源

中间操作 ———— 就像 filter()（选择与条件匹配的元素）、map()（根据函数来转换元素）、distinct()（删除重复）、limit()（在特定大小处截断流）和 sorted() ———— 负责将一个流转换为另一个流。一些操作（比如 mapToInt()）获取一种类型的流并返回一种不同类型的流；清单 1 中的示例的开头处有一个 Stream<Transaction>，它随后被转换为 IntStream。表 2 给出了一些中间流操作。

表2. 中间流操作

中间操作始终是惰性的：调用中间操作仅仅只会设置流管道的下一个阶段，不会启动任何操作。中间操作可进一步划分为 无状态 和 有状态 操作。无状态操作（比如 filter() 或 map()）可独立处理每个元素，而有状态操作（比如 sorted() 或 distinct()）可合并以前看到的，影响其他元素处理的，元素状态。

数据集的处理在执行终止操作时开始，比如缩减（sum() 或 max()）、应用 (forEach()) 或搜索 (findFirst()) 操作。终止操作会生成一个结果或副作用。执行终止操作时，会终止流管道，如果您想再次遍历同一个数据集，可以设置一个新的流管道。表 3 给出了一些终止流操作。

表3. 终止流操作

|操作|描述| |:-|:-| |forEach(Consumer<T> action)|将提供的操作应用于流的每个元素| |toArray()|使用流的元素创建一个数组| |reduce(...)|将流的元素聚合为一个汇总值| |collect(...)|将流的元素聚合到一个汇总结果容器中| |min(Comparator<T>)|通过比较符返回流的最小元素| |max(Comparator<T>)|通过比较符返回流的最大元素| |count()|返回流的大小| |{any,all,none}Match(Predicate<T>)|返回与提供的预期部分/完全/不匹配的元素| |findFirst()|返回流的第一个元素（如果有）| |findAny()|返回流的任何元素（如果有）|

流与集合的比较

尽管流在表面上类似于集合 —— 你可以认为二者都包含数据 —— 但事实上它们有着显著的不同。集合是一种数据结构；它的主要关注点是在内存中组织数据，而且集合会在一段时间内持久存在。集合通常可用作流管道的来源或目标，但流的关注点是计算，而不是数据。数据来自其他任何地方（集合、数组、生成器函数或 I/O 通道），而且可通过一个计算步骤管道处理来生成结果或副作用，在此刻，流已经完结了。流没有为它们处理的元素提供存储空间，而且流的生命周期更像一个时间点 —— 调用终止操作。不同于集合，流也可以是无限的；相应地，一些操作（limit()、findFirst()）是短路的，而且可在无限流上运行有限的计算。

集合和流在执行操作的方式上也不同。集合上的操作是急切和突变性的；在一个 List 上调用 remove() 方法时，调用返回后，您知道列表状态会发生改变，以反映指定元素的删除。对于流，只有终止操作是急切的；其他操作都是惰性的。流操作表示其输入（同样是一个流）上的功能转换，而不是数据集上的突变性操作（过滤一个流会生成一个新流，新流的元素是输入流的子集，但没有从来源删除任何元素）。

将流管道表达为功能转换序列可以实现多种有用的执行策略，比如 惰性/laziness、短路/short circuiting 或 操作融合/operation fusion。短路使得管道能够成功终止，而不必检查所有数据；类似 “找到第一笔超过 1000 美元的交易” 这样的查询不需要在找到匹配值后检查其他任何交易。操作融合表示，可在对数据的一轮遍历中执行多个操作；在清单 1 的示例中，3 个操作组合成了数据上的一轮操作，而不是首先选择所有匹配的交易，然后选择所有对应的金额，最后对它们求和。

类似清单 1 和清单 3 中的查询的命令版本通常依靠物化集合来获得中间计算的结果，比如过滤或映射的结果。这些结果不仅可能让代码变得杂乱，还可能让执行变得混乱。中间集合的物化仅作用于实现，而不作用于结果，而且它使用计算周期将中间结果组织为将会被丢弃的数据结构。

相反，流管道将它们的操作融合到尽可能少的数据轮询中，通常为单轮。（有状态中间操作，比如排序，可引入对多轮执行必不可少的障碍点。）流管道的每个阶段惰性地生成它的元素，仅在需要时计算元素，并直接将它们提供给下一阶段。您不需要使用集合来保存过滤或映射的中间结果，所以省去了填充（和垃圾回收）中间集合的工作。另外，遵循 “深度优先” 而不是 “宽度优先” 的执行策略（跟踪单个数据元素通过整个管道的路径）使得被处理的数据在缓存中变得更 “热”，所以您可以将更多时间用于计算，花更少时间来等待数据。

除了将流用于计算之外，您可能还希望考虑通过 API 方法使用流来返回聚合体，而在以前，您可能返回一个数组或集合。返回流的效率通常更高一些，因为您不需要将所有数据复制到一个新数组或集合中。返回流通常更加灵活；库选择返回的集合形式可能不是调用方所需要的，而且很容易将流转换为任何集合类型。（返回流不合适，而返回物化集合更合适的主要情形是，调用方需要查看某个时间点的状态的一致快照。）

并行性

将计算构建为功能转换的一个有益的结果是，您只需对代码进行极少的更改，即可轻松地在顺序和并行执行之间切换。流计算的顺序表达和相同计算的并行表达几乎相同。清单 4 展示了如何并行地执行清单 1 中的查询。

清单4. 清单 1 的并行版本

int totalSalesFromNY = txns.paralleStream()
                           .filter(t -> t.getSeller().getAddr().getState().equals("NY"))
                           .mapToInt(t -> t.getAmount())
                           .sum();

将流管道表达为一系列功能转换，有助于实施一些有用的执行策略，比如惰性、并行性、短路和操作融合。

第一行将会请求一个并行流而不是顺序流，这是与清单 1 的唯一区别，因为 Streams 库有效地从执行计算的策略中分解出了计算的描述和结构。以前，并行执行要求完全重写代码，这样做不仅代价高昂，而且往往容易出错，因为得到的并行代码与顺序版本不太相似。

所有流操作都可以顺序或并行执行，但请记住，并行性并不是高性能的原因。并行执行可能比顺序执行更快、一样快或更慢。最好首先从顺序流开始，在您知道您能够获得提速（并从中受益）时才应用并行性。本系列后面的一期文章会返回分析流管道的并行性能。

附加信息

尽管 Streams 库是为计算而精心设计的，但执行计算涉及到回调客户端所提供的lambda表达式，这些lambda表达式受到一定约束。违反这些约束可能导致流管道失败或计算出不正确的结果。此外，对于具有副作用的lambda表达式，这些副作用的时限（或存在）可能在某些情况下不合情理。

大多数流操作都要求传递给它们的lambda表达是 互不干扰 和 无状态 的。互不干扰意味着它们不会修改流来源；无状态意味着它们不会访问（读或写）任何可能在流操作寿命内改变的状态。对于缩减操作（例如计算 sum、min 或 max 等汇总数据），传递给这些操作的lambda表达式必须是 结合性 的（或遵守类似的要求）。

从某种程度讲，这些要求源于以下事实：如果管道并行执行，流库可能从多个线程访问数据源，或并发地调用这些lambda表达式。需要这些限制才能确保计算保持正确。（这些限制也可能得到更加简单、更容易理解的代码，无论是否采用并行性。）您可能倾向于让自己相信，您可以忽略这些限制，因为您认为特定的管道从不会并行运行，但最好控制住这一倾向，否则您会在代码中埋下定时炸弹。花点精力来表达您的流管道，使得无论采用何种执行战略，它们都是正确的。

所有并发性风险的根源是 共享可变状态。共享可变状态的一种可能来源是流来源。如果来源是像 ArrayList 这样的传统集合，Streams 库会假设它在流操作过程中保持不变。（明显为了实现并发访问而设计的集合，比如 ConcurrentHashMap，不符合这一假设。）互不干扰要求不仅不包括在流操作期间被其他操作突变的来源，而且传递给流操作的lambda表达式本身也应避免突变来源。

除了不修改流来源之外，传递给流操作的lambda表达式也应是无状态的。例如，清单 5 中的代码（尝试消除任何与前面的元素重复的元素）就违背了这一规则。

清单5. 使用有状态拉姆达表达式的流管道（不要这么做！）

HashSet<Integer> twiceSeen = new HashSet<>();
int[] result = elements.stream()
                       .filter(e -> {
                           twiceSeen.add(e * 2);
                           return twiceSeen.contains(e);
                       })
                       .toArray();

如果并行执行，此管道会生成错误的结果，原因有两个。首先，对 twiceSeen 集的访问是从多个线程进行的，没有进行任何协调，因此不是线程安全的。第二，因为数据被分区了，所以无法确保在处理给定元素时已经处理了该元素前面的所有元素。

最好的情况是，如果传递给流操作的拉姆达表达式完全没有副作用，也就是说，它们不会突变任何基于堆的状态或在执行过程中执行任何 I/O。如果有副作用，它们应负责执行任何需要的协调，以确保这些副作用是线程安全的。

此外，无法保证所有副作用都将执行。例如，在清单 6 中，该库被释放了，以完全避免执行传递给 map() 的拉姆达表达式。因为来源具有已知大小，map() 操作被认为会保持该大小，而且映射不会影响计算的结果，所以库可以通过完全不执行映射来优化计算！（这种优化可以将计算从 O(n) 转换到 O(1)，还可以消除与调用映射函数相关的工作。）

清单6. 具有可能不会被执行的副作用的流管道

int count = anArrayList.stream()
                       .map(e -> { System.out.println("Saw " + e); e })
                       .count();

您会注意到受这种优化影响的唯一情况（除了计算速度快得多）是，传递给 map() 的拉姆达表达式具有副作用 — 在这种情况下，如果这些副作用没有发生，您可能感到非常奇怪。能够实现这些优化的假设前提是，流操作属于功能转换。在大多数时候，该库使我们的代码能够运行得更快，而且不需要我们投入精力。能够执行这样的优化的代价是，我们必须接受对我们传递给流操作的拉姆达表达式的操作的一些限制，以及我们对副作用的一定的依赖。（总之，这是一次很划算的交易。）