問題タブ [concurrenthashmap]

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

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

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

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

また

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

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

update(key, value)]メソッド [が を更新するマルチスレッド Java アプリケーションがありますConcurrentHashMap。キーごとに、マップに配置できるよりも多くの値が受信されるため、キーが更新されると、待機中のスレッドの最新の値のみを使用して、マップを再度更新する必要があります。それとも、待機中のスレッドが 1 つしかない場合に使用できるある種のロックがあるかもしれません - 最後にロックに到達したスレッド (既に待機しているスレッドを事実上破棄します)。マップ全体がロックされていないことが重要です。そのため、HashMapキー A で待機しているスレッドが存在する場合でも、キー B は更新されない限りキー B を更新できるようにする必要があるため、法線の周りで同期ブロックを使用していません。スレッドは、B に格納された値をすでに更新しています。

もっと簡潔に言えば、キーと値のペアが更新よりも速く受信されているマップを、最後に受信した値を次の更新として使用して更新するにはどうすればよいでしょうか? したがって、A が 1 に更新されるときに、5、3、6、8 の値が受信されます。これは、A の次の更新が 8 になることを意味します。

RMIを使用してクラステレポートを実行していますが、これらのスレッドセーフオブジェクトをシリアル化できるかどうかわかりません。以前に試したことはありますか？

UPDATE skaffmanは「はい」と言っていますが、シリアル化に失敗しました。

これは私がテレポートするクラスです。

これはクラスですWhatzNewEntry

skaffmanは正しいかもしれませんが、ここで何が間違っているのでしょうか？

コードが与えられ、ユーザー名とサービスの種類に基づいて一意の ID が作成されます。一意の ID は db にあり、db は表示できない DAO クラスを介して読み取られます。IDを作成するには多くの手順が必要です。

マルチスレッド環境では、一意の ID は保証されません。

唯一性を保証するために

解決策: userId+service をキーとして、id を値として ConcurrentHashmap に id をキャッシュします。メソッドが呼び出されるたびに、キーにロックが存在しない場合は値(id)をチェックし、id を作成します。これにより、競合が減少し、一意性が保証されます。

私のソリューションに問題があるかどうか、および/またはこれに対するより良い解決策があるかどうか疑問に思っていますか?

キャッシュをウォームアップしている間、多くのディスク アクティビティが発生します。org.apache.lucene ConcurrentLRUCache がそれを実行しているかどうかを判断できませんか? (問題のクラスは Java ConcurrentHashMap を使用します)。

ティア・ルネ

私は次のコードを持っています

出力はどちらもnullです。１秒じゃないですか？

重複の可能性：
ConcurrentSkipListMapはいつ使用する必要がありますか？

つまり、JavaライブラリにConcurrentSkipListMapがある場合、ConcurrentHashMapよりも優れている場合があります。ConcurrentSkipListMapはどこで本当に良いのだろうか？

54:15のEffectiveJavaに関する彼の講演で、Joshua Blochは、パフォーマンスと並行性を向上させるために、get以前に使用することを推奨しています。putIfAbsentこれは、なぜこの最適化がすでに組み込まれていないのかという疑問につながります

Webサーバーのキャッシュで使用するマルチスレッドのMapオブジェクトが必要であり、nullキーが必要です。

HashMapnullキーを使用できますが、できConcurrentHashMapません。HashMap同期バージョンのusingを作成しようとしましたが、キーもCollections.synchronizedMap(new HashMap())受け入れません。null

nullキーをラップする方法を実装せずに使用できる代替手段はありますか？

マップの現在の排除アルゴリズムは非常に怠惰です。期限切れのオブジェクトは、データ構造にアクセスした場合にのみ削除されるようです。

たとえば、アドレスからインデクサーへのマップは次のように定義されます。

非常に驚くべきパターンにつながりcontainsKey()ます。指定されたアドレスに対してfalseが返されますが、そのアドレスのインデクサーが削除された直後です。

クリーンアッププロセスをよりリアルタイムにするために推奨されるアプローチは何でしょうか？つまり、実際の有効期限に近いオブジェクトを削除します。

更新：リアルタイムとはどういう意味かをもっと明確にしたいと思います。上記の例では、EXPIRATIONが10秒であるため、最後にアクセスしてから10秒後に挿入されたオブジェクトが削除されることを確認したいと思います。それは今は起こっていません-マップは、立ち退きを開始するために何らかの方法で使用する必要があります。マップが完全に使用されていない場合、オブジェクトは何年もそこにとどまることができます。