43

ユーザーに HashMap を返すアプリケーションを作成しています。ユーザーは、この MAP への参照を取得します。バックエンドでは、マップを更新するいくつかのスレッドを実行します。

私はこれまでに何をしてきましたか？

すべてのバックエンド スレッドを作成したので、共通チャネルを共有して MAP を更新します。したがって、バックエンドでは、同時書き込み操作は問題にならないと確信しています。

私が抱えている問題

  1. ユーザーが MAP を更新しようとすると、同時に MAP がバックエンドで更新されます --> 同時書き込み操作の問題。
  2. MAP から何かを読み取ろうとすると同時に MAP がバックエンドで更新されている場合 --> 同時 READ および WRITE 操作の問題。

今までそのような問題に直面したことはありませんが、将来直面する可能性があることを恐れています. 提案してください。

私は使っているConcurrentHashMap<String, String>.

4

3 に答える 3

58

を使用して正しい軌道に乗っていConcurrentHashMapます。各ポイントについて:

  1. メソッドputIfAbsentを確認すると、replaceどちらもスレッドセーフであり、ハッシュマップの現在の状態のチェックと更新を 1 つのアトミック操作に組み合わせます。
  2. getメソッドは内部的に同期されませんが、指定されたキーの最新の値を返します (議論については ConcurrentHashMap クラスの Javadoc を確認してください)。

ConcurrentHashMaplikeの利点は、内部的に同期された方法で従来の Mapとロジックを提供するCollections.synchronizedMaplike の組み合わせメソッドです。これらの方法を使用し、独自のカスタム同期を提供しようとしないでください。機能しないためです。コレクションは内部的に同期され、他のスレッドはオブジェクトを同期しようとしても応答しません (たとえば、他のスレッドをブロックしません)。putIfAbsentgetputConcurrentHashMapjava.util.concurrentsynchronize(myConcurrentHashMap){}

于 2010-07-11T10:00:31.540 に答える
8

サイドノート：

Cliff Click によるロック フリー ハッシュ テーブルの実装を調べてみるとよいでしょう。これは、高度にスケーラブルな Javaライブラリの一部です。

(これは、このロックフリー ハッシュに関する Cliff Click によるGoogle トークです。)

于 2010-07-11T09:37:21.303 に答える
1

ConcurrentHashMap は、説明したシナリオの問題を回避するために設計および実装されました。心配する必要はありません。

取得の完全な同時実行性と、updates.updates の調整可能な予期される同時実行性をサポートするハッシュ テーブル。

ConcurrentHashMap の javadoc

于 2010-07-11T10:01:22.053 に答える