第1章 Java 8、9、10以及11的变化

自1996年JDK 1.0（Java 1.0）发布以来，Java已经受到了学生、项目经理和程序员等一大批活跃用户的欢迎。这一语言极具活力，不断被用在大大小小的项目里。从Java 1.1（1997年）到Java 7（2011年）, Java通过不断地增加新功能，得到了良好的升级。Java 8于2014年3月发布，Java 9于2017年9月发布，Java 10于2018年3月发布，Java 11于2018年9月发布。那么，问题来了：为什么要关心这些变化？

1.1 为什么要关心Java的变化

我们的理由是，从很多方面来说，Java 8所做的改变，其影响比Java历史上任何一次改变都深远（Java 9新增了效率提升方面的重要改进，但并不伤筋动骨，这些内容本章后面会介绍。Java 10对类型推断做了微调）。好消息是，这些改变会让编程更容易，我们再也不用编写下面这种啰唆的程序了（按照重量给inventory中的苹果排序）：

        Collections.sort(inventory, new Comparator<Apple>() {
            public int compare(Apple a1, Apple a2){
                return a1.getWeight().compareTo(a2.getWeight());
            }
        });

使用Java 8，你能书写更简洁的代码，让代码读起来更接近问题描述本身：

这段代码的意思是“按照重量给库存苹果排序”。目前你不用担心不理解这段代码，本书后续的章节将会介绍它做了什么，以及如何写出这样的代码。

Java 8的改变也受到了硬件的影响：平常我们用的CPU都是多核的——你的笔记本电脑或台式机的处理器可能有四个甚至更多的CPU核。然而，绝大多数现存的Java程序都只使用了其中一个核，其他三个核都闲着，或者仅消耗了它的一小部分处理能力来运行操作系统或杀毒程序。

Java 8之前，专家们可能会跟你说，只有通过多线程才能利用多个处理器核。问题是，多线程用起来不仅难，还容易出错。从Java的演进路径来看，它一直致力于让并发编程更容易、出错更少。早在1.0版本Java就引入了线程和锁，甚至还有一个内存模型——这是当时的最佳做法，然而事实证明，除非你的项目团队是由专家组成的，否则很难可靠地利用这些基本模型。Java 5添加了工业级的构建模块，如线程池和并发集合。Java 7添加了分支/合并（fork/join）框架，让并行变得更实用，然而这依旧很困难。Java 8提供了一种全新的思想，可以帮助你更容易地实现并行。然而，你仍然需要遵循一些规则，这些内容本书都会逐一介绍。

本书还会介绍Java 9新增的反应式编程支持，它是一种实现并发的结构化方法。虽然实现反应式编程有多种专有的方式，但是RxJava和Akka反应式流工具集正日益流行，已成为构建高并发系统的标准方式。

基于前文介绍的两个迫切需求（即编写更简洁的代码，以及更方便地利用处理器的多核）催生出了一座拔地而起相互勾连一致的Java 8大厦。先快速了解一下这些想法（希望能引起你的兴趣，也希望这些总结足够简洁）：

❏ Stream API；

❏ 向方法传递代码的技巧；

❏ 接口的默认方法。

Java 8提供了一个新的API（称为“流”, Stream），它支持多个数据处理的并行操作，其思路和数据库查询语言类似——从高层的角度描述需求，而由“实现”（这里是Stream库）来选择底层最佳执行机制。这样就可以避免用synchronized编写代码，这种代码不仅容易出错，而且在多核CPU上执行所需的成本也比你想象的要高。

从修正的角度来看，在Java 8中加入Stream可以视为添加另外两项的直接原因：向方法传递代码的简洁技巧（方法引用、Lambda）和接口中的默认方法。

如果仅仅把“向方法传递代码”看成引入Stream的结果，就低估了它在Java 8中的应用范围。它提供了一种新的方式，能够简洁地表达行为参数化。比方说，你想要写两个只有几行代码不同的方法，现在只需把不同的那部分代码作为参数传递进去就可以了。采用这种编程技巧，代码更短、更清晰，也比常用的复制粘贴更少出错。高手看到这里就会想，Java 8之前可以用匿名类实现行为参数化呀——但是想想本章开头那个更加简洁的Java 8代码示例，代码本身就说明了它有多清晰！

Java 8里将代码传递给方法的功能（同时也能够返回代码并将其包含在数据结构中）还让我们能够使用一整套新技巧，通常称为函数式编程。一言以蔽之，这种被函数式编程界称为函数的代码，可以被来回传递并加以组合，以产生强大的编程语汇。这样的例子在本书中随处可见。

本章首先从宏观角度探讨语言为什么会演变，然后介绍Java 8的核心特性，接着介绍函数式编程思想——新的特性简化了使用，而且更适应新的计算机体系结构。简而言之，1.2节讨论Java的演变过程和原因，即Java以前缺乏以简易方式利用多核并行的能力。1.3节介绍为什么把代码传递给方法在Java 8里是如此强大的一个新的编程语汇。1.4节对Stream做同样的介绍：Stream是Java 8表示有序数据以及这些数据是否可以并行处理的新方式。1.5节解释如何利用Java 8中的默认方法功能让接口和库的演变更顺畅、编译更少，还会介绍Java 9中新增的模块，有了这一特性，Java系统组件就不会再被称为“只是包的JAR文件”了。最后，1.6节展望在Java和其他共用JVM的语言中进行函数式编程的思想。总的来说，本章会介绍整体脉络，而细节会在本书的其余部分中逐一展开。请尽情享受吧！

1.2 Java怎么还在变

20世纪60年代，人们开始追求完美的编程语言。当时著名的计算机科学家Peter Landin在1966年的一篇标志性论文中提到那时已经有700种编程语言了，并推测了接下来的700种会是什么样子，文中也对类似于Java 8中的函数式编程进行了讨论。

之后，又出现了数以千计的编程语言。于是学者们得出结论：编程语言就像生态系统一样，新的语言会出现，旧语言则被取代，除非它们不断演变。我们都希望出现一种完美的通用语言，可在现实中，某些语言只是更适合某些方面。比如，C和C++仍然是构建操作系统和各种嵌入式系统的流行工具，因为它们编写出的程序尽管安全性不佳，但运行时占用资源少。缺乏安全性可能会导致程序意外崩溃，并把安全漏洞暴露给病毒等。确实，Java和C#等安全型语言在诸多运行资源不太紧张的应用中已经取代了C和C++。

先抢占市场通常能够吓退竞争对手。为了一个功能而改用新的语言和工具链往往太痛苦了，但新来者最终会取代现有的语言，除非后者演变得够快，能跟上节奏。年纪大一点的读者大多可以列举出一堆这样的语言——他们以前用过，但是现在这些语言已经不流行了。随便列举几个吧：Ada、Algol、COBOL、Pascal、Delphi、SNOBOL等。

你是一位Java程序员。在过去近20年的时间里，Java已经成功地霸占了编程生态系统中的一大块，同时替代了竞争对手语言。下面来看看其中的原因。

1.2.1 Java在编程语言生态系统中的位置

Java天资不错。从一开始，它就是一门精心设计的面向对象的语言，提供了大量有用的库。由于有集成的线程和锁的支持，它从第一天起就支持小规模并发（并且它很有先见之明地承认，在硬件无关的内存模型中，并发线程在多核处理器上发生意外的概率比单核处理器上大得多）。此外，将Java编译成JVM字节码（一种很快就被每一种浏览器支持的虚拟机代码）意味着它成为了互联网applet（小应用）的首选。（你还记得applet吗？）确实，Java虚拟机（JVM）及其字节码可能会变得比Java语言本身更重要，而且对于某些应用来说，Java可能会被同样运行在JVM上的竞争对手语言（如Scala或Groovy）取代。JVM各种最新的更新（例如JDK7中的新invokedynamic字节码）旨在帮助这些竞争对手语言在JVM上顺利运行，并与Java交互操作。Java也已经成功地占领了嵌入式计算的若干领域，从智能卡、烤面包机、机顶盒到汽车制动系统。

但是，编程语言生态系统的气候正在变化。程序员越来越多地要处理所谓的大数据（数百万兆甚至更多字节的数据集），并希望利用多核计算机或计算集群来有效地处理。这意味着需要使用并行处理——Java以前对此并不支持。你可能接触过其他编程领域的思想，比如Google的map-reduce，或使用过相对容易的数据库查询语言（如SQL）执行数据操作，它们能帮助你处理大量数据和多核CPU。图1-1总结了语言生态系统：把这幅图看作编程问题空间，每个地方生长的主要植物就是程序最喜欢的语言。气候变化的意思是，新的硬件或新的编程因素（例如，“我为什么不能用SQL的风格来写程序？”）意味着新项目优选的语言各有不同，就像地区气温上升就意味着葡萄在较高的纬度也能长得好。当然这会有滞后——很多老农会一直种植着传统作物。总之，新的语言不断出现，并因为迅速适应了气候变化，越来越受欢迎。

对程序员来说，Java 8的主要好处在于它提供了更多的编程工具和概念，能以更快、更简洁、更易于维护的方式解决新的或现有的编程问题，其中简洁和易维护更重要。虽然这些概念对于Java来说是新的，但是研究型的语言已经证明了它们的强大。我们会重点探讨三个编程概念背后的思想，它们促使Java 8开发出了利用并行和编写更简洁代码的功能。这里介绍它们的顺序和本书其余部分略有不同，一方面是为了类比Unix，另一方面是为了揭示Java 8新的多核并行中存在的“因为这个所以需要那个”的依赖关系。

接下来的三个小节会逐一介绍驱动Java 8设计的三个编程概念。

1.2.2 流处理

第一个编程概念是流处理。流是一系列数据项，一次只生成一项。程序可以从输入流中一个一个读取数据项，然后以同样的方式将数据项写入输出流。一个程序的输出流很可能是另一个程序的输入流。

一个实际的例子是在Unix或Linux中，很多程序都从标准输入（Unix和C中的stdin, Java中的System.in）读取数据，然后把结果写入标准输出（Unix和C中的stdout, Java中的System.out）。首先来看一点点背景：Unix的cat命令会把两个文件连接起来创建一个流，tr会转换流中的字符，sort会对流中的行进行排序，tail -3则给出流的最后三行。Unix命令行允许这些程序通过管道（|）连接在一起，比如下面这段代码会假设file1和file2中每行都只有一个单词，先把字母转换成小写字母，然后打印出按照词典顺序排在最后的三个单词：

        cat file1 file2 | tr "[A-Z]"   "[a-z]"   |   sort   |   tail -3

我们说sort把一个行流作为输入，产生了另一个行流（进行排序）作为输出，如图1-2所示。请注意在Unix中，这些命令（cat、tr、sort和tail）是同时执行的，这样sort就可以在cat或tr完成前先处理头几行。就像汽车组装流水线一样，汽车排队进入加工站，每个加工站会接收、修改汽车，然后将之传递给下一站做进一步的处理。尽管流水线实际上是一个序列，但不同加工站的运行一般是并行的。

基于这一思想，Java 8在java.util.stream中添加了一个Stream API。Stream<T>就是一系列T类型的项目。你现在可以把它看成一种比较花哨的迭代器。Stream API的很多方法可以链接起来形成一个复杂的流水线，就像先前例子里面链接起来的Unix命令一样。

推动这种做法的关键在于，现在你可以在一个更高的抽象层次上写Java 8程序了：思路变成了把这样的流变成那样的流（就像写数据库查询语句时的那种思路），而不是一次只处理一个项目。另一个好处是，Java 8可以透明地把输入的不相关部分拿到几个CPU核上去分别执行你的Stream操作流水线——这是几乎免费的并行，用不着去费劲搞Thread了。本书第4～7章会仔细讨论Java 8的Stream API。

1.2.3 用行为参数化把代码传递给方法

Java 8中增加的另一个编程概念是通过API来传递代码的能力。这听起来实在太抽象了。在Unix的例子里，你可能想告诉sort命令使用自定义排序。虽然sort命令支持通过命令行参数来执行各种预定义类型的排序，比如倒序，但这毕竟是有限的。

比方说，你有一堆发票代码，格式类似于2013UK0001、2014US0002……其中前四位数代表年份，接下来两个字母代表国家，最后四位是客户的代码。你可能想按照年份、客户代码，甚至国家来对发票进行排序。你真正想要的是，能够给sort命令一个参数让用户定义顺序：给sort命令传递一段独立的代码。

那么，直接套在Java上，你是要让sort方法利用自定义的顺序进行比较。你可以写一个compareUsingCustomerId来比较两张发票的代码，但是在Java 8之前，你无法把这个方法传给另一个方法。你可以像本章开头介绍的那样，创建一个Comparator对象，将之传递给sort方法，不过这不但啰唆，而且让“重用现有行为”的思想变得不那么清楚了。Java 8增加了把方法（你的代码）作为参数传递给另一个方法的能力。图1-3是基于图1-2画出的，它描绘了这种思路。我们把这一概念称为行为参数化。它的重要之处在哪儿呢？Stream API就是构建在通过传递代码使操作行为实现参数化的思想上的，当把compareUsingCustomerId传进去，你就把sort的行为参数化了。

我们将在1.3节中概述这种方式，第2章和第3章再进行详细讨论。第18章和第19章将讨论这一功能的高级用法，还有函数式编程自身的一些技巧。

1.2.4 并行与共享的可变数据

第三个编程概念更隐晦一点，它源自前面讨论流处理能力时说的“几乎免费的并行”。你需要放弃什么吗？你可能需要稍微改变一下编写传给流方法的行为的方法。这些改变一开始可能会让你有点儿不舒服，但一旦习惯了你就会爱上它们。你提供的行为必须能够同时在不同的输入上安全地执行。一般情况下这就意味着，所写的代码不能访问共享的可变数据来完成它的工作。这些函数有时被称为“纯函数”“无副作用函数”或“无状态函数”，第18章和第19章会详细讨论。前面说的并行只有在你的代码的多个副本可以独立工作时才能进行。但如果要写入的是一个共享变量或对象，就行不通了：如果两个进程需要同时修改这个共享变量怎么办？（1.4节通过配图给出了更详细的解释。）在后续章节中，你会进一步了解这种风格。

Java 8的流实现并行比Java现有的Thread API更容易，因此，尽管可以使用synchronized来打破“不能有共享的可变数据”这一规则，但这相当于是在和整个体系作对，因为它使所有围绕这一规则做出的优化都失去意义了。在多个处理器核之间使用synchronized，其代价往往比你预期的要大得多，因为同步迫使代码按照顺序执行，而这与并行处理的宗旨相悖。

没有共享的可变数据，以及将方法和函数（即代码）传递给其他方法的能力，这两个要点是函数式编程范式的基石，第18章和第19章会详细讨论。与此相反，在命令式编程范式中，你写的程序则是一系列改变状态的指令。“不能有共享的可变数据”意味着，一个方法可以通过它将参数值转换为结果的方式来完整描述，换句话说，它的行为就像一个数学函数，没有可见的副作用。

1.2.5 Java需要演变

前面已经介绍了Java的演变。例如，引入泛型，以及使用List<String>而不只是List，一开始可能都挺烦人的，但现在你已经熟悉了这种风格和它所带来的好处，即在编译时能发现更多错误，且代码更易读，因为你现在知道列表里面是什么了。

其他改变使得表达普通的东西变得更容易，例如，使用for-each循环，而不用暴露Iterator里面的模板写法。Java 8中的主要变化反映了它开始远离常侧重改变现有值的经典面向对象思想，而向函数式编程领域转变。在函数式编程中，在大体上考虑想做什么（例如，创建一个值来代表所有从A到B的低于给定价格的路线）被视为头等大事，并和具体实现方式（例如，扫描一个数据结构并修改某些元素）区分开来。请注意，如果极端点儿来说，传统的面向对象编程和函数式编程可能看起来是冲突的。但是我们的理念是获取两种编程范式中的精华，以便为任务找到理想的工具。1.3节和1.4节会详细讨论。

简而言之，语言需要不断改进，以适应硬件的更新或满足程序员的期待（如果你还不够信服，想想COBOL可一度是最重要的商用语言之一呢）。要坚持下去，Java必须通过增加新功能来改进，而且只有新功能被人使用，变化才有意义。所以，使用Java 8，你就是在保护你作为Java程序员的职业生涯。除此之外，我们有一种感觉——你一定会喜欢Java 8的新功能。随便问问哪个用过Java 8的人，看看他们愿不愿意退回去使用旧版本。还有，用生态系统打比方的话，Java 8的新功能使得Java能够征服如今被其他语言占领的编程任务领地，所以对Java 8程序员的需求更多了。

下面将逐一介绍Java 8中的新概念，并顺便指出哪一章还会详细讨论这些概念。

1.3 Java中的函数

编程语言中的函数一词通常是指方法，尤其是静态方法，这是在数学函数，也就是没有副作用的函数之外的一个新含义。幸运的是，你将会看到，当Java 8提到函数时，这两种用法几乎是一致的。

Java 8中新增了函数，作为值的一种新形式。它有助于使用1.4节中谈到的流，有了它，Java 8可以在多核处理器上进行并行编程。首先来展示一下作为值的函数本身的有用之处。

想想Java程序可能操作的值吧。首先有原始值，比如42（int类型）和3.14（double类型）。其次，值可以是对象（更严格地说是对象的引用）。获得对象的唯一途径是利用new，这也许是通过工厂方法或库函数实现的；对象引用指向一个类的实例。例子包括"abc"（String类型）、new Integer(1111)（Integer类型），以及new HashMap<Integer, String>(100)的结果——它显式调用了HashMap的构造函数。甚至数组也是对象。那么有什么问题呢？

为了帮助回答这个问题，我们要注意到，编程语言的整个目的就在于操作值，按照历史上编程语言的传统，这些值应被称为一等值（或一等公民）。编程语言中的其他结构也许有助于表示值的结构，但在程序执行期间不能传递，因而是二等值。前面所说的值是Java中的一等值，但其他很多Java概念（比如方法和类等）则是二等值。用方法来定义类很不错，类还可以实例化来产生值，但方法和类本身都不是值。这又有什么关系呢？还真有，人们发现，在运行时传递方法能将方法变成一等值。这在编程中非常有用，因此Java 8的设计者把这个功能加入到了Java中。顺便说一下，你可能会想，让类等其他二等值也变成一等值可能也是个好主意。有很多语言，比如Smalltalk和JavaScript，都探索过这条路。

1.3.1 方法和Lambda作为一等值

Scala和Groovy等语言的实践已经证明，让方法等概念作为一等值可以扩充程序员的工具库，从而让编程变得更容易。一旦程序员熟悉了这个强大的功能，就再也不愿意使用没有这一功能的语言了。因此，Java 8的设计者决定允许将方法作为值，让编程更轻松。此外，让方法作为值也构成了其他几个Java 8功能（比如Stream）的基础。

我们介绍的Java 8的第一个新功能是方法引用。比方说，你想要筛选一个目录中的所有隐藏文件。你需要编写一个方法，然后给它一个File，它就会告诉你文件是不是隐藏的。幸好，File类里面有一个叫作isHidden的方法。可以把它看作一个函数，接受一个File，返回一个布尔值。但要用它做筛选，需要把它包在一个FileFilter对象里，然后传递给File.listFiles方法，如下所示：

呃，真可怕！虽然只有三行，但这三行可真够绕的。我们第一次碰到的时候肯定都说过：“非得这样不可吗？”已经有一个方法isHidden可用，为什么非得把它包在一个啰唆的FileFilter类里面再实例化呢？因为在Java 8之前你必须这么做！

如今在Java 8里，你可以把代码重写成这样：

        File[] hiddenFiles = new File(".").listFiles(File::isHidden);

哇！酷不酷？你已经有了函数isHidden，因此只需用Java 8的方法引用：：语法（即“把这个方法作为值”）将其传给listFiles方法。请注意，我们也开始用函数代表方法了。稍后会解释这个机制是如何工作的。一个好处是，你的代码现在读起来更接近问题的陈述了。

方法不再是二等值了。与用对象引用传递对象类似（对象引用是用new创建的），在Java 8里写下File::isHidden的时候，你就创建了一个方法引用，你同样可以传递它。第3章会详细讨论这一概念。只要方法中有代码（方法中的可执行部分），那么用方法引用就可以传递代码，如图1-3所示。图1-4说明了这一概念。你在下一节中还将看到一个具体的例子——从库存中选择苹果。

Lambda——匿名函数

除了允许（命名）函数成为一等值外，Java 8还体现了更广义的将函数作为值的思想，包括Lambda（或匿名函数）。比如，你现在可以写(int x) -> x + 1，表示“调用时给定参数x，就返回x + 1值的函数”。你可能会想这有什么必要呢？因为你可以在MyMathsUtils类里面定义一个add1方法，然后写MyMathsUtils::add1嘛！确实是可以，但要是你没有方便的方法和类可用，新的Lambda语法更简洁。第3章会详细讨论Lambda。我们说使用这些概念的程序具有函数式编程风格，这句话的意思是“编写把函数作为一等值来传递的程序”。

1.3.2 传递代码：一个例子

来看一个例子，看看它是如何帮助你写程序的，我们在第2章还会进行更详细的讨论。所有的示例代码均可见于图灵社区本书主页http://ituring.com.cn/book/2659“随书下载”处。假设你有一个Apple类，它有一个getColor方法，还有一个变量inventory保存着一个Apples列表。你可能想要选出所有的绿苹果（此处使用包含值GREEN和RED的Color枚举类型），并返回一个列表。通常用筛选（filter）一词来表达这个概念。在Java 8之前，你可能会写这样一个方法filterGreenApples：

但是接下来，有人可能想要选出重的苹果，比如超过150克的苹果，于是你心情沉重地写了下面这个方法，甚至用了复制粘贴：

我们都知道软件工程中复制粘贴的危险——给一个做了更新和修正，却忘了另一个。嘿，这两个方法只有一行不同：if里面加粗的那行条件。如果这两个加粗的方法之间的差异仅仅是接受的重量范围不同，那么你只要把接受的重量上下限作为参数传递给filter就行了，比如指定(150, 1000)来选出重的苹果（超过150克），或者指定(0, 80)来选出轻的苹果（低于80克）。

但是，前面提过了，Java 8会把条件代码作为参数传递进去，这样可以避免filter方法中出现重复的代码。现在你可以写：

要用它的话，你可以写：

        filterApples(inventory, Apple::isGreenApple);

或者

        filterApples(inventory, Apple::isHeavyApple);

接下来的两章会详细讨论它是怎么工作的。现在重要的是你可以在Java 8里面传递方法了！

1.3.3 从传递方法到Lambda

把方法作为值来传递显然很有用，但要是为类似于isHeavyApple和isGreenApple这种可能只用一两次的短方法写一堆定义就有点儿烦人了。不过Java 8也解决了这个问题，它引入了一套新记法（匿名函数或Lambda），让你可以写

        filterApples(inventory, (Apple a) -> GREEN.equals(a.getColor()) );

或者

        filterApples(inventory, (Apple a) -> a.getWeight() > 150 );

甚至

        filterApples(inventory, (Apple a) -> a.getWeight() < 80 ||
                                              RED.equals(a.getColor()) );

所以，你甚至不需要为只用一次的方法写定义。代码更干净、更清晰，因为你用不着去找自己到底传递了什么代码。但要是Lambda的长度多于几行（它的行为也不是一目了然）的话，那你还是应该用方法引用来指向一个有描述性名称的方法，而不是使用匿名的Lambda。你应该以代码的清晰度为准绳。

Java 8的设计师几乎可以就此打住了，要不是有了多核CPU，可能他们真的就到此为止了。函数式编程竟然如此强大，后面你会有更深的体会。本来，Java加上filter和几个相关的东西作为通用库方法就足以让人满意了，比如

        static <T> Collection<T> filter(Collection<T> c, Predicate<T> p);

这样你甚至不需要写filterApples了，因为比如先前的调用

        filterApples(inventory, (Apple a) -> a.getWeight() > 150 );

就可以直接调用库方法filter：

        filter(inventory, (Apple a) -> a.getWeight() > 150 );

但是，为了更好地利用并行，Java的设计师没有这么做。Java 8中有一整套新的类Collection API——Stream，它有一套类似于函数式程序员熟悉的filter的操作，比如map、reduce，还有接下来要讨论的在Collection和Stream之间做转换的方法。

1.4 流

几乎每个Java应用都会制造和处理集合。但集合用起来并不总是那么理想。比方说，你需要从一个列表中筛选金额较高的交易，然后按货币分组。你需要写一大堆模板代码来实现这个数据处理命令，如下所示：

此外，很难一眼看出这些代码是做什么的，因为有好几个嵌套的控制流指令。

有了Stream API，你现在可以这样解决这个问题了：

这看起来有点儿神奇，不过现在先不用担心。第4～7章会专门讲述怎么理解Stream API。现在值得注意的是，Stream API处理数据的方式与Collection API不同。用集合的话，你得自己管理迭代过程。你得用for-each循环一个个地迭代元素，然后再处理元素。我们把这种数据迭代方法称为外部迭代。相反，有了Stream API，你根本用不着操心循环的事情。数据处理完全是在库内部进行的。我们把这种思想叫作内部迭代。第4章还会谈到这些思想。

使用集合的另一个头疼之处是，想想看，要是交易量非常庞大，你要怎么处理这个巨大的列表呢？单个CPU根本搞不定这么大量的数据，但你很可能已经有了一台多核计算机。理想情况下，你可能想让这些CPU核共同分担处理工作，以缩短处理时间。理论上来说，要是你有八个核，那并行起来，处理数据的速度应该是单核的八倍。

多线程并非易事

问题在于，通过多线程代码来利用并行（使用先前Java版本中的Thread API）并非易事。你得换一种思路：线程可能会同时访问并更新共享变量。因此，如果没有协调好，那么数据可能会被意外改变。相比一步步执行的顺序模型，这个模型不太好理解。比如，图1-5就展示了如果没有同步好，两个线程同时向共享变量sum加上一个数时，可能会出现的问题。

Java 8也用Stream API（java.util.stream）解决了这两个问题：集合处理时的模板化和晦涩，以及难以利用多核。这样设计的第一个原因是，有许多反复出现的数据处理模式，类似于前一节所说的filterApples或SQL等数据库查询语言里熟悉的操作，如果库中有这些就会很方便：根据标准筛选数据（比如较重的苹果），提取数据（例如抽取列表中每个苹果的重量字段），或给数据分组（例如，将一个数字列表分为奇数列表和偶数列表）等。第二个原因是，这类操作常常可以并行。例如，如图1-6所示，在两个CPU上筛选列表，可以让一个CPU处理列表的前一半，另一个CPU处理后一半，这称为分支步骤➊。CPU随后对各自的半个列表做筛选➋。最后❸，一个CPU会将两个结果合并（Google搜索这么快就与此紧密相关，当然用的CPU远远不止两个）。

到这里，我们只是说新的Stream API和Java现有的Collection API的行为差不多，它们都能够访问数据项目的序列。不过，现在最好记住，Collection主要是为了存储和访问数据，Stream则主要用于描述对数据的计算。这里的关键点在于，Stream API允许并提倡并行处理一个Stream中的元素。虽然乍看上去可能有点儿怪，但筛选一个Collection（将上一节的filterApples应用在一个List上）的最快方法常常是将其转换为Stream，进行并行处理，然后再转换回List，下面列举的串行和并行的例子都是如此。我们这里还只是说“几乎免费的并行”，让你稍微体验一下，如何利用Stream和Lambda表达式顺序或并行地从一个列表里筛选比较重的苹果。

顺序处理：

        import static java.util.stream.Collectors.toList;
        List<Apple> heavyApples =
            inventory.stream().filter((Apple a) -> a.getWeight() > 150)
                                .collect(toList());

并行处理：

        import static java.util.stream.Collectors.toList;
        List<Apple> heavyApples =
            inventory.parallelStream().filter((Apple a) -> a.getWeight() > 150)
                                        .collect(toList());

第7章会详细探讨Java 8中的并行数据处理及其特点。在加入所有这些新“玩意儿”改进Java的时候，Java 8设计者发现的一个现实问题就是现有的接口也在改进。比如，Collections.sort方法真的应该属于List接口，但从来没有放在后者里。理想情况下，你会希望做list.sort (comparator)，而不是Collections.sort(list, comparator)。这看起来无关紧要，但是在Java 8之前，你可能会更新一个接口，然后发现你把所有实现它的类也给更新了——简直是逻辑灾难！这个问题在Java 8里由默认方法解决了。

1.5 默认方法及Java模块

正如前文所介绍的，现代系统倾向于基于组件进行构建，而这些组件可能源自第三方。历史上，Java对此的支持非常薄弱，它只支持由几个Java包组成的JAR文件，并且这些Java包也没什么结构。此外，要演进这些包中的接口也比较困难——改动一个Java接口时，实现该接口的所有类都会受影响。Java 8和Java 9已经开始着手改进这一问题。

首先，Java 9提供了模块系统，允许你通过语法定义由一系列包组成的模块——通过它你能更好地控制命名空间和包的可见性。模块对简单的类JAR组件进行了增强，使其具备了结构，既能作为用户文档，也能由机器进行检查。第14章会详细探讨这部分内容。其次，Java 8引入了默认方法来支持接口的演进。第13章会详细介绍默认方法。它们非常重要，因为使用接口时你经常会碰到，然而大多数的程序员可能并不需要编写默认方法，因为默认方法只是推进程序演进的一种技术，并不会直接帮助你实现某个特性。本节会基于一个例子简要地介绍默认方法。

1.4节中给出了下面这段Java 8示例代码：

        List<Apple> heavyApples1 =
            inventory.stream().filter((Apple a) -> a.getWeight() > 150)
                                .collect(toList());
        List<Apple> heavyApples2 =
            inventory.parallelStream().filter((Apple a) -> a.getWeight() > 150)
                                        .collect(toList());

但这里有个问题：在Java 8之前，List<T>并没有stream或parallelStream方法，它实现的Collection<T>接口也没有，因为当初还没有想到这些方法嘛！可没有这些方法，这些代码就不能编译。换作你自己的接口的话，最简单的解决方案就是让Java 8的设计者把stream方法加入Collection接口，并加入ArrayList类的实现。

可要是这样做，对用户来说就是噩梦了。有很多集合框架都用Collection API实现了接口。但给接口加入一个新方法，意味着所有的实体类都必须为其提供一个实现。语言设计者没法控制Collection所有现有的实现，这下你就进退两难了：你如何改变已发布的接口而不破坏已有的实现呢？

Java 8的解决方法就是打破最后一环——接口如今可以包含实现类没有提供实现的方法签名了！那谁来实现它呢？缺失的方法主体随接口提供了（因此就有了默认实现），而不是由实现类提供。

这就给接口设计者提供了一种扩充接口的方式，而不会破坏现有的代码。Java 8在接口声明中使用新的default关键字来表示这一点。

例如，在Java 8里，你可以直接对List调用sort方法。它是用Java 8 List接口中如下所示的默认方法实现的，它会调用Collections.sort静态方法：

        default void sort(Comparator<? super E> c) {
            Collections.sort(this, c);
        }

这意味着List的任何实体类都不需要显式实现sort，而在以前的Java版本中，除非提供了sort的实现，否则这些实体类在重新编译时都会失败。

不过请稍等，一个类可以实现多个接口，不是吗？那么，如果在好几个接口里有多个默认实现，是否意味着Java中有了某种形式的多重继承？是的，在某种程度上是这样。第13章中会谈到，Java 8用一些限制来避免出现类似于C++中臭名昭著的菱形继承问题。

1.6 来自函数式编程的其他好思想

前几节介绍了Java从函数式编程引入的两个核心思想：将方法和Lambda作为一等值，以及在没有可变共享状态时，函数或方法可以有效、安全地并行执行。这两种思想新的Stream API都用到了。

常见的函数式语言，如SML、OCaml、Haskell，还提供了进一步的结构来帮助程序员，其中之一就是通过显式使用更多的描述性数据类型来避免null。确实，计算机科学巨擘之一托尼·霍尔（Tony Hoare）在2009年伦敦QCon上的演讲中说道：

我把它叫作我“价值亿万美元的错误”，就是在1965年发明了空引用……我无法抵抗放进一个空引用的诱惑，仅仅是因为它实现起来非常容易。

Java 8提供了一个Optional<T>类，如果你能一致地使用它，就能帮助你避免出现Null-PointerException。这是一个容器对象，它既可以包含值，也可以不包含值。Optional<T>提供了方法来明确地处理值不存在的情况，这样就可以避免NullPointerException了。换句话说，它通过类型系统，允许你表明一个变量可能缺失值。第11章会详细讨论Optional<T>。

第二个思想是（结构化的）模式匹配。这个术语最早用在数学里，例如：

        f(0) = 1
        f(n) = n＊f(n-1) otherwise

Java中，你可以使用if-then-else或switch语句表达同样的语义。其他语言已经证实，对于更复杂的数据类型，在表达编程思想时，使用模式匹配比if-then-else更简明。你也可以采用多态和方法重写替代if-then-else来处理这种类型的数据，但是，到底哪种方式更适合，在语言设计上仍然有很多争论。我们认为两者都是有用的工具，你都应该掌握。不幸的是，Java 8并不完全支持模式匹配，我们会在第19章介绍如何用Java表达模式匹配。此外，还会介绍一个Java改进提议，讨论如何在未来的Java版本中支持模式匹配。与此同时，我们会用Scala语言（这是另一种基于JVM的类Java语言，它启发了Java的一些新特性，更多内容参见第20章）的一个例子进行介绍。譬如，你要设计一个程序，要对描述算术表达式的树做基本的简化。假设数据类型Expr代表了这个表达式，你可以用Scala编写如下代码，将Expr拆分为各个部分，然后返回一个新的Expr：

这里，Scala的语法expr match就对应于Java中的switch (expr)。你暂时不用担心不理解这段代码，第19章会介绍更多关于模式匹配的内容。现在，你可以把模式匹配看作switch的扩展形式，它能够同时将一个数据类型分解成元素。

为什么Java中的switch语句要局限于原始类型值和Strings呢？函数式语言倾向于让switch支持更多的数据类型，甚至允许模式匹配（就像Scala语言中match的操作）。面向对象设计中，常用的访客模式可以用来遍历一组类（比如汽车的不同组件：车轮、发动机、底盘等），并对每个访问的对象执行操作。模式匹配的优势之一是编译器能够检测常见的错误，例如：“Brakes类是用来表示Car类的组件的一族类。你忘记了要显式处理它。”

第18章和第19章会全面介绍函数式编程，以及如何在Java 8中编写函数式风格的程序，包括库中提供的函数工具。第20章会讨论Java 8的功能并与Scala进行比较。Scala和Java一样基于JVM实现，且近年来发展迅速，已经在编程语言生态系统的一些方面威胁到了Java。这部分内容放在了本书的后面几章，你会进一步了解Java 8和Java 9为什么加上了这些新功能。

1.7 小结

以下是本章中的关键概念。

❏ 请记住语言生态系统的思想，以及语言面临的“要么改变，要么衰亡”的压力。虽然Java可能现在非常有活力，但你可以回忆一下其他曾经也有活力但未能及时改进的语言的命运，如COBOL。

❏ Java 8中新增的核心内容提供了令人激动的新概念和功能，方便我们编写既有效又简洁的程序。

❏ Java 8之前的编程实践并不能很好地利用多核处理器。

❏ 函数是一等值。记住方法如何作为函数式值来传递，还有Lambda是怎样写的。

❏ Java 8中流的概念使得集合的许多方面得以推广，但流让代码更易读，并允许并行处理流元素。

❏ Java对基于大型组件的程序设计以及系统需要不断演化的接口的支持一直都不太好。现在，你可以使用Java 9的模块构建你的系统，使用默认方法支持接口的持续演化，而不影响实现该接口的所有类。

❏ 其他来自函数式编程的有趣思想，包括处理null和使用模式匹配。