Compare synchronized, ReentrantLock and ReadWriteLock. How do you decide which to use, and how do you avoid deadlock?

The full picture

Capability	synchronized	ReentrantLock	ReadWriteLock
Auto-release on exception	✅ always	❌ needs `finally`	❌ needs `finally`
Try / timed / interruptible acquire	❌	✅	✅
Fairness option	❌	✅ (throughput cost)	✅
Multiple wait-sets	one (`wait/notify`)	✅ many `Condition`s	—
Concurrent readers	❌	❌	✅ read lock shared

ReentrantLock done right

private final ReentrantLock lock = new ReentrantLock();

void transfer(Account from, Account to, long amount) throws TimeoutException {
    if (!lock.tryLock(2, TimeUnit.SECONDS))       // deadlock-resistant
        throw new TimeoutException("busy, try later");
    try {
        // critical section
    } finally {
        lock.unlock();                            // NEVER forget
    }
}

Deadlock needs four conditions (mutual exclusion, hold-and-wait, no preemption, circular wait); you only have to break one. In practice: acquire locks in one global order (e.g., lock accounts by ascending id), keep critical sections tiny, never call foreign/user code while holding a lock, and prefer tryLock with timeout at integration boundaries. Detect with jstack (it prints found deadlocks) or ThreadMXBean.findDeadlockedThreads().

💡 Interview tip:Interview gold: mention that in modern JVMs uncontended synchronized is nearly free, so the choice is about features, not raw speed — and that with virtual threads (Java 21+), pinning issues that once favoured ReentrantLock over synchronized were resolved in Java 24 (JEP 491).

Compare synchronized, ReentrantLock and ReadWriteLock. How do you decide which to use, and how do you avoid deadlock?

🎤 Say this first

The full picture

🔄 Likely follow-up questions