4

生産者と消費者のシナリオを想像してみてください。スレッド A がエントリを生成し、他の複数のスレッドがそれらを消費します。

このために、一連のエントリを各コンシューマ スレッドに渡しています。

これを行うと、安価かどうかを自問しています（CPU使用率の意味ではプライマリ、メモリではセカンダリ）：

  • 各コンシューマー スレッドに の個別のインスタンスを提供しますHashMap。Mapを 1 つのコンシューマーに渡した後、意志の新しいインスタンスMapが作成され、次に生成されたエントリを次のスレッドに渡すために使用されます。

また

  • シングルを使用し、コンシューマ スレッドごとにConcurrentHashMapを作成し、をスレッドに渡した後、 - をクリアして、各 Iterator に基になる の独自のビューが含まれるようにします。IteratorIteratorMapMap

どう思いますか？多かれ少なかれ一般的な答えは可能ですか?
それとも、エントリ数、スレッドなどのいくつかの変数に強く依存していますか?
編集:または、これらの種類の問題をより適切に解決できる他の種類のデータ構造を使用する必要がありますか?

4

2 に答える 2

5

Java 並行パッケージは、まさにこのシナリオのためのデータ構造を提供します。

@見るjava.util.concurrent.BlockingDeque

ただし、パフォーマンステストを行ってください。結果はユースケースに大きく依存するためです。そして、これがマイクロ最適化にすぎない場合、クリーンで理解しやすいスレッド保存アプローチは、影響のないパフォーマンス最適化よりもはるかに優れています。

于 2011-01-18T10:40:27.927 に答える
0

CPU に関して最もコストがかかるのは、スレッドの競合です。最初のアプローチでは競合がまったく発生しないようです。各スレッドにはローカル バージョンの Map がありますが、メモリ消費量が高くなります。
1 つには、理にかなったいくつかのセットアップ (スレッド数、マップのサイズなど) の 2 つのシナリオのベンチマークを行います。ベンチマークなしで正確な数値を伝えるのは困難です。

于 2011-01-18T10:48:14.563 に答える