ConcurrentHashMap — Why get()+put() Loses Updates

In any production Java service that handles real traffic, you'll have multiple threads reading and writing shared data at the same time. HashMap silently corrupts data under concurrent writes. Hashtable and Collections.synchronizedMap fix the corruption by locking the entire map on every single operation — which turns your multi-threaded service into a single-threaded bottleneck the moment load spikes. Neither option is acceptable when you're building something that has to stay fast under pressure.

ConcurrentHashMap solves this by being surgically precise about where and when it locks. Instead of one global lock, it uses a strategy that lets concurrent reads proceed with zero locking and partitions writes so different threads rarely block each other. In Java 8 the implementation was completely rewritten to ditch the old 'segment' model in favour of CAS (Compare-And-Swap) operations and per-bucket synchronization, pushing throughput to near-HashMap levels while keeping full thread safety.

By the end of this article you'll understand exactly how ConcurrentHashMap achieves that balance — the internal data structure, the locking strategy that changed in Java 8, the atomic operations that let you avoid race conditions in your own code, and the real production mistakes that will bite you if you treat it like a drop-in replacement for HashMap without understanding what it actually guarantees.

What is ConcurrentHashMap in Java?

ConcurrentHashMap sits between HashMap and Hashtable. It gives you the same API as HashMap but guarantees thread safety without the global lock penalty. Internally it splits the bucket array into independent regions — originally segments, now individual buckets with CAS for first insert and synchronized only on the bucket head for updates. This design means reads never block, and writes only contend with other writes hitting the exact same bucket.

You use it exactly like HashMap — put, get, remove, containsKey — but you can call these from any thread without external synchronization. The real power comes from the atomic composite operations: putIfAbsent, computeIfAbsent, compute, and merge. These let you perform check-then-act sequences atomically with zero chance of a race condition.

package io.thecodeforge.collections;

import java.util.concurrent.ConcurrentHashMap;

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

    // Atomic compute: only inserts if absent, no external lock needed
    public int incrementOrInit(String key) {
        return cache.compute(key, (k, v) -> (v == null) ? 1 : v + 1);
    }

    // Get with default: putIfAbsent is atomic
    public int getOrCreate(String key, int defaultValue) {
        Integer existing = cache.putIfAbsent(key, defaultValue);
        return existing != null ? existing : defaultValue;
    }
}

Java 7 vs Java 8 Internals: From Segments to CAS + Tree Bins

Before Java 8, ConcurrentHashMap used a Segment array — each segment was itself a smaller HashMap with its own lock. The default concurrency level of 16 meant up to 16 threads could write at once, one per segment. Reads needed locking only on volatile reads of segment table references. It worked, but the fixed segment count limited scalability when the map grew large.

Java 8 threw out the segment model entirely. The new design uses a single Node array (table) where each bucket is either a Node, a TreeNode (for tree bins), or a ReservationNode (during compute). Updates use CAS on the table reference for the first node, then synchronize on the bucket head for structural modifications. This gives vastly better concurrency because the lock granularity is per-bucket — hundreds of buckets mean hundreds of concurrent writers. Tree bins kick in when a bucket exceeds TREEIFY_THRESHOLD (8) and the map size is over 64, converting the linked list into a balanced tree for O(log n) lookups under high collisions.

package io.thecodeforge.collections;

import java.util.concurrent.ConcurrentHashMap;

public class InternalMetrics {
    // Simulate hash collision to trigger treeification
    public static void main(String[] args) {
        ConcurrentHashMap<Integer, String> map = new ConcurrentHashMap<>();
        // Force collisions by using Integer objects with same hashCode
        for (int i = 0; i < 12; i++) {
            map.put(i, "value" + i);
        }
        // Internally, if all 12 keys land in same bucket and size>64, tree forms
        // But with default capacity, treeification normally requires >8 collisions + size>64
        System.out.println("Map size: " + map.size());
    }
}

Atomic Operations and the Check-Then-Act Trap

The biggest benefit of ConcurrentHashMap over a synchronized wrapper is the set of atomic compound operations. Methods like putIfAbsent, computeIfAbsent, compute, and merge run their function inside the bucket lock, making the entire read-write sequence atomic. If you try to implement the same logic with get followed by put, you'll get a race condition that loses updates.

Consider a request counter: map.compute(key, (k, v) -> v == null ? 1 : v + 1) is safe. The equivalent Integer v = map.get(key); map.put(key, v == null ? 1 : v + 1); can lose increments because another thread might update between the get and put. This is the classic check-then-act race that ConcurrentHashMap's atomic methods eliminate.

package io.thecodeforge.collections;

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

public class AtomicCounter {
    private final ConcurrentHashMap<String, Integer> counts = new ConcurrentHashMap<>();

    public void increment(String key) {
        // Atomic — safe under high concurrency
        counts.compute(key, (k, v) -> (v == null) ? 1 : v + 1);
    }

    public int getCount(String key) {
        return counts.getOrDefault(key, 0);
    }

    public static void main(String[] args) throws InterruptedException {
        AtomicCounter c = new AtomicCounter();
        ExecutorService exec = Executors.newFixedThreadPool(10);
        for (int i = 0; i < 100000; i++) {
            exec.submit(() -> c.increment("visits"));
        }
        exec.shutdown();
        exec.awaitTermination(5, TimeUnit.SECONDS);
        System.out.println("Final count: " + c.getCount("visits")); // Exactly 100000
    }
}

Performance Characteristics and Tuning Trade-offs

ConcurrentHashMap performs best when reads dominate writes and writes are spread across different keys. Under pure read workloads, throughput matches HashMap within 5–10% because reads are essentially volatile reads with no locking. As write contention increases, performance degrades gracefully: with 100% writes, you still get 3–5x better than synchronizedMap due to per-bucket locking.

The initial capacity and concurrencyLevel parameters matter less in Java 8. concurrencyLevel is only a hint for sizing, not the number of allowed segments. Setting initial capacity too high wastes memory; too low triggers resize overhead. A good rule: ConcurrentHashMap<>(expectedSize * 1.1 / 0.75f) to allocate at ~75% load to avoid resizing during warm-up.

Resizing is more expensive than in HashMap because the table must be visible to all threads consistently. The implementation uses a transfer operation where each thread can help advance the table by stealing work from other threads (a kind of cooperative resizing). This reduces latency spikes but doesn't eliminate them — expect pauses of 1–10 ms on maps of hundreds of thousands of entries.

package io.thecodeforge.collections;

import java.util.concurrent.*;
import java.util.*;

public class PerformanceTest {
    static final int OPS = 5_000_000;
    static final int THREADS = 8;

    public static void main(String[] args) throws Exception {
        Map<String, Integer> map = new ConcurrentHashMap<>();
        // Warm-up
        for (int i = 0; i < 100_000; i++) map.put(String.valueOf(i), i);
        long start = System.nanoTime();
        ExecutorService exec = Executors.newFixedThreadPool(THREADS);
        for (int t = 0; t < THREADS; t++) {
            exec.submit(() -> {
                for (int i = 0; i < OPS / THREADS; i++) {
                    map.computeIfPresent("key" + (i % 1000), (k, v) -> v + 1);
                }
            });
        }
        exec.shutdown();
        exec.awaitTermination(1, TimeUnit.MINUTES);
        long elapsed = System.nanoTime() - start;
        System.out.printf("Throughput: %.0f ops/sec%n", OPS * 1e9 / elapsed);
    }
}

Production Pitfalls: What Breaks When You Assume It's Just 'Thread-Safe'

ConcurrentHashMap guarantees thread safety for its own operations — but not for sequences of operations you combine externally. A classic pitfall is iterating while another thread modifies: the iterator is weakly consistent (it reflects the state at some point during iteration, may miss recent changes, but never throws ConcurrentModificationException). If you need a point-in-time snapshot, call new ConcurrentHashMap<>(map) to copy.

Another common mistake: using containsKey then get. Even though each call is safe, the value might be removed between the two calls. Use get directly and check for null, or use atomic computeIfAbsent. Similarly, size() may be stale — it's an estimate, not a precise count. For precise size, use mappingCount() which returns a long but is still approximate.

Deadlocks are impossible because ConcurrentHashMap doesn't use external locks on its own. But if your remapping function inside compute acquires another lock (e.g., a database connection pool lock), you can still deadlock. Never call a blocking or locked method from inside a compute lambda.

package io.thecodeforge.collections;

import java.util.concurrent.ConcurrentHashMap;

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

    // BAD: race between containsKey and get
    public String badGet(String key) {
        if (cache.containsKey(key)) {
            return cache.get(key); // value might have been removed
        }
        return null;
    }

    // GOOD: atomic get + null check
    public String goodGet(String key) {
        return cache.get(key); // null means absent
    }

    // BAD: size() for accounting (approximate, not exact)
    public int badSize() {
        return cache.size(); // could be outdated instantly
    }

    // OK: iterate snapshot
    public void printSnapshot() {
        // Copy for consistent iteration
        var snapshot = new ConcurrentHashMap<>(cache);
        snapshot.forEach((k, v) -> System.out.println(k + " -> " + v));
    }
}

The Initialization Trap: Default Concurrency Level Is a Lie

Most devs treat ConcurrentHashMap's default constructor as a magic 'make it fast' button. That assumption burned a team I mentored. The default concurrency level is 16 — fine for 8 cores, but your Spring Boot app on a 48-thread server? You just created 16 heavily contested buckets. Every write locks a segment, but reads use volatile reads and CAS. Under high write contention, threads spin on CAS retries. The JVM backs off, but your throughput tanks. The fix is counterintuitive: size your map for expected concurrency, not just capacity. If you have 32 threads hammering the same map, set concurrencyLevel to 32 or 64. This spreads the lock stripes. But don't overshoot too far — each stripe adds memory overhead for the internal Node array. Rule of thumb: aim for 2x your core count, and never below 16. The Java 8+ internals use a striped CAS + synchronized on bins, but the concurrency level still seeds the number of segments during initialization. Ignore it at your peril.

// io.thecodeforge
import java.util.concurrent.ConcurrentHashMap;

public class ConcurrentMapFactory {

    // PRODUCTION: estimate thread pool size, not just data volume
    public static ConcurrentHashMap<String, Object> createForHeavyWrites(int expectedThreads) {
        int concurrencyLevel = Math.max(16, expectedThreads * 2);
        // initialCapacity = (expected entries / concurrencyLevel) + 1
        int initialCapacity = 1000; // tune per use-case
        return new ConcurrentHashMap<>(initialCapacity, 0.75f, concurrencyLevel);
    }

    // Default is fine for read-heavy or low-contention maps
    public static ConcurrentHashMap<String, Object> createForReads() {
        return new ConcurrentHashMap<>();
    }
}

Iteration Consistency: A Snapshot That Lies to You

You think iterating a ConcurrentHashMap is safe because it doesn't throw ConcurrentModificationException. That's true — but the lie is 'safety' means 'weakly consistent.' The iterator reflects a snapshot of the map as it existed at some point during iteration. If Thread A inserts a key while Thread B iterates, Thread B may or may not see it. Worse: size(), isEmpty(), and containsValue() are also weakly consistent. They give you a rough estimate, not a programmatic guarantee. I've seen production dashboards spike because a monitoring thread called size() while 20 writers were active — the result was off by thousands. The iteration itself is lock-free per bin; it walks the Node hash chain at the moment of traversal. If a bin gets treeified or split (resize) mid-iteration, the iterator skips or duplicates entries. Never use ConcurrentHashMap for counters, aggregations, or state checks that require atomic snapshots. Use LongAdder for counts, or combine with a ReadWriteLock for coarse-grained consistency. Weak consistency is a feature, not a bug — but only if you know its boundary.

// io.thecodeforge
import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.atomic.LongAdder;

public class IterationPitfall {

    private final ConcurrentHashMap<String, Integer> cache = new ConcurrentHashMap<>();
    private final LongAdder insertCounter = new LongAdder(); // reliable count

    public void put(String key, Integer value) {
        cache.put(key, value);
        insertCounter.increment();
    }

    // DON'T use cache.size() for real-time metrics
    public long getApproximateSize() {
        return cache.size(); // can be stale by thousands
    }

    // DO use LongAdder for atomic accounting
    public long getExactInsertCount() {
        return insertCounter.sum();
    }
}