What do the Collections.synchronizedXxx wrappers provide, what are their limits, and when would you prefer the java.util.concurrent collections?

## The job of the synchronized wrappers Most standard collections (`ArrayList`, `HashMap`, `HashSet`) are **not thread-safe** — concurrent access from multiple threads can corrupt them. `Collections.synchronizedList(list)`, `synchronizedMap(map)`, and `synchronizedSet(set)` return a wrapper where **every method is synchronized on a single internal lock (mutex)**. So one call like `add` or `get` is atomic relative to other calls — no two threads run a wrapped method at the same time. ```java List<String> safe = Collections.synchronizedList(new ArrayList<>()); safe.add("x"); // each individual call is thread-safe ``` ## Caveat 1: compound operations are NOT atomic Thread safety applies only to **single** method calls. A **check-then-act** sequence spans two calls and is a race: ```java if (!safe.contains("x")) { // call 1 safe.add("x"); // call 2 — another thread may have added "x" in between } ``` Between the two calls another thread can interfere. To make a compound action atomic you must **synchronize externally on the wrapper object** (which is the same mutex the wrapper uses internally): ```java synchronized (safe) { if (!safe.contains("x")) safe.add("x"); } ``` ## Caveat 2: iteration must be manually synchronized Iterating calls many methods (`hasNext`, `next`). The wrapper does **not** lock across the whole loop, so another thread can mutate mid-iteration and cause a `ConcurrentModificationException`. You must guard the entire iteration yourself: ```java synchronized (safe) { for (String s : safe) { ... } // hold the lock for the full loop } ``` This is a famous footgun — people assume "synchronized" means "safe to iterate," and it does not. ## Caveat 3: one global lock = poor scalability Because **every** operation contends for the **same single lock**, threads serialize: only one can touch the collection at a time, even pure readers. Under load this becomes a bottleneck. ## The modern alternative: java.util.concurrent - **`ConcurrentHashMap`** — uses fine-grained locking (lock striping / CAS) so many threads operate concurrently. It exposes **atomic compound operations** (`putIfAbsent`, `computeIfAbsent`, `merge`) so you don't need external synchronization. Its iterators are *weakly consistent* — they never throw `ConcurrentModificationException` and tolerate concurrent updates. - **`CopyOnWriteArrayList` / `CopyOnWriteArraySet`** — every write copies the whole backing array, so reads are lock-free and iterators see a stable snapshot. Excellent for read-heavy, write-rare lists (e.g. event listeners); expensive for write-heavy use. - **`ConcurrentLinkedQueue`, `BlockingQueue` implementations** — for producer/consumer patterns. ## When to use what - **Synchronized wrappers:** legacy code, or trivial low-contention cases where you'll also handle iteration/compound locking. Generally discouraged for new code. - **ConcurrentHashMap:** the default for concurrent maps — better throughput and atomic compound ops. - **CopyOnWriteArrayList:** read-mostly lists where writes are rare. ## Key terms - **Thread-safe:** behaves correctly when accessed by multiple threads simultaneously. - **Mutex / lock:** a guard ensuring only one thread enters a critical section at a time. - **Atomic operation:** appears to happen all-at-once; no other thread sees a half-done state. - **Compound / check-then-act:** an operation made of multiple steps that together must be atomic. - **Lock striping:** splitting one lock into many sub-locks so independent operations don't contend. - **Weakly consistent iterator:** an iterator that reflects some state at/after creation, never throws CME, but may not see the latest updates. - **ConcurrentModificationException:** thrown by fail-fast iterators when the collection is structurally modified during iteration.