問題タブ [concurrenthashmap]

単語とそれに対応する整数インデックスをハッシュマップに保存する必要があります。ハッシュマップは同時に更新されます。

例： ハッシュマップには次のキーと値のペアが含まれますwordList。{a,b,c,a,d,e,a,d,e,b}

このためのコードは次のとおりです。

私の質問は、上記のクラスがスレッドセーフかどうかです。基本的に、この場合の不可分操作は、をインクリメントしmaxIndex、単語がない場合はハッシュマップに単語を配置することです。

この状況で並行性を実現するためのより良い方法はありますか？

ConcurrentHashMap.putAll（Map）メソッドはアトミックであると想定されていますか？

ドキュメントでそれを見つけることができず、ConcurrentMapインターフェースに記載されていないので、答えはノーだと思います。正直に言うと、その操作がアトミックでなければ意味がないので、確かにお願いしています。

アトミックでない場合、複数のアイテムのアトミック挿入をサポートするための最良の方法は何でしょうか？古き良き同期に戻りますか？

次の 2 つの状況を考慮してください。

1. 最初に一度データを入力し、その後多くの異なるスレッドからアクセスされるマップ。
2. 多くの異なるスレッドからアクセスされるキャッシュとして使用するマップ。マップに保存される結果が欠落していない限り、その計算を避けたい場合は、get-computation-store ブロックが同期されます。(それ以外の場合、マップは使用されません)

これらのケースのいずれかでConcurrentHashMap、通常以上のスレッド セーフに関して何か追加の機能はありますHashMapか?

ConcurrentHashMapをキャッシュとして使用する株式市場シミュレーターを作成しました。

キャッシュには約 75 個の要素が保持されますが、更新と取得は非常に高速です (1 秒あたり約 500 回)。

これが私がしたことです：

スレッド 1:

特定の銘柄記号のストリーミング クォートを提供する外部システムに接続されています。

スレッド 2 (コールバック スレッド):

外部システムからデータが配信されるまで待機します。データを取得すると、それを解析し、不変の DataEntry オブジェクトを作成してキャッシュし、スレッド 3 にシグナルを送信します。

スレッド 3 (コンシューマー スレッド): シグナルを受信したら、キャッシュから DataEntry を取得して使用します。(スレッド 2 が直接スレッド 3 にデータをプッシュしないようにするのはタスクの一部です)。

プロファイラーで実行した後、大量のDataEntryオブジェクトを作成していることに気付きました。したがって、エデンはすぐにいっぱいになります。

そのため、次の方法でデザインを少し調整することを考えています。

a)DataEntryクラスをミュータブルにする。

b)キャッシュに空のDataEntryオブジェクトを事前設定します。

c)DataEntry更新が到着したら、マップからオブジェクトを取得し、フィールドに入力します。

このようにして、DataEntryオブジェクトの数は定数になり、要素の数に等しくなります。

私の質問は次のとおりです。

a)DataEntryこの設計には、ミュータブルにすることによって導入された可能性のある同時実行の問題がありますか?

b)キャッシュを最適化するために他にできることはありますか?

ありがとう。

JavaConcurrentMapには がありremove(key, expectedValue)、これは次のいずれかを返します。

• 期待値はそこにあり、削除されました。
• 期待値がなかったので、削除されていません。

しかし、私が取得したいのは次のいずれかです。

1. 期待値はそこにあり、削除されました。
2. そのキーの下に値がありますが、予期されたものではないため、削除されていません。
3. そのキーの下には値がないため、削除されていません。

この情報を並行かつスレッドセーフな方法で取得するにはどうすればよいですか?

これは私が安全にしようとしているコードです

または一般化：

これは私の側ではばかげているかもしれませんが、のソースコードを見て、そのクラスのどこにもConcurrentHashMapメソッドの定義を見ることができませんでしたが、このメソッドが何度か呼び出されているのを見ることができます。lock()Eclipseで、でopen宣言を言うとlock()、クラスが表示ReentrantLock.lock()されるので、これがどのように機能するのか混乱していますか？ReentrantLocklock（）メソッド呼び出しのオブジェクト参照はどこにありますか？

ロジックをセンスチェックするための並行マップの特定の使用法について話し合いたいと思いました...

を使用した場合ConcurrentHashMap、ファミリアを実行できます

しかし、 と の間のマップからアイテムを削除すると、上記のメソッドがコレクションに存在しなくなったものを返すという競合状態が存在することに気付きました。これはうまくいくかもしれないし、うまくいかないかもしれませんが、私のユースケースではうまくいかないと仮定しましょう。putIfAbsentget

私が本当に望んでいるのは、すべてをアトミックにすることです。そう、

しかし、これが展開するにつれて

これは、行 [1] がnull最初に使用されたときに返されます (つまり、map.put以前の値が返され、最初に使用された場合は になりますnull)。

このインスタンスで null を返すことはできません

それは私に次のようなものを残します;

最後に、私の質問です。上記の例はセマンティクスでどのように異なりますか?. getExampleThreeアトミック性を保証しgetExampleTwoますが、null リターンを正しく回避しますか? 他に問題はありgetExampleThreeますか?

選択について少し議論したいと思っていました。ConcurrentHashMapメソッドを呼び出すクライアントとgetマップから削除するメソッドを使用して非同期を使用できることを認識していますが、それは ConcurrentHashMap の目的 (非ブロッキングの性質) を無効にしているようです。データを正確に保つための唯一の選択肢ですか?

それが、ConcurrentHashMap を選択する理由の一部だと思います。操作した時点で表示/最新/正確であることを確認しますが、古いデータが問題になる場合は、さらに先に影響がある可能性があります...

1. 値が揮発性のEntryクラスにあるのはなぜですか。ConcurrentHashMap

2. トラバーサル中に、クラスが null のConcurrentHashMap場合、セグメント全体をロックし、値を再度読み取ろうとするチェックインがあります。値だけを null にできるのはどのような場合ですか? 値だけでなく、エントリ全体が null になる必要があります。valueEntry

3. また、セグメント全体をロックすることで、値が null になった場合に正しいトラバーサルを保証する方法。

一意のキーを持ちますが、重複する値を含めることができるキャッシュのやや具体的な実装を記述する必要があります。たとえば、次のようになります。

このクラスは、ノンブロッキングの読み取り/キー ルックアップを提供する必要がありますが、典型的な作成/更新/削除ミューテーターも備えています。たとえば、値2を削除すると、

このキャッシュの読み取りは書き込みをはるかに上回るため、同時書き込みが互いに重なって実行されない限り、書き込みパフォーマンスは問題になりません。エントリの総数は 1000 未満になる可能性が高いため、値をときどき反復することは依然として手頃な価格です。

だから私はこのようなものを書きました（疑似コード）：

ConcurrentHashMap上記を書いた後、私はすべての努力を無意味にするノンブロッキング読み取りも提供することに気付きましたが、そのJavadocには眉をひそめる声明があります:

volatile ImmutableMapの使用法をwithに置き換えてfinal ConcurrentHashMapすべてのブロックを削除するとsynchronized、競合する同時ミューテーターが互いに無効になる可能性はありますか? たとえば、 の 2 つの同時呼び出しがremove競合状態につながり、最初の の結果が完全に無効になることを想像できremoveます。

私が見ることができる唯一の改善点は、使用してfinal ConcurrentHashMap そのままsynchronizedにしておくことで、少なくともデータの不要なコピーを回避できることです。

それは理にかなっていますか? それとも、ここで何かを見落としているのでしょうか? このソリューションの他の代替案を提案できる人はいますか?

ConcurrentHashMap.SegmentJava 1.6コレクションライブラリの設計について：

私見、与えられたSegmentものはそうではありませんReentrantLock、それではなぜこれextendsですか？それは構成でなければなりませんでした：

static final class Segment<K,V> implements Serializable { ReentrantLock lock = ... }