ForkJoinTaskのキャンセルメカニズムは、強制スレッド中断ではなく協調的なフラグに依存しています。これは、cancel()が単に内部の揮発性ステータスを設定するだけで、タスクが明示的に終了要求を確認する必要があることを意味します。したがって、この設計は、FileChannelの読み取りやソケットのInputStream操作などのモノリシック I/O 操作を待機しているスレッドをアンブロックすることができません。これらのブロッキング呼び出しはキャンセルフラグを確認せず、標準的なスレッド中断メカニズムによって中断されることはありません。
作業者がブロックされているときのプールの枯渇を防ぐために、ForkJoinPool.managedBlock API は、開発者が ForkJoinPool.ManagedBlocker インスタンスを登録できるようにします。このブロッカーは、ブロッキング作業にもかかわらず目標の並列性レベルを維持するために、プールに補償作業スレッドを生成するように指示します。ブロッカーの isReleasable メソッドは、プログラム的にキャンセルステータスを確認するフックを提供します。これにより、プールは応答のない I/O に対してスレッド予算を使い果たすのではなく、優雅に劣化することができるようになります。
私たちは、カスタムRecursiveTask内で Files.lines() を使用した並列ログプロセッサを構築中に、この制限に遭遇しました。このタスクは、ネットワークマウントストレージデバイスからテラバイト規模のログファイルを解析していました。ユーザーが長時間実行している分析ジョブのキャンセルを要求すると、ForkJoinPool スレッドは数分間、ブロッキング read() システムコールでスタックしたままでした。彼らはキャンセルフラグを完全に無視し、新しいタスクの開始を防ぎ、深刻なスレッドの枯渇を引き起こしました。
私たちは、デッドロックを解決するために三つの異なるアプローチを検討しました。最初のアプローチは、ForkJoinPoolを完全に放棄し、キャッシュされたThreadPoolExecutorに切り替えることでした。これにより、シンプルな中断セマンティクスと即座のスレッド置換が提供されましたが、CPU集約型の解析段階にとって重要な作業の盗用効率を犠牲にしました。
第二のアプローチは、すべてのI/O呼び出しをThread.interrupt() ロジックでラップし、SocketChannelのような中断可能なチャネルに切り替えることを提案しました。この方法は即時キャンセルをサポートしましたが、標準のブロッキングストリームとサードパーティのパーサーに依存するレガシーライブラリコードとの互換性に欠ける侵入的なものでした。
第三のアプローチでは、ファイル読み取りループをラップするカスタムManagedBlockerを実装することによってForkJoinPool.managedBlockを活用しました。このブロッカーは、ブロッキングスレッドが補償スレッドを生成できるように、定期的に**isCancelled()**をチェックしました。私たちは、ブロッキング操作をプールに明示的に通知し、既存の並列ストリームアーキテクチャを保持する第三の解決策を選択しました。これにより、キャンセルへの応答性とスループットのバランスが保たれ、I/Oレイヤー全体を再記述することなく済みました。
その結果、キャンセル要求が数秒以内に伝播するシステムが実現されました。プールは手動設定なしでI/Oスパイク中に50スレッドまで動的にスケールしました。CPUの飽和は、作業負荷全体で高いままであり、ジョブの終了は、重いネットワーク混雑中でも信頼できるものになりました。
ForkJoinPoolはどのように明示的なmanagedBlock呼び出しなしでスレッドのブロッキングを検出し、補償スレッドを生成する際の閾値は何か？
プールは内部で64ビットのctlフィールドを通じて作業者スレッドの状態を追跡しています。このフィールドは、アクティブなカウントとパークされたカウントを表します。作業者がタスクを実行しているときは"アクティブ"としてカウントされますが、プログラマーのヒントなしではCPU集約型の作業とブロッキングI/Oを区別することはできません。作業者がmanagedBlockを使用せずに同期モニターやI/Oでブロックすると、プールは盗用可能な作業と利用可能な作業者の減少しか観察しません。並列性レベルに達して進行信号が届かない場合、最終的に停止する可能性があります。補償スレッドは、managedBlockが呼び出されたときまたは内部JVMのブロッキングがUnsafe.parkカウンタによって検出されたときにのみ確実に生成されますが、デフォルトの閾値は不透明で独自のブロッキングコードには信頼性がありません。
ForkJoinTask.join() がタスクがキャンセルされると即座に戻らないのはなぜか、また Future.get() とのタイムアウトにおいてそれがどのように異なるのか？
join() は内部で doJoin() を呼び出し、呼び出しスレッドが他の作業を実行または盗んでターゲットタスクが完了するまで待つ"ヘルプ"メカニズムを実装しています。これはキャンセル状況に関係なく発生します。キャンセルは新しいサブタスクのフォークを防ぎ、完了フラグを設定するのみです。このメソッドは待機前にキャンセルフラグをポーリングせず、エントリー時に CancellationException をスローしません。対照的に、ForkJoinTask上のFuture.get()（Futureを実装）がキャンセル状況を即座にチェックし、待機することなくCancellationExceptionをスローできます。この区別は重要で、join() はプール内の協力を目的として設計されているのに対し、get() は標準のFutureセマンティクスを期待する外部クライアントのためのものです。
ForkJoinPoolの並列性レベルと**Runtime.availableProcessors()**の間の相互作用は何か、またなぜ利用可能なプロセッサより高い並列性を設定することがブロッキング操作のスループットを改善する可能性があるのか？
デフォルトの共通プールは、アプリケーションスレッドまたはガベージコレクションのために1つのコアを予約するため、availableProcessors() - 1で初期化されます。並列性はアクティブなスレッドの数のターゲットを定義しますが、厳密な最大値ではありません。プールはmanagedBlockがブロッキング作業を示す場合に、より多くのスレッドを作成できますが、実際にアクティブなのはparallelismスレッドだけです。ブロッキング操作のために、並列性をコア数よりも高く設定する（例：コアの2倍または3倍）は、他のスレッドがI/Oを待っている間にスケジューラがCPUを忙しく保てるようにします。これは、ブロッキングしているにもかかわらず各コアに実行可能なタスクが存在することを保証することによって、"スレッド毎コア"の制限を解消します。ただし、ブロッキング比率が誤って推定されている場合は、過剰なコンテキストスイッチングのオーバーヘッドを防ぐために注意深く調整する必要があります。