Understanding JVM Built‑in Locks: Biased, Lightweight, Heavyweight, Spin and Adaptive Spinning

The JVM performs many optimizations on built‑in locks to improve performance, and the lock inflation strategy is a key technique; understanding biased, lightweight, and heavyweight locks helps developers write and tune lock‑based concurrent programs.

Basic Issues Hidden Under Built‑in Locks

Built‑in locks are the most convenient synchronization tool in the JVM; adding the synchronized keyword to a method or block enables them. Over successive JVM versions, numerous optimizations have been added without requiring code changes.

Heavyweight Lock

Before JDK 1.6, a monitor lock directly mapped to an OS mutex, incurring high costs due to system calls, kernel‑user mode switches, and thread blocking, thus the term “heavyweight lock”.

Spin Lock

Spin locks reduce thread blocking by busy‑waiting (e.g., a short for‑loop) before deciding to block, which can improve performance when lock hold time is short and contention is low.

Typical spin‑lock algorithm:

Thread fails to acquire the lock and intends to block.

Instead of blocking, it spins for a short period.

During spinning it retries acquiring the lock.

If still unsuccessful after the spin, it finally blocks.

Drawbacks: on single‑core CPUs spinning wastes CPU cycles; on multi‑core systems with many threads it can cause unnecessary contention, and if contention is high the spin often fails, wasting CPU time.

Adaptive Spin Lock

Adaptive spinning adjusts the spin duration based on the previous spin outcome and the state of the lock owner. If a lock was recently acquired successfully and the owner is still running, the JVM may allow a longer spin (e.g., 100 loops); otherwise it shortens or skips spinning.

Drawbacks: if the default spin count is poorly chosen, the adaptive mechanism may not converge to an optimal value.

Lightweight Lock

Lightweight locks aim to avoid the heavy cost of heavyweight locks when there is little or no contention. They use CAS to replace part of the object’s Mark Word with a pointer to a thread‑local lock record; if CAS fails, the lock inflates to a heavyweight lock.

Drawbacks: when contention becomes moderate or high, lightweight locks quickly inflate, making the lightweight phase wasteful.

Biased Lock

Biased locks target the no‑contention scenario where a single thread repeatedly acquires the same lock. The lock records the owning thread once via CAS; subsequent acquisitions by the same thread are essentially free, but any competing thread forces inflation to a lightweight lock.

Drawbacks: once another thread competes, the biased lock inflates and cannot use spin‑lock optimization; the bias can be disabled with -XX:-UseBiasedLocking.

Summary of Lock Types

• Biased lock – no contention, only the first thread ever uses the lock. • Lightweight lock – no contention, multiple threads alternate use; short‑term contention allowed. • Heavyweight lock – actual contention, long lock‑hold time.

When contention is short, a spin lock can further optimize lightweight or heavyweight locks by reducing thread switches.

Lock Allocation and Inflation Process

The detailed allocation and inflation flow is illustrated in the following diagram (original image retained):

Key points:

When inflating to a heavyweight lock, the JVM currently blocks the thread directly; a spin‑before‑block approach could further reduce overhead.

CAS updates the owner only when expected==null and newValue==ownerThreadId, meaning only the first thread can acquire a biased lock successfully.

Locks can only inflate (biased → lightweight → heavyweight) and never shrink.

Simplified Version

A simplified flowchart from "Deep Understanding of the Java Virtual Machine" is shown below (original image retained):

Note: the simplified diagram mentions a “re‑bias” ( 重偏向) step, which is an advanced optimization not covered in this article.

Author: 猴子007 – Source: http://t.cn/EAvm0Xz