Understand the concurrency failures Java engineers recognize, including races, stale reads, lock contention, deadlocks, and broken invariants, before replacing hidden mutation with Clojure's explicit state model.
Concurrency is difficult in every JVM language because the hard part is coordination, not syntax. Once multiple threads can observe and change the same identity, the program has to define who is allowed to change it, which changes are atomic, and what other threads are allowed to see.
Java gives you powerful primitives for this problem, but the responsibility is spread across object design, synchronization policy, executor boundaries, and memory-visibility rules. Clojure changes the default shape: most data is immutable, and mutable identity is represented by explicit reference types.
| Failure mode | Java symptom | Clojure design response |
|---|---|---|
| Race condition | Correct result depends on thread timing. | Keep the transition pure and apply it atomically with the right reference type. |
| Stale read | One thread observes an older value than expected. | Read from explicit references and avoid mutable object graphs shared by convention. |
| Deadlock | Threads wait forever on locks acquired in different orders. | Prefer values, atoms, STM, or message flow before manual lock choreography. |
| Broken invariant | Several fields or objects no longer agree. | Put coordinated changes in one transaction or one value-level transition. |
This section starts with the problems Java developers already know, then reframes them in Clojure terms: immutable values are safe to share, but changing identity still needs a deliberate coordination model.