Java 8以前は、コレクション処理の並列化を手動でThread管理するか、明示的にExecutorServiceを使って処理を分担し、開発者が作業の分割と同期を手動で行う必要がありました。Java 8でのStream APIの導入により、Spliteratorインターフェースを通じて並列性が抽象化され、SIZEDなどの特性を使用して既知の要素数を示すことが可能になりました。この特性は、フレームワークがバランスの取れたバイナリ分割を実行し、ForkJoinPoolの最適なタスクツリーを作成できるようにします。
SpliteratorがSIZED特性を欠いている場合（生成関数、Iteratorバックのストリーム、または無限数列に一般的）、フレームワークはバイナリ分割（半分に分けること）を行えず、バランスの取れたタスクツリーを作成できません。盲目的な分割は、何百万もの小さなタスク（粒度爆発）を生成し、コーディネーションのオーバーヘッドが実行時間を支配するか、巨大なチャンクが生成され、1つのスレッドが膨大なバックログを処理している間にワーカースレッドがアイドル状態になることを引き起こします。この予測不可能性は、フォーク・ジョイン並列性の基本的な仮定、すなわち「作業をほぼ同じサブタスクに分割できる」ことを壊します。
フレームワークは、デフォルトのIteratorSpliterator実装を介して幾何バッチ処理を採用します。半分に分割する代わりに、指数的に増加するバッチサイズ（1, 2, 4, 8、最大バッチ数まで）を使用し、分割コストを均すと同時にタスク作成を対数的深さに制限します。ForkJoinPoolは、作業が知らないサイズを補うために、軽量タスクが好まれるワークスティーリングを利用し、AbstractTaskは総サイズ情報を必要とせずに完了信号を計算します。順序付きの無サイズストリームの場合、パイプラインは分割中に要素をArrayListにバッファして遭遇順を保持し、メモリを並列性の安全性とトレードオフします。
テレメトリーシステムは、Socket接続を介して到着するリアルタイムのセンサーデータを処理します。データはJSONオブジェクトの連続ストリームとして到着し、ビジネス要件では、ストレージ前にレイテンシを最小限に抑えるために、これらのオブジェクトを並列に解析およびフィルタリングする必要があります。課題は、到着レートとデータの総ボリュームの予測不可能性にあります。
最初の実装ではInputStreamをBufferedReaderでラップし、lines().parallel()を使用しました。しかし、性能プロファイリングは、並列ストリームが過剰なタスク生成オーバーヘッドのために逐次処理よりもはるかに遅いことを明らかにしました。根本原因は、BufferedReader.lines()からの基盤であるSpliteratorがSIZED特性を欠いており、最初にLong.MAX_VALUEを推定値として報告するため、フレームワークが個々の行のためにマイクロタスクを作成することになったからです。
1つのアプローチは、全ストリームを**ArrayList<String>**にバッファリングしてから並列処理を行うことでした。これにより、SIZED特性が提供され、CPUコア間で完璧なバイナリ分割が可能になります。しかし、これは許容できないレイテンシを引き起こしました—完全なバッチが到着するまでデータは処理できず、毎分数百万のイベントを処理する際に深刻なメモリプレッシャーを引き起こし、ストリーミングパラダイムを事実上無効にしました。
別の検討された解決策は、基盤となるストリームに関係なく常に固定サイズの1000行のチャンクを分割するカスタムSpliteratorを実装することでした。これにより予測可能なタスクサイズが提供されましたが、処理時間が行ごとに大きく異なる場合には失敗しました；1つのワーカーが1000の複雑なオブジェクトを受け取り、別のワーカーが1000の単純なものを受け取ることで、深刻な負荷の不均衡とアイドルCPUコアが最も遅いタスクを待つことになりました。
選択された解決策は、標準ライブラリの幾何バッチ戦略を模倣したカスタムSpliteratorの実装でした。これは、成功した分割ごとに倍加するbatch変数を1から開始し、最大1024まで進行し、フレームワークが事前の知識なしに実際のストリームの長さに適応できるようにしました。このアプローチは、ストリームが進むにつれて小さなタスクの初期オーバーヘッドと大きなバッチの効率をバランスしました。
幾何バッチ処理アプローチは、逐次処理と比較して8コアシステムで3.5倍の速度向上を達成しました。メモリ使用量はストリームの長さに関係なく一定に保たれ、処理は全体の実体化を待つことなく即座に開始されるためレイテンシも低く保たれました。適応サイズは、初期実装で悩まされた粒度爆発を防ぎました。
なぜ、同期コレクションを並列ストリームにラップすることが、CPU集約型の操作に対しても、逐次処理と比較してパフォーマンスを低下させることが多いのか？
多くの候補者は、Collections.synchronizedList()または同期Mapの実装が並列ストリームに対して安全であると仮定します。しかし、これらのコレクションのSpliteratorはSIZEDを報告しますが、各アクセスの同期に固有の内部プロセスが巨大なキャッシュ整合性トラフィックを生み出します。複数のForkJoinPoolスレッドが同じモニターを争うと、同期とコンテキストスイッチのコストが並列処理の利益を上回ります。正しいアプローチは、ConcurrentHashMapやCopyOnWriteArrayListを使用する（書き込みが稀な場合）か、ソースコレクションが干渉しないもので、スレッドセーフなSpliterator特性（CONCURRENTなど）を介してアクセスされることを保証する必要があります。
ORDERED特性は、無サイズストリームとどのように相互作用して端末操作を直列化する可能性があり、なぜsorted()はこれを悪化させるか？
候補者は、ORDEREDとSIZEDの欠如が組み合わさることで、フレームワークが処理の完了前にすべての要素をバッファリングする必要があることを見落としがちです。特に、sorted()やdistinct()のような状態を持つ操作にはこの影響があります。全体のサイズを知ることなしに、フレームワークはtoArray()用の最終配列またはマージソートバッファを事前に割り当てることができず、代わりに要素をリンクリストや動的にサイズ変更されるArrayListに蓄積し、パイプラインの完了段階を実質的に直列化します。つまり、並列スピードアップはmap/filterステージに限定され、端末ステージはフルデータセットを待つ単一スレッドのボトleneckになります。
カスタムSpliteratorのtrySplit()メソッドが親とは異なる特性のセットを報告するSpliteratorを返す場合、具体的にどのような契約違反が発生するか？
開発者がtrySplit()をオーバーライドするが特性の一貫性を保持しない場合、微妙なエラーが発生します。Spliterator契約では、返される自分自身のスプリッタが、順序、独特性、ソート性に関して親と同じ特性を持っている必要があります。親がORDEREDを報告するが子（分割結果）がそうでない場合、Streamフレームワークの最適化パスがソート段階を排除したり、操作を並べ替えたりする可能性があり、不正確な結果につながります。特性は分割ごとに安定している必要があり、パイプラインはこれらのフラグに基づいて融合を最適化、たとえばfilterとmapを組み合わせていますが、不一貫なフラグは並列正しさに必要な起こりうる前の関係を壊します。