Concurrent Collections

ConcurrentHashMap is a thread-safe map that many threads can read and write at once safely. Use it instead of HashMap (not thread-safe) or a synchronized map (locks the whole map) when several threads share a map.

ArrayBlockingQueue is backed by a fixed-size array and is always bounded. LinkedBlockingQueue uses linked nodes and is optionally bounded (unbounded by default). ArrayBlockingQueue uses one lock; LinkedBlockingQueue uses two (put and take), so it often has higher throughput under contention.

Use put/take when blocking forever is acceptable, offer/poll when you must act immediately and not wait, and the timed offer/poll when you'll wait but only up to a limit. put and take throw InterruptedException, so handle interruption (usually by restoring the interrupt flag and stopping).

They do a check-and-update as one atomic step, so two threads can't interleave between checking and writing. A manual get-then-put has a race window where both threads see the same state and clobber each other; these methods close that window.

When you start iterating, the iterator grabs the current array and walks that. Later changes go to a new array the iterator never sees, so it can't notice a modification and never throws ConcurrentModificationException. The downside: you may iterate stale data.

CopyOnWriteArrayList is a thread-safe list. Every time you add or remove an element, it makes a fresh copy of the internal array. Reads happen on the array without locking, so many threads can read safely at the same time. A plain ArrayList is not thread-safe.

Because of an ambiguity: if get(key) returned null, you couldn't tell whether the key is absent or present with a null value. In a single thread you could re-check with containsKey, but under concurrency another thread could change the answer between calls, so nulls are banned outright.

Every write copies the whole array, so one write is O(n) in time and allocates a new array of size n. Adding n elements one by one is O(n squared). CopyOnWriteArraySet is the Set version with no duplicates, backed by a CopyOnWriteArrayList, so adds also scan for existing elements.

It is a thread-safe, unbounded FIFO queue. Instead of locking, it uses atomic compare-and-swap (CAS) operations to update its head and tail, so many threads can add and remove items at once without blocking each other.

They are thread-safe, sorted map and set classes — the concurrent versions of TreeMap and TreeSet. They keep elements in sorted order and can be used safely by many threads at once, supporting range queries like 'all keys between A and B'.

Neither is FIFO. PriorityBlockingQueue returns elements in priority order (a heap), and is unbounded. DelayQueue holds Delayed elements that only become available for take() after their delay expires; until then the queue acts empty even if it has elements.

A SynchronousQueue has zero capacity: it holds no elements. Each put must wait for a matching take (and vice versa) — it's a direct hand-off between two threads. Use it when you want producers and consumers to rendezvous with no buffering.

In Java 8+, the map is one big array of buckets. Adding the first entry to an empty bucket uses a single atomic CAS instruction (no lock). Adding to a non-empty bucket locks just that bucket. Reads never lock. The old design instead split the map into a few fixed 'segments', each with its own lock.

synchronizedList wraps a list so every method takes one lock, and you must still lock manually to iterate safely. CopyOnWriteArrayList instead copies the array on writes so reads need no lock and iteration is safe and never throws. Use COW when reads dominate; use synchronizedList or your own lock when writes are frequent.

Use a BlockingQueue when consumers should wait for work and you want a size limit so producers slow down when it's full. Use ConcurrentLinkedQueue when you never want threads to block and don't need a bound — it just keeps growing and returns null when empty.

Weakly consistent iterators (used by concurrent collections like ConcurrentLinkedQueue and ConcurrentSkipListMap) let you keep iterating even while other threads change the collection, and never throw an error. Fail-fast iterators (used by ArrayList, HashMap) throw ConcurrentModificationException if the collection changes during iteration.

Each single operation (get, put, merge, etc.) is atomic, but a series of operations or anything spanning multiple keys is not. size() and bulk reads are only approximate while the map changes. For cross-key or whole-map consistency you need your own coordination, a snapshot, or a different design.

It breaks down when writes are frequent or the list is large (each write copies everything), when readers must see the very latest data (the snapshot can be stale), or when you must mutate during iteration. Then prefer ConcurrentHashMap-based structures, ConcurrentLinkedQueue, or a ReadWriteLock.

Each operation tries to update a pointer with compare-and-swap (CAS); if another thread changed it first, the CAS fails and the operation retries. 'Lock-free' means the system as a whole always makes progress even if some threads stall, but an individual thread can be made to retry indefinitely.