Java Map vs ConcurrentMap: A Multithreaded Use Case

Working with maps in Java is a fundamental part of many applications. However, when it comes to multithreaded environments, not all Map types behave the same. In this blog post, we’ll explore the difference between Map and ConcurrentMap using a practical example—a simple caching layer accessed by multiple threads. Along the way, we’ll see how to avoid race conditions and improve performance in concurrent scenarios.

1. Understanding the Problem

Let’s say we have a cache of user data where multiple threads need to read and write simultaneously. Using a standard HashMap in such an environment introduces problems since HashMap is not thread-safe. Let’s look at a naive implementation of a cache:

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

public class UserCache {
    private final Map<String, String> cache = new HashMap<>();

    public String getUser(String userId) {
        String user = cache.get(userId);
        if (user == null) {
            user = fetchFromDatabase(userId);
            cache.put(userId, user);
        }
        return user;
    }

    private String fetchFromDatabase(String userId) {
        // Simulate fetching data
        return "User_" + userId;
    }
}

This works fine in a single-threaded app. But once multiple threads access getUser(), you risk multiple threads fetching and writing the same key simultaneously, potentially leading to corrupted state or race conditions.

2. Demonstrating Race Conditions with HashMap

Let’s test the race condition by simulating concurrent access:

import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;

public class CacheTest {
    public static void main(String[] args) {
        UserCache cache = new UserCache();
        ExecutorService executor = Executors.newFixedThreadPool(5);

        for (int i = 0; i < 10; i++) {
            int userId = i % 3; // Same key reused to amplify race
            executor.submit(() -> {
                System.out.println(Thread.currentThread().getName() + ": " + cache.getUser("user" + userId));
            });
        }

        executor.shutdown();
    }
}

This code may result in inconsistent or incorrect data due to concurrent writes. We need a thread-safe solution.

3. Introducing ConcurrentMap and ConcurrentHashMap

Java provides ConcurrentMap interface and its popular implementation ConcurrentHashMap to handle concurrency correctly. Let’s modify our cache to use it:

import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.ConcurrentMap;

public class ThreadSafeUserCache {
    private final ConcurrentMap<String, String> cache = new ConcurrentHashMap<>();

    public String getUser(String userId) {
        return cache.computeIfAbsent(userId, this::fetchFromDatabase);
    }

    private String fetchFromDatabase(String userId) {
        return "User_" + userId;
    }
}

Now, instead of a manual null-check and put, we use computeIfAbsent() which atomically checks and updates the map. This guarantees that only one thread computes the value for a given key.

4. Why computeIfAbsent is Critical

computeIfAbsent() plays a vital role in avoiding redundant computation and race hazards. Here’s why it’s better than the manual pattern:

Atomic check-then-act behavior
No need for external locks or synchronization
Performance and scalability across many threads

Internally, ConcurrentHashMap segments the underlying storage to reduce contention and ensure high concurrency.

// Thread-safe, clean, efficient
public String getUser(String userId) {
    return cache.computeIfAbsent(userId, this::fetchFromDatabase);
}

5. Performance Tips and Trade-offs

While ConcurrentHashMap greatly improves safety and performance under concurrency, it’s also important to understand trade-offs:

ConcurrentRead-Write: Reads do not block—with lock-free read paths, it’s efficient under high loads.
Slightly Slower than HashMap: There’s still overhead due to internal synchronization during writes.
Granular locking: It avoids global locks by locking segments or buckets, improving parallelism.

If reads significantly outnumber writes, ConcurrentHashMap is usually the best drop-in replacement for HashMap in multithreaded scenarios.

Conclusion

When writing multithreaded Java applications, choosing the right data structure is critical. If you use Map naively in concurrent environments, you open the door for race conditions and corrupted state. By switching to ConcurrentMap and leveraging APIs like computeIfAbsent(), you write cleaner, safer, and more efficient code. Make the right decision early to avoid debugging headaches later.

Useful links: