Reentrancy

For this lesson, we'll pick up right where synchronized and monitors left off. You know one thread at a time gets the monitor. Now the question is: what happens when the thread that's already inside asks for the same lock again? Interviewers love this one because the first answer ("it works") is easy, and the follow-ups ("so can you upgrade a read lock?", "is StampedLock reentrant?") quietly separate people who've memorised a word from people who know how the lock keeps score.

01Picture it first: one key for every door

Picture your house with a front door, a hallway door and a study door, all opened by the same key. You unlock the front door, walk to the hallway, and the same key opens that too. You don't wait outside your own hallway for yourself to come out. That would be silly.

Now add one rule. Your partner wants to come in, but only after you've left the house completely. So the house keeps a little tally card: "owner: you, doors passed: 3". Every door you walk through adds one. Every door you walk back out of subtracts one. When the tally hits 0, the key goes back on the hook and your partner can go in.

That's the whole idea of a reentrant lock, and here's the sketch.

In Java terms: the house is one object, the key is its lock, you're a thread, and the tally card is the hold count. The lock also remembers the owner thread. When a thread asks for the lock, the check is: "is it free? Then you're the owner, count 1. Is the owner you? Then count + 1 and walk in. Anyone else waits."

02Why Java needs this

You might be thinking: why would a thread ever ask for a lock it already holds? It happens all the time, usually without you noticing. Here are the three classic shapes.

class Inventory {
    private int stock = 10;

    public synchronized boolean reserve(int n) {     // takes the lock on "this"
        if (!hasStock(n)) return false;              // calls another synchronized method
        stock -= n;
        return true;
    }

    public synchronized boolean hasStock(int n) {    // same lock, same thread: walks in
        return stock >= n;
    }

    public synchronized int countDown(int n) {       // recursion: re-enters on every call
        return n == 0 ? 0 : 1 + countDown(n - 1);
    }
}

class AuditedInventory extends Inventory {
    @Override
    public synchronized boolean reserve(int n) {     // lock on "this"
        System.out.println("reserving " + n);
        return super.reserve(n);                     // the parent's synchronized method, same "this"
    }
}

AuditedInventory is the one that trips people up. The override and the parent method are both synchronized, and they lock the same object, because super.reserve runs on the same this. Java Concurrency in Practice uses this exact shape (a logging subclass calling super) to show why intrinsic locks must be reentrant: if they weren't, that super call would wait forever for a lock its own thread holds. No other thread involved. The program just stops. So reentrancy isn't a nice-to-have: it's what lets you build objects out of small synchronized methods that call each other.

03Under the hood: owner and hold count

ReentrantLock shows us the tally directly. getHoldCount() returns how many times the current thread holds it, and isHeldByCurrentThread() answers "am I the owner?". For synchronized there's no counter you can read, but Thread.holdsLock(obj) tells you whether the current thread owns that object's monitor.

import java.util.concurrent.locks.ReentrantLock;

public class HoldCount {
    static final ReentrantLock lock = new ReentrantLock();

    static void outer() {
        lock.lock();
        try {
            System.out.println("in outer: holdCount=" + lock.getHoldCount());
            inner();
            System.out.println("back in outer: holdCount=" + lock.getHoldCount());
        } finally {
            lock.unlock();
        }
    }

    static void inner() {
        lock.lock();                       // same thread, lock already held: no wait
        try {
            System.out.println("in inner: holdCount=" + lock.getHoldCount()
                    + ", mine=" + lock.isHeldByCurrentThread());
        } finally {
            lock.unlock();
        }
    }

    static synchronized void a() { System.out.println("a(): holdsLock(HoldCount.class)=" + Thread.holdsLock(HoldCount.class)); b(); }
    static synchronized void b() { System.out.println("b(): still got in, holdsLock=" + Thread.holdsLock(HoldCount.class)); }

    public static void main(String[] args) {
        System.out.println("before: holdCount=" + lock.getHoldCount() + ", mine=" + lock.isHeldByCurrentThread());
        outer();
        System.out.println("after: holdCount=" + lock.getHoldCount() + ", locked=" + lock.isLocked());
        a();
        System.out.println("after a(): holdsLock=" + Thread.holdsLock(HoldCount.class));
    }
}

Running java HoldCount.java on JDK 21 printed this, the same every time:

before: holdCount=0, mine=false
in outer: holdCount=1
in inner: holdCount=2, mine=true
back in outer: holdCount=1
after: holdCount=0, locked=false
a(): holdsLock(HoldCount.class)=true
b(): still got in, holdsLock=true
after a(): holdsLock=false

Here's that count, step by step:

Notice three things.

• The inner unlock() didn't free the lock. It took the count from 2 to 1. Another thread trying to get in at that moment would still wait.
• synchronized does the same thing, invisibly. b() got in while a() held the class lock. The JLS puts it plainly: a thread may lock a monitor more than once, and each unlock reverses one lock.
• static synchronized locks the Class object, which is why I passed HoldCount.class to holdsLock.

04Pair every lock() with exactly one unlock()

With synchronized, the compiler writes the release for you, on every exit path including exceptions. With ReentrantLock, you're the compiler. The rule is boring and absolute: one lock(), one unlock() in a finally, every time. That's why outer() and inner() above each have their own try/finally. What happens if you miss one?

import java.util.concurrent.TimeUnit;
import java.util.concurrent.locks.ReentrantLock;

public class ForgotUnlock {
    public static void main(String[] args) throws Exception {
        ReentrantLock lock = new ReentrantLock();
        Thread worker = new Thread(() -> {
            lock.lock();
            lock.lock();          // re-entered once
            lock.unlock();        // ...but only released once
        }, "worker");
        worker.start();
        worker.join();
        System.out.println("worker alive=" + worker.isAlive() + ", lock still locked=" + lock.isLocked());

        long t0 = System.nanoTime();
        boolean got = lock.tryLock(500, TimeUnit.MILLISECONDS);
        System.out.printf("main tryLock(500 ms) -> %s after %d ms%n", got, (System.nanoTime() - t0) / 1_000_000);

        try {
            lock.unlock();        // main never locked it
        } catch (IllegalMonitorStateException e) {
            System.out.println("main unlock() -> " + e.getClass().getSimpleName());
        }
    }
}

worker alive=false, lock still locked=true
main tryLock(500 ms) -> false after 502 ms
main unlock() -> IllegalMonitorStateException

This is the bit that surprises people. The worker is dead, and it still owns the lock. A ReentrantLock is not released when its owner thread dies. The count is stuck at 1 forever, and every other thread that calls plain lock() would wait forever. I used tryLock with a timeout so the demo finishes; in production you'd get a hung service and a thread dump full of WAITING (parking) on that lock.

And no, another thread can't "fix" it by calling unlock(). Only the owner may release. Anyone else gets IllegalMonitorStateException. The same exception appears if you call wait() or notify() without holding the monitor.

05Reentrancy is per thread, not per task

Reentrancy asks one question: is the caller the same thread as the owner? Not the same request, not the same user, not the same method chain. Same Thread object.

That matters as soon as work hops threads:

• Thread pools. If a task holding a lock submits a second task that needs the same lock, then waits for it with future.get(), the second task runs on a pool thread. It's a different thread, so it waits for the lock, while the first task waits for it. That's a deadlock, and reentrancy doesn't help.
• Async callbacks. A CompletableFuture callback may run on another thread. It does not inherit your holds.
• Hand-offs. You can't lock() on one thread and unlock() on another. ReentrantLock throws IllegalMonitorStateException. If you need a "lock" that any thread can release, you want a Semaphore, and that has its own catch, coming up next.

06Locks that are not reentrant

Not every lock-like thing in java.util.concurrent keeps an owner. A Semaphore only counts permits; it has no idea who took them. So new Semaphore(1), a popular "mutex", will happily block its own holder.

import java.util.concurrent.Semaphore;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.locks.StampedLock;

public class NotReentrant {
    public static void main(String[] args) throws Exception {
        Semaphore mutex = new Semaphore(1);
        mutex.acquire();
        System.out.println("semaphore: first acquire ok, permits=" + mutex.availablePermits());
        boolean again = mutex.tryAcquire(1, TimeUnit.SECONDS);   // same thread, second time
        System.out.println("semaphore: same thread tryAcquire(1 s) -> " + again);
        mutex.release();

        StampedLock sl = new StampedLock();
        long stamp = sl.writeLock();
        long second = sl.tryWriteLock(1, TimeUnit.SECONDS);       // 0 means "did not get it"
        System.out.println("stampedLock: same thread tryWriteLock(1 s) -> stamp " + second);
        sl.unlockWrite(stamp);
    }
}