Chapter 10: Avoiding Liveness Hazards

Back> 

Unlike safety issues (which are about correctness), liveness hazards are about progress. Your program might be perfectly correct in theory, but under certain conditions, it may just stop moving forward.

Common types of liveness hazards include:

• Deadlock – two or more threads wait forever for each other to release locks.

• Livelock – threads keep reacting to each other but make no progress.

• Starvation – a thread waits indefinitely because others are always chosen instead.

This post walks through 5 Java examples that illustrate these problems and shows how to avoid them by applying the recommended strategies.

A program will be free of lock-ordering deadlocks if all threads acquire the locks they need in a fixed global order.

---

1. LeftRightDeadlock.java — Simple Lock-Ordering Deadlock

This example demonstrates a basic deadlock caused by inconsistent locking order.

// One thread locks left then right
lrdl.leftRight();
// Another thread locks right then left
lrdl.rightLeft();

When two threads acquire the same locks in opposite order, they can end up waiting on each other forever.

👉 Full code:
LeftRightDeadlock.java

The deadlock can be analyzed with thread dump (kill -3 or press the Ctrl+\ key on Unix or Ctrl + Break on Windows).

Thread dump Example

---

2. DynamicOrderDeadlock.java — Randomized Lock-Ordering Deadlock

This example shows how deadlocks can happen dynamically in systems like banking transfers, where the locking order depends on randomly selected accounts.

synchronized (fromAccount) {
    synchronized (toAccount) {
        ...
    }
}

If two threads select the same account pair in reverse order, they can deadlock.

👉 Full code:
DynamicOrderDeadlock.java

---

3. InduceLockOrder.java — Fixing Deadlock with Consistent Lock Ordering

To fix the problem in the previous example, we impose a global lock ordering by comparing the identity hash codes of the account objects.

if (fromHash < toHash) {
    synchronized (fromAcct) {
        synchronized (toAcct) { ... }
    }
}

This ensures that all threads acquire locks in the same order, eliminating circular wait and preventing deadlock.

👉 Full code:
InduceLockOrder.java

Invoking an alien method with lock held is asking for liveness trouble. The alien method might acquire other locks (risking deadlock) or block for an unexpectedly long time, stalling other threads that need the lock you hold.

---

4. CooperatingDeadlock.java — Mutual Calls Between Objects

In this example, we simulate a GPS system where a Taxi updates its location and notifies a Dispatcher when it becomes available. At the same time, the Dispatcher retrieves locations of all taxis to update a GUI.

// Taxi.setLocation holds taxi lock → calls Dispatcher.notifyAvailable
// Dispatcher.getImage holds dispatcher lock → calls Taxi.getLocation

These circular calls between synchronized methods can easily result in deadlock if both threads hold one lock and wait on the other.

👉 Full code:
CooperatingDeadlock.java

Strive to use open calls throughout your program. Programs that rely on open calls are far easier to analyze for deadlock-freedom than those that allow calls to alien methods with locks held.

---

5. CooperatingNoDeadlock.java — Using Open Calls to Avoid Deadlock

This improved version breaks the circular locking by using open calls. The idea is simple: don’t call another synchronized method while holding a lock.

public void setLocation(Point location) {
    boolean reached;
    synchronized (this) {
        this.location = location;
        reached = location.equals(destination);
    }
    if (reached) dispatcher.notifyAvailable(this); // open call!
}

Similarly, the dispatcher copies the taxi set inside a synchronized block and then iterates over it outside the lock.

👉 Full code:
CooperatingNoDeadlock.java

---

Conclusion

Deadlocks are notoriously difficult to reproduce and debug. Fortunately, there are reliable strategies to avoid them:

• Always acquire locks in a consistent order.

• Use open calls—release your lock before calling into other objects.

• Consider using tryLock or higher-level concurrent utilities.

• Avoid nested locking when possible.