注：本文是笔者在上述地址学习 Java SE 8 Lambda 表达式的笔记。笔者的学习习惯，是在学习过程中将内容敲打一遍，记忆会更加深刻。本文只节选了原文一部分，更多内容详见原文。
一. 背景
不过有些 Java 对象只是对单个函数的封装。例如下面这个典型用例：Java API 中定义了一个接口（一般被称为回调接口），用户通过提供这个接口的实例来传入指定行为，例如：
public interface ActionListener {
void actionPerformed(ActionEvent e);
}
这里并不需要专门定义一个类来实现 ActionListener 接口，因为它只会在调用处被使用一次。用户一般会使用匿名类型把行为内联（inline）：
button.addActionListener(new ActionListener) {
public void actionPerformed(ActionEvent e) {
ui.dazzle(e.getModifiers());
}
}
很多库都依赖于上面的模式。对于并行 API 更是如此，因为我们需要把待执行的代码提供给并行API，并行编程是一个非常值得研究的领域，因为在这里摩尔定律得到了重生：尽管我们没有更快的 CPU，但是我们有更多的 CPU。
随着回调模式和函数式编程风格的日益流行，我们需要在 Java 中提供一种尽可能轻量级的将代码封装为数据的方法。但匿名内部类并不是一个好的选择，因为：
- 语法过于冗余；
- 匿名类中的this和变量名容易使人产生误解；
- 类型载入和实例创建语义不够灵活；
- 无法捕获非final的局部变量；
- 无法对控制流进行抽象；
对于上述问题，在 Java 8 中大多都被解决：
- 提供更简洁的语法和局部作用域规则 -> 解决了问题 1 和问题 2
- 提供更加灵活而且便于优化的表达式语义 -> 绕开了问题 3
- 允许编译器推断变量的“常量性” -> 减轻了问题 4
二. 函数式接口
上面提到的 ActionListener 接口只有一个方法，大多数回调接口都拥有这个特征。比如 Runnable 接口和 Comparator 接口。我们把这些只拥有一个方法的接口称为函数式接口。编译器会根据接口的结构自行判断。
注：
- 判断过程并非简单的对接口方法计数；
- API 作者们可以通过 @FunctionalInterface 注解来显式指定一个接口是函数式接口，加上这个注解之后，编译器就会验证该接口是否满足函数式接口的要求。
函数式类型的另一种方式，是引入一个全新的结构化函数类型：“箭头”类型。例如，一个接收 String 和 Object 并返回 int 的函数类型可以被表示为：
(String, Object) -> int
但 Sun 公司最终出于下面的原因将其否定：
- 它会为Java类型系统引入额外的复杂度，并带来结构类型和指名类型的混用。而 Java 几乎全部使用指名类型；
- 它会导致类库风格的分歧——一些类库会继续使用回调接口，而另一些类库会使用结构化函数类型；
- 它的语法会变得十分笨拙；
- 每个函数类型很难拥有其运行时表示，使开发者受到类型擦除 (erasure) 的困扰和局限。例如：我们无法对方法 m(T->U) 和 m(X->Y) 进行重载；
所以 Sun 公司最终选择了“使用已知类型”这种方法。因为现有的类库大量使用了函数式接口，通过沿用这种模式，我们使得现有类库能够直接使用 lambda 表达式。
Java SE 7 中已经存在的函数式接口如下：
- java.lang.Runnable
- java.util.concurrent.Callable
- java.security.PrivilegedAction
- java.util.Comparator
- java.io.FileFilter
- java.beans.PropertyChangeListener
除此之外，Java SE 8 中增加了一个新的包：java.util.function。它里面包含了常用的函数式接口，例如：
- Predicate<T>: 接收 T 对象并返回 boolean；
- Consume<T>: 接收 T 对象，不返回值；
- Functio<T, R>: 接收 T 对象，返回 R 对象；
- Supplie<T>: 提供 T 对象（例如工厂），不接收值；
- UnaryOperato<T>: 接收 T 对象，返回 T 对象；
- BinaryOperator<T>: 接收两个 T 对象，返回 T 对象；
除了上面的这些基本的函数式接口，还有一些针对原始类型的特化函数式接口，例如 IntSupplier 和 LongBinaryOperator。（只为 int, long, double 提供了特化函数式接口，如果需要使用其它原始类型则需要进行类型转换）
同样，还有一些针对多个参数的函数式接口，例如 BiFunction<T, U, R>，它接收 T 对象和 U 对象，返回 R 对象。
三. lambda 表达式
lambda 表达式是匿名方法，它提供了轻量级的语法，从而解决了匿名内部类带来的冗余语法问题（又被称为“高度问题”）。下面是一些lambda表达式：
(int x, int y) -> x + y
() -> 42
(String s) -> { System.out.println(s); }
这几个表达式的意义如下：
- 第一个：lambda 表达式接收 x 和 y 这两个整形参数并返回它们的和；
- 第二个：lambda 表达式不接收参数，返回整数'42'；
- 第三个：lambda 表达式接收一个字符串并把它打印到控制台，不返回值。
lambda 表达式的语法由参数列表、箭头符号->和函数体组成。其中函数体既可以是一个表达式，也可以是一个语句块：
- 表达式：表达式会被执行然后返回执行结果；
- 语句块：语句块中的语句会被依次执行，就像方法中的语句一样；
- return语句会把控制权交给匿名方法的调用者；
- break和continue只能在循环中使用；
- 如果函数体有返回值，那么函数体内部的每一条路径都必须返回值；
lambda 表达式也会经常出现在嵌套环境中，比如说作为方法的参数。为了使 lambda 表达式在这些场景下尽可能简洁，我们去除了不必要的分隔符。不过在某些情况下我们也可以把它分为多行，然后用括号包起来，就像其它普通表达式一样。
下面是一些出现在语句中的lambda表达式：
FileFilter java = (File f) -> f.getName().endsWith("*.java");
String user = doPrivileged(() -> System.getProperty("user.name"));
new Thread(() -> {
connectToService();
sendNotification();
}).start();
四. 目标类型
对于给定的 lambda 表达式，它的类型是由其上下文推导而来。例如，下面代码中的 lambda 表达式类型是 ActionListener：
ActionListener l = (ActionEvent e) -> ui.dazzle(e.getModifiers());
这就意味着，同样的 lambda 表达式在不同上下文里可以拥有不同的类型。例如第一个 lambda 表达式 () -> "done" 是 Callable 的实例，而第二个 lambda 表达式则是 PrivilegedAction 的实例。
Callable<String> c = () -> "done";
PrivilegedAction<String> a = () -> "done";
编译器负责推导 lambda 表达式的类型。它利用 lambda 表达式所在上下文所期待的类型进行推导，这个被期待的类型被称为目标类型。lambda 表达式只能出现在目标类型为函数式接口的上下文中。
当然，lambda 表达式对目标类型也是有要求的。编译器会检查 lambda 表达式的类型和目标类型的方法签名是否一致。当且仅当下面所有条件均满足时，lambda 表达式才可以被赋给目标类型 T：
- T 是一个函数式接口；
- lambda 表达式的参数和 T 的方法参数在数量和类型上一一对应
- lambda 表达式的返回值和 T 的方法返回值相兼容；
- lambda 表达式内所抛出的异常和 T 的方法 throws 类型相兼容；
由于函数式接口的目标类型已经了解 lambda 表达式的形式参数类型，所以我们没有必要把已知类型再重复一遍，即 lambda 表达式的参数类型可以从目标类型中得出。例如：
Comparator<String> c = (s1, s2) -> s1.compareToIgnoreCase(s2);
编译器可以推导出 s1 和 s2 的类型是 String。此外，当 lambda 的参数只有一个而且它的类型可以被推导得知时，该参数列表外面的括号可以被省略。例如：
FileFilter java = f -> f.getName().endsWith(".java");
button.addActionListener(e -> ui.dazzle(e.getModifiers()));
这些改进展示了我们的设计目标：“不要把高度问题转化成宽度问题。”语法元素能够尽可能的少，以便代码的读者能够直达 lambda 表达式的核心部分。
五. 目标类型的上下文
前文提到，lambda 表达式只能出现在拥有目标类型的上下文中。这些带有目标类型的上下文有：
- 变量声明
- 赋值
- 返回语句
- 数组初始化器
- 方法和构造方法的参数
- lambda 表达式函数体
- 条件表达式（? :）
- 转型（Cast）表达式
在变量声明、赋值、返回语句里，目标类型即是被赋值或被返回的类型：
Comparator<String> c;
c = (String s1, String s2) -> s1.compareToIgnoreCase(s2);
public Runnable toDoLater() {
return () -> {
System.out.println("later");
}
}
数组初始化器和赋值类似，只是这里的“变量”变成了数组元素，而类型是从数组类型中推导得知的：
filterFiles(new FileFilter[] {
f -> f.exists(), f -> f.canRead(), f -> f.getName().startsWith("q")
});
方法参数的类型推导要相对复杂，涉及到其它两个语言特性重载解析和参数类型推导。
重载解析会为一个给定的方法调用寻找最合适的方法声明。由于不同的声明具有不同的签名，当 lambda 表达式作为方法参数时，重载解析就会影响到 lambda 表达式的目标类型。编译器会通过它所得之的信息来做出决定。如果 lambda 表达式具有显式类型（参数类型被显式指定），编译器就可以直接使用 lambda 表达式的返回类型；如果 lambda 表达式具有隐式类型（参数类型被推导而知），重载解析则会忽略 lambda 表达式函数体而只依赖 lambda 表达式参数的数量。
如果在解析方法声明时存在二义性，我们就需要利用转型 (cast) 或显式 lambda 表达式来提供更多的类型信息。如果 lambda 表达式的返回类型依赖于其参数的类型，那么 lambda 表达式函数体有可能可以给编译器提供额外的信息，以便其推导参数类型。例如：
List<Person> ps = ...
Stream<String> names = ps.stream().map(p -> p.getName());
在上面的代码中，ps 的类型是 List<Person>，所以 ps.stream() 的返回类型是 Stream<Person>。map() 方法接收一个类型为 Function<T, R> 的函数式接口，这里 T 的类型即是 Stream 元素的类型，也就是 Person，而 R 的类型未知。由于在重载解析之后 lambda 表达式的目标类型仍然未知，我们就需要推导 R 的类型：通过对 lambda 表达式函数体进行类型检查，我们发现函数体返回 String，因此 R 的类型是 String，因而 map() 返回 Stream<String>。绝大多数情况下编译器都能解析出正确的类型，但如果碰到无法解析的情况，我们则需要：
- 使用显式 lambda 表达式（为参数 p 提供显式类型）以提供额外的类型信息；
- 把 lambda 表达式转型为 Function<Person, String>；
- 为泛型参数 R 提供一个实际类型。（Stream<String> names = ps.stream().<String>map(p -> p.getName())）
lambda 表达式本身也可以为它自己的函数体提供目标类型，也就是说 lambda 表达式可以通过外部目标类型推导出其内部的返回类型，这意味着我们可以方便的编写一个返回函数的函数：
Supplier<Runnable> c = () -> () -> { System.out.println("hi"); };
类似的，条件表达式可以把目标类型“分发”给其子表达式：
Callable<Integer> c = flag ? (() -> 23) : (() -> 42);
转型表达式 (Cast expression) 可以显式提供 lambda 表达式的类型，这个特性在无法确认目标类型时非常有用：
// 非法代码
// Object o = () -> { System.out.println("hi"); };
// 有效代码
Object o = (Runnable) () -> { System.out.println("hi"); };
六. 方法引用
lambda 表达式允许我们定义一个匿名方法，并允许我们以函数式接口的方式使用它。我们也希望能够在已有的方法上实现同样的特性。方法引用和 lambda 表达式拥有相同的特性，例如，它们都需要一个目标类型，并需要被转化为函数式接口的实例。不过我们并不需要为方法引用提供方法体，我们可以直接通过方法名称引用已有方法。
以下面的代码为例，假设我们要按照 name 或 age 为 Person 数组进行排序：
class Person {
private final String name;
private final int age;
public int getAge() { return age; }
public String getName() {return name; }
...
}
Person[] people = ...
Comparator<Person> byName = Comparator.comparing(p -> p.getName());
Arrays.sort(people, byName);
这段代码可以用方法引用代替 lambda 表达式：
Comparator<Person> byName = Comparator.comparing(Person::getName);
这里的 Person::getName 可以被看作为 lambda 表达式的简写形式。尽管方法引用不一定会把语法变的更紧凑，但它拥有更明确的语义：如果我们想要调用的方法拥有一个名字，我们就可以通过它的名字直接调用它。
因为函数式接口的方法参数对应于隐式方法调用时的参数，所以被引用方法签名可以通过放宽类型，装箱以及组织到参数数组中的方式对其参数进行操作，就像在调用实际方法一样：
// void exit(int status)
Consumer<Integer> b1 = System::exit;
// void sort(Object[] a)
Consumer<String[]> b2 = Arrays:sort;
// void main(String... args)
Consumer<String> b3 = MyProgram::main;
// void main(String... args)
Runnable r = Myprogram::mapToInt
七. 方法引用的种类
方法引用有很多种，它们的语法如下：
- 静态方法引用：ClassName::methodName
- 实例上的实例方法引用：instanceReference::methodName
- 超类上的实例方法引用：super::methodName
- 类型上的实例方法引用：ClassName::methodName
- 构造方法引用：Class::new
- 数组构造方法引用：TypeName[]::new
对于静态方法引用，我们需要在类名和方法名之间加入 "::" 分隔符，例如 Integer::sum。
对于具体对象上的实例方法引用，我们则需要在对象名和方法名之间加入分隔符：
Set<String> knownNames = ...
Predicate<String> isKnown = knownNames::contains;
这里的隐式 lambda 表达式会从 knownNames 中捕获 String 对象，而它的方法体则会通过 Set.contains 使用该 String 对象。有了实例方法引用，在不同函数式接口之间进行类型转换就变的很方便：
Callable<Path> c = ...
Privileged<Path> a = c::call;
引用任意对象的实例方法，都需要在实例方法名称和其所属类型名称间加上分隔符：
Function<String, String> upperfier = String::toUpperCase;
如果类型的实例方法是泛型的，那么我们就需要在 "::" 分隔符前提供类型参数，或者利用目标类型推导出其类型。
需要注意的是，静态方法引用和类型上的实例方法引用拥有一样的语法。编译器会根据实际情况做出决定。一般我们不需要指定方法引用中的参数类型，因为编译器往往可以推导出结果，但如果需要我们也可以显式在 :: 分隔符之前提供参数类型信息。
和静态方法引用类似，构造方法也可以通过 new 关键字被直接引用：
SocketImplFactory factory = MySocketImpl::new;
如果类型拥有多个构造方法，那么我们就会通过目标类型的方法参数来选择最佳匹配，这里的选择过程和调用构造方法时的选择过程是一样的。
如果待实例化的类型是泛型的，那么我们可以在类型名称之后提供类型参数，否则编译器则会依照"菱形"构造方法调用时的方式进行推导。
数组的构造方法引用的语法则比较特殊，为了便于理解，你可以假想存在一个接收int参数的数组构造方法。参考下面的代码：
IntFunction<int[]> arrayMaker = int[]::new;
int[] array = arrayMaker.apply(10) // 创建数组 int[10]
