Javaスレッドプールの使用の概要

最近のプロジェクトでは、SQL クエリを頻繁に使用したり、ファイルを書き込んだり、サブタスクを分割したりする必要がある状況に遭遇しました。プログラムのスループットを向上させるために、スレッド プールを使用します。

最初は、その数に応じてユーザーをシャーディングすることを検討してください。データベースクエリでは、Oracle では () 内の where に対するクエリの数が 1,000 を超えないという制限があるためです。したがって、900 ユーザーごとに 1 つのスライスに分割することを検討してください。各スライスは 1 つです。タスクは処理のために修正スレッド プールに渡されます。

ただし、各タスクには、クーポンのクエリと作成されるコメントの数のクエリという 2 つの大きなサブタスクがあります。これら 2 つのサブタスクは大量の SQL クエリを必要とするため、これら 2 つのサブタスクをタスクにカプセル化し、それらをスレッドに渡すことを検討しました。処理。ただし、メインタスクの実行はサブタスクの結果に依存するため、同じスレッドプールが使用されている場合、サブタスクがサブミットされた後も、ワークキューで実行されるタスクは依然としてメインタスクであり、CPU は最初に送信されたメインタスクで Future.get を待機していました () が返されると、サブタスクは実行するための CPU リソースを取得できず、タスクキューで待機しているため、プログラムは終了を待機します。したがって、送信されたタスクが CPU 時間を取得し、キュー内で常に待機しないことを期待して、スレッド プールが修正からキャッシュに変更されました。その後、これによって問題も発生しましたが、これについては次の記事で説明します。

ユーザーの請求書データが計算されるときは、テンプレート センターを呼び出して電子メールを生成する必要があり、生成された電子メールをディスクに保存する必要があります。これらは 2 つの異なる IO 集中型タスクであり、1 つはソケット上で待機しています。もう 1 つはローカル IO で待機します。キャッシュ スレッド プールにサブミットし続けると、スレッド プールがタスクごとにスレッドを生成するため、多くのリソースが消費され、CPU が頻繁にスレッドを切り替えてプログラムのスループットが低下することを考慮します。したがって、新しい修正スレッド プールを作成し、これらの後続のタスクを処理のために修正スレッド プールに送信します。スレッド プールは実行に固定数のジョブを使用します。これにより、プログラムはさまざまなブロック条件下で実行を継続でき、ブロックの作成が回避されます。大量のスレッドリソースが無駄になります。

実際、最終的なプログラムでは 5 つのスレッド プールが使用されました。グレーディングを使用する理由は次のとおりです。

プログラムの実行効率を向上させるために、最初に言語に従ってユーザーを分類し、次に次のように分けることができます。 900 人によるスライス。各スライスにはタスクがあり、各部分が処理された後、電子メールを作成するにはネットワーク IO が必要で、電子メールを保存するにはディスク IO が必要です。同じスレッド プールが使用されている場合、上位タスクによって生成されたサブタスクが修正スレッド プールに送信された後、ワーク キューは依然として上位タスクによって占有されているため、異なる種類の IO 操作がタスク キューで待機することになります。システムのスループットを向上させます。下位レベルのタスクを他のスレッド プールに送信した後、下位レベルのタスクはすぐに実行され、ネットワーク IO とディスクの読み取りと書き込みを実行できるため、操作効率が向上します。