Inconsistent responses when using ConcurrentHashMap in multi-threaded environment

Question

We have a single thread that regularly updates a Map. And then we have multiple other threads that read this map.

This is how the update thread executes

private Map<String, SecondMap> firstMap = new ConcurrentHashMap<>();

private void refresh() //This method is called every X seconds by one thread only
{
   List<SecondMap> newData = getLatestData();
   final List<String> newEntries = new ArrayList<>(); 
   for(SecondMap map : newData) {
       newEntries.add(map.getName());
       firstMap.put(map.getName(), map); 
   }
   final Set<String> cachedEntries = firstMap.keySet();
   for (final String cachedEntry : cachedEntries) {
       if (!newEntries.contains(cachedEntry)) {
           firstMap.remove(cachedEntry);
       }
   } 
}

public Map<String, SecondMap> getFirstMap()//Other threads call this
{
    return firstMap;
}

The SecondMap class looks like this

class SecondMap {
    Map<String, SomeClass> data; //Not necessarily a concurrent hashmap
    public Map<String, SomeClass> getData() {
        return data;
    }
}

Below is the simplified version of how reader threads access

public void getValue() {
    Map<String, SecondMap> firstMap = getFirstMap();
    SecondMap secondMap = firstMap.get("SomeKey");
    secondMap.getData().get("AnotherKey");// This returns null
}

We are seeing that in other threads, when they iterate over the received firstMap, sometimes they get null values for some keys in the SecondMap. We don't see any null values for keys in the firstMap, but we see null values for keys in second value. One thing that we can rule out is that the method getLatestData will never return such data. It reads from a database and returns these entries. There can never be null values in the database in the first place. Also we see that this happens occasionally. We are probably missing something here in handling multi-threaded situation in a proper way, but I am looking for an explanation why this can happen.

Answer 1

Assuming the Map<String, SomeClass> data; inside the SecondMap class is a HashMap, you can get a null value for a key in two scenarios. 1. If the key maps to a null value. Example "Something" -> null. 2. If the key is not in the map in the first place.

So without knowing much about where the data is coming from. If one of maps returned by getLatestData(); doesn't have the key "SomeKey" in the map at all, it will return null.

Also since there's not enough information about how that Map<String, SomeClass> data; is updated, and if it's mutable or immutable, you may have issues there. If that map is immutable and the SecondMap is immutable then it's more probably ok. But if you are modifying if from multiple threads you should make it a ConcurrentHashMap and if you update the reference to a new Map<String, SomeClass> data from different threads, inside the SecondMap you should also make that reference volatile.

class SecondMap {
    volatile Map<String, SomeClass> data; //Not necessarily a concurrent hashmap
    public Map<String, SomeClass> getData() {
        return data;
    }
}

If you'd like to understand in depth on when to use the volatile keyword and all the intricacies of data races, there's a section in this online course https://www.udemy.com/java-multithreading-concurrency-performance-optimization/?couponCode=CONCURRENCY about it. I have not seen any resource that explains and demonstrates it better. And unfortunately there are so many articles online that just explain it WRONG, which is sad.

I hope from the little information in the question I was able to point you to some directions that might help. Please share more information if nothing of that works, or if something does work, please let me know, I'm curious to know what it was :)