Java 8ラムダ、Function.identity（）またはt-> t

Function.identity()メソッドの使い方について質問があります。

次のコードを想像してみてください：

Arrays.asList("a", "b", "c")
          .stream()
          .map(Function.identity()) // <- This,
          .map(str -> str)          // <- is the same as this.
          .collect(Collectors.toMap(
                       Function.identity(), // <-- And this,
                       str -> str));        // <-- is the same as this.

Function.identity()代わりにstr->str（またはその逆に）使用する理由はありますか？2番目のオプションの方が読みやすいと思います（もちろん、好みの問題です）。しかし、人が好まれるべき「本当の」理由はありますか？

現在のJRE実装でFunction.identity()は、は常に同じインスタンスを返しますが、が出現identifier -> identifierするたびに独自のインスタンスが作成されるだけでなく、別個の実装クラスも含まれます。詳細については、こちらをご覧ください。

その理由は、コンパイラーがラムダ式の自明な本体（の場合、x->xと同等return identifier;）を保持する合成メソッドを生成し、このメソッドを呼び出す関数インターフェイスの実装を作成するようランタイムに指示するためです。したがって、ランタイムは異なるターゲットメソッドのみを認識し、現在の実装ではメソッドを分析して、特定のメソッドが同等であるかどうかを確認しません。

したがって、のFunction.identity()代わりにを使用すると、x -> xメモリが節約される可能性がありますが、x -> xそれよりも読みやすいと本当に思っても、それによって決定が決まることはありませんFunction.identity()。

デバッグ情報を有効にしてコンパイルする場合、合成メソッドにはラムダ式を保持するソースコード行を指す行デバッグ属性があるため、Functionデバッグ中に特定のインスタンスのソースを見つける可能性があることも考慮できます。 。対照的に、Function.identity()操作のデバッグ中にによって返されたインスタンスに遭遇した場合、だれがそのメソッドを呼び出し、インスタンスを操作に渡したかはわかりません。

あなたの例ではとの間には大きな差がないstr -> strとFunction.identity()、それは単に内部からはt->t。

ただしFunction.identity、を使用できないために使用できない場合がありFunctionます。ここを見てください：

List<Integer> list = new ArrayList<>();
list.add(1);
list.add(2);

これはうまくコンパイルされます

int[] arrayOK = list.stream().mapToInt(i -> i).toArray();

しかし、コンパイルしようとすると

int[] arrayProblem = list.stream().mapToInt(Function.identity()).toArray();

とは関係ないをmapToInt予期しているため、コンパイルエラーが発生ToIntFunctionしFunctionます。メソッドもありToIntFunctionませんidentity()。

JDKソースから：

static <T> Function<T, T> identity() {
    return t -> t;
}

したがって、それが構文的に正しい限り、いいえ。