Java で一般的に使用されるいくつかのスレッドプールの比較に関する簡単な説明-＆＃＆チュートリアル-php.cn

1. スレッドプールを使用する理由

Web サーバー、データベースサーバー、ファイルサーバー、メールサーバーなどの多くのサーバーアプリケーションは、リモートソースからの多数の短いタスクを処理することを目的としています。リクエストは、ネットワークプロトコル (HTTP、FTP、POP など)、JMS キュー、またはデータベースのポーリングなど、何らかの方法でサーバーに到達します。リクエストの到着方法に関係なく、サーバーアプリケーションでは、単一タスクの処理時間は非常に短いのに、リクエストの数が膨大になることがよくあります。

サーバーアプリケーションを構築するための単純なモデルは、リクエストが到着するたびに新しいスレッドを作成し、その新しいスレッドでリクエストを処理することです。実際、このアプローチはプロトタイピングには問題なく機能しますが、この方法で実行されるサーバーアプリケーションを展開しようとすると、このアプローチの重大な欠点が明らかになります。リクエストごとのスレッドのアプローチの欠点の 1 つは、リクエストごとに新しいスレッドを作成するのにコストがかかることです。リクエストごとに新しいスレッドを作成するサーバーは、スレッドの作成と破棄に多くの時間を費やし、より多くの時間とシステムを消費します。実際のユーザー要求の処理に費やされるリソースよりも多くのリソースが使用されます。

スレッドの作成と破棄のオーバーヘッドに加えて、アクティブなスレッドはシステムリソースも消費します。 JVM で作成するスレッドが多すぎると、システムがメモリ不足になったり、過度のメモリ消費による「オーバースイッチ」が発生したりする可能性があります。リソースの枯渇を防ぐために、サーバーアプリケーションには、一度に処理できるリクエストの数を制限する何らかの方法が必要です。

スレッドプールは、スレッドライフサイクルのオーバーヘッド問題とリソース不足の問題の解決策を提供します。複数のタスクにスレッドを再利用することにより、スレッド作成のオーバーヘッドが複数のタスクに分散されます。利点は、リクエストが到着したときにスレッドがすでに存在しているため、スレッドの作成によって生じる遅延も不用意に解消されることです。こうすることで、リクエストを即座に処理できるため、アプリケーションの応答性が向上します。さらに、スレッドプール内のスレッドの数を適切に調整することにより、つまりリクエストの数が一定のしきい値を超えた場合、他の受信リクエストは、それらを処理するためのスレッドが取得されるまで強制的に待機されるため、リソースの不足を防ぐことができます。

2. スレッドプールを使用するリスク

スレッドプールはマルチスレッドアプリケーションを構築するための強力なメカニズムですが、その使用にはリスクがないわけではありません。スレッドプールを使用して構築されたアプリケーションは、同期エラーやデッドロックなど、他のマルチスレッドアプリケーションが影響しやすいすべての同時実行リスクの影響を受けやすくなります。また、プール関連のデッドロックなど、スレッドプールに特有の他のいくつかのリスクにも影響されます。 , リソース不足とスレッド漏れ。

2.1 デッドロック

マルチスレッドアプリケーションにはデッドロックの危険があります。プロセスまたはスレッドのグループのそれぞれが、グループ内の別のプロセスによってのみ引き起こされる可能性のあるイベントを待機しているとき、そのプロセスまたはスレッドのグループはデッドロックしていると言います。デッドロックの最も単純なケースは、スレッド A がオブジェクト X の排他ロックを保持し、オブジェクト Y のロックを待機しているのに対し、スレッド B はオブジェクト Y の排他ロックを保持しているが、オブジェクト X のロックを待機していることです。ロックの待機を解除する何らかの方法がない限り (Java ロックはこの方法をサポートしていません)、デッドロックされたスレッドは永久に待機することになります。

マルチスレッドプログラムにはデッドロックのリスクがありますが、スレッドプールではデッドロックの別の可能性が生じます。つまり、すべてのプールスレッドが、キュー内でブロックされて待機している別のタスクを実行しますが、その結果を実行するタスクです。占有されていないスレッドがないため、タスクを実行できません。これは、スレッドプールを使用して、多くの相互作用するオブジェクトが関与するシミュレーションを実装する場合に発生します。シミュレートされたオブジェクトは相互にクエリを送信でき、クエリオブジェクトが同期的に応答を待機している間に、これらのクエリはキューに入れられたタスクとして実行されます。

2.2 リソース不足

スレッドプールの利点の 1 つは、他の代替スケジューリングメカニズム (そのうちのいくつかはすでに説明しました) と比べて一般的に非常に優れたパフォーマンスを発揮することです。ただし、これはスレッドプールサイズが適切に調整されている場合にのみ当てはまります。スレッドは、メモリやその他のシステムリソースを含む大量のリソースを消費します。 Thread オブジェクトに必要なメモリに加えて、各スレッドには 2 つの実行呼び出しスタックが必要ですが、これは大きくなる可能性があります。さらに、JVM は Java スレッドごとにネイティブスレッドを作成する場合があり、これらのネイティブスレッドは追加のシステムリソースを消費します。最後に、スレッド間の切り替えによるスケジューリングのオーバーヘッドは小さいですが、スレッドが多数ある場合、コンテキストの切り替えがプログラムのパフォーマンスに重大な影響を与える可能性があります。

スレッドプールが大きすぎる場合、それらのスレッドによって消費されるリソースがシステムのパフォーマンスに重大な影響を与える可能性があります。スレッド間の切り替えは時間を無駄にします。また、実際に必要な以上のスレッドを使用すると、他のタスクでより効率的に使用される可能性のあるリソースをプールスレッドが消費するため、リソース枯渇の問題が発生する可能性があります。スレッド自体によって使用されるリソースに加えて、リクエストの処理で実行される作業には、JDBC 接続、ソケット、ファイルなどの他のリソースが必要になる場合があります。これらもリソースが限られており、同時リクエストが多すぎると、JDBC 接続を割り当てられないなどの障害が発生する可能性があります。

2.3 同時実行エラー

スレッドプールとその他のキューイングメカニズムは wait() メソッドと Notice() メソッドの使用に依存していますが、どちらも使用するのが困難です。正しくコーディングされていない場合、通知が失われ、キューに処理すべき作業があるにもかかわらず、スレッドがアイドル状態のままになる可能性があります。これらの方法を使用する場合は、細心の注意を払う必要があります。代わりに、util.concurrent パッケージなど、動作することがすでにわかっている既存の実装を使用することをお勧めします。

2.4 スレッドリーク

さまざまなタイプのスレッドプールにおける重大なリスクはスレッドリークです。これは、タスクを実行するためにスレッドがプールから削除され、タスクの完了後にスレッドがプールに戻されない場合に発生します。。スレッドリークが発生する状況の 1 つは、タスクが RuntimeException またはエラーをスローした場合です。プールクラスがそれらをキャッチしない場合、スレッドは単に終了し、スレッドプールのサイズは永続的に 1 つ減ります。これが何度も発生すると、最終的にはスレッドプールが空になり、タスクを処理できるスレッドがなくなるためシステムが停止します。

一部のタスクは特定のリソースまたはユーザーからの入力を永遠に待機する可能性があり、これらのリソースが利用可能になるとは限りません。そのようなタスクは永久に停止し、これらの停止したタスクもスレッドと同じ問題を引き起こします。リーク。スレッドがそのようなタスクによって永続的に消費される場合、そのスレッドは事実上プールから削除されます。このようなタスクの場合は、独自のスレッドのみを与えるか、限られた時間だけ待機させる必要があります。

2.5 リクエストの過負荷

リクエストだけでサーバーに負荷がかかる可能性があります。このシナリオでは、実行のためにキューに入れられたタスクがシステムリソースを大量に消費し、リソース枯渇を引き起こす可能性があるため、すべての受信リクエストをワークキューにキューに入れることは望ましくありません。この状況で何をするかはユーザー次第です。場合によっては、単純にリクエストを放棄し、上位レベルのプロトコルを利用して後でリクエストを再試行することも、サーバーが一時的に停止していることを示す応答で応答することもできます。リクエストを拒否するのに忙しいです。

3. スレッドプールを効果的に使用するためのガイドライン

いくつかの簡単なガイドラインに従う限り、スレッドプールはサーバーアプリケーションを構築する非常に効果的な方法になります。

他のタスクの結果を同期的に待機しているタスクをキューに入れないでください。タスク。これにより、前述のデッドロックの形式が発生する可能性があります。この状態では、すべてのスレッドが非常にビジーであるために実行できないキューに入れられたタスクの結果を待っているタスクによってすべてのスレッドが占有されます。

長時間かかる可能性のある操作にプールされたスレッドを使用する場合は注意してください。 I/O などのリソースが完了するまでプログラムが待機する必要がある場合は、最大待機時間を指定し、その後タスクを無効にするか、後で実行するために再度キューに入れるかを指定します。そうすることで、正常に完了する可能性が高いタスクへのスレッドを解放することで、最終的にある程度の進捗が得られることが保証されます。

タスクを理解します。スレッドプールのサイズを効果的に設定するには、キューに入れられているタスクとその実行内容を理解する必要があります。 CPU に依存しているのでしょうか? I/Oバウンドですか?あなたの答えは、アプリケーションの調整方法に影響します。特性が大きく異なるさまざまなタスククラスがある場合、それに応じて各プールを調整できるように、さまざまなタスククラスに複数のワークキューを用意することが合理的である可能性があります。

4. スレッドプールサイズの設定

スレッドプールのサイズを調整するのは、基本的に、スレッドが少なすぎるかスレッドが多すぎるという 2 種類のエラーを回避するためです。幸いなことに、ほとんどのアプリケーションでは、多すぎることと少なすぎることの間のマージンがかなり広いです。

覚えておいてください: アプリケーションでスレッドを使用すると、I/O などの遅い操作を待っていても処理を続行できること、および複数のプロセッサを活用できることという 2 つの主な利点があります。 N 個のプロセッサを備えたマシンの計算制約下で実行されているアプリケーションでは、スレッド数が N に近づくにつれてスレッドを追加すると全体の処理能力が向上する可能性がありますが、スレッド数が N を超えると追加のスレッドを追加しても効果はありません。実際、スレッドが多すぎると、追加のコンテキスト切り替えオーバーヘッドが発生するため、パフォーマンスが低下する可能性さえあります。

スレッドプールの最適なサイズは、使用可能なプロセッサの数とワークキュー内のタスクの性質によって異なります。 N 個のプロセッサ (すべてが計算タスク) を備えたシステム上にワークキューが 1 つだけある場合、通常、スレッドプールに N または N+1 のスレッドがあるときに CPU 使用率が最大になります。

I/O が完了するまで待機する必要がある可能性のあるタスク (ソケットから HTTP リクエストを読み取るタスクなど) については、すべてのスレッドが動作しているわけではないため、プールサイズを使用可能なプロセッサーの数を超えるようにする必要があります。時間。プロファイリングを使用すると、一般的なリクエストの待機時間 (WT) とサービス時間 (ST) の比率を推定できます。この比率を WT/ST と呼ぶ場合、N 個のプロセッサを備えたシステムの場合、プロセッサを最大限に活用するには、約 N*(1+WT/ST) 個のスレッドをセットアップする必要があります。

スレッドプールのサイジングプロセスで考慮すべき点は、プロセッサーの使用率だけではありません。スレッドプールが大きくなるにつれて、スケジューラ、使用可能なメモリ、またはソケットの数、開いているファイルハンドル、データベース接続などのその他のシステムリソースに制限が生じる可能性があります。

5. 一般的に使用されるいくつかのスレッドプール

5.1 newCachedThreadPool

スレッドプールの長さが処理の必要性を超えた場合、アイドル状態のスレッドを柔軟にリサイクルできます。作成した。

このタイプのスレッドプールの特徴は次のとおりです:

• 作成されるワーカースレッドの数にほとんど制限がないため (実際には制限があり、数は Integer.MAX_VALUE です)、スレッドを追加できます。スレッドプールに柔軟に対応します。

• スレッドプールにタスクが長期間送信されなかった場合、つまり、ワーカースレッドが指定された時間 (デフォルトは 1 分) アイドル状態になった場合、ワーカースレッドは自動的に終了します。終了後に新しいタスクを送信すると、スレッドプールはワーカースレッドを再作成します。

• CachedThreadPool を使用する場合は、タスクの数の制御に注意する必要があります。そうしないと、同時に多数のスレッドが実行されるため、システムが麻痺する可能性があります。

サンプルコードは以下の通りです:

package test;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
public class ThreadPoolExecutorTest {
 public static void main(String[] args) {
 ExecutorService cachedThreadPool = Executors.newCachedThreadPool();
 for (int i = 0; i < 10; i++) {
  final int index = i;
  try {
  Thread.sleep(index * 1000);
  } catch (InterruptedException e) {
  e.printStackTrace();
  }
  cachedThreadPool.execute(new Runnable() {
  public void run() {
   System.out.println(index);
  }
  });
 }
 }
}

ログイン後にコピー

5.1 newFixedThreadPool

指定された数のワーカースレッドを持つスレッドプールを作成します。タスクが送信されるたびにワーカースレッドが作成され、ワーカースレッドの数がスレッドプールの初期最大数に達すると、送信されたタスクはプールキューに格納されます。

FixedThreadPool は典型的な優れたスレッドプールで、プログラムの効率を向上させ、スレッド作成時のオーバーヘッドを節約するという利点があります。ただし、スレッドプールがアイドル状態のとき、つまりスレッドプールに実行可能なタスクがないときは、ワーカースレッドは解放されず、特定のシステムリソースも占有します。

サンプルコードは以下の通りです:

package test;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
public class ThreadPoolExecutorTest {
 public static void main(String[] args) {
 ExecutorService fixedThreadPool = Executors.newFixedThreadPool(3);
 for (int i = 0; i < 10; i++) {
  final int index = i;
  fixedThreadPool.execute(new Runnable() {
  public void run() {
   try {
   System.out.println(index);
   Thread.sleep(2000);
   } catch (InterruptedException e) {
   e.printStackTrace();
   }
  }
  });
 }
 }
}

ログイン後にコピー

スレッドプールサイズが3なので、各タスクはインデックス出力後2秒間スリープするため、2秒ごとに3つの数字が出力されます。

固定長スレッドプールのサイズは、Runtime.getRuntime().availableProcessors() などのシステムリソースに応じて設定するのが最適です。

5.1 newSingleThreadExecutor

シングルスレッド Executor を作成します。つまり、タスクを実行するための唯一のワーカースレッドのみを作成し、すべてのタスクが指定された順序 (FIFO、FIFO) になるようにします。 LIFO、優先レベル) の実行。このスレッドが異常終了した場合は、順次実行を保証するために別のスレッドに置き換えられます。単一ワーカースレッドの最大の特徴は、タスクが順番に実行され、同時に複数のスレッドがアクティブになることがないことを保証できることです。

サンプルコードは以下の通りです:

package test;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
public class ThreadPoolExecutorTest {
 public static void main(String[] args) {
 ExecutorService singleThreadExecutor = Executors.newSingleThreadExecutor();
 for (int i = 0; i < 10; i++) {
  final int index = i;
  singleThreadExecutor.execute(new Runnable() {
  public void run() {
   try {
   System.out.println(index);
   Thread.sleep(2000);
   } catch (InterruptedException e) {
   e.printStackTrace();
   }
  }
  });
 }
 }
}

ログイン後にコピー

5.1 newScheduleThreadPool

固定長のスレッドプールを作成し、スケジュールされた定期的なタスクの実行をサポートし、スケジュールされた定期的なタスクの実行をサポートします。

3 秒間実行を遅延します。遅延実行のサンプルコードは次のとおりです。

package test;
import java.util.concurrent.Executors;
import java.util.concurrent.ScheduledExecutorService;
import java.util.concurrent.TimeUnit;
public class ThreadPoolExecutorTest {
 public static void main(String[] args) {
 ScheduledExecutorService scheduledThreadPool = Executors.newScheduledThreadPool(5);
 scheduledThreadPool.schedule(new Runnable() {
  public void run() {
  System.out.println("delay 3 seconds");
  }
 }, 3, TimeUnit.SECONDS);
 }
}

ログイン後にコピー

は、1 秒の遅延後に 3 秒ごとに実行されることを意味します。通常の実行のサンプルコードは次のとおりです。

上記の記事は、一般的に使用されるいくつかの Java スレッドプールの比較について簡単に説明したものであり、編集者が共有するすべての内容が参考になることを願っています。また、PHP 中国語 Web サイトをサポートしていただければ幸いです。

Java で一般的に使用されるいくつかのスレッドプールの比較に関するその他の関連記事については、PHP 中国語 Web サイトに注目してください。