ReentrantLock vs synchronized in Java

Introduction

In Java, concurrency control is essential to ensure thread safety when multiple threads access shared resources. Java provides two primary mechanisms to achieve synchronization: synchronized blocks/methods and ReentrantLock from the java.util.concurrent.locks package. Both have their own use cases, advantages, and limitations.

In this article, we will explore the key differences between ReentrantLock and synchronized, their internal workings, and when to use them.

What is `synchronized` in Java?

The synchronized keyword in Java is a built-in mechanism that ensures that only one thread can execute a critical section at a time. It can be used in two ways:

1. Method-level synchronization

public class SynchronizedExample {
    public synchronized void method() {
        System.out.println("Thread-safe method execution");
    }
}

2. Block-level synchronization

public class SynchronizedBlockExample {
    private final Object lock = new Object();

    public void method() {
        synchronized (lock) {
            System.out.println("Thread-safe block execution");
        }
    }
}

Features of `synchronized`

Implicit locking and unlocking.
No need for manual lock handling.
Automatically releases the lock in case of exceptions.
Works at both method and block levels.
Thread-safe but lacks advanced control mechanisms.

What is `ReentrantLock`?

ReentrantLock is an explicit locking mechanism introduced in Java 5 as part of the java.util.concurrent.locks package. It provides greater flexibility than synchronized by allowing advanced control over the locking process.

Example of `ReentrantLock`

import java.util.concurrent.locks.ReentrantLock;

public class ReentrantLockExample {
    private final ReentrantLock lock = new ReentrantLock();

    public void method() {
        lock.lock();
        try {
            System.out.println("Executing thread-safe operation");
        } finally {
            lock.unlock();
        }
    }
}

Features of `ReentrantLock`

Explicit Locking and Unlocking: Requires manual lock() and unlock() calls.
Fairness Policy: Can provide fairness by ensuring the longest-waiting thread gets the lock first.
TryLock Mechanism: Supports non-blocking attempts to acquire a lock.
Interruptible Locks: Allows a thread to be interrupted while waiting for a lock.

Key Differences Between `ReentrantLock` and `synchronized`

Feature	`synchronized`	`ReentrantLock`
Lock Acquisition	Implicit and automatic	Explicit via `lock()`
Lock Release	Implicit	Requires manual `unlock()`
Exception Handling	Automatically releases lock	Must use `try-finally` to avoid deadlocks
Fairness	No fairness policy	Can be fair or non-fair
Performance	Better for lightweight locks	Useful for high-contention scenarios
Interruptibility	Cannot be interrupted while waiting	Supports `lockInterruptibly()`
Try Lock Mechanism	Not available	Supports `tryLock()` to avoid blocking
Condition Variables	Uses `wait()` and `notify()`	Uses `newCondition()` for advanced waiting

When to Use `synchronized` vs. `ReentrantLock`

Use `synchronized` when:

You need simple and reliable synchronization.
You don’t require explicit lock control.
Performance overhead is not an issue.
You prefer automatic unlocking in case of exceptions.

Use `ReentrantLock` when:

You need finer control over locking.
You require a fairness policy.
You need advanced features like tryLock(), lockInterruptibly(), or condition variables.
You want to handle lock acquisition manually.

Conclusion

Both synchronized and ReentrantLock are powerful tools for ensuring thread safety in Java applications. While synchronized is easier to use and suitable for most cases, ReentrantLock provides greater flexibility and control for complex concurrency scenarios. Choosing between them depends on your specific application needs.

Understanding their differences and use cases will help developers write more efficient and thread-safe Java programs.