Why Concurrent Collections in Java — HashMap, synchronizedMap, and the Real Solutions

Standard HashMap and ArrayList are not thread-safe, and the naive 'fix' — Collections.synchronizedMap — solves only part of the problem.

The problems with plain collections

• Structural corruption: pre-Java 8 HashMap famously produced infinite loops during concurrent resize — threads spinning at 100% CPU forever
• Lost updates: map.put(k, map.get(k) + 1) races
• `ConcurrentModificationException`: fail-fast iterators throw on any modification during iteration

Why `Collections.synchronizedMap` is not the answer

• Single big lock around every method — terrible throughput on multi-core
• Iteration still requires external `synchronized(map)` block — huge footgun
• Compound operations like containsKey + put are still race conditions
• Inherits HashMap quirks like null handling

`ConcurrentHashMap` — the right default

• Per-bucket locking + lock-free reads — scales to hundreds of cores
• Atomic compound operations: computeIfAbsent, merge, compute, replace
• Fail-safe iterator — doesn't throw on concurrent modification, sees a weakly-consistent view
• No null keys or values — design decision to avoid ambiguity
• Use ConcurrentHashMap.newKeySet() for concurrent sets

`CopyOnWriteArrayList` — right for ONE case

• Every write copies the whole internal array
• Reads are lock-free; iterators see a snapshot
• Perfect for read-heavy, rarely-written lists: event listeners, config lists
• Terrible for frequently-modified lists — write cost is O(n)

`BlockingQueue` family for producer-consumer

• ArrayBlockingQueue — bounded, array-backed
• LinkedBlockingQueue — optionally bounded, separate put/take locks — best throughput
• PriorityBlockingQueue — priority heap
• DelayQueue — delayed elements (used by ScheduledThreadPoolExecutor)
• SynchronousQueue — zero capacity, direct handoff (used by CachedThreadPool)
• LinkedTransferQueue — modern lock-free transfer queue
• All have blocking put/take that correctly handle lock release during waits

Modern defaults I'd use in new code

• Map → ConcurrentHashMap
• Set → ConcurrentHashMap.newKeySet()
• Sorted map → ConcurrentSkipListMap
• Listener list → CopyOnWriteArrayList
• Work queue → LinkedBlockingQueue(capacity) or ArrayBlockingQueue
• Unbounded non-blocking FIFO → ConcurrentLinkedQueue

Compound operations still need atomic methods

• map.computeIfAbsent(key, k -> load(k)) instead of containsKey + put
• map.merge(key, 1L, Long::sum) instead of get + put
• map.replace(key, oldValue, newValue) for optimistic updates

Recommendation: In any code written after 2005, reach for java.util.concurrent collections first. ConcurrentHashMap should be the default map for any shared state — never HashMap behind a lock, never Collections.synchronizedMap. For producer-consumer pipelines, use the appropriate BlockingQueue. Reserve CopyOnWriteArrayList exclusively for read-heavy listener lists. And whenever you'd write containsKey followed by put, stop and use computeIfAbsent or merge instead — the atomic compound methods are what make ConcurrentHashMap truly thread-safe at the logical level, not just the memory level.