在Java 8中使用方法引用语法而不是lambda语法是否会对性能产生好处？

方法引用是否跳过了lambda包装器的开销？他们将来可能吗？

根据有关方法参考的Java教程：

有时... lambda表达式除了调用现有方法外什么也不做。在这种情况下，通常更容易按名称引用现有方法。方法引用使您可以执行此操作；它们是紧凑的，易于阅读的lambda表达式，用于已经具有名称的方法。

由于以下几个原因，我更喜欢lambda语法而不是方法引用语法：

Lambda更清晰

尽管有Oracle的主张，但我发现lambda语法比对象方法引用的简写形式更易于阅读，因为方法引用的语法是模棱两可的：

Bar::foo

您是否在x的类上调用静态的一参数方法并将其传递给x？

x -> Bar.foo(x)

还是在x上调用零参数实例方法？

x -> x.foo()

方法参考语法可以代表任何一种。它隐藏了您的代码实际在做什么。

Lambda更安全

如果将Bar :: foo引用为类方法，并且Bar以后添加了同名的实例方法（反之亦然），则代码将不再编译。

您可以始终使用lambda

您可以将任何函数包装在lambda中-因此您可以在所有位置一致地使用相同的语法。方法引用语法不适用于采用或返回原始数组，引发已检查异常或具有与实例和静态方法相同的方法名称的方法（因为该方法引用语法对于调用哪种方法尚不明确） 。当您使用相同数量的参数重载方法时，它们不起作用，但是无论如何您都不应这样做（请参见Josh Bloch的第41项），因此我们不能将其与方法引用相对应。

结论

如果这样做不影响性能，我很想在我的IDE中关闭警告，并始终使用lambda语法，而不会将偶然的方法引用散布到我的代码中。

聚苯乙烯

无论在这里还是那里，但在我的梦中，对象方法引用看起来都更像这样，并且无需lambda包装器就直接在对象上对方法应用invoke-dynamic：

_.foo()

在许多情况下，我认为lambda和method-reference是等效的。但是，lambda将通过声明的接口类型包装调用目标。

例如

public class InvokeTest {

    private static void invoke(final Runnable r) {
        r.run();
    }

    private static void target() {
        new Exception().printStackTrace();
    }

    @Test
    public void lambda() throws Exception {
        invoke(() -> target());
    }

    @Test
    public void methodReference() throws Exception {
        invoke(InvokeTest::target);
    }
}

您将看到控制台输出stacktrace。

在中lambda()，方法调用target()为lambda$lambda$0(InvokeTest.java:20)，具有可追溯的行信息。显然，这就是您编写的lambda，编译器会为您生成一个匿名方法。然后，lambda方法的调用者类似于JVM中InvokeTest$$Lambda$2/1617791695.run(Unknown Source)的invokedynamic调用，这意味着该调用已链接到生成的方法。

在中methodReference()，方法调用target()直接是InvokeTest$$Lambda$1/758529971.run(Unknown Source)，这意味着调用直接链接到该InvokeTest::target方法。

结论

最重要的是，与方法引用相比，使用lambda表达式只会导致 对lambda的生成方法再进行一次方法调用。

一切都与元工厂有关

首先，大多数方法引用不需要通过lambda元工厂来简化，它们只是用作引用方法。在Lambda表达式翻译（“ TLE”）文章的“ Lambda身体糖化”部分下：

在所有条件都相同的情况下，私有方法胜于非私有方法，静态方法胜于实例方法，最好是将lambda主体分解为出现lambda表达式的最内层类，签名应与lambda的主体签名相匹配，否则对于捕获的值，参数应该放在参数列表的最前面，并且根本不对方法引用进行糖化处理。但是，在某些例外情况下，我们可能不得不偏离此基准策略。

在TLE的“ Lambda Metafactory”中进一步强调了这一点：

metaFactory(MethodHandles.Lookup caller, // provided by VM
            String invokedName,          // provided by VM
            MethodType invokedType,      // provided by VM
            MethodHandle descriptor,     // lambda descriptor
            MethodHandle impl)           // lambda body

该impl参数标识lambda方法，可以是经过减重的lambda主体，也可以是方法参考中命名的方法。

静态（Integer::sum）或无限制实例方法（Integer::intValue）引用是“最简单”或最“方便”的引用，从某种意义上说，可以通过“快速路径”元工厂变量 对它们进行最佳处理而无需花费很多精力。TLE的“ Metafactory变体”中指出了这一优势：

通过消除不需要的参数，类文件变得更小。快速路径选项降低了VM进行lambda转换操作的门槛，从而使其可以被视为“装箱”操作并简化了拆箱优化。

自然地，实例捕获方法参考（obj::myMethod）需要提供有界实例作为调用方法句柄的参数，这可能意味着需要使用'bridge'方法进行讨价还价。

结论

我不确定您要暗示的lambda“包装器”是什么，但是即使使用用户定义的lambda或方法引用的最终结果是相同的，但达到的方式似乎也大不相同，并且如果不是现在，将来可能会有所不同。因此，我认为元工厂更有可能以更好的方式处理方法引用。

使用可能影响性能的lambda表达式有一个非常严重的后果。

声明lambda表达式时，将在本地范围内创建一个闭包。

这意味着什么？它对性能有何影响？

好吧，我很高兴你问。这意味着每个小lambda表达式都是一个小的匿名内部类，这意味着它带有对lambda表达式相同范围内的所有变量的引用。

这也意味着this引用对象实例及其所有字段。取决于lambda实际调用的时间，这可能构成相当大的资源泄漏，因为只要保存lambda的对象仍然存在，垃圾收集器就无法释放这些引用。