Java 8でラムダ構文の代わりにメソッド参照構文を使用すると、パフォーマンス上の利点はありますか？

メソッド参照はラムダラッパーのオーバーヘッドをスキップしますか？将来的にはそうなるのでしょうか？

メソッド参照に関するJavaチュートリアルによると：

時々...ラムダ式は既存のメソッドを呼び出すだけです。これらの場合、既存のメソッドを名前で参照する方が明確な場合がよくあります。メソッド参照により、これを行うことができます。これらは、既に名前を持っているメソッドのコンパクトで読みやすいラムダ式です。

いくつかの理由から、メソッド参照構文よりもラムダ構文の方が好きです。

ラムダはより明確です

Oracleの主張にもかかわらず、メソッド参照構文があいまいであるため、ラムダ構文はオブジェクトメソッド参照の速記より読みやすいと思います。

Bar::foo

xのクラスで静的な1引数のメソッドを呼び出してxを渡しますか？

x -> Bar.foo(x)

または、xで引数のないインスタンスメソッドを呼び出していますか？

x -> x.foo()

メソッド参照構文は、どちらの代わりにもなります。コードが実際に行っていることを隠します。

ラムダはより安全です

クラスメソッドとしてBar :: fooを参照し、Barが後で同じ名前のインスタンスメソッドを追加した場合（またはその逆）、コードはコンパイルされなくなります。

ラムダを一貫して使用できます

任意の関数をラムダでラップできます。そのため、どこでも同じ構文を一貫して使用できます。メソッド参照構文は、プリミティブ配列を取得または返すメソッド、チェックされた例外をスローするメソッド、またはインスタンスと静的メソッドとして使用されるメソッド名が同じメソッドでは機能しません（メソッド参照構文が呼び出されるメソッドについて曖昧だからです） 。同じ数の引数を持つメソッドをオーバーロードした場合は機能しませんが、とにかくそれを行うべきではないため（Josh Blochの項目41を参照）、メソッド参照に対してそれを保持することはできません。

結論

パフォーマンスの低下がない場合は、IDEで警告をオフにし、メソッド参照をコードに散在させることなくラムダ構文を一貫して使用したいと思います。

PS

ここでもそこでもありませんが、私の夢では、オブジェクトメソッドの参照は次のように見え、ラムダラッパーなしでメソッドに対してinvoke-dynamicを直接適用します。

_.foo()

多くのシナリオで、ラムダとメソッド参照は同等だと思います。ただし、ラムダは、宣言するインターフェイスタイプによって呼び出しターゲットをラップします。

例えば

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);
    }
}

コンソールからスタックトレースが出力されます。

ではlambda()、メソッド呼び出しtarget()はでlambda$lambda$0(InvokeTest.java:20)、追跡可能な行情報があります。明らかに、それはあなたが書いたラムダであり、コンパイラはあなたのために匿名メソッドを生成します。そして、ラムダメソッドの呼び出し元はのようなものInvokeTest$$Lambda$2/1617791695.run(Unknown Source)、つまりinvokedynamicJVMでの呼び出しです。つまり、呼び出しは生成されたメソッドにリンクされます。

ではmethodReference()、メソッド呼び出しtarget()は直接でありInvokeTest$$Lambda$1/758529971.run(Unknown Source)、呼び出しがInvokeTest::targetメソッドに直接リンクされていることを意味します。

結論

とりわけ、ラムダ式を使用すると、ラムダからの生成メソッドへのメソッド呼び出しが1つだけ発生し ます。

それはすべてメタファクトリーです

まず、ほとんどのメソッド参照は、ラムダメタファクトリによるデシュガー化を必要とせず、単に参照メソッドとして使用されます。ラムダ式の翻訳（「TLE」）記事の「ラムダ体糖化」セクションの下：

すべてのものが等しい、プライベートメソッドは非プライベート、静的メソッドはインスタンスメソッドよりも好ましいです。ラムダ式が表示される最も内側のクラスでラムダボディが脱糖されている場合が最適です、シグネチャはラムダのボディシグネチャと一致する必要があります、余分引数は、キャプチャされた値の引数リストの先頭に追加する必要があり、メソッド参照をまったくデ糖化しません。ただし、このベースライン戦略から逸脱する必要がある例外的なケースがあります。

これは、TLEの「The 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引数はラムダ法、脱糖ラムダ本体またはメソッド参照で指定方法のいずれかを識別する。

静的（Integer::sum）または無制限のインスタンスメソッド（Integer::intValue）参照は、脱糖 なしで「高速パス」メタファクトリバリアントによって最適に処理できるという意味で、「最も簡単」または「最も便利」です。この利点は、TLEの「メタファクトリーバリアント」で有益に指摘されています。

不要な引数を削除することにより、クラスファイルは小さくなります。また、高速パスオプションにより、VMのバーが低くなり、ラムダ変換操作が本質的になり、「ボクシング」操作として扱うことができ、unboxの最適化が容易になります。

当然、インスタンスキャプチャメソッド参照（obj::myMethod）は、呼び出しのためのメソッドハンドルへの引数として境界付きインスタンスを提供する必要があります。これは、「ブリッジ」メソッドを使用したデシュガーの必要性を意味する場合があります。

結論

あなたが示唆しているラムダ「ラッパー」が何であるかは正確にはわかりませんが、ユーザー定義のラムダまたはメソッド参照を使用した最終的な結果は同じですが、到達する方法はまったく異なるようです現在そうでない場合は、将来異なる可能性があります。したがって、メソッド参照はメタファクトリーにより最適な方法で処理できる可能性が高いと思います。

パフォーマンスに影響する可能性のあるラムダ式を使用すると、非常に深刻な結果が1つあります。

ラムダ式を宣言すると、ローカルスコープでクロージャーが作成されます。

これは何を意味し、パフォーマンスにどのように影響しますか？

まあ、あなたが尋ねてくれてうれしいです。これは、これらの小さなラムダ式のそれぞれが小さな匿名の内部クラスであり、ラムダ式の同じスコープ内にあるすべての変数への参照を保持することを意味します。

これはthis、オブジェクトインスタンスとそのすべてのフィールドの参照も意味します。ラムダの実際の呼び出しのタイミングによっては、ラムダを保持しているオブジェクトがまだ生きている限り、ガベージコレクターがこれらの参照を手放すことができないため、これはかなり重大なリソースリークになります。