Concurrent Reads from Unmodfiable Map

Question

If I statically initialize a map and set the reference to a Collections.unmodifiableMap(Map m). Do I need to synchronize reads?

private static final Map<String,String> staticMap; 
static{
   Map<String,String> tempMap = new HashMap<String,String>();

   tempMap.put("key 1","value 1");
   tempMap.put("key 2","value 2");
   tempMap.put("key 3","value 3");

   staticMap = Collections.unmodifiableMap(tempMap);
}

Answer 1

No, the map you're creating there is effectively immutable (since nothing has a reference to the mutable backing map) and safe for concurrent access. If you want a clearer guarantee of that along with making it easier to create the map, Guava's ImmutableMap type is designed for just this sort of use (among other things):

private static final ImmutableMap<String, String> staticMap = ImmutableMap.of(
    "key1", "value1",
    "key2", "value2",
    "key3", "value3");

Answer 2

Nope, reads don't modify the map so i wouldn't worry about it at all. it's only the write+write or write+read that requires synchronization around it.

Answer 3

It depends on the Map implementation. HashMap, TreeMap and the like all have reads that are modification free and so are fine, but implementations that track usage may perform updates internally.

An example is a LinkedHashMap with access ordering:

new LinkedHashMap(int initialCapacity, float loadFactor, boolean accessOrder)

This will actually reorder the elements on each read such that iteration over the keys, values or entries will be in last accessed first order. Another map that may modify is WeakHashMap.

An excellent alternative \would be the ImmutableMap found in Google's guava library.

Answer 4

I disagree with the above answers. Contained in the map implementations are non-volatile fields (like HashMap.entrySet. In the unmodifiable case: UnmodifiableMap.keySet, UnmodifiableMap.entrySet and UnmodifiableMap.values). These fields are lazily initialized, so NULL after the static initializer. If one thread then calls entrySet(), this initializes the entrySet field. Access to this field is unsafe from all other threads. The field may be seen from another thread in an inconsistent state or not at all.

Answer 5

The short answer is: no. You don't need to lock if there is no read-write contention. You only lock if whatever you're sharing might change, if it doesn't change then it's basically immutable and immutables are considered thread safe.

Answer 6

I think others have covered the answer already (yes in the case of the HashMap implementation). If you don't necessarily always need the map to be created, you can make it lazy using the Initialize-On-Demand Holder idiom:

import java.util.Collections;
import java.util.HashMap;
import java.util.Map;

public class YourClass {

  // created only if needed, thread-safety still preserved
  private static final class MapHolder {
    private static final Map<String,String> staticMap; 
    static{
      System.out.println("Constructing staticMap");
      Map<String,String> tempMap = new HashMap<String,String>();

      tempMap.put("key 1","value 1");
      tempMap.put("key 2","value 2");
      tempMap.put("key 3","value 3");

      staticMap = Collections.unmodifiableMap(tempMap);
    }
  }

  // use this to actually access the instance 
  public static Map<String,String> mapGetter() {
    return MapHolder.staticMap;
  }

  public static void main(String[] arg) {
    System.out.println("Started, note that staticMap not yet created until...");
    Map<String,String> m = mapGetter();
    System.out.println("we get it: " + m);
  }
}

which will print:

Started, note that staticMap not yet created until...
Constructing staticMap
we get it: {key 1=value 1, key 2=value 2, key 3=value 3}