What is lock elision (biased toward synchronization removal) via escape analysis, and when can the JIT safely drop a synchronized block?

## Why locks exist A **`synchronized` block** (or synchronized method) acquires a **monitor** — a per-object lock — so that only one thread at a time can execute the protected region against that object. Its entire purpose is to coordinate **multiple threads** sharing mutable state and to enforce memory-visibility guarantees between them. Acquiring and releasing a monitor has a cost: in the uncontended case it is cheap but not free (atomic operations and memory barriers); under contention it is much more expensive. ## The insight behind lock elision If a lock object can only ever be touched by **one** thread, then there is never another thread to coordinate with — the lock is guarding against contention that cannot happen. In that situation the `synchronized` is doing no useful work. **Lock elision** (also called **synchronization elision**) is the JIT optimization that detects this and removes the lock: it drops the monitor enter/exit instructions and keeps only the code inside the block. ## How escape analysis enables it The key question is: *can any other thread ever observe this lock object?* That is exactly what **escape analysis** answers. If the lock object is proven **NoEscape** — created in this method, never returned, never stored in a shared/static/instance field, never thrown, never handed to another thread — then by construction no other thread can reach it, so no other thread can ever acquire its monitor. The lock is therefore safe to elide. ## The canonical example ```java String build(String a, String b) { StringBuffer sb = new StringBuffer(); // StringBuffer methods are synchronized sb.append(a); sb.append(b); return sb.toString(); } ``` Every `append` and `toString` on `StringBuffer` is `synchronized`. But `sb` is a NoEscape local: no other thread can see it. The JIT elides all of those locks, so the synchronized `StringBuffer` runs as fast as the unsynchronized `StringBuilder` would here. (You should still prefer `StringBuilder` in source; the point is the JIT can rescue the synchronized case.) Similar things happen with a locally-confined `Vector` or a `Collections.synchronizedList` that never escapes. ## When it is safe — and when it is not **Safe to elide** when the lock object is NoEscape: single-thread visibility is guaranteed, so removing the lock changes no observable behavior. **Not safe (and not applied)** the moment the object could be shared: - it is returned, stored in a static or instance field, or otherwise published; - it is passed to a method the compiler cannot inline/analyze, so it must assume the object may escape; - it is reachable by another thread. In all these cases the compiler conservatively keeps the lock, because eliding a lock that a second thread might actually use would be a correctness bug (lost mutual exclusion). ## Relationship to other escape-analysis optimizations Lock elision is a sibling of scalar replacement and stack allocation — all three are unlocked by a NoEscape proof. They are independent: an object might be lock-elided but not scalar-replaced, or vice versa, depending on how it is used. Lock elision is governed by `-XX:+EliminateLocks` (default on), itself gated by `-XX:+DoEscapeAnalysis`. ## Don't confuse it with lock coarsening or biased locking - **Lock coarsening** merges several adjacent lock/unlock pairs on the same object into one larger critical section to reduce repeated enter/exit overhead — it does *not* require non-escape. - **Biased locking** (now removed/deprecated in modern JDKs) was a different runtime trick to make uncontended locks cheap by biasing a monitor toward one thread. Lock elision specifically *removes* the lock entirely based on proven single-thread visibility, which only escape analysis can establish.