Lambda表达式

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

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

类型检查

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

类型检查过程可以分解为如下所示。

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

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

同样的Lambda,不同的函数式接口

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

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

这里，第一个赋值的目标类型是Callable<Integer>,第二个赋值的目标类型是PrivilegedAction<Integer>。
同一个Lambda可用于多个不同的函数式接口：

Comparator<Apple> c1 = (Apple al,Apple a2) -> a1.getWeight().compareTo(a2.getWeight ());

ToIntBiFunction<Apple,Apple> c2 = (Apple al,Apple a2) -> a1.getWeight().compareTo(a2.getWeight ());

BiFunction<Apple,Apple,Integer> c3 = (Apple al,Apple a2) -> a1.getWeight().compareTo(a2.getWeight ());

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

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 = s -> list.add(s);
// Consumer返回了一个void
Consumer<String> b = s -> list.add(s);

到现在为止，应该能够很好地理解在什么时候以及在哪里可以使用Lambda表达式了。它们可以从赋值的上下文、方法调用的上下文(参数和返回值),以及类型转换的上下文中获得目标类型。

测验:类型检查——为什么下面的代码不能编译呢?
该如何解决这个问题呢?
Object o = () -> {System.out.println("Tricky example");};

答案：Lambda表达式的上下文是Object(目标类型)。但Object不是一个函数式接口。
为了解决这个问题，可以把目标类型改成Runnable,它的函数描述符是()-> void:
Runnable r =() -> {System.out.println("Tricky example");};

已经见过如何利用目标类型来检查一个Lambda是否可以用于某个特定的上下文。其实，它也可以用来做一些略有不同的事：推断Lambda参数的类型。

类型推断

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

//参数a没有显式类型
List<Apple> greenApples =filter(inventory, a -> "green".equals(a.getcolor()));

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

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

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

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

使用局部变量

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

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

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

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

对局部变量的限制

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

第二，这一限制不鼓励使用改变外部变量的典型命令式编程模式。

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

Java 8代码中的另一个功能：方法引用。可以把它们视为某些Lambda的快捷写法。