Java 8 的新特性，有哪些？
- 为了更易于创建函数对象，加入了 functional interfaces, lambdas 和 method references
- 为了处理序列数据元素，加入了 Streams API
解释一下 function types
- 只含有一个抽象方法的接口或抽象类
解释一下 function objects
- function types的实例，相当于 functions 或者 actions
解释一下 functional interfaces
- 只含有一个抽象方法的接口
在创建函数对象时，为什么优先使用lambdas，而不使用匿名类
- 使用匿名类的实例作为函数对象，已经过时
- 匿名类冗长，Lambdas 支持类型推断，更简洁
举几个例子，说明Lambdas比匿名类好用
Collections.sort(words, new Comparator<String>() {
public int compare(String s1, String s2) {
return Integer.compare(s1.length(), s2.length());
}
});
Collections.sort(words,
(s1, s2) -> Integer.compare(s1.length(), s2.length()));
Collections.sort(words, comparingInt(String::length));
words.sort(comparingInt(String::length));
使用Lambdas的注意事项
- 由于Lambdas 缺少 names 和 documentation，如果一次计算不是自解释性的，或者超过3行，则最好不要放在Lambdas里。
- 只有在创建 functional interfaces 的实例时，才建议使用Lambdas
- Lambdas 和 匿名类一样，你不应该去序列化以及反序列化它们，如果你想序列化或反序列化一个function object，则使用一个 private static nested class
什么时候只能使用匿名类，而不能使用lambdas
- lambdas只限于functional interfaces，如果想创建含有多个抽象方法的实例，则要使用匿名类
- lambda不能获取对自己的引用，在lambdas中， this关键字指的是enclosing instance，在匿名类中，this关键字指的是anonymous class instance。
为什么优先使用method references，而不是lambdas
- 举个java8 Map接口中的merge方法的例子，第一行是使用lambdas，第二行是使用method references
map.merge(key, 1, (count, incr) -> count + incr);
map.merge(key, 1, Integer::sum);
- method references 往往能生成更简洁清晰的代码，如果一个lambdas的代码片段太长或太复杂，可以把这段代码抽出来生成一个新方法，可以对该新方法起个好名字，然后把lambdas替换成对该新方法的引用
- method 和 lambda在同一个类中时，或者使用Function接口中的identity方法，此时应该优先使用lambda，如下：
service.execute(GoshThisClassNameIsHumongous::action);
等价于
service.execute(() -> action());
相似地，
Function.identity()
等价于
x -> x
有哪几种方法引用？
- Static引用
Integer::parseInt
对应的Lambda
str -> Integer.parseInt(str)
- Bound引用
Instant.now()::isAfter
对应的Lambda
Instant then = Instant.now();
t -> then.isAfter(t)
- Unbound引用
String::toLowerCase
对应的Lambda
str -> str.toLowerCase()
- Class Constructor引用
TreeMap<K,V>::new
对应的Lambda
() -> new TreeMap<K,V>
- Array Constructor 引用
int[]::new
对应的Lambda
len -> new int[len]
优先使用 standard functional interfaces, 说说你对java.util.function.Function中的函数接口的了解
- java.util.Function中一共有43个函数接口，可以概括成6种基本函数接口，从这6种基础接口，可以推导出其他接口，同时每一种基本接口，都有对原始类型int, long 和 double的变体，6种基本函数接口如下:
| Interface | Function Signature | Example |
|---|---|---|
| UnaryOperator<T> | T apply(T t) | String::toLowerCase |
| BinaryOperator<T> | T apply(T t1, T t2) | BigInteger::add |
| Predicate<T> | boolean test(T t) | Collection::isEmpty |
| Function<T,R> | R apply(T t) | Arrays::asList |
| Supplier<T> | T get() | Instant::now |
| Consumer<T> | void accept(T t) | System.out::println |
在使用Streams API时，应该注意什么？
- 使用流，是为了让程序变得更shorter and clearer，如果流使你的程序在简洁的基础上，又便于阅读和维护，那么就去用它，否则就远离它
- 滥用流，会让程序变得难以阅读和维护
- 用 流 替换 loop 时，也要注意代码的可读性和维护性的问题
- forEach函数应该仅仅用于report流计算的结果，而不应该执行计算
在流中，如何使用无副作用的函数
- 不要使用下面的方式实例化frequency table
Map<String, Long> freq = new HashMap<>();
try (Stream<String> words = new Scanner(file).tokens()) {
words.forEach(word -> {
freq.merge(word.toLowerCase(), 1L, Long::sum);
});
}
- 应该使用下面的方式实例化frequency table
Map<String, Long> freq;
try (Stream<String> words = new Scanner(file).tokens()) {
freq = words
.collect(groupingBy(String::toLowerCase, counting()));
}
- 应该使用下面方式获取 top10 words from a frequency table
List<String> topTen = freq.keySet().stream()
.sorted(comparing(freq::get).reversed())
.limit(10)
.collect(toList());
- 使用 toMap collector 来构建一个<string, enum> 的 map
private static final Map<String, Operation> stringToEnum =
Stream.of(values()).collect(
toMap(Object::toString, e -> e));
- 使用 toMap collector 生成针对key的特定的value的map
Map<Artist, Album> topHits = albums.collect(
toMap(Album::artist, a->a, maxBy(comparing(Album::sales))));
Collector to impose last-write-wins policy
toMap(keyMapper, valueMapper, (v1, v2) -> v2)
- groupingBy的简单使用
words.collect(groupingBy(word -> alphabetize(word)))
Map<String, Long> freq = words
.collect(groupingBy(String::toLowerCase, counting()));
- 多关注 java.util.stream.Collectors中的静态方法
为了同时提供使用 iteration 和 stream 的功能，应该优先使用Collection作为返回类型，而不是Stream
谨慎使用streams parallel，在使用时应该注意的问题
- 现在的Java，写concurrent programs 越来越简单，但写出 correct 以及 fast 的 concurrent programs 依旧很难
- 不要盲目的 parallelize stream pipelines
- 如果流的源头来自Stream.iterate或者在中间操作中使用limit，那么parallelizing a pipeline 不会提高性能
- 如果流的源头是 ArrayList, HashMap, HashSet, ConcurrentHashMap instances；arrays; int ranges; long ranges，那么parallelizing a pipeline 可能会提高性能
- parallelizing a stream 不但很可能造成差的性能，它还可能导致不正确的结果和不可预测的行为
- 总之，不要轻易 parallelize a stream pipeline
