Java synchronized: Methods vs Blocks
Fast recall
Quick revision
Core answer
Whether you understand synchronized as mutual exclusion, and that a block is finer-grained and lets you use a private lock, vs a method's coarse lock.
Using synchronized methods everywhere (coarse, can hurt throughput), or synchronizing on this/string literal (exposing the lock to callers).
synchronized = mutual exclusion; a method locks the whole method on this (coarse); a block locks a region on a chosen object (fine). Prefer blocks; use a private lock.
Interview-ready guide
Interview answer
synchronized is Java's built-in mechanism for mutual exclusion — only one thread at a time can execute a synchronized region, which prevents concurrent access to shared mutable state.
A synchronized method locks the entire method on the object, this, or on the Class for a static method, which is coarse and can hurt throughput when the method is long.
A synchronized block, synchronized of lock, locks only the critical region on a chosen object, which is finer-grained, and lets you use a dedicated private final lock object to avoid exposing the lock to callers who might lock on this and cause deadlock. Prefer synchronized blocks for finer control; synchronized methods are simpler but coarser.
The common mistakes are synchronizing on this or a string literal, which exposes the lock to callers and risks deadlock, using synchronized methods everywhere which holds the lock longer and hurts throughput, and forgetting that a static synchronized method locks on the Class, not this, which is a different lock.
Java synchronized: Methods vs Blocks
Direct Answer
synchronized is Java's built-in mechanism for mutual exclusion — only one thread at a time can execute a synchronized region, preventing concurrent access to shared mutable state. A synchronized method locks the whole method on the object (or the Class for static methods), which is coarse and can hurt throughput. A synchronized block (synchronized(lock){...}) locks only a critical region on a specified object, which is finer-grained and lets you use a dedicated private lock to avoid exposing the lock to callers. Prefer synchronized blocks for finer control; synchronized methods are simpler but coarser.
Code Example
// (1) SYNCHRONIZED METHOD: locks the whole method on `this`. Coarse.
public synchronized void increment() { count++; }
// Equivalent to: synchronized(this) { count++; }
// Problem: callers can also lock on `this` -> deadlock risk; long method
// holds the lock a long time.
// (2) SYNCHRONIZED BLOCK: locks only the critical region on a PRIVATE lock.
private final Object lock = new Object();
public void increment() {
// ... other non-critical work that DOESN'T need the lock ...
synchronized (lock) { // fine-grained, private lock
count++;
}
}
// Benefits: only the critical region is locked; the lock is private so
// callers can't lock on it -> safer; better throughput.
Common Mistakes & Pitfalls
- Synchronizing on this or a string literal — the lock is exposed to callers, risking deadlock.
- Using synchronized methods everywhere — coarse locks hold longer and hurt throughput.
- Forgetting that a static synchronized method locks on the Class, not this (different lock).
Check your understanding
Answer these without looking back at the article.
- What does synchronized do (mutual exclusion), and what does a method lock on?
- What's the difference between a synchronized method and a synchronized block (granularity)?
- Why use a private final lock object instead of synchronizing on this?
- What does a static synchronized method lock on (the Class, not this)?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.