Synchronization

Both let only one thread run the protected code at a time. A synchronized method locks the whole method on the instance (or the class for static methods). A synchronized block locks only a chosen region and a lock object you pick, so it can be narrower.

The reader can keep using a stale cached copy of the flag because nothing forces it to refresh from main memory. The fix is to read the flag with the same synchronization (same lock, or make it volatile) so entering re-reads the latest value the writer flushed.

Hold the lock for as short a time as possible. Only the steps that actually touch shared data need the lock. Move slow or unrelated work — I/O, network calls, logging, big computations, object creation — outside the locked block so other threads wait less.

Every Java object has one built-in lock called its intrinsic lock or monitor. The synchronized keyword acquires that lock when a thread enters the region and releases it when the thread leaves, so only one thread at a time can hold it.

An instance synchronized method locks on that one object (this), so each instance has its own lock. A static synchronized method locks on the Class object, shared by all instances. The two locks are independent: a thread in a static synchronized method does not block a thread in an instance synchronized method.

synchronized does two jobs. It blocks other threads from the same locked code (mutual exclusion), and it makes memory visible: when a thread leaves the block its changes are pushed to main memory, and when another thread enters on the same lock it re-reads fresh values instead of stale cached ones.

A coarse-grained lock protects everything with one lock: simple, but all threads queue on it. Fine-grained locking uses many locks for different pieces of data, so unrelated threads don't block each other — but it's more complex and can cause deadlock. Lock striping splits a structure into segments, each with its own lock.

The lock object determines what is mutually exclusive. If you lock on something other code can also see and lock (like this or a String/Integer), outside code can interfere, cause unexpected contention, or deadlock. Locking on a private final object you fully control keeps the lock policy safe and encapsulated.

Reentrant means a thread that already holds a lock can acquire the same lock again without blocking itself. This lets a synchronized method safely call another synchronized method on the same object. Without it, a thread could deadlock against a lock it already owns.

Look for threads stuck waiting on the same lock. A thread dump shows BLOCKED threads and what monitor they're waiting for. Tools like Java Flight Recorder and async-profiler record lock-contention events, telling you which locks are hot and how long threads wait.

Because the visibility comes from taking and releasing the lock, not from the code inside. Entering the block forces a fresh read of shared memory and exiting forces your changes out to memory, so an empty synchronized block still publishes and refreshes data.

Both create the same acquire/release visibility: entering/reading refreshes from memory, exiting/writing flushes to memory. synchronized adds mutual exclusion, so it can make a multi-step operation atomic. volatile only gives visibility for a single field, with no locking and no atomicity for compound actions.

When a lock is a proven hotspot, you can avoid it instead of shrinking it. Options: immutable objects (nothing to lock), thread-confined data (each thread its own copy), read-mostly locks, atomic CAS classes like AtomicLong, or LongAdder for hot counters. They reduce or remove contention.

The happens-before edge only forms between unlock and lock of the same monitor. If writes use lock A and reads use lock B, there's no edge between them, so a reader can see stale or reordered data even though both sides 'use a lock'. Prevent it by binding each piece of shared state to one documented lock.