Java Concurrent Collections: ConcurrentHashMap, BlockingQueue, and More

The synchronized collections (Collections.synchronizedMap()) serialize all access to your map. That’s fine for low contention, but hammer it with multiple threads and you’ll watch your CPU utilization drop while threads wait in line. Java’s concurrent collections are designed for actual concurrent access. Let’s see where each one belongs.

Introduction

synchronized collections serialize all access. One thread goes, everyone else waits. This works for low contention, but hammer a Collections.synchronizedMap() with multiple threads and you watch CPU utilization drop while threads queue up. Java’s concurrent collections are designed for actual concurrent access, letting readers proceed without blocking and writers proceed with fine-grained locking rather than global serialization.

The concurrent collections hierarchy serves different access patterns. ConcurrentHashMap segments its data into buckets with independent locks, allowing concurrent reads and writes on different buckets with minimal contention. BlockingQueue adds blocking operations for producer-consumer patterns where producers need to wait when the queue is full and consumers need to wait when it is empty. CopyOnWriteArrayList copies its entire array on every write, making writes expensive but reads never block or see partial modifications—ideal for listener lists where reads vastly outnumber writes.

This post covers how ConcurrentHashMap achieves concurrent reads without locking, when to use bounded versus unbounded queues, why SynchronousQueue is a zero-capacity handoff rather than a traditional queue, how LongAdder outperforms AtomicLong under high contention by spreading updates across striped cells, and the common pitfalls that catch engineers: null policy surprises in ConcurrentHashMap, unbounded queues causing OOM, and the thundering herd problem when multiple threads hit computeIfAbsent for the same missing key.

ConcurrentHashMap

Why Not Just Use synchronizedMap?

// This serializes all access - one thread at a time
Map<String, Integer> syncMap = Collections.synchronizedMap(new HashMap<>());
syncMap.put("key", 1); // Only one thread can touch this at a time

// ConcurrentHashMap allows concurrent reads and writes
ConcurrentHashMap<String, Integer> chm = new ConcurrentHashMap<>();
chm.put("key", 1); // Multiple threads can write concurrently

How ConcurrentHashMap Works

ConcurrentHashMap segments its data into buckets, each protected by its own lock. Reads don’t block at all - they see the latest written values thanks to volatile semantics.

ConcurrentHashMap<String, Integer> map = new ConcurrentHashMap<>();

// Atomic operations - no synchronized needed
map.putIfAbsent("key", 0);  // Put only if absent
map.replace("key", 0, 1);    // Replace only if current value matches
map.computeIfAbsent("key", k -> expensiveComputation()); // Lazy init
map.merge("key", 1, Integer::sum); // Combine values

// Bulk operations - iterate without ConcurrentModificationException
map.forEach(1, (k, v) -> System.out.println(k + "=" + v));
map.search(1, (k, v) -> v > 100 ? k : null); // Search with concurrency

Iteration in ConcurrentHashMap

Unlike regular iterators, ConcurrentHashMap iterators are weakly consistent:

ConcurrentHashMap<String, Integer> map = new ConcurrentHashMap<>();
map.put("a", 1);
map.put("b", 2);

// This won't throw ConcurrentModificationException
for (Map.Entry<String, Integer> entry : map.entrySet()) {
    // May or may not see updates that happened during iteration
    // but won't repeat any entries
    System.out.println(entry.getKey() + "=" + entry.getValue());
}

The iterator may reflect changes that occurred during iteration, but it won’t throw CME and won’t revisit entries.

Null Handling

Important: ConcurrentHashMap does not allow null keys or values. This was a deliberate design decision to avoid ambiguity in concurrent contexts.

map.put(null, 1);  // NullPointerException
map.get(null);      // NullPointerException

If you need null support, consider Collections.synchronizedMap() or a plain map with external synchronization.

BlockingQueue

BlockingQueue adds blocking operations for producer-consumer patterns. Producers block when the queue is full, consumers block when empty.

BlockingQueue<Order> queue = new LinkedBlockingQueue<>(1000); // Bounded

// Producer side - blocks if queue is full
public void enqueue(Order order) throws InterruptedException {
    queue.put(order); // Blocks until space available
}

// Consumer side - blocks if queue is empty
public Order dequeue() throws InterruptedException {
    return queue.take(); // Blocks until item available
}

// Non-blocking alternatives
queue.offer(order, 1, TimeUnit.SECONDS); // Wait up to 1 second
queue.poll(1, TimeUnit.SECONDS);          // Wait up to 1 second

Bounded vs Unbounded Queues

// Unbounded - grows as needed, can cause OOM
LinkedBlockingQueue<Order> unbounded = new LinkedBlockingQueue<>();

// Bounded - limits memory usage
LinkedBlockingQueue<Order> bounded = new LinkedBlockingQueue<>(1000);

// Array-based - more predictable performance
ArrayBlockingQueue<Order> arrayQueue = new ArrayBlockingQueue<>(1000);

// Priority-based - keeps elements sorted
PriorityBlockingQueue<Order> priorityQueue = new PriorityBlockingQueue<>();

Implementations

Implementation	Bounded	Notes
LinkedBlockingQueue	Optional	Most common
ArrayBlockingQueue	Yes	Fixed size, array-backed
PriorityBlockingQueue	No	Priority queue
DelayQueue	No	Elements with delays
SynchronousQueue	Yes (capacity 0)	Handoff - no storage

SynchronousQueue for Handoffs

SynchronousQueue has no capacity - a put must wait for a take and vice versa:

SynchronousQueue<Task> handoff = new SynchronousQueue<>();

// Producer
new Thread(() -> {
    try {
        // Blocks until consumer takes
        handoff.put(task);
    } catch (InterruptedException e) {
        Thread.currentThread().interrupt();
    }
}).start();

// Consumer
Task task = handoff.take(); // Blocks until producer puts

Use this when you want direct handoff between threads without buffering.

CopyOnWriteArrayList

CopyOnWriteArrayList creates a fresh copy on every write. Reads are lock-free and never see partial modifications.

CopyOnWriteArrayList<Listener> listeners = new CopyOnWriteArrayList<>();

// Readers - never block, never see partial writes
public void notifyListeners() {
    for (Listener listener : listeners) {
        listener.onEvent(); // Safe iteration
    }
}

// Writers - expensive, but no readers ever blocked
public void addListener(Listener listener) {
    listeners.add(listener); // New copy created
}

When to Use CopyOnWriteArrayList

Good for:

• Listener lists where reads vastly outnumber writes
• Cached configurations read frequently but updated rarely
• Situations where iteration must not throw CME

Bad for:

• Write-heavy workloads (every write copies the entire array)
• Large lists (copying costs grow with size)
• When you need to modify during iteration (use iterator.remove())

When NOT to Use Concurrent Collections

Concurrent collections are not always the right call, and using them reflexively creates problems. If your collection is only ever accessed from one thread — which is common in simpler applications or narrow scopes — a plain ArrayList, HashMap, or ArrayDeque is faster and introduces no concurrency overhead. The lock-free algorithms in ConcurrentHashMap and its siblings perform memory ordering operations on every read and write, and that cost is wasted if no other thread is actually competing.

Snapshot isolation catches people off guard. Concurrent collection iterators are weakly consistent: they may or may not reflect updates that happened during iteration, and they will not throw ConcurrentModificationException — but they also will not give you a point-in-time snapshot. If you need consistent iteration over a collection’s state, you must copy it first (new ArrayList<>(source)). Making decisions based on weakly consistent iteration is how subtle correctness bugs creep in.

ConcurrentHashMap gets overused as a catch-all cache or counter. The computeIfAbsent method looks handy for building caches, but if your loader blocks or does expensive computation, you create a thundering herd where dozens of threads all compute the same key at once. Use LoadingCache from Guava or Caffeine instead. And if you are using ConcurrentHashMap as a counter with incrementAndGet() under heavy contention, you are likely slower than LongAdder — it spreads contention across internal cells instead of all hitting the same CAS. See Java Atomics and VarHandle for lock-free alternatives that handle high-contention scenarios better.

ConcurrentLinkedQueue and Deque

Lock-free linked structures for high throughput:

ConcurrentLinkedQueue<Task> queue = new ConcurrentLinkedQueue<>();
ConcurrentLinkedDeque<Task> deque = new ConcurrentLinkedDeque<>();

// Queue operations
queue.offer(task);      // Add to tail
Task task = queue.poll(); // Remove from head

// Deque operations - can operate on both ends
deque.offerFirst(task);
deque.offerLast(task);
Task first = deque.pollFirst();
Task last = deque.pollLast();

Choosing a Concurrent Collection

// Need a map with concurrent access?
// - High read, low write: ConcurrentHashMap
// - Need ordering: ConcurrentSkipListMap

// Need a queue for producer-consumer?
// - Bounded: LinkedBlockingQueue or ArrayBlockingQueue
// - Handoff (no buffer): SynchronousQueue
// - Priority-based: PriorityBlockingQueue

// Need a list with safe iteration?
// - Read-heavy, few updates: CopyOnWriteArrayList
// - Otherwise: ConcurrentLinkedQueue for queue semantics

// Need a set?
// - ConcurrentHashMap.newKeySet() - most efficient
// - ConcurrentSkipListSet - if ordering needed

Architecture Diagram

ConcurrentMap

graph TD
    subgraph ConcurrentMap
        CM1[ConcurrentHashMap] --> CM2[Segment-based locking]
        CM3[ConcurrentSkipListMap] --> CM4[Red-black tree, lock-free]
    end

BlockingQueue

graph TD
    subgraph BlockingQueue
        BQ1[LinkedBlockingQueue] --> BQ5[Bounded/unbounded linked]
        BQ2[ArrayBlockingQueue] --> BQ6[Fixed array, bounded]
        BQ3[PriorityBlockingQueue] --> BQ7[Heap, priority ordered]
        BQ4[SynchronousQueue] --> BQ8[No storage, direct handoff]
    end

CopyOnWrite

graph TD
    subgraph CopyOnWrite
        COW1[CopyOnWriteArrayList] --> COW2[Full copy on write]
    end

LockFree

graph TD
    subgraph LockFree
        LF1[ConcurrentLinkedQueue] --> LF3[CAS operations]
        LF2[ConcurrentLinkedDeque] --> LF3
    end

Production Failure Scenarios

Scenario 1: Memory Explosion with CopyOnWriteArrayList

// BROKEN - writing frequently causes memory churn
CopyOnWriteArrayList<LogMessage> logs = new CopyOnWriteArrayList<>();
executor.scheduleAtFixedRate(() -> {
    logs.add(new LogMessage("periodic update")); // Copies entire list every second!
}, 1, 1, TimeUnit.SECONDS);

// FIXED - use a queue or concurrent collection
ConcurrentLinkedQueue<LogMessage> logs = new ConcurrentLinkedQueue<>();

Scenario 2: BlockingQueue Without Capacity

// BROKEN - unbounded queue can grow without limit
BlockingQueue<Task> queue = new LinkedBlockingQueue<>();
// If producers outpace consumers, this grows until OOM

// FIXED - always set reasonable capacity
BlockingQueue<Task> queue = new LinkedBlockingQueue<>(1000);

Scenario 3: ConcurrentHashMap and null Values

// BROKEN - NPE will occur
ConcurrentHashMap<String, Object> cache = new ConcurrentHashMap<>();
cache.putIfAbsent("user", null); // NPE

// FIXED - use a different marker value
cache.putIfAbsent("user", NULL_PLACEHOLDER);

Trade-off Table

Collection	Reads	Writes	Memory	Use When
ConcurrentHashMap	Lock-free	Lock per segment	Low	General concurrent map
Hashtable	Lock whole	Lock whole	Medium	Legacy compatibility
synchronizedMap	Lock whole	Lock whole	Medium	Need null keys
CopyOnWriteArrayList	Lock-free	Expensive copy	High per write	Read-heavy, few writes
LinkedBlockingQueue	Blocking	Blocking	Moderate	Producer-consumer
ArrayBlockingQueue	Blocking	Blocking	Fixed	Bounded producer-consumer
SynchronousQueue	Blocking	Blocking	None	Direct handoff

Implementation Snippets

Producer-Consumer with BlockingQueue

public class OrderProcessor {
    private final BlockingQueue<Order> orders = new LinkedBlockingQueue<>(500);
    private final ExecutorService consumerPool;

    public OrderProcessor(int consumerCount) {
        consumerPool = Executors.newFixedThreadPool(consumerCount);
        for (int i = 0; i < consumerCount; i++) {
            consumerPool.submit(this::processOrders);
        }
    }

    public void submitOrder(Order order) throws InterruptedException {
        orders.put(order);
    }

    private void processOrders() {
        while (!Thread.currentThread().isInterrupted()) {
            try {
                Order order = orders.take();
                process(order);
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
                break;
            }
        }
    }

    public void shutdown() {
        consumerPool.shutdownNow();
    }
}

Cache with ConcurrentHashMap

public class DataCache<K, V> {
    private final ConcurrentHashMap<K, V> cache = new ConcurrentHashMap<>();
    private final Function<K, V> loader;

    public DataCache(Function<K, V> loader) {
        this.loader = loader;
    }

    public V get(K key) {
        return cache.computeIfAbsent(key, loader);
    }

    public void invalidate(K key) {
        cache.remove(key);
    }

    public void clear() {
        cache.clear();
    }
}

Observability Checklist

• Do you know which collections allow null values?
• Are your bounded queues actually bounded?
• Can you detect queue saturation in monitoring?
• Are you using CopyOnWriteArrayList for read-heavy workloads only?
• Do you have appropriate queue capacity for backpressure?
• Are consumers faster than producers on average?

Security Notes

Collections can expose data if not properly secured:

• ConcurrentHashMap doesn’t prevent unauthorized read access within the same JVM
• Use defensive copies when passing collections to untrusted code
• Consider immutability wrappers for shared data: Collections.unmodifiableMap()

Common Pitfalls / Anti-Patterns

1. Using synchronized collections under load: They’ll serialize access and kill throughput
2. CopyOnWriteArrayList for write-heavy use: Every write copies the entire array
3. Unbounded queues: Can cause OutOfMemoryError
4. Assuming iteration is point-in-time: In concurrent collections, it’s weakly consistent
5. Ignoring null policies: ConcurrentHashMap rejects nulls
6. Queue capacity mis-tuning: Too small causes blocking, too large wastes memory

Quick Recap Checklist

• ConcurrentHashMap uses segment-based locking, allows concurrent reads/writes
• BlockingQueue blocks producers on full queue, consumers on empty
• CopyOnWriteArrayList copies entire array on write, great for read-heavy
• SynchronousQueue is zero-capacity handoff, not a queue
• Bounded queues provide backpressure
• ConcurrentHashMap doesn’t allow null keys/values
• Iteration is weakly consistent in concurrent collections

Interview Questions

Further Reading

• ConcurrentHashMap internals and segmentation — How segment-based locking works under the hood
• BlockingQueue implementations comparison — Bounded vs unbounded and array vs linked trade-offs
• CopyOnWriteArrayList memory behavior — When the copy cost is worth it
• Weakly consistent iterators in Java concurrent collections — Guarantees and limitations
• Caffeine Cache: High-performance caching — Why ConcurrentHashMap computeIfAbsent can cause thundering herd

Conclusion

You now understand Java’s concurrent collection hierarchy from ConcurrentHashMap to CopyOnWriteArrayList. Apply the right collection for your access pattern: segment-locked maps for general concurrent access, blocking queues for producer-consumer workflows, and copy-on-write lists for read-heavy listener patterns. Always use bounded queues to introduce backpressure, and remember that ConcurrentHashMap does not allow null keys or values. Continue with Java Atomics and VarHandle to explore lock-free alternatives to synchronized collections.