Java Stream API：うまくいくものとそうでないもの

Java 8 Stream APIはとても「エネルギッシュ」ですか？ コレクションの複雑な操作の処理を単純で理解可能なコードに「変える」ことは可能ですか？ 並列操作の利点はどこにあり、いつ停止するのですか？ これらは、読者が遭遇する多くの質問の一部です。 @irnyとも呼ばれるTagir Valeevを使用して、Stream APIの落とし穴を理解してみましょう。 多くの読者は、会議での記事、Javaの研究、および表現力豊かなレポートについての対話者にすでに精通しています。 ですから、遅滞なく、議論を始めます。



-Tagir、StackOverflowリソースのパフォーマンスが優れています（ java-streamブランチのゴールドステータス ）。 Java 8 Stream APIを使用するダイナミクスと設計の複雑さが（このリソースに関する質問と回答に基づいて）大きくなったと思いますか？



-確かに、かつてStackOverflowに多くの時間を費やし、Stream APIの問題を常に監視していました。 私の意見では、最も興味深い質問への答えがすでにあるので、私は定期的に調べます。 もちろん、人々はStream APIを試してみたように感じますが、試してみないとおかしいでしょう。 このトピックに関する最初の質問は、人々が初期ビルドを実験したJava 8がリリースされる前から現れていました。 全盛期は2014年と2015年の終わりに来ました。

多くの興味深い質問は、Stream APIでできることだけでなく、サードパーティのライブラリなしでは通常できないことにも関連しています。 ユーザーは、常に質問と議論を重ねながら、Stream APIの範囲を拡大しようとしました。 これらの質問のいくつかは、Java 8 Stream APIの機能を拡張するStreamExライブラリのアイデアの源になっています。



-StreamExに言及しました。 創作のきっかけを教えてください。 あなたの目標は何ですか？



-動機は純粋に実用的でした。 仕事でJava 8に切り替えたとき、美しさと便利さからの最初の陶酔感はすぐに一連の旅行に置き換えられました。私は、実行すべきStream APIで特定のことをしたかったのですが、うまくいきませんでした。 コードを長くするか、仕様から逸脱する必要がありました。 これらの問題を解決するために、作業中のプロジェクトに補助クラスと補助メソッドを追加し始めましたが、見苦しくなりました。 その後、クラスで標準ストリームをラップすると、多くの追加操作が提供され、作業がずっと楽しくなりました。 これらのクラスを別のオープンプロジェクトで選択し、開発を開始しました。



- あなたの意見では、どのような種類の計算と操作、およびどのデータにStream APIを使用して実装する価値がありますか。また、処理にあまり適さないものは何ですか。



-ストリームAPIは不変データが大好きです。 新しいデータ構造を作成するのではなく、既存のデータ構造を変更する場合は、別のものが必要です。 新しい標準メソッド（List.replaceAllなど）に注目してください。



ストリームAPIは独立したデータが大好きです。 入力セットの複数の要素を同時に使用する必要がある場合、サードパーティのライブラリがないと非常に不格好になります。 しかし、StreamExのようなライブラリは、多くの場合、この問題を解決します。



ストリームAPIは、パスごとに1つの問題を解決するのが好きです。 1回のデータラウンドでいくつかの異なる問題を解決する場合は、独自のコレクターを作成する準備をしてください。 そして、それがまったくうまくいくという事実ではありません。



ストリームAPIは、チェックされた例外を好みません。 Stream APIオペレーションからそれらをスローすることはあまり便利ではありません。 繰り返しになりますが、これを簡単にしようとするライブラリー（たとえばjOOλ ）がありますが、チェック済みの例外を放棄することをお勧めします。



標準のStream APIには、非常に必要な操作がいくつかありません。 たとえば、takeWhileはJava 9でのみ表示されます。非常に合理的で複雑でないものが必要な場合がありますが、これを行うことはできません。 繰り返しますが、jOOλやStreamExのようなライブラリがこれらの問題のほとんどを解決することは注目に値します。







- 常にparallelStreamを使用するのが理にかなっていると思いますか？ メソッドをストリームからparallelStreamに「切り替える」ときに発生する可能性のある問題は何ですか？



-どのような場合でも、常にparallelStreamを使用しないでください。 非常にまれにしか使用されず、これには十分な理由があるはずです。



まず、Stream APIを使用して解決されるタスクのほとんどは、ForkJoinPoolのタスクを分散して同期するオーバーヘッドに比べて速すぎます。 Doug Leaの有名な記事「 いつパラレルストリームを使用するか 」は経験則です。現代のマシンでは、通常、実行時間が100マイクロ秒を超えるタスクをパラレル化するのが理にかなっています。 私のテストでは、並列化によって20マイクロ秒のタスクが加速されることがありますが、これはすでに多くの要因に依存しています。



第二に、タスクが長時間実行されたとしても、並列処理がそれを加速するという事実ではありません。 これは、ソースの品質、中間操作（たとえば、順序付けされたストリームの制限が長時間にわたって機能する）、および端末操作（たとえば、forEachOrderedが並行性の利点を無効にする場合がある）に依存します。 最適な中間操作はステートレス操作（フィルター、マップ、flatMap、およびピーク）であり、最適な最終操作はリデュース/コレクトファミリーです。これは連想的です。つまり、タスクを効率的にサブタスクに分割し、結果を結合できます。 また、マージ手順が最適でない場合もあります（たとえば、複雑なgroupingByチェーンの場合）。



第三に、多くの人々がStream APIを誤って使用し、仕様に違反しています。 たとえば、ステートフル状態のラムダをフィルターやマップなどの操作に渡します。 または、reduceのユニット要件と結合性に違反しています。 間違ったコレクターがいくつ書いているかは言うまでもありません。 これは多くの場合、連続するストリームでは許されますが、並列ストリームでは完全に受け入れられません。 もちろん、これは間違って記述する理由ではありませんが、事実は明らかです。パラレルストリームを使用することはより難しく、単にどこかにparallel（）を追加するだけではありません。



そして最後に、ストリームが長時間実行されていても、その中の操作は簡単に並列化でき、すべてを正しく実行しています。プロセッサコアが実際にアイドル状態であるかどうかを検討する価値があります。 リクエストが常にロードされるWebサービスがある場合、各リクエストを個別のスレッドで処理する方が合理的である可能性が非常に高くなります。 多数のコアがある場合、またはシステムが完全にロードされていない場合にのみ、パラレルストリームについて考えることができます。 おそらく、並列ストリームを制限するためにjava.util.concurrent.ForkJoinPool.common.parallelismをインストールする価値があるかもしれません。



たとえば、コアが16個あり、通常12個がロードされている場合、残りのコアをストリームで占有するように並列度レベル4を設定してみてください。 もちろん、一般的なヒントはありません。常に確認する必要があります。



- 並列化の議論を続けると、パフォーマンスはデータの量と構造、プロセッサコアの数に影響されると言うことはできますか？ どのデータソース（LinkedListなど）を並列処理するべきではありませんか？



-LinkedListはまだ最悪のソースではありません。 少なくとも彼は自分のサイズを知っているので、Stream APIはタスクをよりうまく分割できます。 最悪なのは、並列処理のために、本質的に一貫性のあるソース（LinkedListなど）で、サイズを報告しないソースです。 通常、これはSpliterators.spliteratorUnknownSize（）を通じて、またはサイズを指定せずにAbstractSpliteratorを通じて作成されます。 JDKの例は、Stream.iterate（）、Files.list（）、Files.walk（）、BufferedReader.lines（）、Pattern.splitAsStream（）などです。 この点については、今年のJPointに関するStreamPoint Odditiesレポートで説明しました。 実装が非常に悪いため、たとえば、このソースに含まれる要素が1024個以下の場合、まったく並列しないという事実につながります。 そして、それでもかなりひどく似ています。 多かれ少なかれ通常の並列処理を行うには、何万もの要素が必要です。 StreamExの実装は改善されています。 たとえば、StreamEx.ofLines（リーダー）（BufferedReader.lines（）の類似物）は、小さなファイルでも十分に並列します。 悪いソースがあり、それを並列化する場合、最初に順番にリストに収集する方が効率的です（たとえば、Stream.iterate（...）.collect（toList（））。ParallelStream（）...）



ほとんどの標準JDKデータ構造は優れたソースです。 Java 7と互換性のあるサードパーティライブラリの構造とラッパーに注意してください。Spliterator（）メソッドをオーバーライドできないため（Java 7にはスプリッタがないため）、Collection.spliterator（）またはList.spliterator（）の実装を使用します。デフォルトでは、もちろん、データ構造について何も知らず、単純にイテレータをラップするため、うまく並列しません。 9では、これはランダムアクセスリストで改善されます。



- 中間操作を使用する場合、あなたの意見では、Stream パイプラインの しきい値はどのようなもので、 どのように決定されますか？ 制限（明示的および暗黙的）はありますか？



-厳しい制限があるとは言いません。 ほとんどの中間Stream API操作は、1回の呼び出しでスタックの深さを増やします。 一方で、これはインライン化の効率を低下させる可能性があります（HotSport JVMのデフォルトではMaxInlineLevel = 9）。 しかし、通常、これは孤立したベンチマークでのみ役割を果たします。 実際のアプリケーションでは、呼び出しは依然として多態的であり、インライン化を最大限に活用できません。 長いスタックトレースは、ログを詰まらせたり、例外オブジェクトの作成を遅くしたり、初心者を怖がらせるだけです。 しかし、一般的に、それらは無害です。 本当に必要な場合は、数十の中間操作を実行しても問題ありません。 もちろん、例えばwhile（何か）stream = stream.map（x-> ...）ループのように、制御不能にストリームを増やすべきではありません。 ターミナル操作の後続の実行には、StackOverflowErrorから落ちるリスクがあります。



処理中にコレクションを整理する方法（中間の並べ替え（）操作）または順序付けされたデータソースを使用し、マップ、フィルター、および操作の削減を使用してそれを操作する方法は、パフォーマンスの向上につながりますか？



いいえ、ほとんど。 入力がソートされるという事実を利用するのは、distinct（）操作のみです。 アルゴリズムを変更し、要素を前の要素と比較します。ソートせずにHashSetを保持する必要があります。 ただし、このために、ソースはソートされていることを報告する必要があります。 JDKからのすべてのソートされたソース（BitSet、TreeSet、IntStream.range）にはすでに一意の要素が含まれているため、distinct（）は役に立たない。 理論的には、セットの前半がtrueで後半がfalseの場合、プロセッサでの分岐予測が優れているため、フィルター操作は何かに勝つことができます。 ただし、データが既に述語でソートされている場合は、Stream APIを使用せず、バイナリ検索を使用して境界線を見つける方が効率的です。 さらに、入力データのソートが不十分な場合、ソート自体が遅くなります。 したがって、ソート（）の場合、ランダムデータのDistinct（）は、distinct（）自体が高速化されますが、distinct（）よりも低速になります。



- コードのデバッグに関連する重要な問題を提起する必要があります。 peek（）メソッドを使用して中間結果を取得しますか？ 独自のテストの秘密を持っている可能性はありますか？ それらを読者と共有してください。



-何らかの理由で、デバッグにpeek（）を使用しません。 ストリームが非常に複雑で、プロセスで不可解なことが発生した場合、それを複数の（中間リストを使用して）分割して、このリストを確認できます。 一般に、IDEの通常のステップバイステップデバッガーでストリームをバイパスすることに慣れることができます。 最初は怖いですが、それに慣れます。



新しいスプリッターとコレクターを開発するとき、包括的なテスト、さまざまな不変条件のチェック、異なる条件下での起動を行うテストで補助メソッドを使用します。 パラレルストリームとシリアルストリームの結果が同じであることを比較するだけでなく、パラレルストリームに人工スプリッターを挿入できます。これにより、パラレルタスクを作成するときに空のフラグメントが生成されます。 結果に影響を与えてはならず、重要なバグを見つけるのに役立つはずです。 または、スプリッターをテストするとき、それらをランダムに（ただし同じスレッドで）実行するサブタスクにランダムに分割し、結果を順次のものと比較します。 これは安定した再現可能なテストであり、シングルスレッドですが、並列スプリッターでほとんどのエラーをキャッチできます。 一般に、すべてのコードブロックを包括的にチェックし、エラーが発生した場合に健全なレポートを発行するクールなテストシステムは、通常デバッグを完全に置き換えます。



- 今後、Stream APIのどのような開発が見られますか？



-難しい質問です。将来を予測する方法がわかりません。 現在、多くは4つのStream APIの特殊化（Stream、IntStream、LongStream、DoubleStream）の存在に依存しているため、多くのコードを4回複製する必要があります。 誰もがジェネリックスペシャライゼーションを楽しみにしています。ジェネリックスペシャライゼーションはJava 10で完成する可能性があります。そうすれば簡単になります。



Stream API拡張機能にも問題があります。 ご存じのように、Streamはインターフェイスであり、何らかの最終クラスではありません。 一方で、これにより、サードパーティの開発者がStream APIを拡張できます。 一方、Stream APIに新しいメソッドを追加するのはそれほど簡単ではありません。Java8でこのインターフェースを既に実装しているすべてのクラスを壊す必要はありません。 新しいメソッドはそれぞれ、既存のメソッドの観点から表されたデフォルトの実装を提供する必要がありますが、これは常に可能で簡単ではありません。 したがって、機能の爆発的な成長はほとんど期待できません。



Java 9で表示される最も重要なことは、takeWhileおよびdropWhileメソッドです。 Stream.ofNullable、Optional.streamの3つの引数といくつかの新しいコレクター-flatMapping、filteringで反復する小さな楽しいものがあります。 しかし、全体として、まだ多くが見落とされます。 しかし、JDKにはストリームを作成する追加のメソッドがあります。新しいAPIは現在ストリームに注目して開発されており、古いAPIは強化されています。



- 多くの人が、2015年のスピーチを「私たちは何を測定しているのですか？」というレポートで思い出しました。 今年は新しいジョーカーのテーマを計画していますか？ それはどうなるのでしょうか？



-新しいレポートを作成することにしましたが、「Stream API Fads」とはあまり創造的ではありません。 これは、ある意味で、JPointのレポート「ストリームAPIの奇異」の続きです。Java9で修正されるものに焦点を当てて、ストリームAPIの予期しないパフォーマンス効果と滑りやすいスポットについて説明します。



- 興味深く、詳細な回答をありがとうございます。 新しいパフォーマンスを楽しみにしています。

---

Joker 2016カンファレンスでは、Stream APIおよびその他のJavaハードコアの世界に触れることができます。 講演者への質問、レポートに関する議論、無限のネットワーキングもあります。