Concurrent Collections

#Introduction

Standard collections like ArrayList and HashMap are not thread-safe: concurrent modification can lose entries, corrupt internal structure or throw exceptions. Java offers two ways to fix that — synchronized wrappers (lock everything) and the concurrent collections in java.util.concurrent (designed for concurrency from the ground up).

#Option 1 — Synchronized Wrappers

List<String> list = Collections.synchronizedList(new ArrayList<>());
Map<String, Integer> map = Collections.synchronizedMap(new HashMap<>());

Every method locks one shared lock. Simple, but:

• all threads contend for the same lock, so throughput is poor under load;
• compound actions (check-then-act) still need external locking;
• iteration requires holding the lock for the whole loop.

synchronized (list) {          // required — otherwise ConcurrentModificationException is possible
    for (String s : list) {
        process(s);
    }
}

Vector and Hashtable are legacy classes with the same "lock every method" approach.

#Option 2 — Concurrent Collections

#Fail-Fast vs Fail-Safe Iterators

In Java, fail-fast and fail-safe describe how iterators behave when a collection is modified during iteration.

Fail-Fast Iterators

• Throw ConcurrentModificationException if the collection is structurally modified (add(), remove()) during iteration — by another thread or by the same thread outside the iterator.
• Work directly on the original collection.
• Track changes with an internal modCount: the iterator records it at creation and checks it on every next(); if it changed, it throws.
• Used by the non-concurrent collections: ArrayList, LinkedList, HashSet, HashMap and so on.

List<String> names = new ArrayList<>(List.of("a", "b", "c"));
for (String n : names) {
    if (n.equals("b")) names.remove(n);   // ConcurrentModificationException
}

names.removeIf(n -> n.equals("b"));        // ✅ safe way to remove while iterating

Fail-Safe Iterators

• Don't throw ConcurrentModificationException, even if the collection is modified during iteration.
• Used by concurrent collections from java.util.concurrent.

But they don't all work the same way — there are two kinds:

#ConcurrentHashMap — Use the Atomic Methods

ConcurrentHashMap locks only small parts of the table (per-bin locking plus CAS since Java 8), so many threads can read and write at once. Reads don't lock at all.

But individual calls being thread-safe doesn't make your logic atomic:

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

// ❌ Race: two threads read the same value and both write value + 1
Integer current = hits.get(page);
hits.put(page, current == null ? 1 : current + 1);

// ✅ Atomic per key
hits.merge(page, 1, Integer::sum);

// A thread-safe local cache: the loader runs at most once per key
Map<Long, Customer> cache = new ConcurrentHashMap<>();
Customer c = cache.computeIfAbsent(id, customerRepository::load);

// Counting with LongAdder values for very hot keys
ConcurrentHashMap<String, LongAdder> counts = new ConcurrentHashMap<>();
counts.computeIfAbsent(event, k -> new LongAdder()).increment();

size() is an estimate under concurrent updates; mappingCount() returns a long.

#CopyOnWriteArrayList

Every write (add, set, remove) copies the entire underlying array; reads and iteration use the current array without any locking.

List<OrderListener> listeners = new CopyOnWriteArrayList<>();

listeners.add(auditListener);              // rare: copies the array

for (OrderListener l : listeners) {        // frequent: no lock, no CME
    l.onOrderPlaced(order);
}

Iterators are snapshots and don't support remove() (it throws UnsupportedOperationException).

#BlockingQueue — the Producer–Consumer Workhorse

A BlockingQueue adds operations that wait when the queue is empty (on take) or full (on put):

BlockingQueue<Order> queue = new ArrayBlockingQueue<>(1_000);

// Producer — e.g. a request thread
if (!queue.offer(order, 100, TimeUnit.MILLISECONDS)) {
    throw new ServiceUnavailableException("Order queue full");
}

// Consumer — a background worker
while (!Thread.currentThread().isInterrupted()) {
    Order next = queue.take();    // waits for work
    process(next);
}

Implementations

Graceful Shutdown with a Poison Pill

static final Order POISON_PILL = new Order(-1);

// Producer, when done:
queue.put(POISON_PILL);

// Consumer:
while (true) {
    Order o = queue.take();
    if (o == POISON_PILL) break;
    process(o);
}

#ConcurrentLinkedQueue

A non-blocking, unbounded, lock-free (CAS-based) FIFO queue. offer and poll never block — poll() returns null when empty. Use it when threads shouldn't wait for elements; use a BlockingQueue when consumers need to wait for work.

#Choosing a Thread-Safe Collection

#Key Takeaways

• Synchronized wrappers serialize everything; concurrent collections allow real concurrency.
• Fail-fast iterators throw ConcurrentModificationException; fail-safe iterators are either snapshots (copy-on-write) or weakly consistent (ConcurrentHashMap).
• ConcurrentHashMap is thread-safe per call — use merge, compute* and putIfAbsent for atomic logic.
• CopyOnWriteArrayList suits read-mostly lists.
• BlockingQueue implements producer–consumer with built-in waiting and back-pressure.