この方法Objects.requireNonNullでは、SupplierJavaの8で追加されますが、私はパフォーマンスの改善が宣言だかわからないんだけど。
これは与えるかもしれないがnull以外の場合は、パフォーマンス上の利点をこの方法でケアを呼び出すために決定する際、作成のコストように注意しなければならないメッセージの供給者が少ないだけで直接文字列メッセージを作成するコストよりもあります。
nullでない場合は文字列を持つメソッドは、パラメータを無視します：
public static <T> T requireNonNull(T obj, String message) {
if (obj == null)
throw new NullPointerException(message);
return obj;
}
私が見つかりました。JDK-8011800：java.util.Objects.requireNonNull追加（Tを、サプライヤー）
JDK 7では、java.util.Objectsはnullが見つかった場合のリターンにメッセージを取ったものを含め、ヌルをチェックするためにいくつかの方法が含まれています。JDK 8にラムダと、含めるための別の変形ではなく、文字列の文字列サプライヤーをとるrequireNonNull方法です。だからこそ、文字列メッセージを作成するコストがnull以外のケースのために回避することができます。ラムダキャプチャががゼロ以外のコストを持つことができることに注意してください。
コメントでも、パフォーマンスへの影響がないことを示します。
非ゼロキャプチャコストが心配私を行います。私はそれが頻繁にサプライヤーを使用して任意の利点が消去されることを懸念しています。2013年9月4日
私は他の質問を見つけましたが、パフォーマンスコストを持つパラメータ（理由）送信文字列を参照することではありません
それは、ラムダ式/ストリームの使用のための特定のですか？
このことを考えてみましょう、どこgenerateStringから文字列を生成するために多くのものを行いますsomeParam：
Objects.requireNonNull(obj, generateString(someParam));
引数手段ジャワ、中に熱心に評価されるgenerateString前に評価されますがrequireNonNull呼ばれます。したがって、関係なく、かどうかの計算されたobjヌルかではありません。
あなたはこれにそれを変更することでこの問題を解決することができます：
Objects.requireNonNull(obj, () -> generateString(someParam));
この場合は、generateString場合にのみ呼び出されますobj実際にはnullでした。とき、これは、より効率的でgenerateString作成するよりも高価であるSupplier-objectを。
あなたのStringパラメータが単にリテラルである場合は、同じように、通常の非ラムダメソッドを使用する必要があります。
Objects.requireNonNull(obj, "obj was null!");