5

複数のスレッドからアクセスできる HashMap が必要です。

通常の HashMap を使用して同期する方法と、ConcurrentHashMap を使用する方法の 2 つの簡単なオプションがあります。

ConcurrentHashMap は読み取り操作でブロックしないため、私のニーズにははるかに適しているようです (ほとんど読み取りだけで、更新はほとんどありません)。一方、同時実行性は非常に低いと予想されるため、ブロッキングは発生しないはずです (ロックを管理するコストのみ)。

それが違いを生む場合、マップも非常に小さくなります (10 エントリ未満)。

通常の HashMap と比較して、読み取り操作と書き込み操作のコストはどのくらい高くなりますか? それとも、読み取り/更新の比率とサイズに関係なく、中程度のレベルの同時アクセスが存在する可能性がある場合でも、ConcurrentHashMap は常に優れているのでしょうか?

4

4 に答える 4

6

一方、同時実行性は非常に低いと予想されるため、ブロッキングは発生しないはずです (ロックを管理するコストのみ)。

競合しないJava ミューテックス (プリミティブ ロック)を取得して解放するコストはごくわずかです。したがって、競合の可能性が非常に低いと思われる場合HashMapは、おそらく単純なものが最善の策です。

しかし、これはすべて推測です。アプリケーションを実際にプロファイリングしない限り、投機的な最適化に費やされるすべての時間は、ほとんどの場合 (*) 無駄になります。

* ... あなたが本当に優れた直感を持っていない限り。

于 2010-10-17T02:19:40.263 に答える
2

スループットとパフォーマンスに関しては、通常、オーバーヘッドは無視できます。

別の注意として、ConcurrentHashMap の (インスタンス レベルでの) メモリ フットプリントは、HashMap よりもいくらか大きくなります。小さなサイズの CHM が多数ある場合、このオーバーヘッドが増える可能性があります。

于 2010-10-17T15:53:18.920 に答える
2

CHM は、Atomic* 操作を裏で使用した場合に、HashMap. いくら?何を推測します...あなたのアプリでそれを測定してください... ;-)

実際にパフォーマンスの問題があることがわかった場合は、おそらく 10 エントリ未満の非常に特殊なソリューションがあり、java.util土地の外で組み立てたソリューションよりも安価ですが、パフォーマンスの問題があることがわかるまで、それに飛びつくことはありません。

于 2010-10-17T02:09:22.473 に答える
0

CHM に関する主な問題: c-tor 呼び出しを変更しない限り、うまくスケーリングされませんが、ほとんどの場合、使用可能なコアに対して自動的にスケーリングされません。

以下の 3 つのリンクは、ロックフリーのハッシュマップです
http://www.azulsystems.com/blog/cliff-click/2007-03-26-non-blocking-hashtable
http://www.azulsystems.com/blog/cliff-click /2007-04-01-non-blocking-hashtable-part-2
http://sourceforge.net/projects/high-scale-lib/

于 2011-01-24T12:18:16.147 に答える