Collections framework: interview questions & scenarios

Model answer

Use a HashMap<String, Book>, with the ISBN as the key and the Book as the value. The operation the requirement makes important is exact lookup by a unique key, so a list scan is the wrong shape.

The honest cost is expected O(1) for get, put and remove, assuming a good hashCode and equals contract for the key. A resize can make one insert O(n), and collision-heavy bins are protected by tree bins in Java 8+, but the interview answer should not flatten that into "HashMap is always O(1)".

record Book(String isbn, String title) { }

Map<String, Book> byIsbn = new HashMap<>();
byIsbn.put("978-0134685991", new Book("978-0134685991", "Effective Java"));
Book book = byIsbn.get("978-0134685991");

This lines up with the decision path in Choosing the right collection: key lookup starts with HashMap, then moves only if ordering, enum keys, reference identity or concurrency changes the requirement.

Model answer

For a shared mutable map, start with ConcurrentHashMap<K,V>, then use its atomic methods such as merge, compute or putIfAbsent. If the values are hot counters, a common shape is ConcurrentHashMap<String, LongAdder>.

Hashtable and Collections.synchronizedMap(new HashMap<>()) synchronize individual method calls. That is better than a plain HashMap under mutation, but it does not make a multi-step operation atomic unless you hold the same external lock around the whole sequence. They also serialize more access through one monitor, while ConcurrentHashMap is designed for concurrent reads and updates.

ConcurrentMap<String, Integer> hits = new ConcurrentHashMap<>();
hits.merge("/checkout", 1, Integer::sum);

The requirement is not "make any collection synchronized". It is "keep a shared invariant correct under interleaving threads". Sometimes that still means an explicit lock or a different design, especially when the invariant spans several collections.