java.lang.IllegalMonitorStateException: current thread is not owner

What this error actually means

The runtime refused a monitor operation that is only legal for the monitor’s owner. `Object.wait()`, `notify()`, and `notifyAll()` all require that the calling thread currently holds the monitor of the object they are called on; `ReentrantLock.unlock()` requires that the calling thread is the recorded owner. You called one without that ownership, and the check is unconditional and immediate.

This is not an arbitrary restriction. `wait()` must *release* the monitor and re-acquire it before returning, and you cannot release something you do not hold — so the operation is undefined without ownership. `notify()` is worse: it is meaningful only as a statement about state that the monitor protects, and signalling without the lock would mean announcing a condition change that no waiter can trust, since the change and the signal would not be atomic. The ownership requirement is what makes the wait/notify protocol sound.

Because the check is precise, the exception is unusually informative: it proves the calling thread holds no claim on that specific object at that moment. There are only a few ways to arrive there, and they are all structural rather than timing-dependent — which makes this one of the few concurrency exceptions that reproduces on the first run.

The most consequential variant is the one where the object identity is wrong rather than the lock discipline. `synchronized (this)` followed by `queue.wait()` acquires one monitor and waits on another. The code compiles, reads as correct, and fails every time, because the monitor of `this` and the monitor of `queue` are different objects.

How to diagnose it

assert Thread.holdsLock(items) : "not holding items monitor";
// for explicit locks:
log.info("heldByMe={} holdCount={}", lock.isHeldByCurrentThread(), lock.getHoldCount());

grep -n -A 8 "tryLock" src/main/java/**/*.java

grep -n -B 3 "IllegalMonitorStateException" app.log | head -30

The fix

Lock and wait on the same object, and make that pairing structural rather than remembered. The safest shape is a private `final Object lock = new Object();` used for both the `synchronized` block and the `wait`/`notify` calls, with the guarded state in the same class. If the two operations name the same final field, the mismatch cannot occur.

Keep the wait loop inside the `synchronized` block rather than factoring it into a helper. If you must extract it, make the helper `synchronized` on the same object, or pass the monitor explicitly and document the precondition — but inlining is better, because monitor ownership is a property of the whole call chain and helpers hide it.

For `tryLock`, tie the release to the acquire result: capture the boolean, and unlock only inside `if (acquired)`. Never release in an unconditional `finally` after a conditional acquire. The same rule prevents both this exception and the leaked-lock bug at the other extreme.

Ensure exactly one release per acquire on the same thread, including in reentrant paths. If a helper method may or may not lock, make it never lock and require the caller to hold the lock — an asymmetry between callers is how hold counts drift.

If the design genuinely needs a permit acquired on one thread and released on another, use `Semaphore`. Its permits are not owned by a thread, so cross-thread release is legal and intended, whereas with a lock it is a bug by construction.

Fix `finally` blocks so cleanup cannot replace the exception being propagated. Guard the release with an ownership check, or restructure so cleanup is only reached when it is valid — otherwise this exception will keep hiding the failure you actually need to see.

// Throws every time: holds this's monitor, waits on items's
synchronized void awaitItem() throws InterruptedException {
    while (items.isEmpty()) items.wait();   // IllegalMonitorStateException
}

// Throws from finally, masking the real exception
if (!lock.tryLock()) { /* fall through anyway */ }
try {
    doWork();
} finally {
    lock.unlock();                          // not the owner
}

// Correct: one final monitor, locked and waited on consistently
private final Object lock = new Object();
private final Deque<Task> items = new ArrayDeque<>();

Task take() throws InterruptedException {
    synchronized (lock) {
        while (items.isEmpty()) lock.wait();
        Task t = items.removeFirst();
        lock.notifyAll();
        return t;
    }
}

// Correct: release governed by the acquire result
boolean acquired = lock.tryLock(200, TimeUnit.MILLISECONDS);
if (!acquired) throw new BusyException();
try {
    doWork();
} finally {
    lock.unlock();
}

How to stop it coming back

• Declare the monitor as a `private final` field and never synchronise on `this` or on a public object — it makes the lock/wait pairing checkable and stops outside code from interfering
• Keep guarded state, its monitor, and its wait loop in one small class; ownership bugs are almost always the product of spreading them across layers
• Ban unconditional `unlock()` in `finally` after a conditional acquire; make the acquire result the only thing that authorises a release
• Use `Thread.holdsLock()` assertions on methods documented to require the lock, and run tests with assertions enabled
• Prefer `BlockingQueue` and the other `java.util.concurrent` synchronisers over hand-written wait/notify, which removes the ownership obligation entirely
• Treat any exception thrown from a `finally` as a defect, because it destroys the stack trace of the failure that was already propagating

FAQ

Related

Other errors engineers hit next to this one

• Idempotency key reused with a different request body
• Read-after-write returned stale data from a replica
• Replication lag: replica served stale data after a write
• FATAL ERROR: Reached heap limit Allocation failed
• Unhandled promise rejection crashes the process
• ECONNRESET: socket hang up on a reused connection
• MaxListenersExceededWarning: possible EventEmitter memory leak
• EADDRINUSE: address already in use