Java Concurrency Uncovered — Part 11: Compare-And-Swap (CAS) & Atomic Classes

Learn why int++ is a race condition, why volatile isn't enough, and how Java's atomic classes use Compare-And-Swap (CAS) to provide lock-free thread safety.

Imagine you’re building a payment service that processes thousands of transactions every day. It successfully processes 50,000 transactions without a single failure, yet the operations dashboard reports only 49,873 completed payments.

No failures. No exceptions.

So why is the dashboard showing the wrong number?

Real-time dashboards often use in-memory counters instead of querying the database for every request. But when multiple threads update the same counter concurrently, their changes can overwrite one another, causing increments to be lost. The payment records remain correct, but the in-memory count no longer reflects reality.

In Part 10, we explored how CompletableFuture handles asynchronous workflows and failures. But running tasks concurrently introduces another challenge: keeping shared data consistent when multiple threads access it at the same time.