3

バケットレベルのロックにより、Collections.synchronizedMap（...）/ hashtableの代わりにCHMを使用すると、パフォーマンスが向上します。

イテレータにConcurrentModificationExceptionをスローさせたくない場合は、CHMを使用することもOKです。

しかし、CHMのコンテキストでの意味と混同さthread-safeれています。これは、変更が取得と書き込みの重複の間に反映されるのを妨げないためです。

4

2 に答える 2

2

ConcurrentHashMapスレッドセーフとは、複数のスレッド間でオブジェクトを共有し、外部ロックなしでそのオブジェクトに同時にアクセス/変更できることを意味します。

正確なセマンティクスはドキュメントで説明されています：

取得操作（を含むget）は通常ブロックされないため、更新操作（およびを含む）と重複する場合がありputますremove。取得は、開始時に保持されている最後に完了した更新操作の結果を反映します。

putAllおよびなどの集計操作のclear場合、同時取得は一部のエントリのみの挿入または削除を反映する場合があります。同様に、イテレータ/列挙の作成時または作成以降のある時点でのハッシュテーブルの状態を反映する要素Iteratorsを返します。Enumerations彼らは投げませんConcurrentModificationException。ただし、イテレータは、一度に1つのスレッドのみが使用するように設計されています。

于 2012-06-13T13:19:54.057 に答える
1

Aixが述べたように、ConcurrentHashMap外部ロックなしで複数のスレッド間でオブジェクトを共有することはThread-Safe

仕組みは、ConcurrentHashMap（Sunの現在の実装）が、基になるマップをいくつかの個別のバケットに分割することで機能するようなものです。要素を取得すること自体はロックを必要としませんが、アトミック/揮発性操作を使用します。これは、メモリバリア（非常にコストがかかる可能性があり、他の可能な最適化に干渉する可能性があります）を意味しますが、Collections.synchronizedMap(...)ロックはマップ全体に適用されるため、コストがかかります。

使用法： ConcurrentHashMap is implemented for higher throughput in cases where high concurrency is expected

于 2012-06-13T13:28:44.817 に答える