从多个线程从java.util.HashMap获取值是否安全（无修改）？

在某些情况下，将构造一个映射，并且一旦对其进行初始化，就永远不会再对其进行修改。但是，它将从多个线程访问（仅通过get（key））。java.util.HashMap以这种方式使用安全吗？

（当前，我很乐意使用java.util.concurrent.ConcurrentHashMap，并没有提高性能的需要，但是只是HashMap想知道一个简单的方法是否足够。因此，这个问题不是 “我应该使用哪个？”，也不是一个性能问题。相反，问题是“安全吗？”）

当且仅当对的引用HashMap被安全发布时，您的惯用法才是安全的。而不是有关的内部事情HashMap本身，安全出版物与构建线程如何使得参考地图到其他线程是可见的交易。

基本上，这里唯一可能的竞争是在的构造与在HashMap完全构造之前可能会访问它的任何读取线程之间。大部分讨论是关于map对象状态发生的事情，但这是无关紧要的，因为您从未修改过它-因此，唯一有趣的部分是如何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. 通过volatile字段（JLS 17.4.5）或由于此规则而通过AtomicX类交换引用
4. 将值初始化为最终字段（JLS 17.5）。

对于您的情况最有趣的是（2），（3）和（4）。特别是（3）直接适用于我上面的代码：如果将以下声明转换MAP为：

public static volatile HashMap<Object, Object> MAP;

那么一切都是洁净的：看到非null值的读者必然与该存储与to 发生事前关系，MAP因此看到与该地图初始化关联的所有存储。

其他方法会更改方法的语义，因为（2）（使用静态初始化器）和（4）（使用final）都暗示您不能MAP在运行时动态设置。如果您不需要这样做，则只需声明MAP为a static final HashMap<>即可确保发布安全。

实际上，这些规则对于安全访问“未经修改的对象”很简单：

如果要发布的对象不是固有不变的（如在声明的所有字段中一样final），并且：

• 您已经可以创建将在声明^a时分配的对象：仅使用一个final字段（包括static final静态成员）。
• 您希望稍后在引用可见之后分配对象：使用volatile字段^b。

而已！

实际上，它非常有效。static final例如，使用字段可以使JVM假定该值在程序生命周期内保持不变，并且可以对其进行大量优化。final成员字段的使用允许大多数体系结构以与普通字段读取等效的方式读取该字段，并且不会阻止进一步的优化^c。

最后，使用volatile确实会产生一些影响：在许多体系结构（例如x86，特别是那些不允许读取传递读取的结构）上都不需要硬件障碍，但是在编译时可能不会发生一些优化和重新排序-但这效果一般很小。作为交换，您实际上得到的不仅仅是所需的内容-您不仅可以安全地发布一个HashMap，还可以存储更多未修改的HashMaps，以使用相同的参考文献，并确保所有读者都能看到安全发布的地图。

有关更多详细信息，请参阅Shipilev或Manson和Goetz的本常见问题解答。

[1]直接引用shipilev。

^一个这听起来很复杂，但我的意思是，你可以在指定施工时间参考-无论是在申报点或在构造函数（成员字段）或静态初始化（静态字段）。

^b（可选）您可以使用一种synchronized方法来获取/设置或一个AtomicReference或某物，但是我们正在谈论的是您可以做的最少工作。

c某些内存模型非常弱的体系结构（我正在看着您，Alpha）在读取之前可能需要某种类型的读取屏障final-但是今天这些很少见。

涉及Java内存模型的神杰里米·曼森（Jeremy Manson）在这个主题上有一个由三部分组成的博客-因为从本质上讲，您是在问“访问不变的HashMap是否安全”这个问题，答案是肯定的。但是您必须回答该问题的谓词-“我的HashMap是不可变的”。答案可能会让您感到惊讶-Java具有一组相对复杂的确定不变性的规则。

有关该主题的更多信息，请阅读Jeremy的博客文章：

第1部分有关Java的不变性：http : //jeremymanson.blogspot.com/2008/04/immutability-in-java.html

第2部分有关Java的不可变性：http : //jeremymanson.blogspot.com/2008/07/immutability-in-java-part-2.html

第3部分有关Java的不变性：http : //jeremymanson.blogspot.com/2008/07/immutability-in-java-part-3.html

从同步的角度来看，读取是安全的，但从内存的角度来看，则不是。在Java开发人员中，包括在Stackoverflow上，这是一个普遍被误解的东西。（观察该答案的等级以作证明。）

如果您正在运行其他线程，如果当前线程没有写出内存，则他们可能看不到HashMap的更新副本。内存写操作是通过使用synced或volatile关键字，或通过使用某些Java并发结构进行的。

有关详细信息，请参见Brian Goetz在新的Java内存模型上的文章。

经过一番寻找之后，我在java doc中找到了这个（重点是我的）：

请注意，此实现未同步。 如果多个线程同时访问哈希映射，并且至少一个线程在结构上修改了该映射，则必须在外部进行同步。（结构修改是添加或删除一个或多个映射的任何操作；仅更改与实例已经包含的键相关联的值不是结构修改。）

这似乎暗示着它是安全的，假设存在相反的说法。

需要注意的是，在某些情况下，来自未同步的HashMap的get（）可能导致无限循环。如果并发的put（）引起了Map的重新哈希，则会发生这种情况。

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

但是有一个重要的转折。访问该映射是安全的，但是通常不能保证所有线程都将看到与HashMap完全相同的状态（因此也就是值）。这可能发生在多处理器系统上，在该系统上，由一个线程（例如，填充它的线程）对HashMap进行的修改可以位于该CPU的缓存中，而在其他CPU上运行的线程将看不到该哈希，直到发生内存隔离操作为止。执行以确保缓存一致性。Java语言规范对此非常明确：解决方案是获取一个发出内存隔离操作的锁（同步（...））。因此，如果您确定在填充HashMap之后，每个线程都获得了ANY锁，那么从那时开始就可以从任何线程访问HashMap，直到再次修改HashMap为止。

根据http://www.ibm.com/developerworks/java/library/j-jtp03304/＃初始化安全性，您可以将HashMap设置为最终字段，并在构造函数完成后将其安全发布。

在新的内存模型下，类似于在构造函数中写入final字段与在另一个线程中对该对象的共享引用的初始加载之间的事前关系。...

因此，您描述的场景是需要将大量数据放入Map中，然后在完成填充后将其视为不可变的。一种“安全”的方法（意味着您要强制将其确实视为不可变的）是Collections.unmodifiableMap(originalMap)在准备好使其成为不可变对象时，将其替换为。

有关并发使用地图时如何严重失败的示例，以及我提到的建议解决方法，请查看此Bug游行条目：bug_id = 6423457

Brian Goetz的“ Java并发实践”一书（清单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声明为as final且其初始化是在所有者的类构造函数中完成的，因此，保证以后构造者完成该操作时，读取此映射的任何线程都可以看到它，前提是没有其他线程尝试修改该映射的内容。

请注意，即使在单线程代码中，用HashMap替换ConcurrentHashMap也不是安全的。ConcurrentHashMap禁止将null作为键或值。HashMap不会禁止它们（不要问）。

因此，在不太可能的情况下，您的现有代码可能会在设置过程中向集合添加null（可能是在某种情况下发生故障），按所述方式替换集合将改变功能行为。

就是说，只要您不执行其他任何操作，从HashMap进行的并发读取都是安全的。

[编辑：通过“并发读取”，我的意思是没有并发修改。

其他答案说明了如何确保这一点。一种方法是使地图不可变，但这不是必需的。例如，JSR133内存模型将启动线程明确定义为同步操作，这意味着在启动线程B之前在线程A中所做的更改在线程B中可见。

我的目的不是与有关Java内存模型的更详细的答案相矛盾。该答案旨在指出，除了并发问题之外，ConcurrentHashMap和HashMap之间至少还有一个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");

}

保存以下代码，因为编写volatile将负责同步。

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也是易变的。并且如果该方法是构造函数。