マルチコア マシンで多数の (1 億を超える) 要求を処理する必要があります (各要求はデータ ファイル内の行を処理するためのものであり、リモート システムとの I/O を伴います。詳細はあまり重要ではありませんが、 、特定のタスクは、いくつかのデータ ファイルから配布された Hazelcast マップを読み込むことです)。実行はThreadPoolExecutorを通じて処理されます。1 つのスレッドがファイルを読み取り、データを複数の独立したスレッドに送信してマップに配置します。マシンには 32 個のコアがあるため、マップの並列読み込みに十分な空き容量があります。
リクエストの数が多いため、タスクを作成して executor サービスのキューに入れるという一般的な方法は、キューに入れられたタスクが大量のメモリを消費するため、現実的ではありません。
ExecutorCompletionServiceをもたらします。それを使用すると、前の操作が完了したときにタスクが送信されます。これは、呼び出しtake()(またはpoll()、該当する場合) によって認識されます。これは、executor サービスのすべてのスレッドが使用されている場合に正常に機能します。ただし、「すべてのスレッドをロードする」ことはまだ行われていません。次の 2 つのフェーズがあります。
キューをいっぱいにする: プールにまだ未使用のスレッドがある間に、タスクを ExecutorCompletionService に送信し、さらに送信するまで待機しません。
feed the queue : スレッドがすべて使用されたら、前のタスクが終了したときにのみタスクを送信します。したがって、行は可能な限り迅速にフィードされますが、それ以上速くはならず、キューにも入れられません。
上記はコーディングできますが、上記のロジックが既に実装されているかどうか疑問に思っていて、どういうわけか見逃していました。よくあるシナリオだと思うので質問します。