Card 05/ 08
Deadlock vs Livelock vs Starvation
Three ways work stops getting done, told apart by what the processors are doing.
Deadlock, livelock and starvation all look like "the work is not getting done" from outside, and each needs a different fix. In a deadlock threads wait forever in a cycle; in a livelock they keep reacting to each other without progressing; in starvation one thread never gets its turn. The table compares them, and a thread dump, a snapshot of every thread's state from jstack, tells them apart in about a minute. Lock ordering means every thread takes locks in one agreed order; randomised backoff means waiting a random time before retrying.
| Failure | The threads are | Processor use | Fixed by |
|---|---|---|---|
| Deadlock | Blocked forever, in a cycle | Idle | A lock ordering |
| Livelock | Running, reacting to each other, making no progress | High | Randomised backoff, or one decider |
| Starvation | Running, but one of them never gets its turn | High | Fairness, or priority |
Livelock is the one most people have not met. Two threads each notice the other is waiting, each politely backs off and retries, and the timing makes them collide again, like two people stepping aside in a corridor, repeatedly.
Starvation is one thread losing every race. A lock with no fairness goes to whoever asks at the right moment, and a thread that always asks at the wrong moment can wait indefinitely while the others are served.
The decision rule for diagnosing one. Look at the processors first. Idle threads that are not moving mean a deadlock. Busy threads that are not finishing mean a livelock. Busy threads where most finish and one does not mean starvation.
← → move through sections and cards