← All categories

Concurrency

Code that has to stay correct when many threads run it at once.

Concurrency bugs are rare in tests and common in production. Two threads read and write the same value, one sees half of another's update, or two locks are taken in opposite orders and both threads wait forever.

Problems in this category ask you to make shared state safe without making everything slow: immutable objects that can be shared freely, blocking queues instead of busy loops, bounded thread pools, read-write locks and a consistent lock order.

You'll recognise it when

  • Workers loop and sleep while checking a shared list for work.
  • A new thread is started for every request.
  • Every method is synchronized "to be safe".
  • Shared configuration is changed field by field while others read it.

Example

A ticket counter counts entries at several gates, each on its own thread.

Before
class GateCounter {
    private int entered = 0;
    void personEntered() { entered++; }   // read, add, write: three steps
    int entered() { return entered; }
}
After
class GateCounter {
    private final AtomicInteger entered = new AtomicInteger();
    void personEntered() { entered.incrementAndGet(); }   // one indivisible step
    int entered() { return entered.get(); }
}

Why it's better: With a plain int, two gates can read the same value and both write back value + 1, losing a person. The atomic version can't lose updates, and it needs no lock.

Ideas you'll practise

Immutable objectsProducer-consumerThread poolsRead-write locksLock orderingAtomic variables

Problems 6