Deadlock, race conditions, starvation

1. Race condition — the interleaving that eats an update

The trap is that count++ is not one step. The CPU does three: read the value into a register, add one, write it back. Two threads can slide in between each other's steps, and then both add 1 to the same starting value — so two increments produce one.

// Both threads run this. count starts at 0.
count++;      // really: 1. read count   2. add 1   3. write count

//  T1: read 0 ....................... add → 1 ... write 1
//  T2: ......... read 0 ... add → 1 ............ write 1
//  count is now 1. Two increments happened. One survived.

The fix is to make the whole read-modify-write atomic — indivisible from any other thread's point of view. Either wrap it in a lock (a critical section: at most one thread inside at a time) or use a hardware atomic like AtomicInteger.incrementAndGet() / atomic.Add. Both mean the same thing: nobody else can observe or touch the value halfway through.

2. Deadlock — the cycle of polite waiting

Thread 1 holds lock A and needs B. Thread 2 holds lock B and needs A. Neither will let go of what it has before it gets what it wants, so both wait forever. Nothing crashes; the threads just go to sleep and never wake. Draw the waiting relationships as arrows and you'll see a cycle — that ring is the signature of a deadlock.

A deadlock needs four conditions to hold at once (the Coffman conditions). Break any single one and deadlock becomes impossible:

• Mutual exclusion — the resource can only be held by one thread at a time. (Break it: use immutable data or a copy per thread, so there's nothing to lock.)
• Hold and wait — a thread keeps what it has while waiting for more. (Break it: grab all the locks you need in one shot, or release what you hold before waiting.)
• No preemption — you can't yank a lock away from a thread. (Break it: tryLock with a timeout, so a waiter gives up, releases everything, and retries.)
• Circular wait — the waiting arrows form a ring. (Break it: a global lock order — every thread takes A before B, always. This is the fix you'll use 90% of the time.)

// ✗ Two orders → a ring is possible
void t1() { synchronized (A) { synchronized (B) { work(); } } }   // A → B
void t2() { synchronized (B) { synchronized (A) { work(); } } }   // B → A

// ✓ One global order → no ring can ever form
void t1() { synchronized (A) { synchronized (B) { work(); } } }   // A → B
void t2() { synchronized (A) { synchronized (B) { work(); } } }   // A → B
// T2 now waits at A holding NOTHING, so it can't block anybody.

Other real fixes, in rough order of preference: take fewer locks (one coarse lock is boring and correct), hold them for less time (never call unknown code — a callback, an RPC — while holding a lock), tryLock with a timeout so a stuck thread backs off and retries instead of hanging, and best of all no shared mutable state at all (message passing, immutable values, one owner per piece of data).

3. Starvation — able to run, never picked

A starving thread is not stuck on anything — it is runnable. It just never wins the turn, because greedier or higher-priority threads keep getting there first. Plain locks make no promise about who goes next: when a lock is released, whichever thread the OS happens to wake grabs it, and a thread that has waited a long time gets no special treatment. Under constant load, one unlucky thread can wait effectively forever.

• Fair locks / FIFO queues — hand out turns in arrival order, so the longest waiter is served next. In Java that's new ReentrantLock(true); more generally, put requests in a queue instead of letting threads scramble.
• Don't play priority games — big priority gaps let high-priority work permanently drown low-priority work. Keep priorities close to default unless you have a real reason.
• Bound the greedy work — batch sizes, per-client rate limits, and time slices stop one hot task from monopolising the resource.

Telling them apart when something goes wrong

• Wrong numbers, everything still running → race condition. Look for shared mutable state touched without a lock or an atomic.
• Hung, no CPU, no error → deadlock. Take a thread dump: you'll see threads BLOCKED, each on a lock another blocked thread owns.
• Hung, CPU pinned at 100% → livelock or a spin loop, not a deadlock.
• Everything works but one task never completes → starvation. Check who else is hammering that lock, queue, or thread pool.

Go looking for these when...

• Any mutable state is reachable from two threads — a counter, a cache, a shared list, a lazily built singleton. That is the entire precondition for a race.
• A code path takes two or more locks — the instant that happens, write down the order and make it a rule everyone follows. Two lock orders in one codebase is a deadlock waiting for load.
• Threads have different priorities or wildly different workloads — a fast, frequent task sharing a lock with a slow, rare one is the classic starvation setup.

Sidestep them entirely when...

• The state can be immutable — nothing to race on, nothing to lock, no cycle to form. This is the cheapest fix in existence.
• One thread can own the data — an actor, a single-writer goroutine, an event loop. Others send messages instead of touching state.
• A library already solved it — ConcurrentHashMap, AtomicLong, BlockingQueue, channels. Hand-rolled locking loses to battle-tested primitives almost every time.