Explain the check-then-act race condition with a concrete Java example, and show why it is unsafe even with thread-safe collections.

## The shape of the bug **Check-then-act** is any code that (1) *checks* a condition about shared state, then (2) *acts* on the result of that check — as two separate operations. The danger is the **window** between them: another thread can change the state in that gap, making your check **stale** by the time you act. ### A minimal example: lazy initialization ```java private Connection conn; public Connection get() { if (conn == null) { // CHECK conn = new Connection(); // ACT } return conn; } ``` Two threads call `get()` at the same time when `conn` is null: - Thread A sees `conn == null` (check passes). - Thread B sees `conn == null` too (A hasn't assigned yet). - Both run the act: two `Connection` objects are created; one leaks, and the two callers may use *different* connections. If `Connection` was meant to be a singleton, the invariant is broken. ### Why "use a thread-safe collection" does NOT fix it A common misconception: "I'll store it in a `ConcurrentHashMap`, that's thread-safe, so I'm fine." ```java ConcurrentHashMap<String, User> cache = new ConcurrentHashMap<>(); if (!cache.containsKey(id)) { // CHECK (atomic by itself) cache.put(id, loadUser(id)); // ACT (atomic by itself) } ``` `containsKey` is atomic. `put` is atomic. But the **pair** is not. Thread A and Thread B can both run `containsKey` (both get false) before either runs `put`, so both call the expensive `loadUser` and both `put`. You did the work twice and may have stored two different objects. **Thread-safety of a collection means each individual method won't corrupt the collection's internal state or leave it inconsistent — it says nothing about your multi-step *use* of the collection.** Compound actions you build out of several thread-safe calls are not automatically atomic. ### The general structure Check-then-act covers many idioms: - **Lazy init**: `if (x == null) x = create();` - **Put-if-absent**: `if (!map.containsKey(k)) map.put(k, v);` - **Get-then-update**: `int n = map.get(k); map.put(k, n + 1);` (this is also read-modify-write) - **Conditional remove**: `if (list.size() > 0) list.remove(0);` — size can drop to 0 in the gap, throwing. In every case the *decision* (check) is computed from a snapshot of shared state that may no longer be true when the *action* runs. ### How to fix it The rule: **make the check and the act a single atomic step.** Options: 1. **Use a compound atomic API the container already provides:** - `map.putIfAbsent(k, v)` — atomically checks absence and puts. - `map.computeIfAbsent(k, key -> loadUser(key))` — atomically checks and, only if absent, computes and inserts (and `loadUser` runs at most once per key). - `AtomicReference.compareAndSet(expected, new)` — atomic check-then-set. 2. **Hold a lock across both steps** so no other thread can observe or change the state in between: ```java synchronized (lock) { if (conn == null) conn = new Connection(); } ``` For lazy init of a static singleton, the **holder idiom** (a nested static class) or an `enum` gives lazy, thread-safe initialization without explicit locking, because class initialization is itself atomic by the JLS. 3. **Don't share mutable state at all** — confine or use immutable data. ### Why testing rarely catches it The window between check and act is usually tiny, so two threads collide only occasionally and only under load (data-dependent, nondeterministic). The code passes unit tests and single-threaded reasoning, then fails in production. That's the signature of a race.