Synchronization vs Lock

java

concurrency-control

lock-acquisition

deadlocks

byAnton Shumikhin·Mar 8, 2025

When in need of simple mutual exclusion, choose synchronized. It's great for compact, no-frills code blocks where the locking strategy is straightforward:

synchronized (object) { /* "I have the key, nobody else allowed!" */ }

In contrast, leverage Lock from java.util.concurrent.locks when the situation screams for advanced controls such as timed waits, non-blocking attempts, or lock interruptions. It's your go-to for any scenario demanding finesse in lock handling:

Lock lock = new ReentrantLock();
if (lock.tryLock()) {
  try { /* "I might have the key, unless I got interrupted or ran out of patience!" */ } 
  finally { lock.unlock(); }
}

To summarize, Synchronization is your bread-and-butter, while Lock is your seasoning to taste.

A closer look at `Lock`

In need of specific controls during the lock acquisition process? The Lock interface extends flexibility beyond what synchronized can offer. Several advancements include:

Timed lock acquisition: You can attempt to acquire a lock and opt not to wait forever. // REWRITE
Interruptible lock acquisition: The thread can attempt to acquire lock but can be interrupted, staying responsive to cancellation requests.
Non-block-structured locking: Unlike synchronized blocks, Lock allows holding and release of a lock variably across scopes, enabling intricate locking patterns.

Embrace higher-level concurrency control

Put java.util.concurrent utilities to work

Aim higher: use CyclicBarrier or LinkedBlockingQueue from java.util.concurrent instead of Lock for most needs:

CyclicBarrier enables threads to congregate at a barrier point. Perfect for parallel computations or any situation needing simultaneous launch of threads.
LinkedBlockingQueue offers a thread-safe data management, while taking care of low-level synchronization for you.

Be cautious with wait() and notify()

wait() and notify(): not without reason they're famous for the sleepless nights they cause developers. While they have their unique use cases, the danger of deadlocks or missed signals often makes them more trouble than they're worth. Instead, use higher-level utilities like CountDownLatch, Semaphore, or Exchanger for better safety and code readability.

Why `ReentrantLock` could be your new best friend

ReentrantLock can outperform synchronized locks in terms of throughput in certain high concurrent scenarios thanks to an ability to charm multiple threads into acquiring the lock.

The newCondition() method in ReentrantLock brings multiple await/signal conditions to the table, creating a world of difference from the one wait-set per monitor approach of intrinsic locking.
Fancy trying out complex locking techniques like "hand-over-hand" or "chain locking"? Lock lets you do that, which is a level of flexibility far beyond the reach of synchronized methods or blocks.

Surefire strategies and best practices

Always unlock in a finally block

When using Lock, it's an absolute must to ensure that the lock is released in a finally block. It's one small step that significantly reduces potential deadlocks caused by wayward exceptions:

lock.lock();
try {
    // critical section code, "losing this key will keep me up all night!"
} finally {
    lock.unlock(); // "like good old Gandalf - you shall not pass (without the key)!"
}

Lean on queues and semaphores

Lock has its moments, but queues and semaphores often simplify matters when battling with concurrency. For instance, BlockingQueue is a dab hand at producer-consumer scenarios with its built-in mechanism, and Semaphore gracefully handles access to a resource pool.

The beauty of `synchronized`

While it may not be the new kid on the block, intrinsic locking through synchronized still holds its charm thanks to its simplicity and intuitiveness. It's quite common for Java developers to lean on this good old trusty friend before giving other locking mechanisms a go.

explain-codes / Java / Synchronization vs Lock

Linked

Avoid synchronized(this) in Java?



Java synchronized method lock on object, or method?



Illegalmonitorstateexception on wait() call



Is there a concurrent List in Java's JDK?



What's the difference between Thread start() and Runnable run()

