MethodHandle -这是怎么回事？

Question

我正在研究JDK1.7的新特性，只是无法理解MethodHandle是为什么而设计的？我理解(直接)调用静态方法(在本例中直接使用Core反射API )。我还理解(直接)调用虚拟方法(非静态的、非最终的)(以及使用需要通过类的层次结构obj.getClass().getSuperclass()的核心反射API )。非虚拟方法的调用可以看作是前者的特例.

是的，我知道超载有问题。如果要调用方法，则必须提供确切的签名。您不能以简单的方式检查重载的方法。

但是，MethodHandle是关于什么的呢？反射API允许您“查看”对象内部，而无需任何预先假设(比如实现接口)。你可以为了某种目的检查这个物体。但是MethodHandle的设计也是什么呢？为什么和什么时候我应该使用它？

更新：--我现在正在阅读http://blog.headius.com/2008/09/first-taste-of-invokedynamic.html的这篇文章。根据它，主要目标是简化运行在JVM之上的脚本语言的生活，而不是Java语言本身。

UPDATE-2: I阅读了上面的链接，引用了以下内容：

JVM将成为构建动态语言的最佳VM，因为它已经是一种动态语言VM。而InvokeDynamic，通过向一流JVM公民推广动态语言，将证明这一点。

使用反射来调用方法可以解决一些问题，比如great...except。方法对象必须从特定类型中检索，并且不能在常规way.<...>中创建

...reflected调用比直接调用慢得多。多年来，JVM已经非常擅长快速地进行反射调用。现代JVM实际上在幕后生成了一堆代码，以避免大量处理旧JVM的开销。但简单的事实是，通过任意多个层的反射访问总是比直接调用慢，部分原因是完全泛化的“调用”方法必须检查和重新检查接收方类型、参数类型、可见性和其他细节，还因为参数必须都是对象(因此原语得到对象装箱)，并且必须作为数组提供以覆盖所有可能的属性(因此参数得到数组装箱)。

对于执行几次反射调用的库来说，性能差异可能并不重要，特别是如果这些调用主要是动态地在内存中设置一个静态结构，以便对其进行正常调用。但是在动态语言中，每个调用都必须使用这些机制，这会严重影响性能。

http://blog.headius.com/2008/09/first-taste-of-invokedynamic.html

因此，对于Java程序员来说，这基本上是无用的。我说的对吗？从这个角度来看，它只能作为核心反射API的替代方式。

更新-2020：确实可以被认为是核心反射API的更强大的替代品。从JDK 8开始，也有使用它的Java语言特性。

Answer 1

使用MethodHandles可以做的是使用curry方法，更改参数的类型并更改它们的顺序。

方法句柄可以同时处理方法和字段。

MethodHandles的另一个技巧是直接使用原语(而不是通过包装)。

MethodHandles可以比使用反射更快，因为JVM中有更多的直接支持，例如它们可以内联。它使用新的invokedynamic指令。

Answer 2

把MethodHandle看作是一种现代的、更灵活的、更典型的思考方式。

它目前处于生命周期的早期阶段--但随着时间的推移，它有可能被优化，变得比反射更快--以至于它可以变得和常规的方法调用一样快。

Answer 3

就内存而言，java.lang.reflect.Method的速度相对较慢，成本也较高。方法句柄被认为是一种传递指向JVM有机会优化的函数的指针的“轻量级”方式。对于JDK8方法句柄没有进行很好的优化，而lambda很可能最初是按照类来实现的(就像内部类一样)。