3.5　类型检查、类型推断以及限制

3.5　类型检查、类型推断以及限制

当我们第一次提到Lambda表达式时，说它可以为函数式接口生成一个实例。然而，Lambda表达式本身并不包含它在实现哪个函数式接口的信息。为了全面了解Lambda表达式，你应该知道Lambda的实际类型是什么。

3.5.1　类型检查

Lambda的类型是从使用Lambda的上下文推断出来的。上下文（比如，接受它传递的方法的参数，或接受它的值的局部变量）中Lambda表达式需要的类型称为目标类型。让我们通过一个例子，看看当你使用Lambda表达式时背后发生了什么。图3-4概述了下列代码的类型检查过程。

List<Apple> heavierThan150g =
        filter(inventory, (Apple apple) -> apple.getWeight() > 150);

类型检查过程分解如下。

第一，你要找出filter方法的声明。
第二，要求它是Predicate（目标类型）对象的第二个正式参数。
第三，Predicate是一个函数式接口，定义了一个叫作test的抽象方法。
第四，test方法描述了一个函数描述符，它可以接受一个Apple，并返回一个boolean。
第五，filter的任何实际参数都必须匹配这个要求。

图 3-4　解读Lambda表达式的类型检查过程

这段代码是有效的，因为我们所传递的Lambda表达式也同样接受Apple为参数，并返回一个boolean。请注意，如果Lambda表达式抛出一个异常，那么抽象方法所声明的throws语句也必须与之匹配。

3.5.2　同样的Lambda，不同的函数式接口

有了目标类型的概念，同一个Lambda表达式就可以与不同的函数式接口联系起来，只要它们的抽象方法签名能够兼容。比如，前面提到的Callable和PrivilegedAction，这两个接口都代表着什么也不接受且返回一个泛型T的函数。因此，下面两个赋值是有效的：

Callable<Integer> c = () -> 42;
PrivilegedAction<Integer> p = () -> 42;

这里，第一个赋值的目标类型是Callable，第二个赋值的目标类型是PrivilegedAction。

在表3-3中展示了一个类似的例子，同一个Lambda可用于多个不同的函数式接口：

Comparator<Apple> c1 =
  (Apple a1, Apple a2) -> a1.getWeight().compareTo(a2.getWeight());
ToIntBiFunction<Apple, Apple> c2 =
  (Apple a1, Apple a2) -> a1.getWeight().compareTo(a2.getWeight());
BiFunction<Apple, Apple, Integer> c3 =
  (Apple a1, Apple a2) -> a1.getWeight().compareTo(a2.getWeight());

菱形运算符

那些熟悉Java演变的人会记得，Java 7中已经引入了菱形运算符（<>），利用泛型推断从上下文推断类型的思想（这一思想甚至可以追溯到更早的泛型方法）。一个类实例表达式可以出现在两个或更多不同的上下文中，并会像下面这样推断出适当的类型参数：
List<String> listOfStrings = new ArrayList<>();
List<Integer> listOfIntegers = new ArrayList<>();

特殊的void兼容规则

如果一个Lambda的主体是一个语句表达式，它就和一个返回void的函数描述符兼容（当然需要参数列表也兼容）。例如，以下两行都是合法的，尽管List的add方法返回了一个boolean，而不是Consumer上下文（T -> void）所要求的void：
// Predicate返回了一个boolean
Predicate<String> p = (String s) -> list.add(s);
// Consumer返回了一个void
Consumer<String> b = (String s) -> list.add(s);

到现在为止，你应该能够很好地理解在什么时候以及在哪里可以使用Lambda表达式了。它们可以从赋值的上下文、方法调用的上下文（参数和返回值），以及类型转换的上下文中获得目标类型。为了检验你的掌握情况，请试试测验3.5。

测验3.5：类型检查——为什么下面的代码不能编译呢？

你该如何解决这个问题呢？
Object o = () -> { System.out.println("Tricky example"); };
答案：Lambda表达式的上下文是Object（目标类型）。但Object不是一个函数式接口。为了解决这个问题，你可以把目标类型改成Runnable，它的函数描述符是() -> void：
Runnable r = () -> { System.out.println("Tricky example"); };
你还可以通过强制类型转换将Lambda表达式转换成Runnable，显式地生成一个目标类型，以这种方式来修复这个问题：
Object o = (Runnable) () -> { System.out.println("Tricky example"); };
处理方法重载时，如果两个不同的函数式接口却有着同样的函数描述符，使用这个技巧有立竿见影的效果。到底该选择使用哪一个方法签名呢？为了消除这种显式的二义性，你可以对Lamda进行强制类型转换。

譬如，下面这段代码中，方法调用execute( () -> {} )使用了execute方法，不过它存在着二义性，因为Runnable和Action接口中都提供了同样的函数描述符：
public void execute(Runnable runnable) {
    runnable.run();
}
public void execute(Action<T> action) {
    action.act();
}
@FunctionalInterface
interface Action {
    void act();
}
然而，通过强制类型转换表达式，这种显式的二义性被消除了：
execute((Action) () -> { });

你已经了解如何利用目标类型来判断某个Lambda是否适用于某个特定的上下文。其实，它还可以用来做一些别的事：推断Lambda参数的类型。

3.5.3　类型推断

你还可以进一步简化你的代码。Java编译器会从上下文（目标类型）推断出用什么函数式接口来配合Lambda表达式，这意味着它也可以推断出适合Lambda的签名，因为函数描述符可以通过目标类型来得到。这样做的好处在于，编译器可以了解Lambda表达式的参数类型，这样就可以在Lambda语法中省去标注参数类型。换句话说，Java编译器会像下面这样推断Lambda的参数类型：3

3请注意，当Lambda仅有一个类型需要推断的参数时，参数名称两边的括号也可以省略。

List<Apple> greenApples =
        filter(inventory, apple -> GREEN.equals(apple.getColor()));       ←---- 参apple没有显式类型

Lambda表达式有多个参数，代码可读性的好处就更为明显。例如，你可以这样来创建一个Comparator对象：

Comparator<Apple> c =
  (Apple a1, Apple a2) -> a1.getWeight().compareTo(a2.getWeight());       ←---- 没有类型推断
Comparator<Apple> c =
  (a1, a2) -> a1.getWeight().compareTo(a2.getWeight());       ←---- 有类型推断

请注意，有时候显式写出类型更易读，有时候去掉它们更易读。没有什么法则说哪种更好，对于如何让代码更易读，程序员必须做出自己的选择。

3.5.4　使用局部变量

我们迄今为止所介绍的所有Lambda表达式都只用到了其主体里面的参数。但Lambda表达式也允许使用自由变量（不是参数，而是在外层作用域中定义的变量），就像匿名类一样。它们被称作捕获Lambda。例如，下面的Lambda捕获了portNumber变量：

int portNumber = 1337;
Runnable r = () -> System.out.println(portNumber);

尽管如此，还有一点点小麻烦：关于能对这些变量做什么有一些限制。Lambda可以没有限制地捕获（也就是在其主体中引用）实例变量和静态变量。但局部变量必须显式声明为final，或事实上是final。换句话说，Lambda表达式只能捕获指派给它们的局部变量一次。（注：捕获实例变量可以被看作捕获最终局部变量this。）例如，下面的代码无法编译，因为portNumber变量被赋值两次：

int portNumber = 1337;
Runnable r = () -> System.out.println(portNumber);       ←---- 错误：Lambda表达式引用的局部变量必须是最终的（final）或事实上最终的portNumber = 31337;

对局部变量的限制

你可能会问自己，为什么局部变量有这些限制。第一，实例变量和局部变量背后的实现有一个关键不同。实例变量都存储在堆中，局部变量则保存在栈上。如果Lambda可以直接访问局部变量，而且Lambda是在一个线程中使用的，则使用Lambda的线程，可能会在分配该变量的线程将这个变量收回之后，去访问该变量。因此，Java在访问自由局部变量时，实际上是在访问它的副本，而不是访问基本变量。如果局部变量仅仅赋值一次那就没有什么区别了——因此就有了这个限制。

第二，这一限制不鼓励你使用改变外部变量的典型命令式编程模式（我们会在以后的各章中解释，这种模式会阻碍很容易做到的并行处理）。

闭包

你可能已经听说过闭包（closure，不要和Clojure编程语言混淆）这个词，可能会想Lambda是否满足闭包的定义。用科学的说法来说，闭包就是一个函数的实例，且它可以无限制地访问那个函数的非本地变量。例如，闭包可以作为参数传递给另一个函数。它也可以访问和修改其作用域之外的变量。现在，Java 8的Lambda和匿名类可以做类似于闭包的事情：它们可以作为参数传递给方法，并且可以访问其作用域之外的变量。但有一个限制：它们不能修改定义Lambda的方法的局部变量的内容。这些变量必须是隐式最终的。可以认为Lambda是对值封闭，而不是对变量封闭。如前所述，这种限制存在的原因在于局部变量保存在栈上，并且隐式表示它们仅限于其所在线程。如果允许捕获可改变的局部变量，就会引发造成线程不安全的新的可能性，而这是我们不想看到的（实例变量可以，因为它们保存在堆中，而堆是在线程之间共享的）。

现在，我们来介绍你会在Java 8代码中看到的另一个功能：方法引用。可以把它们视为某些Lambda的快捷写法。

3.5 类型检查、类型推断以及限制