2

コントローラに注入されるシングルトンスプリングサービス内でConcurentHashMapのスレッドセーフな使用法を実装しようとしています。

@Service
public MyService{

  final ConcurrentMap<String, AtomicInteger> myMap = new ConcurrentHashMap<String,   AtomicInteger>(10) {
        {/* initialize the ten key/values */
        }
    };

 public int add(String key) {
   return myMap.get(key).incrementAndGet();
 }

    // accessed via ajax loop (and controller), if value changes update display
  public int getCount(String key) {
    return myMap.get(key).get();
  }
}

ハッシュマップへのアクセスをスレッドセーフにするためのより良い方法はありますか？クラスター環境で機能するようにこれをどのように適応させることができますか？それは私の他の質問へのフォローです。

4

1 に答える 1

0

私は質問espの答えを持っていることを目指していません。私はクラスター化された状況に関する専門知識を持っていないからです。しかし、私が注目する価値があると思うことを指摘したいと思います。

コメントの1つにある@JBNizetは、コードがスレッドセーフで正しい​​と述べています。追加したいのですが、 Java APIリファレンスに基づいて一貫性がありません：

通常、取得操作（getを含む）はブロックされないため、更新操作（putおよびremoveを含む）と重複する場合があります。

これは、更新の実行中にクライアントがこの情報を取得する可能性があることを意味します。そして、コードで「ループ」について言及しているので、それは理にかなっています。したがって、これがあなたのケースで重要でない場合は、すべてがうまくいくはずです。

しかし、これをより厳密にする必要がある場合は、インスタンスを使用するのReentrantReadWriteLockが良い選択かもしれないと考えていました。ロックにより、利用可能な情報の一貫したスナップショットが得られるまで、コードはすべての読み取り要求をブロックできます。おそらく、メソッドのロックを使用して、コードで使用されているマップの一貫したスナップショットを待機しているすべてのロックをメソッドが解放するgetCountまで、厳密にブロックします。add

また、これをクラスター化されたソリューションに移行する場合にも、同じ懸念が当てはまると思います。異なるクラスターノード間で一貫性が必要な場合は、それを処理する必要があります。

于 2012-06-20T20:16:44.057 に答える