Unlocking Java Concurrency: How Biased, Lightweight, and Heavyweight Locks Work

Biased Lock

Biased lock was introduced in JDK6 as a lock optimization for cases where most lock acquisitions are uncontended and repeatedly performed by the same thread, reducing the cost of acquiring the lock.

Basic idea of biased lock:

When there is no competition, the lock state is recorded in the object header and the thread ID is stored in the lock flag.

Subsequent accesses only need to check whether the stored thread ID matches, avoiding extra lock and unlock operations and improving performance.

When a thread first accesses an object, it attempts a CAS operation to set the header's mark to biased lock and records its thread ID.

Later accesses by the same thread will directly enter the critical section if the thread ID matches, without additional locking.

Lightweight Lock

If another thread attempts to access the object while it is in biased‑lock state, the biased lock is revoked and the object transitions to a lightweight lock.

Lightweight lock is a JVM optimization technique designed to improve synchronization performance.

The advantage of a lightweight lock is that, in the absence of contention, it avoids thread context switches and blocking, thereby enhancing program performance.

However, when contention becomes significant, the lightweight optimization fails and the lock escalates to a heavyweight lock.

Heavyweight Lock

Heavyweight lock is a JVM mechanism introduced to guarantee data consistency in multithreaded programs.

Its advantage lies in ensuring data consistency and preventing data races and deadlocks.

In high‑concurrency scenarios, intense competition forces multiple threads to constantly contend for and block on the lock, leading to performance degradation.

Heavyweight lock relies on operating‑system support, which incurs higher overhead and performance cost, so it is used as the last resort.

Lock Summary

The above provides a concise overview of biased, lightweight, and heavyweight locks in Java.