2

スレッドセーフのクラスを単体テストしています。異なるスレッドからそのメソッドを呼び出して、それらすべてが同じ結果を受け取るようにします (一言で言えば)。これは、使用するスレッドの数を決定する方法です。

int threads = Runtime.getRuntime().availableProcessors() * 4;

それは良い習慣ですか？何個使えばいいですか？多ければ多いほどいい？

4

3 に答える 3

6

私は通常、3 セットのテストを実行します。

  • シングルスレッド環境で正しい動作を確認するための 1 つのスレッド
  • プロセッサの数 + 1 (または、一般的なアプリケーションの設定)
  • コンテキストの切り替えと競合を増やすための多くのスレッド (たとえば 1000)

また、マルチスレッド テストでは、すべてのスレッドが多かれ少なかれ同時にタスクを開始するように、タスクの開始を CountDownLatch と同期させることによって、インターリーブを最大化しようとします。

また、テスト中の追加の同期を避けるようにしています (たとえば、スレッド セーフな構造を使用して結果を保存するなど)。これは、テストされたコードを人為的に "再同期" する可能性があるためです (ケースバイケースで評価されます)。

JCiPの第 12 章は、効率的なマルチスレッド テストを行うための良い着想源です (つまり、並行性のバグを引き起こす多くのヒントを与えてくれます)。

最後に、@PeterLawrey が指摘したように、コードがテストでスレッドセーフであることを保証することはできません。並行性のバグを見つける可能性を高めることしかできません。

于 2012-08-28T13:13:36.657 に答える
0

通常、スレッド化の問題はめったに発生しないため、スレッド化の問題を強調すればするほど、競合状態や競合の問題などが発生します。

したがって、4 * #processors では、意味のある結果が得られない可能性があります。実際、すべてが機能しているという誤った感覚を与えることさえあります。

本番環境で実際に同時に実行されるスレッドの数を見積もり、その数を大幅に上回る必要があります。

于 2012-08-28T13:22:23.810 に答える
0

これは、スレッドによって実行された IO の量によって異なります。CPU を集中的に使用するタスクの場合、1 コアあたり 1 スレッドが適していますが、データベースの読み取り/書き込み操作、ファイル操作などの IO タスクを待機している場合は、コアあたり 2 スレッド以上に数を増やしても安全です。パフォーマンスを測定するだけで、テストに最適な値が得られます:)

于 2012-08-28T13:12:36.750 に答える