## Java Core Deep Dive: Concurrent Collections and Java 8 Features You are interviewing for a backend engineering role on a team that builds high-throughput JVM services. The interviewer wants to gauge how deeply you understand the standard library you rely on every day. The conversation has two threads: how Java's hash-based maps behave under concurrency, and how you actually apply the functional features introduced in Java 8. ### Constraints & Assumptions - Target runtime is **Java 8 or later** (the `ConcurrentHashMap` discussion assumes the Java 8 implementation, which differs significantly from Java 7). - Services are multi-threaded and may have many reader and writer threads hitting shared maps. - Answers should be grounded in real mechanics and real usage, not slogans. ### Clarifying Questions to Ask - Is the shared map read-heavy, write-heavy, or mixed? (This changes whether `ConcurrentHashMap`, an immutable copy, or external locking is the right tool.) - Do we need a *consistent snapshot* across the whole map, or is per-entry consistency enough? - Which JDK version are we targeting — does the team use newer additions (records, `var`, virtual threads) or are we restricted to the Java 8 baseline? - Are there compound operations ("check then put") that need to be atomic, or only single-key reads/writes? ### Part 1: HashMap vs. ConcurrentHashMap Explain the main differences between `HashMap` and `ConcurrentHashMap`, then describe in detail **how `ConcurrentHashMap` supports safe concurrent access** without serializing every operation behind a single lock. ```hint Where to start Start from thread-safety guarantees: `HashMap` offers none and can corrupt its internal structure (or spin in an infinite loop on older JDKs) under concurrent writes. Then contrast the *locking granularity* `ConcurrentHashMap` uses to allow concurrency. ``` ```hint Mechanism Recall how Java 8 changed the implementation: instead of Java 7's segment locks, it uses a single bin array where empty-bin inserts use a lock-free CAS and non-empty bins are guarded by `synchronized` on the first node. Also contrast `HashMap`'s **fail-fast** iterator with `ConcurrentHashMap`'s **weakly consistent** iterator, and remember that `ConcurrentHashMap` forbids `null` keys and values. ``` #### What This Part Should Cover ```premium-lock What This Part Should Cover ``` ### Part 2: Practical Java 8 — Lambdas, Streams, and Optional Drawing on real project experience, explain how you use **lambda expressions**, the **Streams API**, and **`Optional`**. For each, show a concrete before/after transformation and call out the most common misuse. ```hint What to anchor on Tie every feature to a concrete code transformation: an anonymous inner class collapses into a lambda; an imperative `for` loop with a mutable accumulator becomes a declarative stream pipeline; a nested null check becomes an `Optional` chain with `map`/`orElseGet`. ``` ```hint Pitfall Mention stream laziness and short-circuiting (intermediate ops do nothing until a terminal op runs), the danger of parallel streams over a shared mutable accumulator, and that `Optional` is designed for *return values*, not for fields, method parameters, or collection elements. ``` #### What This Part Should Cover ```premium-lock What This Part Should Cover ``` ### What a Strong Answer Covers ```premium-lock What a Strong Answer Covers ``` ### Follow-up Questions - A "check then act" sequence (`if (!map.containsKey(k)) map.put(k, v)`) is racy even on a `ConcurrentHashMap`. How do `putIfAbsent` and `computeIfAbsent` fix this, and what atomicity does each guarantee? - Why does `ConcurrentHashMap` reject `null` keys and values when `HashMap` allows them? - You parallel-stream a large list and accumulate into a shared `ArrayList`. What goes wrong, and how would you make it correct (and is parallelizing even worth it here)? - When would you prefer `Collections.synchronizedMap(...)` or a `CopyOnWriteArrayList` over `ConcurrentHashMap`?