skip to content

What is the difference between a synchronized method and a synchronized block in Java, and when would you prefer one over the other?

level: juniorimportance: must knowfreq 78%

answer

  1. Method = whole body; block = chosen region
  2. Instance method locks this; static method locks the Class
  3. Block lets you pick the lock object
  4. Smaller critical section = less contention
  5. synchronized method ≡ synchronized(this){body}

basics

~20 s

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.

solid answer

~40 s

A synchronized method acquires an implicit lock for the whole method body: the instance (this) for an instance method, the Class object for a static method. A synchronized block lets you (a) protect a smaller region rather than the entire method, and (b) choose which object's lock to use via synchronized(lockObject). Prefer blocks when only part of the method touches shared state, to shorten the critical section and reduce contention, or when you need a dedicated private lock object instead of exposing this. Prefer methods for brevity when the entire body is the critical section. Both rely on the same intrinsic-lock (monitor) mechanism; the difference is scope and the choice of lock object, not the locking semantics.

go deeper

for a junior

Knows that synchronized lets one thread at a time run the code, and that a block can wrap a smaller region than the whole method.

for a middle

Can state precisely which object's monitor each form acquires (this vs Class) and explains the equivalence synchronized method ≡ synchronized(this){body}.

for a senior

Reasons about critical-section size and contention, and chooses block vs method deliberately to minimize the locked region and control the lock object.

for a principal

Frames the choice within a broader concurrency strategy — lock granularity, when to move to java.util.concurrent locks or lock-free structures, and the throughput/latency trade-offs of critical-section size.

## The problem When multiple threads run at once, they can interleave operations on shared data and corrupt it (a *race condition*). A *critical section* is a piece of code that must run for only one thread at a time. Java's `synchronized` keyword provides *mutual exclusion*: it guarantees that while one thread is inside a synchronized region guarded by a given lock, no other thread can enter any region guarded by that **same** lock. ## Intrinsic lock (monitor) Every Java object has exactly one built-in lock, called the *intrinsic lock* or *monitor*. You never create it; it exists for every object. `synchronized` acquires that lock on entry and releases it on exit (even if an exception is thrown). Only one thread can hold a given object's monitor at a time. ## Synchronized method ```java public synchronized void increment() { count++; } ``` This is shorthand. For an **instance** method, the lock acquired is the monitor of the receiver object, `this`. For a **static** method, the lock is the monitor of the `Class` object (e.g. `Counter.class`). The *entire method body* is the critical section. ## Synchronized block ```java public void increment() { doCheapStuff(); // not under the lock synchronized (this) { // critical section starts count++; } // lock released here } ``` A block lets you pick **two** things the method form fixes for you: 1. **Scope** — only the wrapped statements are protected, so threads spend less time holding the lock. 2. **Lock object** — the expression in `synchronized(expr)` is the object whose monitor is used. With a method you are forced to use `this` (or the Class). A block can use a private field, a different object, etc. ## Why narrower is better Holding a lock serializes threads. The longer and broader the locked region, the more threads queue up waiting — that is *contention*. Keeping critical sections small (only the lines that actually touch shared state) lets unrelated work run concurrently and improves throughput. So `synchronized` methods are convenient when the whole method is the critical section; blocks are preferred when only part of it is, or when you want to control the lock object. ## Equivalence A synchronized instance method is exactly equivalent to wrapping the whole body in `synchronized(this){...}`; a synchronized static method is equivalent to `synchronized(ClassName.class){...}`. The locking mechanism is identical — blocks just give you finer control.

  • What object does a synchronized static method lock on?
    The Class object for the declaring class (e.g. Counter.class), not any instance. This lock is independent of the per-instance this lock used by instance methods.
  • Is there any performance reason to prefer a block over a method?
    Yes — a block can shrink the critical section to only the lines that touch shared state, so threads hold the lock for less time and contention drops. A method always locks the entire body.

saying these in an interview costs you the question

  • Thinking a synchronized method locks the whole class or all instances — it locks only this (one instance) for instance methods.
  • Believing blocks and methods use different locking mechanisms — they use the same intrinsic lock.
  • Claiming you must always use blocks for performance — for a method whose entire body is critical, the method form is identical and cleaner.
  • Forgetting that a static synchronized method and an instance synchronized method use two different, independent locks.

context