Thread.interrupt() が Selector.select() でブロックされているスレッドを対象とすると、セレクタは選択されたキーセットが空のままで即座に返し、スレッドの中断フラグを設定します。これにより、呼び出しコードは返り値だけでチャンネルが I/O のために準備ができているのか、または返り値が単に中断信号を反映しているのかを判断できなくなるため、アーキテクチャのあいまいさが生じます。Selector.wakeup() とは異なり、これは中断ステータスに副作用を与えずにセレクタをブロック解除するのに対し、中断はシャットダウンシグナルを I/O イベントと混同させます。その結果、堅牢な実装では、Thread.interrupted() を明示的にチェックするか、共有のボラタイル状態変数を参照して、真の準備と虚偽のウェイクアップを区別する必要があり、CPU 集中型のスピンループを防ぎます。
高スループットの Java NIO ゲートウェイが市場データフィードを処理する場合を考えます。ここでは、専用スレッドが Selector.select() にブロックして SelectionKey イベントをワーカースレッドにディスパッチします。ゼロダウンタイムのデプロイメント中に、オーケストレーションレイヤーはこのセレクタスレッドに処理を優雅に終了させる必要があります。
最初の実装では、終了を知らせるために Thread.interrupt() を使用しました。これにより、select() が正常にブロック解除されましたが、重要なリバースロック状態を引き起こしました：select() がゼロのキーを返し、イベントループが CPU 使用率を最大限にしたまま連続して繰り返し処理される原因となりました。スレッドは、I/O アクティビティが存在すると仮定し、すべての登録されたチャンネルで非ブロッキング読み取りを試みましたが、準備されているチャンネルがなく、すぐに select() を再呼び出しし、それもすぐに戻りました。これは中断フラグが残っているためです。
提案された別の代替案では、無期限のブロッキングを select(100) に置き換え、ボラタイルな boolean シャットダウンフラグを使用しました。この戦略により、ブロッキング時間を制限することによって CPU の飽和を防ぎ、Thread.interrupt() に依存せずに終了シグナルを取得するための単純なポーリングメカニズムを提供しました。しかし、終了検出においてタイムアウト期間までの決定論的なレイテンシが導入され、ピーク負荷時にコンテキストスイッチのオーバーヘッドが 20% 増加し、高頻度操作のスループットが低下しました。
もう一つの候補解決策では、Selector.wakeup() をシャットダウンフックによってのみトリガーし、中断セマンティクスを完全に回避しました。これにより、空のキーセットに関するあいまいさなしに即座にブロック解除され、真の緊急終了シナリオのために中断フラグが保持されました。しかし、セレクタスレッドがキーを処理している間に wakeup() が実行されると、"失われたウェイクアップ" の競合条件のリスクがあり、select() が I/O イベントが到着するまで無期限にブロックされる可能性がありました。
最終設計では、慎重な happens-before セマンティクスを使用して、ボラタイルな AtomicBoolean シャットダウンフラグを Selector.wakeup() と同期しました。シャットダウンシーケンスはフラグを原子的に設定し、その後に wakeup() を呼び出し、イベントループは select() の戻り直後にフラグをチェックし、キーの可用性にかかわらず終了が要求された場合にクリーンに終了しました。これにより、CPU スピンを排除し、シャットダウン開始まで I/O のスループットを維持し、中断ステータスチェックに依存せずに 50ms 未満の終了レイテンシを達成しました。
ゲートウェイは、ローリングデプロイメント中に失敗したリクエストゼロで 10,000 を超える同時接続を正常に処理しました。CPU 使用率はシャットダウンシーケンスを通して基準レベルを維持し、アーキテクチャは I/O イベント処理とライフサイクル管理シグナルの明確な分離を提供しました。
Thread.interrupted() は Thread.isInterrupted() とどう異なり、フラグをクリアすることが入れ子のクリーンアップルーチンでどのような危険をもたらすのか？
Thread.interrupted() は現在のスレッドの中断ステータスをチェックしてクリアしますが、Thread.isInterrupted() はフラグを変更せずにプローブします。セレクタループでは、開発者はしばしば Thread.interrupted() を呼び出してシャットダウンシグナルを検出し、ループを終了することを意図します。しかし、その後のクリーンアップコードが channel.close() のようなブロッキング I/O 操作を行ったり、CountDownLatch ターミネーションを待機したりすると、これらの操作は以前にクリアされた中断ステータスを見ることができず、元の終了要求に応答するのではなく無期限にブロックされる可能性があります。
なぜ Selector.select() は中断時にゼロキーで通常返すのか、InterruptedException をスローする代わりに、そしてこれがどのような制御フローのあいまいさを生じるのか？
Object.wait() や Thread.sleep() などのブロッキングメソッドとは異なり、Selector.select() は InterruptedException を宣言せず、Thread.interrupt() が呼び出されたときに選択されたキーがゼロの状態で即座に返します。この設計選択により、偶然ゼロキーを返す可能性のある真の I/O 準備と中断信号が混同され、アプリケーションは「チャンネルが準備できていない」と「シャットダウンが要求された」とを区別するために明示的な状態チェックを実装せざるを得なくなります。候補者はしばしばこの区別を見逃し、ゼロのキーがリバースロックを示すか、すぐに再試行することを仮定したループを書き、セレクタが単に中断フラグに応答しているときに CPU の飽和を引き起こします。
なぜ Selector.wakeup() が共有変数に対してメモリ可視性の保証を提供しないのか、そしてこれがシャットダウンフラグのためにボラタイルまたは同期セマンティクスを必要とする理由は何か？
Selector.wakeup() はセレクタスレッドを原子的にブロック解除しますが、wakeup 呼び出しとブロック解除されたスレッドによる共有シャットダウン変数のその後の読み取りとの間に happens-before 関係を確立しません。そのため、シャットダウンフラグをボラタイルと宣言したり、同期ブロック内でアクセスしたりしない限り、セレクタスレッドは wakeup() が実行された後でも古いキャッシュされた値（false）を観察する可能性があり、選択に再度入って永久にブロックされる原因となります。これは Java メモリモデルの微妙な相互作用を意味し、wakeup() のみでは信頼できるスレッド間通信には不十分であり、状態変化の可視性を確保するためには適切な同期と組み合わせる必要があります。