Java Synchronization: synchronized, wait/notify, and Lock Implementations

Java gives you multiple tools for synchronization, and most developers reach for synchronized without thinking twice. Sometimes that’s the right call. Sometimes you’re leaving performance on the table or creating deadlock risks you didn’t need to take. Let’s break down what each primitive actually does under the hood.

Introduction

Java offers multiple synchronization mechanisms — synchronized blocks, wait()/notify(), and the java.util.concurrent.locks hierarchy (ReentrantLock, ReadWriteLock, StampedLock) — and most developers reach for synchronized without considering the trade-offs. The choice matters more than it first appears: wrong synchronization primitives cause deadlocks, thread starvation, priority inversion, and performance bottlenecks that are notoriously difficult to reproduce in testing. Understanding what each primitive actually does to the JVM’s internal monitors and memory ordering guarantees is essential for writing correct high-concurrency code.

The core difference between synchronized and the explicit Lock implementations is that synchronized is non-interruptible, non-timeoutable, and locks arbitrarily, while ReentrantLock gives you tryLock() with timeout, interruptibility, and fair scheduling policies. ReadWriteLock and StampedLock go further by allowing concurrent read access — something synchronized cannot do. This post dissects each primitive, explains the monitor mechanics and happens-before guarantees behind them, and shows the concurrency patterns where each excels.

The synchronized Keyword

synchronized is the oldest synchronization mechanism in Java. It provides mutual exclusion on an object monitor and establishes happens-before relationships.

public class Counter {
    private long count = 0;

    // Instance method - locks on 'this'
    public synchronized void increment() {
        count++;
    }

    public synchronized long getCount() {
        return count;
    }

    // Static method - locks on the Class object
    public static synchronized void incrementStatic() {
        // ...
    }

    // Explicit block - more control over what you're locking
    public void decrement() {
        synchronized (this) {
            count--;
        }
    }
}

What synchronized Guarantees

1. Mutual exclusion: Only one thread can execute the synchronized block at a time
2. Visibility: Changes made before exiting a synchronized block are visible to the next thread entering a synchronized block on the same monitor
3. Atomicity: Compound actions within synchronized blocks are atomic

Limitations of synchronized

• No try-lock capability
• No fairness policy
• Cannot be interrupted while waiting
• Only works within the same JVM

wait() and notify()/notifyAll()

These are the classic Java coordination mechanisms. They require holding the monitor lock and are used for condition-based waiting.

public class BlockingQueue<E> {
    private final Queue<E> queue = new LinkedList<>();
    private final int capacity;

    public BlockingQueue(int capacity) {
        this.capacity = capacity;
    }

    public synchronized void put(E element) throws InterruptedException {
        while (queue.size() == capacity) {
            // Releases lock and waits until notified
            wait();
        }
        queue.add(element);
        // Wake up one waiting thread
        notifyAll(); // Always use notifyAll() unless you're certain only one thread cares
    }

    public synchronized E take() throws InterruptedException {
        while (queue.isEmpty()) {
            wait();
        }
        E element = queue.remove();
        notifyAll(); // Signal that space is now available
        return element;
    }
}

Why always notifyAll()?

Using notify() is risky. If multiple threads are waiting for different conditions, you might wake the wrong thread:

// RISKY - using notify()
synchronized (lock) {
    if (conditionA) {
        // Only one waiting thread cares about conditionA
        notify();
    }
    if (conditionB) {
        // But what if a thread waiting for conditionB gets woken?
    }
}

// SAFER - use notifyAll() when in doubt
synchronized (lock) {
    conditionA = true;
    conditionB = true;
    notifyAll(); // Everyone wakes up, each checks what they care about
}

The Spurious Wakeup Problem

Always use while() loops around wait(), not if():

// BAD - susceptible to spurious wakeups
if (queue.isEmpty()) {
    wait();
}

// GOOD - loop protects against spurious wakeups
while (queue.isEmpty()) {
    wait();
}

Spurious wakeups can occur on some platforms where the JVM wakes a thread without the usual notify() call.

Lock Implementations

The java.util.concurrent.locks package provides more flexible locking.

ReentrantLock

ReentrantLock provides the same mutual exclusion as synchronized but with additional features:

public class Counter {
    private final ReentrantLock lock = new ReentrantLock();
    private long count = 0;

    public void increment() {
        lock.lock();
        try {
            count++;
        } finally {
            lock.unlock(); // Always in finally - don't let exceptions leak the lock
        }
    }

    public long getCount() {
        lock.lock();
        try {
            return count;
        } finally {
            lock.unlock();
        }
    }

    // Try-lock with timeout - doesn't block forever
    public boolean tryIncrementWithTimeout(long timeout, TimeUnit unit)
            throws InterruptedException {
        boolean acquired = lock.tryLock(timeout, unit);
        if (acquired) {
            try {
                count++;
                return true;
            } finally {
                lock.unlock();
            }
        }
        return false;
    }
}

Fairness Policy

ReentrantLock has a fair constructor parameter:

// Fair lock - threads acquire in order of request
ReentrantLock fairLock = new ReentrantLock(true);

// Unfair lock (default) - better throughput, but starvation possible
ReentrantLock unfairLock = new ReentrantLock(false);

Fair locks hand the lock to the longest-waiting thread. Unfair locks let new threads “barge in” if the lock is available, which is faster but can starve waiting threads.

ReadWriteLock

Separate read and write locks let multiple readers proceed concurrently:

public class Cache<K, V> {
    private final Map<K, V> cache = new HashMap<>();
    private final ReadWriteLock rwLock = new ReentrantReadWriteLock();

    public V get(K key) {
        rwLock.readLock().lock();
        try {
            return cache.get(key);
        } finally {
            rwLock.readLock().unlock();
        }
    }

    public void put(K key, V value) {
        rwLock.writeLock().lock();
        try {
            cache.put(key, value);
        } finally {
            rwLock.writeLock().unlock();
        }
    }
}

Multiple threads can read simultaneously, but writes require exclusive access.

StampedLock

StampedLock improves on ReadWriteLock with optimistic reads:

public class Point {
    private double x, y;
    private final StampedLock sl = new StampedLock();

    public void move(double deltaX, double deltaY) {
        long stamp = sl.writeLock();
        try {
            x += deltaX;
            y += deltaY;
        } finally {
            sl.unlockWrite(stamp);
        }
    }

    public double distanceFromOrigin() {
        // Optimistic read - no lock acquired yet
        long stamp = sl.tryOptimisticRead();
        double dx = x;
        double dy = y;

        // Validate that the read was consistent
        if (!sl.validate(stamp)) {
            // Wasn't consistent - get a proper read lock
            stamp = sl.readLock();
            try {
                dx = x;
                dy = y;
            } finally {
                sl.unlockRead(stamp);
            }
        }
        return Math.sqrt(dx * dx + dy * dy);
    }
}

StampedLock can be faster when reads frequently succeed without contention.

Architecture Diagram

Monitor Lock

graph TD
    subgraph MonitorLock
        S1[synchronized] --> S2[Mutual Exclusion]
        S2 --> S3[Happens-Before Guarantee]
    end

Condition Coordination

graph TD
    subgraph ConditionCoordination
        W1[wait] --> W2[Release Monitor]
        W2 --> W3[Wait for notify]
        W3 --> W4[notify/notifyAll]
        W4 --> W5[Re-acquire Monitor]
    end

java.util.concurrent Locks

graph TD
    subgraph java.util.concurrent
        R1[ReentrantLock] --> R2[Try-lock Support]
        R2 --> R3[Timeout Support]
        R2 --> R4[Fairness Configurable]

        RW1[ReadWriteLock] --> RW2[Concurrent Reads]
        RW2 --> RW3[Exclusive Writes]

        ST1[StampedLock] --> ST2[Optimistic Reads]
        ST2 --> ST3[Write Lock]
        ST2 --> ST4[Read Lock]
    end

Production Failure Scenarios

Scenario 1: Lock Leak via Exception

// BROKEN - lock never released if doSomething throws
public void brokenMethod() {
    lock.lock();
    doSomething(); // If this throws, unlock() never called!
    lock.unlock();
}

// FIXED - always unlock in finally
public void fixedMethod() {
    lock.lock();
    try {
        doSomething();
    } finally {
        lock.unlock();
    }
}

Scenario 2: Deadlock via Nested Locks

// BROKEN - deadlock if otherMethod also locks in opposite order
public void methodA() {
    synchronized (lockA) {
        synchronized (lockB) {
            doSomething();
        }
    }
}

public void methodB() {
    synchronized (lockB) { // If thread1 holds lockB and thread2 holds lockA...
        synchronized (lockA) { // ...both wait forever
            doSomethingElse();
        }
    }
}

// FIX: Always acquire locks in the same order
public void methodA() {
    synchronized (lockA) {
        synchronized (lockB) { // Same order as methodB
            doSomething();
        }
    }
}

Scenario 3: Lost Wakeup with notify()

// BROKEN - signal can be missed
public void waitForSignal() {
    synchronized (lock) {
        while (!signalReceived) {
            lock.wait();
        }
        // Process signal
    }
}

public void sendSignal() {
    synchronized (lock) {
        signalReceived = true;
        lock.notify(); // If no thread is waiting, this is lost!
    }
}

// FIX: Always use notifyAll() or a queue of signals
public void sendSignal() {
    synchronized (lock) {
        signalReceived = true;
        lock.notifyAll(); // All waiting threads wake up and check the condition
    }
}

Trade-off Table

Implementation Snippets

Condition Variables with ReentrantLock

public class BoundedBuffer<T> {
    private final ReentrantLock lock = new ReentrantLock();
    private final Condition notFull = lock.newCondition();
    private final Condition notEmpty = lock.newCondition();
    private final Queue<T> queue = new LinkedList<>();
    private final int capacity;

    public void put(T item) throws InterruptedException {
        lock.lock();
        try {
            while (queue.size() == capacity) {
                notFull.await(); // Wait until space available
            }
            queue.add(item);
            notEmpty.signal(); // Signal that item available
        } finally {
            lock.unlock();
        }
    }

    public T take() throws InterruptedException {
        lock.lock();
        try {
            while (queue.isEmpty()) {
                notEmpty.await(); // Wait until item available
            }
            T item = queue.remove();
            notFull.signal(); // Signal that space available
            return item;
        } finally {
            lock.unlock();
        }
    }
}

Upgrading ReadLock to WriteLock

public class UpgradableExample {
    private final ReadWriteLock rwLock = new ReentrantReadWriteLock();
    private String data = "initial";

    // Read operation
    public String read() {
        rwLock.readLock().lock();
        try {
            return data;
        } finally {
            rwLock.readLock().unlock();
        }
    }

    // Write operation - must upgrade
    public void write(String newData) {
        rwLock.writeLock().lock();
        try {
            data = newData;
        } finally {
            rwLock.writeLock().unlock();
        }
    }

    // Careful upgrade (requires write lock first)
    public boolean updateIf(String expected, String newData) {
        rwLock.writeLock().lock();
        try {
            if (expected.equals(data)) {
                data = newData;
                return true;
            }
            return false;
        } finally {
            rwLock.writeLock().unlock();
        }
    }
}

Observability Checklist

• Are all lock acquisitions matched with try-finally?
• Is lock acquisition order consistent across all code paths?
• Are you using tryLock() with timeouts to prevent deadlocks?
• Do you use notifyAll() instead of notify() for condition variables?
• Are conditions checked in while() loops, not if() statements?
• Can you identify lock contention via thread dumps?
• Are you using fair locks only when necessary (they’re slower)?

Security Notes

Lock-related security issues:

• Denial of service: Lock contention can be exploited to slow down critical sections
• Lock ordering deadlocks: Can be triggered intentionally by attackers
• Timing attacks: Lock acquisition timing can leak information about operation patterns

When NOT to Use Synchronization Primitives

Synchronization primitives solve real problems, but they bring complexity that is not always necessary. If you are reaching for ReentrantLock when synchronized would work, you are writing more code for the same guarantee and more chances to forget to unlock when exceptions fire. ReadWriteLock sounds appealing for read-heavy workloads, but it adds bookkeeping overhead on every read — if writes are frequent or reads are cheap, the lock manager costs more than the concurrency you get.

Over-synchronization kills performance. When every method in a class acquires a lock, even reads serialize. The JVM’s bias and thin lock optimizations help under low contention, but once threads start competing, they queue up and your parallelism evaporates. If profiling shows high lock contention, consider splitting your data structure into separate synchronized components or switching to lock-free atomics. StampedLock and java.util.concurrent.atomic exist precisely for read-heavy scenarios where you want concurrency without the serialization of exclusive locks.

Do not use locks when a higher-level construct already handles your problem. BlockingQueue gives you producer-consumer coordination with built-in blocking — layering raw wait() and notify() on top of it creates bugs for no gain. If you find yourself thinking about monitor ownership, spurious wakeups, or lock ordering, check whether java.util.concurrent already solved it. See java.util.concurrent: Thread Pools, ForkJoinPool, Synchronizers for the higher-level tools that make raw synchronization a last resort.

Common Pitfalls / Anti-Patterns

1. Forgetting to unlock: Always use try-finally
2. Locking at wrong granularity: Too coarse wastes parallelism, too fine risks deadlock
3. Ignoring starvation: Unfair locks improve throughput but can starve threads
4. Calling wait() without holding the lock: Throws IllegalMonitorStateException
5. Not handling InterruptedException: Always restore interrupt status or propagate
6. Condition variables with synchronized: You can’t use wait/notify with Lock

Quick Recap Checklist

• synchronized provides mutual exclusion + happens-before
• wait()/notify() require holding the monitor lock
• Always use while() loops around wait() to handle spurious wakeups
• ReentrantLock offers tryLock(), timeout, and fairness options
• ReadWriteLock separates read and write access for better concurrency
• StampedLock adds optimistic read mode for read-heavy workloads
• Always release locks in finally blocks
• Lock ordering matters - same order everywhere prevents deadlock

Interview Questions

if (instance == null) {           // Check 1
    synchronized (lock) {
        if (instance == null) {     // Check 2
            instance = new Singleton();
        }
    }
}

Further Reading

• Java Concurrency in Practice — The classic textbook on Java concurrency
• Liveness and Performance: Avoiding Deadlock — Lock ordering patterns and deadlock prevention
• ReadWriteLock vs StampedLock —When to choose stamped over read-write locks
• Signalling Constructs in java.util.concurrent — How synchronizers work under the hood
• Avoiding Synchronization overhead —Reducing lock contention techniques

Conclusion

You now understand Java’s full suite of synchronization primitives from synchronized to StampedLock. Apply the right tool for your scenario: synchronized for simple mutual exclusion, ReentrantLock when you need try-lock or fairness, ReadWriteLock for read-heavy workloads, and StampedLock for optimistic reads. Always acquire locks in a consistent order to prevent deadlocks, and prefer higher-level constructs from java.util.concurrent wherever they fit. Continue with java.util.concurrent: Thread Pools, ForkJoinPool, Synchronizers to learn how to pool and coordinate threads at scale.