Java ConcurrentHashMap Best Practices

The ConcurrentHashMap is very similar to the HashMap class, except that ConcurrentHashMap offers internally maintained concurrency. It means you do not need to have synchronized blocks when accessing ConcurrentHashMap in multithreaded application.

//Initialize ConcurrentHashMap instance
ConcurrentHashMap<String, Integer> m = new ConcurrentHashMap<String, Integer>();

//Print all values stored in ConcurrentHashMap instance
for each (Entry<String, Integer> e : m.entrySet())

Above code is reasonably valid in multi-threaded environment in your application. The reason, I am saying “reasonably valid” is that, above code yet provides thread safety, still it can decrease the performance of application. And ConcurrentHashMap was introduced to improve the performance while ensuring thread safety, right??

So, what is that we are missing here??

To understand that we need to understand the internal working of ConcurrentHashMap class. And the best way to start is look at the constructor arguments. Fully parametrized constructor of ConcurrentHashMap takes 3 parameters, initialCapacity, loadFactor and concurrencyLevel.

1) initialCapacity
2) loadFactor
3) concurrencyLevel

First two are fairly simple as their name implies but last one is tricky part. This denotes the number of shards. It is used to divide the ConcurrentHashMap internally into this number of partitions and equal number of threads are created to maintain thread safety maintained at shard level.



The default value of “concurrencyLevel” is 16. It means 16 shards whenever we create an instance of ConcurrentHashMap using default constructor, before even adding first key-value pair. It also means the creation of instances for various inner classes like ConcurrentHashMap$Segment, ConcurrentHashMap$HashEntry[] and ReentrantLock$NonfairSync.

In most cases in normal application, a single shard is able to handle multiple threads with reasonable count of key-value pairs. And performance will be also optimal. Having multiple shards just makes the things complex internally and introduces a lot of un-necessary objects for garbage collection, and all this for no performance improvement.

The extra objects created per concurrent hashmap using default constructor are normally in ratio of 1 to 50 i.e. for 100 such instance of ConcurrentHashMap, there will be 5000 extra objects created.

Based on above, I will suggest to use the constructor parameters wisely to reduce the number of unnecessary objects and improving the performance.

A good approach can be having initialization like this:

ConcurrentHashMap<String, Integer> instance = new ConcurrentHashMap<String, Integer>(16, 0.9f, 1);

An initial capacity of 16 ensures a reasonably good number of elements before resizing happens. Load factor of 0.9 ensures a dense packaging inside ConcurrentHashMap which will optimize memory use. And concurrencyLevel set to 1 will ensure that only one shard is created and maintained.

Please note that if you are working on very high concurrent application with very high frequency of updates in ConcurrentHashMap, you should consider increasing the concurrencyLevel more than 1, but again it should be a well calculated number to get the best results.

Happy Learning !!

Was this post helpful?

Join 7000+ Awesome Developers

Get the latest updates from industry, awesome resources, blog updates and much more.

* We do not spam !!

35 thoughts on “Java ConcurrentHashMap Best Practices”

  1. My question is suppose a iteration is going on the list as its read there is no lock. In between a write is done. Now control comes back to iteration so i think now concurrentModification will be thrown. Could you please explain how above scenario is handled. Is there any way to replicate such scenario?

    • Modification is being done on the copy of original map so the user will be able to see the original map that was present before current iteration. As soon as iteration completes the new map will be available for read purpose.

  2. Hi lokesh,
    Nice articles. Thanks for sharing n making our work easier. Could you please explain what is meaning of volatile read and what is its internal working?

  3. Irrelevant?
    When looking at the constructors of ConcurrentHashMap, the concurrencyLevel parameter does not do much, only to adjust the initialcapacity parameter if it is smaller than concurlevel.

  4. Hi,

    Thanks for this amazing blog, concepts are very well explained. When you get a chance could you please answer my question –

    1. Say for example I have multiple threads (count = 8) that would add or update my Hashmap. What would be concurrencyLevel you would recommend?

    ConcurrentHashMap<String, Integer> instance = new ConcurrentHashMap<String, Integer>(16, 0.9f, 1); 
    Collections.synchronizedMap( HashMap )

    Won’t they have almost same performance since ConcurrentHashMap has only 1 Segment and all Threads will have to wait while updating HashEntry?

    • Load factor is the ratio between the number of “buckets” in the map and the number of expected elements. A value of 0.75 will suggest that if the buckets are more than 75% full, the Map should be resized. Similarly, 0.90 will suggest that if the buckets are more than 90% full, the Map should be resized.

      • I think you are wrong regarding your load factor explanation.
        If hashCode always returns 1, which means all entries will go to 1 bucket only. Do you mean the map will never resize?

          • So the correct definition of load factor should be
            the ratio between
            1) the number of “Entries”
            2) initialCapacity

            not as you said
            1) the number of “buckets” in the map
            2) the number of expected elements.

            Please be really cautious with basic knowledge of HashMap.

  5. Nice article. But I would suggest one small correction

    “First two are fairly simple as their name implies but last one is tricky part. This denotes the number of shards. ”

    The parameter concurrencyLevel isn’t always equal to the number of segments created. It will only be true if it is a power of 2.

  6. What is the bucket in HashMap ?

    is it the Entry Array ? I am looking for collision condition solution when we have same hash code for 2 objcets.

    In case of collision , objects are stored in same bucket and retrieved using equals function to get exact object.

  7. Hi,

    I have doubt over the concurrencyLevel parameter.

    Suppose I have initialized my ConcurrentHashMap with concurrencyLevel of 2.

    I have 2 threads trying to update the first shard elements @ same time.

    How this situation will be handled?

    Do we need to apply extra care and synchronization for such cases ? Or it is handled internally by ConcurrentHashMap itself ?

  8. Hi,
    No doubt it’s a wonderfull post. But I have two questions.

    1) Is Shards and Segments are same?

    2) What is the use of Segment

      • Is that means that each segments contains same key-value pair? Secondly if I create 20 shards then it means that 20 threads can do concurrent transaction on my map. Correct me if I am wrong.

        Is that possible for you to explain that if I enter a key value pair in the concurrent hash map how it’s getting updated in multiple segments.

  9. Nice article..Thanks for that..Suppose I am having a concurrent hashmap with Concurrency level as 2 and i need to read/write values in it by using multiple threads .In the scenario, if one thread has locked up one segment and checking the value and if another thread comes in will it bypass that segment or wait ?
    In case of bypass, how come it will check the locked up segment..(because my scenario is to check whole map for a particular count).


Leave a Comment


A blog about Java and related technologies, the best practices, algorithms, and interview questions.