synchronized vs Lock in Java: When to Choose Each for Thread Safety

Overview of synchronized and Lock

In Java concurrent programming, thread safety is a perpetual topic. The two most common lock mechanisms, synchronized and Lock, are often debated. This article analyzes their principles, performance, flexibility, and selection strategies.

synchronized and Lock similarities

1. Common goal: ensure thread safety

Both synchronized and Lock aim to protect shared resources and prevent consistency problems.

2. Visibility guarantee

Both use memory barriers (happens‑before) to ensure visibility.

synchronized uses monitor lock.

Lock (e.g., ReentrantLock) uses explicit lock/unlock.

3. Reentrancy

Both support reentrant locks, allowing the same thread to acquire the lock multiple times.

Typical scenario: recursive calls or nested synchronized blocks.

Advantage: simplifies lock management and reduces deadlock risk.

synchronized vs Lock differences

1. Usage differences

Comparison (converted to list):

Syntax : synchronized is a keyword with automatic lock/unlock; Lock is an interface requiring explicit lock() and unlock().

Lock object : synchronized can lock methods or blocks (default lock is this); Lock requires explicit lock object such as ReentrantLock.

Exception handling : synchronized automatically releases lock even if an exception occurs; Lock requires manual release in a finally block.

2. Flexibility comparison

synchronized : lock order fixed, lock granularity single, cannot distinguish read/write locks.

Lock : lock order flexible, supports read/write locks (e.g., ReentrantReadWriteLock) allowing multiple concurrent reads.

3. Performance and implementation

synchronized : JVM built‑in monitor lock with bias, lightweight, and heavyweight locks; Java 6+ optimizations narrow performance gap with Lock.

Lock : built on AbstractQueuedSynchronizer, supports fair/unfair locks.

Performance comparison:

Java 5 and earlier: Lock significantly outperforms synchronized.

Java 6 and later: performance difference is negligible.

4. Interruption and timeout

synchronized does not support interruption or timeout; threads may wait indefinitely.

Lock provides lockInterruptibly() for interruptible waiting and tryLock() for immediate or timed attempts.

How to choose synchronized or Lock

1. Prefer built‑in utilities

Use java.util.concurrent utilities (e.g., ConcurrentHashMap, CountDownLatch) when possible; avoid locks if not needed.

2. When to use synchronized

Simple synchronization needs such as a single method or block.

When code simplicity and safety are priorities.

3. When to use Lock

Complex synchronization requiring try‑lock, timeout, or interruption.

High‑performance read/write scenarios using ReentrantReadWriteLock.

4. Selection summary

Simple sync → synchronized.

Complex sync (timeout, interruption) → Lock.

Read/write separation → ReentrantReadWriteLock.

Highest performance → java.util.concurrent utilities.

FAQ

Q1: What is a reentrant lock?

A reentrant lock allows the same thread to acquire the same lock multiple times.

public synchronized void outer() {
    inner(); // same thread calls inner()
}
public synchronized void inner() { ... }

Q2: Why does Lock require manual unlock?

synchronized is managed by the JVM, while Lock is an interface that requires explicit unlock(), typically placed in a finally block.

Q3: Why don’t read and write locks conflict?

ReentrantReadWriteLock separates read and write locks: multiple threads can hold the read lock concurrently, while the write lock is exclusive.

Practical cases

Case 1: High‑concurrency counter

Problem: counting accesses safely.

Solution: Use AtomicLong or LongAdder instead of explicit locks.

// Using LongAdder instead of a lock
LongAdder adder = new LongAdder();
adder.increment();

Case 2: Cache update and read

Problem: multiple threads read cache, exclusive write needed.

Solution: Use ReentrantReadWriteLock.

ReentrantReadWriteLock lock = new ReentrantReadWriteLock();
lock.readLock().lock(); // read operation
lock.writeLock().lock(); // write operation

Java 8+ concurrency features

StampedLock provides optimistic read lock to reduce contention.

LongAdder offers high‑throughput counting via segmented counters.

Summary and selection strategy

synchronized and Lock each have advantages; the choice depends on business scenario and performance requirements.

Simple scenarios: prefer synchronized.

Complex scenarios: choose Lock for flexible control.

Ultimate solution: leverage java.util.concurrent utilities to avoid manual lock management.

Practical recommendations

When using ReentrantLock, always release the lock in a finally block.

For read/write separation, prefer ReentrantReadWriteLock.

Avoid excessive lock contention by designing appropriate lock granularity, e.g., using ConcurrentHashMap.

On Java 8+, consider LongAdder or StampedLock for better performance.