java8 接口 变量_Java 8 新特性之 接口改进和Lambdas

测试环境

$ java -version

java version "1.8.0-ea"

Java(TM) SE Runtime Environment (build 1.8.0-ea-b106)

Java HotSpot(TM) 64-Bit Server VM (build 25.0-b48, mixed mode)

IntelliJ IDEA 12.1.4

接口改进

以前Java的接口里只能声明方法和定义常量，现在可以在接口里定义静态方法和默认方法。

定义静态方法

定义静态(static)方法带来的好处就是可以减少创建工具类的需求了。比如 java.util.Collection 接口定义了一个集合，对于此接口实例操作的很多通用方法都是通过工具类 java.util.Collections 来提供的，现在可以在接口里定义静态方法，我们就可以把工具类里的静态方法直接移到接口类里，不需要独立创建工具类了。

下面是Java8里添加到接口 java.util.Comparator 的一个静态方法：

public static > Comparator naturalOrder() {

return (Comparator) Comparators.NaturalOrderComparator.INSTANCE;

}

定义默认方法

另一个改进是，可以在不破坏现有接口实现的前提下添加默认(default)方法。比如 java.lang.Iterable 接口现在拥有一个默认的 forEach 方法：

public default void forEach(Consumer super T> action) {

Objects.requireNonNull(action);

for (T t : this) {

action.accept(t);

}

}

默认方法不能覆盖 equals, hashCode, toString 方法

一个接口不能提供Object类里的任何方法的默认实现。这意味着不能在接口里提供 equals, hashCode, toString 方法的默认实现。

这里列出一个具有足够说服力的理由：

It would become more difficult to reason about when a default method is invoked. Right now it’s simple: if a class implements a method, that always wins over a default implementation. Since all instances of interfaces are Objects, all instances of interfaces have non-default implementations of equals/hashCode/toString already. Therefore, a default version of these on an interface is always useless, and it may as well not compile.

大意是：由于所有接口的实例都是Objects，那么所有实例都已有 equals/hashCode/toString 这些方法的非默认实现。因此，接口上这些方法的默认版本是没有用的，可能不会被编译。

函数接口

函数接口是Java8引入的一个核心概念。如果一个接口只定义了一个抽象方法，它就是函数接口。例如java.lang.Runnable就是一个函数接口，因为它只定义了一个抽象方法： public void run()。

默认方法不是抽象的，所以一个函数接口可以定义任意多的默认方法。

新引入的注解 @FunctionalInterface 用来表明接口准备成为函数接口，但不管有没有这个注解，编译器都认为只有一个抽象方法的接口是函数接口。

Lambdas

函数接口一个极具价值的属性是可以在lambdas里实例化。下面是lambdas的一些实例：

(param1 ParamType1, param2 ParamTeyp2, ... ) -> { statements; } // lambdas 完整形式

(int x, int y) -> { return x + y; } // 完整输入参数类型，具有返回语句的语句块

(x, y) -> x + y // 自动类型推导参数类型，语句块只有一条 return 语句时可以省略大括号和return关键字，

x -> x * x // 只有一个输入参数，可以省略入参列表的小括号。

() -> x // 如果没有入参，小括号不能省略。

x -> { System.out.println(x); } // 没有返回语句，语句块的大括号不能省略。

方法引用

静态方法引用： String::valueOf。

非静态方法引用： Object::toString。

构造函数引用： ArrayList::new。

捕获方法引用： x::toString。

方法引用等价的lambda表达式：

String::valueOf x -> String.valueOf(x)

Object::toString x -> x.toString()

x::toString () -> x.toString() // 这个好像不行

ArrayList::new () -> new ArrayList<>()

当然，在Java里可以重载方法。类可以有很多有同样名字但不同参数的方法，构造函数也一样。用哪个方法取决于它是用于哪个函数接口的。

一个lambda与一个函数接口有相同的“形状”时被认为是兼容的。这里的“形状”是指：输入输出的类型和声明的受检查异常。

举例

List strList = new ArrayList<>();

strList.add("no");

strList.add("hello");

strList.add("world");

long count = strList

.stream()

.filter((String str) -> { return str != null; }) // 完整的lambda表达式

.filter(str -> { return str.length() > 0; }) // 参数类型自动推导；只有一个输入参数，省略小括号

.filter(str -> str.length() > 3) // 语句块只是返回一个表达式的值，省略return语句直接返回表达式的值；省略语句块的花括号。

.map(String::length) // 用方法代替lambda表达式

.count();

System.out.println("\n\ncount:" + count);

Runnable r = () -> { System.out.println("Running!"); };

Comparator c = (a, b) -> Integer.compare(a.length(), b.length());

捕获与非捕获lambdas

如果lambda表达式访问一个定义在lambda体之外的非静态变量或对象，则说Lambda表达式是“捕获的”。在下面的例子里，return返回的lambda捕获了变量 x：

int x = 5;

return y -> x + y;

为了让这个lambda声明是合法的，它捕获的变量必须是“effectively final”。这样，它们必须标记为 final 或 赋值(被lambda捕获)之后就不能再修改。

一个lambda捕获与否对性能有影响。一个非捕获的lambda一般比一个捕获的更高效。虽然这没有在任何规范里定义，你不能依赖于程序员的正确性。一个非捕获的lambda只需要计算一次。然后，它将返回一个完全相同的实例。捕获的lambda在每次遇到时都需要进行计算，当前的动作与实例化匿名内部类非常类似。

举例

private static int count = 0;

public static void main(String[] args) {

// basic ();

testCapture();

}

public static void testCapture() {

Runnable run = capture();

count++;

Runnable run2 = capture();

new Thread(run).start();

new Thread(run2).start();

}

public static Runnable capture() {

int x = 5;

Runnable r = () -> { System.out.println("x is:" + x); System.out.println("count is:" + count); };

// 在这里给x赋值也会报错 Variable used in lambda expression should be effectively final

return r;

}

执行后的输出是：

x is:5

count is:1

x is:5

count is:1

对于x的值都没有问题，但count的值就要注意了。进入testCapture()方法的时候，count的值是0，第一次捕获的时候也是0，然后进行加1，再次进行捕获，然后用两个线程计算捕获的值，得到的值是1和1，而不是0和1，因为，lambda捕获只是捕获了变量的引用，而不是变量的值。

lambdas 不能做的

有些约束是lambdas不提供的，为了简单和由于时间约束。

非final变量捕获

如果一个变量被赋予新值，它就不能用在lambda里。“final”关键字不是必须的，但变量必须是“effectively final”(如前所述)。下面的代码将报编译错误：

int count = 0;

List strings = Arrays.asList("a", "b", "c");

strings.forEach(s -> {

count++; // error: can't modify the value of count

});

注意，如果count是个非局部变量，它将是可以修改的。

异常透明

如果lambda代码体会抛出受检查的异常，函数接口必须声明它会抛出的受检查异常。异常不会传播到包含方法。下面的代码不能编译：

void appendAll(Iterable values, Appendable out)

throws IOException { // doesn't help with the error

values.forEach(s -> {

out.append(s); // error: can't throw IOException here

// Consumer.accept(T) doesn't allow it

});

}

简单说就是lambda的代码块不能抛出受检查异常。

流程控制(break，early return)

在上面的forEach例子里，传统的“continue”可以是通过lambda体内的“return;”语句来达到。然而，没有方法来中断loop循环或从lambda内返回一个结果到包含方法。举例：

import java.util.Arrays;

public class Lambdas2 {

public static void main(String[] args) {

Arrays.asList(args).forEach(s -> {

if (s.length() > 3) {

return; // 这个return语句并不能终止loop循环。

}

});

}

}

上面的代码生成的字节码是这样的：

$ javap -c Lambdas2.class

Compiled from "Lambdas2.java"

public class Lambdas2 {

public Lambdas2();

Code:

0: aload_0

1: invokespecial #1 // Method java/lang/Object."":()V

4: return

public static void main(java.lang.String[]);

Code:

0: aload_0

1: invokestatic #2 // Method java/util/Arrays.asList:([Ljava/lang/Object;)Ljava/util/List;

4: invokedynamic #3, 0 // InvokeDynamic #0:accept:()Ljava/util/function/Consumer;

9: invokeinterface #4, 2 // InterfaceMethod java/util/List.forEach:(Ljava/util/function/Consumer;)V

14: return

}

结合前面 java.lang.Iterable 接口的forEach方法实现可知，目前的lambda应该是编译成一个对象的，然后再对每个元素调用此对象的accept方法，也就是说lambda代码块被编译成Consumer的accept方法的代码，所以不能在lambda代码块里控制forEach的loop流程。

为什么抽象类不能用lambda实例化？

一个抽象类，即使它只有一个抽象方法，也不能用lambda实例化。

大多数反对这个的争论是这会增加阅读lambda的困难。以这种方式实例化一个抽象类会导致执行额外的隐藏代码：抽象类构造器里的代码。

另一个理由是这抛弃了优化lambda的可能。在将来，lambda可能将不再实例化为对象。允许用户以lambda的形式声明抽象类将阻止这类优化。

欢迎关注我的微信公众号: coderbee笔记，可以更及时回复你的讨论。