Concurrent Collections

Ordinary collections are not thread-safe

ArrayList, HashMap, and ArrayDeque assume one thread at a time. Used concurrently they do not merely lose an update — they can corrupt their internal structure.

List<Integer> shared = new ArrayList<>();

Runnable adder = () -> {
    for (int i = 0; i < 10_000; i++) shared.add(i);
};

Thread a = new Thread(adder);
Thread b = new Thread(adder);
a.start(); b.start(); a.join(); b.join();

System.out.println(shared.size());     // rarely 20000; may throw

add reads a size, writes an element, and updates the size. Two threads interleaving those steps can lose elements, overwrite each other, or leave the list in a state that throws ArrayIndexOutOfBoundsException from a later, innocent-looking call.

A corrupted HashMap has historically been able to produce an infinite loop on a subsequent get — a hang with no obvious cause, long after the damage was done.

The thread-safe options

What to use instead

ConcurrentHashMap

The one you will use most.

import java.util.concurrent.ConcurrentHashMap;

Map<String, Integer> counts = new ConcurrentHashMap<>();

counts.put("intake", 1);
counts.merge("intake", 1, Integer::sum);        // atomic increment
counts.computeIfAbsent("shooter", k -> 0);      // atomic

Individual operations are atomic and safe. But combining two operations is not:

// BROKEN — another thread can act between the get and the put
if (!counts.containsKey(key)) {
    counts.put(key, 0);
}

// CORRECT — one atomic operation
counts.putIfAbsent(key, 0);

Blocking queues

The best tool for concurrency, because it lets threads hand work to each other rather than share variables.

import java.util.concurrent.*;

BlockingQueue<String> queue = new ArrayBlockingQueue<>(100);

// producer
new Thread(() -> {
    try {
        for (int i = 0; i < 50; i++) {
            queue.put("frame " + i);       // blocks if the queue is full
        }
        queue.put("DONE");
    } catch (InterruptedException e) {
        Thread.currentThread().interrupt();
    }
}).start();

// consumer
new Thread(() -> {
    try {
        while (true) {
            String item = queue.take();    // blocks until something arrives
            if (item.equals("DONE")) break;
            process(item);
        }
    } catch (InterruptedException e) {
        Thread.currentThread().interrupt();
    }
}).start();

put and take handle the waiting for you. No polling, no sleeping, and no shared variable that either thread writes.

The “DONE” marker is a common way to signal completion, since a queue has no end-of-stream concept of its own.

The four method families

Blocking queues offer four behaviours for the same operation:

Choose deliberately. Using add on a full queue throws; offer silently returns false and drops the item — a quiet data-loss bug if you ignore the return value.

CopyOnWriteArrayList

Safe for concurrent use, but every write copies the entire backing array:

List<Listener> listeners = new CopyOnWriteArrayList<>();
listeners.add(listener);              // copies the whole array

for (Listener l : listeners) {        // never throws ConcurrentModificationException
    l.onEvent();
}

Only appropriate when reads vastly outnumber writes — a listener list is the classic case. Using it for a collection written in a loop is much worse than a lock.

Its iteration is a genuine advantage: you get a snapshot, so modification during iteration cannot break the loop.

Synchronized wrappers

The older approach still appears in existing code:

List<Integer> list = Collections.synchronizedList(new ArrayList<>());

Every method is individually synchronized, but iteration is not — you must lock manually:

synchronized (list) {
    for (int v : list) { ... }
}

Prefer the purpose-built concurrent collections. They are faster and do not have this trap.

The best option is still to share nothing

Related