複数のスレッドからjava.util.HashMapから値を取得しても安全ですか（変更なし）？

マップが作成され、一度初期化されると、再度変更されることはありません。ただし、複数のスレッドから（get（key）を介してのみ）アクセスされます。java.util.HashMapこのように使用しても安全ですか？

（現在、私は喜んで使っていjava.util.concurrent.ConcurrentHashMapて、パフォーマンスを向上させるために何を測定する必要がありませんが、シンプルであれば、単純に興味津々HashMap十分であろう。したがって、この質問がありません「？1は、私が使用すべき」またそれがパフォーマンスの問題です。むしろ、問題は「安全でしょうか？」）

への参照が安全に公開されている場合に限り、イディオムは安全です。安全な公開は、それ自体の内部に関連するものではなく、構築中のスレッドがマップへの参照を他のスレッドから見えるようにする方法を扱います。HashMapHashMap

基本的に、ここで可能な唯一の競合は、の構築と、HashMapそれが完全に構築される前にそれにアクセスする可能性のある読み取りスレッドの間の競合です。ほとんどの議論はマップオブジェクトの状態に何が起こるかについてですが、これを変更することはないため、これは重要ではありませんHashMap。

たとえば、次のようにマップを公開するとします。

class SomeClass {
   public static HashMap<Object, Object> MAP;

   public synchronized static setMap(HashMap<Object, Object> m) {
     MAP = m;
   }
}

...そして、ある時点setMap()でマップで呼び出され、他のスレッドがSomeClass.MAPマップへのアクセスに使用して、次のようにnullをチェックします。

HashMap<Object,Object> map = SomeClass.MAP;
if (map != null) {
  .. use the map
} else {
  .. some default behavior
}

おそらく安全であるように見えても、これは安全ではありません。問題は、別のスレッドのセットと後続の読み取りの間に前に発生する関係がないSomeObject.MAPため、読み取りスレッドは部分的に構築されたマップを自由に参照できることです。これはほとんど何でもでき、実際には、読み取りスレッドを無限ループに入れるようなことも行います。

安全マップを公開するには、確立する必要がたまたま、前との関係を参照の書き込みにHashMap（すなわち、出版物）およびその参照のその後の読者（すなわち、消費）。便利なことに、唯一のいくつかの覚えやすい方法があります達成それは^、[1] ：

1. 適切にロックされたフィールドを介して参照を交換する（JLS 17.4.5）
2. 静的初期化子を使用してストアを初期化します（JLS 12.4）
3. 揮発性フィールド（JLS 17.4.5）を介して、またはこのルールの結果として、AtomicXクラスを介して参照を交換します
4. 値を最終フィールドに初期化します（JLS 17.5）。

シナリオで最も興味深いのは、（2）、（3）、（4）です。特に、（3）は上記のコードに直接適用されます。宣言を次のように変換した場合MAP：

public static volatile HashMap<Object, Object> MAP;

次に、すべてがコーシャです。null 以外の値を参照するリーダーは、ストアと必然的に関係が発生MAPし、マップの初期化に関連付けられているすべてのストアを参照します。

（2）（静的初期化子を使用）と（4）（finalを使用）はどちらもMAP実行時に動的に設定できないことを意味するため、他のメソッドはメソッドのセマンティクスを変更します。それを行う必要がない場合は、MAPとして宣言するだけで、static final HashMap<>安全な公開が保証されます。

実際には、「変更されていないオブジェクト」に安全にアクセスするためのルールは単純です。

（宣言されたすべてのフィールドのように）本質的に不変ではないオブジェクトを公開する場合final：

• あなたは既に宣言した瞬間に割り当てられることになるオブジェクトを作成することができ^、Aを：ちょうど使用final（含むフィールドをstatic final静的メンバのため）。
• 参照がすでに表示されている後、オブジェクトを後で割り当てたい場合は、揮発性フィールド^bを使用します。

それでおしまい！

実際には、非常に効率的です。static finalたとえば、フィールドを使用すると、JVMはプログラムの存続期間中は値が変更されていないと想定し、大幅に最適化できます。finalメンバーフィールドを使用すると、ほとんどのアーキテクチャで、通常のフィールド読み取りと同等の方法でフィールドを読み取ることができ、それ以上の最適化が^{妨げられる}ことはありません^c。

最後に、の使用にvolatileはいくつかの影響があります。多くのアーキテクチャ（x86など、特に読み取りで読み取りを渡すことができないアーキテクチャ）ではハードウェアバリアは必要ありませんが、コンパイル時に一部の最適化と並べ替えが行われない場合がありますが、これは効果は一般に小さいです。代わりに、実際に要求した以上のものが得られます-安全に公開できるだけでなく、同じ参照に必要なだけHashMap多くの未変更HashMapのを保存でき、すべての読者が安全に公開された地図を見ることができます。 。

詳細については、ShipilevまたはMansonとGoetzによるこのFAQを参照してください。

[1] Shipilevから直接引用。

それは複雑に聞こえますが^、つまり、宣言時に、またはコンストラクター（メンバーフィールド）または静的初期化子（静的フィールド）のいずれかで、構築時に参照を割り当てることができるということです。

^bオプションで、synchronizedメソッドを使用して取得/設定、AtomicReferenceまたは何かを行うことができますが、ここでは、実行できる最低限の作業について説明します。

cメモリモデルが非常に弱い一部のアーキテクチャ（私はあなたを見ている、Alpha）は、final読み取りの前になんらかの種類の読み取りバリアを必要とする場合がありますが、今日これらは非常にまれです。

Java Memory Modelの神であるJeremy Mansonは、このトピックについて3つのパートからなるブログを持っています-本質的に「不変のHashMapにアクセスするのは安全ですか」という質問をしているからです-その答えはイエスです。しかし、その質問に対する述語である「Is my HashMap is immutable」に答える必要があります。答えはあなたを驚かせるかもしれません-Javaには不変性を決定するための比較的複雑なルールのセットがあります。

このトピックの詳細については、Jeremyのブログ投稿をご覧ください。

Javaの不変性に関するパート1：http ://jeremymanson.blogspot.com/2008/04/immutability-in-java.html

Javaの不変性に関するパート2：http ://jeremymanson.blogspot.com/2008/07/immutability-in-java-part-2.html

Javaの不変性に関するパート3：http ://jeremymanson.blogspot.com/2008/07/immutability-in-java-part-3.html

読み取りは同期の観点からは安全ですが、メモリの観点からは安全ではありません。これは、ここStackoverflowを含め、Java開発者の間で広く誤解されているものです。（証明のためにこの回答の評価を確認してください。）

他のスレッドを実行している場合、現在のスレッドからメモリへの書き込みがないと、HashMapの更新されたコピーが表示されないことがあります。メモリへの書き込みは、synchronizedまたはvolatileキーワードを使用するか、いくつかのJava同時実行構造を使用して行われます。

詳細については、新しいJavaメモリモデルに関するBrian Goetzの記事を参照してください。

もう少し調べた後、私はこれをjavaドキュメントで見つけました（強調は私のものです）：

この実装は同期されていないことに注意してください。 複数のスレッドが同時にハッシュマップにアクセスし、少なくとも1つのスレッドがマップを構造的に変更する場合、外部で同期する必要があります。（構造変更は、1つ以上のマッピングを追加または削除する操作です。インスタンスに既に含まれているキーに関連付けられている値を変更するだけでは、構造変更は行われません。）

これは、そこにあるステートメントの逆が真実であると仮定すると、安全であることを暗示しているようです。

ある状況下では、非同期のHashMapからのget（）が無限ループを引き起こす可能性があることに注意してください。これは、同時にput（）がマップの再ハッシュを引き起こす場合に発生する可能性があります。

http://lightbody.net/blog/2005/07/hashmapget_can_cause_an_infini.html

ただし、重要なひねりがあります。マップにアクセスしても安全ですが、一般に、すべてのスレッドがHashMapのまったく同じ状態（つまり値）を表示することは保証されていません。これはマルチプロセッサシステムで発生する可能性があり、1つのスレッド（たとえば、データを設定したスレッド）によって行われたHashMapへの変更がそのCPUのキャッシュに存在し、メモリフェンス操作が実行されるまで、他のCPUで実行されているスレッドからは見えません。キャッシュの一貫性を確保するために実行されます。Java言語仕様はこれについて明示的です。解決策は、メモリフェンス操作を発行するロック（同期（...））を取得することです。したがって、HashMapにデータを入力した後、各スレッドがANYロックを取得したことが確実な場合は、その時点から、HashMapが再度変更されるまで、任意のスレッドからHashMapにアクセスできます。

http://www.ibm.com/developerworks/java/library/j-jtp03304/によると＃初期化の安全性はHashMapを最終フィールドにすることができ、コンストラクターが完了すると安全に公開されます。

...新しいメモリモデルでは、コンストラクタでの最終フィールドの書き込みと、別のスレッドでのそのオブジェクトへの共有参照の初期ロードとの間に発生前の関係に似たものがあります。...

したがって、説明したシナリオでは、大量のデータをマップに入れる必要があり、データの入力が完了したら、不変として扱います。「安全」（実際に不変として扱われることを強制していることを意味する）の1つのアプローチは、不変Collections.unmodifiableMap(originalMap)にする準備ができたときに参照を置き換えることです。

同時に使用した場合にマップがどれほどひどく失敗するかの例と、私が述べた推奨の回避策については、このバグパレードエントリを確認してください：bug_id = 6423457

この質問は、Brian Goetzの「Java Concurrency in Practice」の本（リスト16.8、ページ350）で扱われています。

@ThreadSafe
public class SafeStates {
    private final Map<String, String> states;

    public SafeStates() {
        states = new HashMap<String, String>();
        states.put("alaska", "AK");
        states.put("alabama", "AL");
        ...
        states.put("wyoming", "WY");
    }

    public String getAbbreviation(String s) {
        return states.get(s);
    }
}

以来statesとして宣言されfinal、その初期化が、所有者のクラスのコンストラクタ内で達成された後に、このマップを読み込み、どのスレッドが他のスレッドを提供しないコンストラクタが終了すると、マップの内容を変更しようとする時のようにそれを見ることが保証されます。

シングルスレッドコードでも、ConcurrentHashMapをHashMapに置き換えるのは安全ではない場合があることに注意してください。ConcurrentHashMapは、キーまたは値としてnullを禁止します。HashMapはそれらを禁止しません（質問しないでください）。

そのため、セットアップ中に既存のコードがコレクションにnullを追加する可能性がある場合（おそらく何らかの障害の場合）で、説明されているようにコレクションを置き換えると、機能の動作が変わります。

とはいえ、HashMapからの同時読み取りが安全である場合を除いて、何もしません。

[編集：「同時読み取り」とは、同時変更もないことを意味します。

他の回答はこれを確実にする方法を説明しています。1つの方法は、マップを不変にすることですが、必須ではありません。たとえば、JSR133メモリモデルでは、スレッドの開始を同期アクションとして明示的に定義しています。つまり、スレッドBを開始する前にスレッドAで行われた変更は、スレッドBで可視です。

私の意図は、Javaメモリモデルに関するより詳細な回答と矛盾しないことです。この回答は、同時実行の問題は別として、ConcurrentHashMapとHashMapの間には少なくとも1つのAPIの違いがあることを指摘することを目的としています。

http://www.docjar.com/html/api/java/util/HashMap.java.html

これがHashMapのソースです。ご存知のように、ロックやミューテックスのコードはまったくありません。

つまり、マルチスレッドの状況でHashMapから読み取ることは問題ありませんが、複数の書き込みがあった場合は必ずConcurrentHashMapを使用します。

興味深いのは、.NET HashTableとDictionary <K、V>の両方に同期コードが組み込まれていることです。

初期化とすべての書き込みが同期されている場合は、保存されます。

クラスローダーが同期を処理するため、次のコードは保存されます。

public static final HashMap<String, String> map = new HashMap<>();
static {
  map.put("A","A");

}

揮発性の書き込みが同期を処理するため、次のコードは保存されます。

class Foo {
  volatile HashMap<String, String> map;
  public void init() {
    final HashMap<String, String> tmp = new HashMap<>();
    tmp.put("A","A");
    // writing to volatile has to be after the modification of the map
    this.map = tmp;
  }
}

finalも揮発性であるため、これはメンバー変数がfinalの場合にも機能します。メソッドがコンストラクタの場合。