synchronized Lock Upgrade: Biased, Lightweight, Heavyweight

synchronized in the modern JVM is three locks in a trench coat, upgrading based on contention. The state lives in the object's Mark Word — two bits for lock type plus payload. No contention path — biased locking. The first thread to enter a synchronized block CAS-writes its thread ID into the Mark Word. Subsequent entries by the same thread just check the thread ID and go — no CAS, virtually free. This was added to optimize the common case where a single thread dominantly accesses an object. Low-contention path — lightweight locking. When a second thread arrives, the biased lock has to be revoked (which requires stopping the biased thread at a safepoint, expensive). The lock becomes lightweight: each contending thread copies the Mark Word into its own stack as a "displaced header" and CAS-installs a pointer to its stack slot into the Mark Word. If CAS fails, the thread spins briefly (adaptive spinning) waiting. No OS-level park yet. Heavy-contention path — heavyweight locking. If spinning doesn't resolve quickly, the lightweight lock inflates to a full ObjectMonitor, an OS-backed mutex. Waiting threads call pthread_mutex_lock or its equivalent and are parked by the kernel. Expensive to enter/exit but scales to many waiters. The upgrade is one-way: no downgrade. Once inflated to heavyweight, the object stays heavyweight. JDK 15 deprecated biased locking by default because modern server apps — heavily multi-threaded, many short critical sections — tended to trigger biased-lock revocation so often that the supposed optimization was a pessimization. JDK 18 removed support entirely. In practice this means for new code on current JVMs, synchronized starts as lightweight and upgrades to heavyweight under contention. The performance gap between synchronized and ReentrantLock has narrowed so much that in most cases they're interchangeable; ReentrantLock still wins for tryLock, fair locks, and condition variables.