how locks work inside

the picture

you know how synchronized has a reputation for being slow, and then you measure it and it's a few nanoseconds? both are true. it depends entirely on whether anyone else wanted the lock.

think of a meeting room. if nobody else is around, you flip the sign on the door to "occupied" and walk in: that's lightweight locking, one flip of a sign. if someone shows up while you're inside, flipping signs isn't enough anymore: now you need a receptionist with a waiting list and a way to tap the next person on the shoulder when the room frees up. that's the monitor. the receptionist is expensive, so they only get hired when there's actually a queue, and they go home again when the room has been quiet for a while.

the lock bits

the last two bits of every object's mark word say how it's locked. on jdk 25:

these aren't from a diagram, they're read off a live object with Unsafe.getLong(lock, 0):

unlocked:            ...00000001  (lock bits 01)
synchronized:        ...00000000  (lock bits 00)
nested synchronized: ...00000000  (lock bits 00)
released:            ...00000001  (lock bits 01)
other thread waits:  ...00000010  (lock bits 10)  mark=0x78a10c6a02
after notify+join:   ...00000010  (lock bits 10)
1.5 s later:         ...00000010  (lock bits 10)

one lock, two threads

step through every state a lock goes through on jdk 25, in order.

two details from that walk-through worth keeping. first, inflation is sticky: once a lock has a monitor, it keeps using it until the Monitor Deflation Thread (one of the 18 threads in an idle JVM) decides it's idle. the real object above was still inflated 1.5 seconds after everyone was done with it. second, wait() inflates on its own, contention or not, because only monitors have a wait set:

inflate: object=0x...7018409410, mark=0x...c687aa02, type='java.io.PrintStream' cause=Monitor Enter
inflate: object=0x...7018422c50, mark=0x...c687aca2, type='java.lang.Object' cause=Monitor Wait
inflate: object=0x...7018479730, mark=0x...c687ad82, type='java.lang.Thread' cause=Monitor Wait

that last one is t.join(), which is implemented with wait() on the Thread object. and since monitors are what wait/notify use, calling them without owning the lock fails fast:

void main() throws InterruptedException {
    Object lock = new Object();
    IO.println("holds lock? " + Thread.holdsLock(lock));
    synchronized (lock) {
        IO.println("holds lock? " + Thread.holdsLock(lock));
        lock.wait(10);   // fine: we own the monitor
    }
    try {
        lock.wait(10);   // not inside synchronized (lock)
    } catch (IllegalMonitorStateException e) {
        IO.println(e);
    }
}

holds lock? false
holds lock? true
java.lang.IllegalMonitorStateException: current thread is not owner

how we got here

HotSpot has rewritten its locking three times. the history explains a lot of advice you'll still find online.

you can check both ends of that story on jdk 25 yourself:

$ java -XX:+UseBiasedLocking -version
Unrecognized VM option 'UseBiasedLocking'
Error: Could not create the Java Virtual Machine.
 
$ java -XX:LockingMode=1 -version
OpenJDK 64-Bit Server VM warning: Option LockingMode was deprecated in version 24.0 and will likely be removed in a future release.

and java -XX:+PrintFlagsFinal -version shows LockingMode = 2: lightweight.