在本文中，我们将展示一些在 Java 8 中不太为人所了解的 Lambda 表达式技巧及其使用限制。本文的主要的受众是 Java 开发人员，研究人员以及工具库的编写人员。 这里我们只会使用没有 com.sun 或其他内部类的公共 Java API，如此代码就可以在不同的 JVM 实现之间进行移植。
Lambda 表达式作为在 Java 8 中实现匿名方法的一种途径而被引入，可以在某些场景中作为匿名类的替代方案。 在字节码的层面上来看，Lambda 表达式被替换成了 invokedynamic 指令。这样的指令曾被用来创建功能接口的实现。 而单个方法则是利用 Lambda 里面所定义的代码将调用委托给实际方法。
例如，我们手头有如下代码：
void printElements(List<String> strings){
strings.forEach(item -> System.out.println("Item = %s", item));
}这段代码被 Java 编译器翻译过来就成了下面这样：
private static void lambda_forEach(String item) { //generated by Java compiler
System.out.println("Item = %s", item);
}
private static CallSite bootstrapLambda(Lookup lookup, String name, MethodType type) { //
//lookup = provided by VM
//name = "lambda_forEach", provided by VM
//type = String -> void
MethodHandle lambdaImplementation = lookup.findStatic(lookup.lookupClass(), name, type);
return LambdaMetafactory.metafactory(lookup,
"accept",
MethodType.methodType(Consumer.class), //signature of lambda factory
MethodType.methodType(void.class, Object.class), //signature of method Consumer.accept after type erasure
lambdaImplementation, //reference to method with lambda body
type);
}
void printElements(List < String > strings) {
Consumer < String > lambda = invokedynamic# bootstrapLambda, #lambda_forEach
strings.forEach(lambda);
}invokedynamic 指令可以用 Java 代码粗略的表示成下面这样：
private static CallSite cs;
void printElements(List < String > strings) {
Consumer < String > lambda;
//begin invokedynamic
if (cs == null)
cs = bootstrapLambda(MethodHandles.lookup(), "lambda_forEach", MethodType.methodType(void.class, String.class));
lambda = (Consumer < String > ) cs.getTarget().invokeExact();
//end invokedynamic
strings.forEach(lambda);
}正如你所看见的，LambdaMetafactory 被用来生成一个调用站点，用目标方法句柄来表示一个工厂方法。这个工厂方法使用了 invokeExact 来返回功能接口的实现。如果 Lambda 封装了变量，则 invokeExact 会接收这些变量拿来作为实参。
在 Oracle 的 JRE 8 中，metafactory 会利用 ObjectWeb Asm 来动态地生成 Java 类，其实现了一个功能接口。 如果 Lambda 表达式封装了外部变量，生成的类里面就会有额外的域被添加进来。这种方法类似于 Java 语言中的匿名类 —— 但是有如下区别：
匿名类是在编译时由 Java 编译器生成的。
Lambda 实现的类则是由 JVM 在运行时生成。
metafactory 的如何实现要看是什么 JVM 供应商和版本
当然，invokedynamic 指令并不是专门给 Java 中的 lambda 表达式来使用的。引入该指令主要是为了可以在 JVM 之上运行的动态语言。Java 所提供的 Nashorn JavaScript 引擎开箱即用，就大大地利用了该指令。
在本文的后续内容中，我们将重点介绍 LambdaMetafactory 类及其功能。本文的下一节将假设你已经完全了解了 metafactory 方法如何工作以及 MethodHandle 是什么。
在本节中，我们将介绍如何使用 lambdas 动态构建日常任务。
我们都知道，Java 提供的所有函数接口不支持检查异常。检查与未检查异常在 Java 中打着持久战。
如果你想使用与 Java Streams 结合使用的 lambdas 内的检查异常的代码呢？ 例如，我们需要将字符串列表转换成 URL 列表，如下所示：
Arrays.asList("http://localhost/", "https://github.com")
.stream()
.map(URL::new)
.collect(Collectors.toList())URL（String）已经在 throws 地方声明了一个检查的异常，因此它不能直接用作 Function 的方法引用。
你说“是的，这里可以使用这样的技巧”：
public static <T> T uncheckCall(Callable<T> callable) {
try { return callable.call(); }
catch (Exception e) { return sneakyThrow(e); }
}
private static <E extends Throwable, T> T sneakyThrow0(Throwable t) throws E { throw (E)t; }
public static <T> T sneakyThrow(Throwable e) {
return Util.<RuntimeException, T>sneakyThrow0(e);
}
// Usage sample
//return s.filter(a -> uncheckCall(a::isActive))
// .map(Account::getNumber)
// .collect(toSet());这是一个很挫的做法。原因如下：
使用 try-catch 块
重新抛出异常
Java 中类型擦除的使用不足
这个问题被使用以下方式可以更“合法”的方式解决：
检查的异常仅由 Java 编程语言的编译器识别
throws 部分只是方法的元数据，在 JVM 级别没有语义含义
检查和未检查的异常在字节码和 JVM 级别是不可区分的
解决的办法是只把 Callable.call 的调用封装在不带 throws 部分的方法之中：
static <V> V callUnchecked(Callable<V> callable){
return callable.call();
}这段代码不会被 Java 编译器编译通过，因为方法 Callable.call 在其 throws 部分有受检异常。但是我们可以使用动态构造的 lambda 表达式擦除这个部分。
首先，我们要声明一个函数式接口，没有 throws 部分但能够委派调用给 Callable.call：
@FunctionalInterface
interface SilentInvoker {
MethodType SIGNATURE = MethodType.methodType(Object.class, Callable.class);//signature of method INVOKE
<V> V invoke(final Callable<V> callable);
}第二步是使用 LambdaMetafactory 创建这个接口的实现，以及委派 SilentInvoker.invoke 的方法调用给方法 Callable.call。如前所述，在字节码的级别上 throws 部分被忽略，因此，方法 SilentInvoker.invoke 能够调用方法 Callable.call 而无需声明受检异常：
private static final SilentInvoker SILENT_INVOKER;
final MethodHandles.Lookup lookup = MethodHandles.lookup();
final CallSite site = LambdaMetafactory.metafactory(lookup,
"invoke",
MethodType.methodType(SilentInvoker.class),
SilentInvoker.SIGNATURE,
lookup.findVirtual(Callable.class, "call", MethodType.methodType(Object.class)),
SilentInvoker.SIGNATURE);
SILENT_INVOKER = (SilentInvoker) site.getTarget().invokeExact();第三，写一个实用方法，调用 Callable.call 而不声明受检异常：
public static <V> V callUnchecked(final Callable<V> callable) /*no throws*/ {
return SILENT_INVOKER.invoke(callable);
}现在，我们可以毫无顾忌地重写我们的流，使用异常检查：
Arrays.asList("http://localhost/", "https://dzone.com")
.stream()
.map(url -> callUnchecked(() -> new URL(url)))
.collect(Collectors.toList());此代码将成功编译，因为 callUnchecked 没有被声明为需要检查异常。此外，使用单态内联缓存时可以内联式调用此方法，因为在 JVM 中只有一个实现 SilentInvoker 接口的类。
如果实现的 Callable.call 在运行时抛出一些异常，只要它们被捕捉到就没什么问题。
try{
callUnchecked(() -> new URL("Invalid URL"));
} catch (final Exception e){
System.out.println(e);
}尽管有这样的方法来实现功能，但还是推荐下面的用法：
只有当调用代码保证不存在异常时，才能隐藏已检查的异常，才能调用相应的代码。
下面的例子演示了这种方法:
callUnchecked(() -> new URL("https://dzone.com")); //this URL is always valid and the constructor never throws MalformedURLException这个方法是这个工具的完整实现，在这里它作为开源项目SNAMP的一部分。
这一节对不同数据格式（如 JSON，Thrift 等等）的序列化/反序列化的编写工具有用。此外，如果你的代码严重依赖了为 JavaBean 的 getter 和 setter 准备的 Java 反射，那么它及其有用。
getter 是在 JavaBean 中的一个使用 getXXX 命名的无参且非 Void 返回类型的方法、setter 是在 JavaBea n中的一个使用 setXXX 命名的有一个单独参数并返回 void 类型的方法。这两个符号可以被表示为函数的接口：
一个 getter 可以被表示为一个函数的参数是 this 引用的 Function 。
一个 setter 可以被表示为一个第一个参数是 this 引用，第而个参数是被传进 setter 的值的 BiConsumer。
现在，我们创建两个方法，这两个方法可以把任何 getter 或 setter 转换为这些函数的接口。无论这两个函数接口是不是通用。只要类型擦除掉之后，真实的类型都等于一个对象。自动的构造一个返回类型和可以被 LambdaMetafactory 识别的参数。此外，uava's Cache 帮助为相同的 getter 或 setter 缓存 lambdas 。
首先，必须为 getter 和 setter 声明一个缓存。从 Reflection API 上看，Method 表示一个真实的 getter 或 setter，并且做为一个 Key 被使用。在缓存中的值代表对于特定的 getter 或 setter 的动态构造函数接口。
private static final Cache<Method, Function> GETTERS = CacheBuilder.newBuilder().weakValues().build();
private static final Cache<Method, BiConsumer> SETTERS = CacheBuilder.newBuilder().weakValues().build();其次，创建工厂方法通过从方法句柄中指向一个 getter 或 setter 来创建一个函数接口的实例：
private static Function createGetter(final MethodHandles.Lookup lookup,
final MethodHandle getter) throws Exception{
final CallSite site = LambdaMetafactory.metafactory(lookup, "apply",
MethodType.methodType(Function.class),
MethodType.methodType(Object.class, Object.class), //signature of method Function.apply after type erasure
getter,
getter.type()); //actual signature of getter
try {
return (Function) site.getTarget().invokeExact();
} catch (final Exception e) {
throw e;
} catch (final Throwable e) {
throw new Error(e);
}
}
private static BiConsumer createSetter(final MethodHandles.Lookup lookup,
final MethodHandle setter) throws Exception {
final CallSite site = LambdaMetafactory.metafactory(lookup,
"accept",
MethodType.methodType(BiConsumer.class),
MethodType.methodType(void.class, Object.class, Object.class), //signature of method BiConsumer.accept after type erasure
setter,
setter.type()); //actual signature of setter
try {
return (BiConsumer) site.getTarget().invokeExact();
} catch (final Exception e) {
throw e;
} catch (final Throwable e) {
throw new Error(e);
}
}通过 samMethodType 和 instantiatedMethodType（分别为方法 metafactory 的第三个和第五个参数）之间的区别，可以实现类型擦除后的函数接口中基于对象的参数和实际参数类型之间的自动转换以及 getter 或 setter 中的返回类型。实例化的方法类型是提供专门的 lambda 的方法实现。
然后，为这些工厂具有缓存的支持，创建一个门面：
public static Function reflectGetter(final MethodHandles.Lookup lookup, final Method getter) throws ReflectiveOperationException {
try {
return GETTERS.get(getter, () -> createGetter(lookup, lookup.unreflect(getter)));
} catch (final ExecutionException e) {
throw new ReflectiveOperationException(e.getCause());
}
}
public static BiConsumer reflectSetter(final MethodHandles.Lookup lookup, final Method setter) throws ReflectiveOperationException {
try {
return SETTERS.get(setter, () -> createSetter(lookup, lookup.unreflect(setter)));
} catch (final ExecutionException e) {
throw new ReflectiveOperationException(e.getCause());
}
}作为使用 Java 反射 API 的 Method 实例，获取的方法信息可以轻松地转换为 MethodHandle。考虑到实例方法总是有隐藏的第一个参数用于将其传递给方法。静态方法没有这些隐藏的参数。例如，Integer.intValue（）方法具有 int intValue 的实际签名（Integer this）。这个技巧用于实现 getter 和 setter 的功能包装器。
现在是时候测试代码了:
final Date d = new Date();
final BiConsumer<Date, Long> timeSetter = reflectSetter(MethodHandles.lookup(), Date.class.getDeclaredMethod("setTime", long.class));
timeSetter.accept(d, 42L); //the same as d.setTime(42L);
final Function<Date, Long> timeGetter = reflectGetter(MethodHandles.lookup(), Date.class.getDeclaredMethod("getTime"));
System.out.println(timeGetter.apply(d)); //the same as d.getTime()
//output is 42这种使用缓存的 getter 和 setter 的方法可以在诸如 Jackson 这样的序列化和反序列化库中高效的使用，这些库在序列化/反序列化库的过程中使用 getter 和 setter。
使用 LambdaMetafactory 来动态生成的实现调用函数接口比通过 Java Reflection API 的调用快 得多
你可以在这里找到完整的代码，它是开源项目 SNAMP 的一部分。
在本节中，我们将给出在 Java 编译器和 JVM 中与 lambdas 相关的一些错误和限制。 所有这些限制都可以在 OpenJDK 和 Oracle JDK 上重现，它们适用于 Windows 和 Linux 的 javac 1.8.0_131。
如你所知，可以使用 LambdaMetafactory 动态构建 lambda。要实现这一点，你应该指定一个 MethodHandle，其中包含一个由函数接口声明的单个方法的实现。我们来看看这个简单的例子：
final class TestClass {
String value = "";
public String getValue() {
return value;
}
public void setValue(final String value) {
this.value = value;
}
}
final TestClass obj = new TestClass();
obj.setValue("Hello, world!");
final MethodHandles.Lookup lookup = MethodHandles.lookup();
final CallSite site = LambdaMetafactory.metafactory(lookup,
"get",
MethodType.methodType(Supplier.class, TestClass.class),
MethodType.methodType(Object.class),
lookup.findVirtual(TestClass.class, "getValue", MethodType.methodType(String.class)),
MethodType.methodType(String.class));
final Supplier<String> getter = (Supplier<String>) site.getTarget().invokeExact(obj);
System.out.println(getter.get());上面代码等价于:
final TestClass obj = new TestClass();
obj.setValue("Hello, world!");
final Supplier<String> elementGetter = () -> obj.getValue();
System.out.println(elementGetter.get());但如果我们用一个可以表示一个字段获取方法的方法处理器来替换指向 getValue 的方法处理器的话，情况会如何呢：
final CallSite site = LambdaMetafactory.metafactory(lookup,
"get",
MethodType.methodType(Supplier.class, TestClass.class),
MethodType.methodType(Object.class),
lookup.findGetter(TestClass.class, "value", String.class), //field getter instead of method handle to getValue
MethodType.methodType(String.class));该代码应该是可以按照预期来运行的，因为 findGetter 会返回一个指向字段获取方法、并且具备有效签名的方法处理器。 但是如果你运行了代码，就会看到如下异常：
java.lang.invoke.LambdaConversionException: Unsupported MethodHandle kind: getField有趣的是，如果我们使用 MethodHandleProxies，字段获取方法却可以运行得很好:
final Supplier<String> getter = MethodHandleProxies
.asInterfaceInstance(Supplier.class, lookup.findGetter(TestClass.class, "value", String.class)
.bindTo(obj));要注意 MethodHandleProxies 并非动态创建 lambda 表达式的理想方法，因为这个类只是把 MethodHandle 封装到一个代理类里面，然后把对 InvocationHandler.invoke 的调用指派给了 MethodHandle.invokeWithArguments 方法。 这种方法使得 Java 反射机制运行起来非常的慢。
如前所述，并不是所有的方法句柄都可以在运行时用于构建 lambdas。
只有几种与方法相关的方法句柄可以用于 lambda 表达式的动态构造
这包括:
REF_invokeInterface: 对于接口方法可通过 Lookup.findVirtual 来构建
REF_invokeVirtual: 对于由类提供的虚方法可以通过 Lookup.findVirtual 来构建
REF_invokeStatic: 对于静态方法可通过 Lookup.findStatic 构建
REF_newInvokeSpecial: 对于构造函数可通过 Lookup.findConstructor 构建
REF_invokeSpecial: 对于私有方法和由类提供的早绑定的虚方法可通过 Lookup.findSpecial 构建
其他方法的句柄将会触发 LambdaConversionException 异常。
这个 bug 与 Java 编译器以及在 throws 部分声明泛型异常的能力有关。下面的示例代码演示了这种行为：
interface ExtendedCallable<V, E extends Exception> extends Callable<V>{
@Override
V call() throws E;
}
final ExtendedCallable<URL, MalformedURLException> urlFactory = () -> new URL("http://localhost");
urlFactory.call();这段代码应该编译成功因为 URL 构造器抛出 MalformedURLException。但事实并非如此。编译器产生以下错误消息：
Error:(46, 73) java: call() in <anonymous Test$CODEgt; cannot implement call() in ExtendedCallable
overridden method does not throw java.lang.Exception但如果我们用一个匿名类替换 lambda 表达式，那么代码就编译成功了：
final ExtendedCallable<URL, MalformedURLException> urlFactory = new ExtendedCallable<URL, MalformedURLException>() {
@Override
public URL call() throws MalformedURLException {
return new URL("http://localhost");
}
};
urlFactory.call();结论很简单：
当与 lambda 表达式配合使用时，泛型异常的类型推断不能正确工作。
一个带有多个边界的泛型可以用 & 号构造：<T extends A & B & C & ... Z>。这种泛型参数定义很少被使用，但由于其局限性，它对 Java 中的 lambda 表达式有某些影响：
每一个边界，除了第一个边界，都必须是一个接口。
具有这种泛型的类的原始版本只考虑了约束中的第一个边界。
第二个局限性使 Java 编译器在编译时和 JVM 在运行时产生不同的行为，当 Lambda 表达式的联动发生时。可以使用以下代码重现此行为：
final class MutableInteger extends Number implements IntSupplier, IntConsumer { //mutable container of int value
private int value;
public MutableInteger(final int v) {
value = v;
}
@Override
public int intValue() {
return value;
}
@Override
public long longValue() {
return value;
}
@Override
public float floatValue() {
return value;
}
@Override
public double doubleValue() {
return value;
}
@Override
public int getAsInt() {
return intValue();
}
@Override
public void accept(final int value) {
this.value = value;
}
}
static < T extends Number & IntSupplier > OptionalInt findMinValue(final Collection < T > values) {
return values.stream().mapToInt(IntSupplier::getAsInt).min();
}
final List < MutableInteger > values = Arrays.asList(new MutableInteger(10), new MutableInteger(20));
final int mv = findMinValue(values).orElse(Integer.MIN_VALUE);
System.out.println(mv);这段代码绝对没错，而且用 Java 编译器编译也会成功。MutableInteger 这个类可以满足泛型 T 的多个类型绑定约束：
MutableInteger 是从 Number 继承的
MutableInteger 实现了 IntSupplier
但是在运行的时候会抛出异常：
java.lang.BootstrapMethodError: call site initialization exception
at java.lang.invoke.CallSite.makeSite(CallSite.java:341)
at java.lang.invoke.MethodHandleNatives.linkCallSiteImpl(MethodHandleNatives.java:307)
at java.lang.invoke.MethodHandleNatives.linkCallSite(MethodHandleNatives.java:297)
at Test.minValue(Test.java:77)
Caused by: java.lang.invoke.LambdaConversionException: Invalid receiver type class java.lang.Number; not a subtype of implementation type interface java.util.function.IntSupplier
at java.lang.invoke.AbstractValidatingLambdaMetafactory.validateMetafactoryArgs(AbstractValidatingLambdaMetafactory.java:233)
at java.lang.invoke.LambdaMetafactory.metafactory(LambdaMetafactory.java:303)
at java.lang.invoke.CallSite.makeSite(CallSite.java:302)
之所以会这样是因为 Java Stream 的管道只捕获到了一个原始类型，它是一个 Number 类。Number 类本身并没有实现 IntSupplier 接口。 要修复此问题，可以在一个作为方法引用的单独方法中明确定义一个参数类型：
private static int getInt(final IntSupplier i){
return i.getAsInt();
}
private static <T extends Number & IntSupplier> OptionalInt findMinValue(final Collection<T> values){
return values.stream().mapToInt(UtilsTest::getInt).min();
}
这个示例就演示了 Java 编译器和运行时所进行的一次不正确的类型推断。
在 Java 中的编译时和运行时处理与 lambdas 结合的多个类型绑定会导致不兼容。原文来自:开源中国社区
声明：所有来源为“聚合数据”的内容信息，未经本网许可，不得转载！如对内容有异议或投诉，请与我们联系。邮箱：marketing@think-land.com
分享
苏公网安备 32059002001776号