Locking Strategies Explained: When to Use ReentrantLocks#

Why Concurrency Matters#

In modern applications, concurrency is a crucial concept. Multiple threads can run in parallel, increasing efficiency and performance on multi-core systems. This parallelism, however, introduces complexities, particularly related to shared data access. Without proper synchronization, multiple threads can read and write to the same data and cause:

1. Race conditions
2. Data inconsistency
3. Non-deterministic behavior

To avoid such pitfalls, we employ locking mechanisms and synchronization constructs that ensure proper ordering and mutual exclusion when accessing shared resources.

What Are Locks?#

Locks are tools for controlling access to shared resources. Think of a lock as a physical lock on a door: once someone enters a room and locks the door, nobody else can enter until the first person unlocks it. In Java:

• Intrinsic locks come from using the synchronized keyword.
• Explicit locks are instances of classes like ReentrantLock.

Both strategies ensure mutual exclusivity (only one thread holds the lock at a time), but each carries different properties, benefits, and trade-offs.

The Basics of synchronized#

In Java, the simplest way to enforce mutual exclusion is to use the synchronized keyword on a method or a block. For example:

1
public class Counter {
2
    private int count = 0;
3

4
    public synchronized void increment() {
5
        count++;
6
    }
7

8
    public synchronized int getCount() {
9
        return count;
10
    }
11
}

Here, both increment() and getCount() methods are protected by the same intrinsic lock that belongs to the Counter instance (also called the monitor lock). Synchronized blocks can also be used:

1
public void incrementCounter() {
2
    synchronized (this) {
3
        count++;
4
    }
5
}

In this context, this acts as the lock object. Intrinsic locks are reentrant by nature: if a thread already owns the lock, it can enter another synchronized block or method that locks on the same object without deadlocking itself.

Limitations of synchronized#

Although synchronized is simple and effective, it has certain limitations:

• You cannot attempt to acquire the lock without blocking. In other words, you don’t have methods like tryLock().
• Intrinsic locks do not easily provide fairness policies or interruptible lock acquisition.
• Signaling conditions (e.g., waiting and notifying or condition variables) is less flexible and generally managed with wait(), notify(), and notifyAll().

Overview#

A ReentrantLock is part of the java.util.concurrent.locks package. It provides an explicit locking mechanism that offers advanced operations not possible or not convenient with synchronized. Like intrinsic locks, ReentrantLock is also reentrant. A reentrant lock means that the thread that holds the lock can acquire it again without blocking, incrementing an internal hold count.

Motivations Behind ReentrantLock#

Developers often switch to ReentrantLock for these reasons:

1. Conditional Locking (Condition Variables) – You can create multiple Condition objects from a single lock, allowing flexible thread coordination.
2. Interruptible & Timed Lock Acquisition – Support for methods such as lockInterruptibly() and tryLock(timeout).
3. Fairness – You can create a ReentrantLock with a fairness policy to reduce thread starvation.
4. Performance Tuning – Under some high-contention scenarios, ReentrantLock may perform better than intrinsic locks.

Creating and Using a ReentrantLock#

Here is a simple example of using ReentrantLock:

1
import java.util.concurrent.locks.ReentrantLock;
2

3
public class SimpleLockExample {
4
    private final ReentrantLock lock = new ReentrantLock();
5
    private int count;
6

7
    public void increment() {
8
        lock.lock(); // Acquire the lock
9
        try {
10
            count++;
11
        } finally {
12
            lock.unlock(); // Release the lock in finally block
13
        }
14
    }
15

16
    public int getCount() {
17
        lock.lock();
18
        try {
19
            return count;
20
        } finally {
21
            lock.unlock();
22
        }
23
    }
24
}

The typical usage pattern is:

1. Call lock.lock() before accessing or modifying shared state.
2. Use a try/finally block to ensure lock.unlock() executes even if an exception occurs.

Failing to release the lock in a finally block can lead to a situation where the lock remains held if an exception is thrown, causing potential deadlocks.

Attempting to Acquire a Lock Without Blocking#

Unlike synchronized, ReentrantLock offers non-blocking attempts at lock acquisition via tryLock():

1
if (lock.tryLock()) {
2
    try {
3
        // Perform operations if lock is acquired
4
    } finally {
5
        lock.unlock();
6
    }
7
} else {
8
    // Lock not available, do something else
9
}

This is particularly useful when you want to avoid indefinite blocking and instead perform alternative logic if the lock is not immediately available.

1. Timed Lock Acquisition#

tryLock(long timeout, TimeUnit unit) allows you to wait for a specified time for the lock to become available:

1
import java.util.concurrent.TimeUnit;
2
import java.util.concurrent.locks.ReentrantLock;
3

4
public void safeOperation(ReentrantLock lock) {
5
    try {
6
        if (lock.tryLock(2, TimeUnit.SECONDS)) {
7
            try {
8
                // operate on shared resource
9
            } finally {
10
                lock.unlock();
11
            }
12
        } else {
13
            // Could not acquire the lock within 2 seconds
14
            // fallback or alternative logic
15
        }
16
    } catch (InterruptedException e) {
17
        // Handle interruption
18
        Thread.currentThread().interrupt();
19
    }
20
}

2. Interruptible Lock Acquisition#

Using lockInterruptibly() allows a thread to become interruptible while it is waiting for the lock. If the waiting thread is interrupted, it aborts the lock attempt:

1
public void performTask(ReentrantLock lock) throws InterruptedException {
2
    lock.lockInterruptibly();
3
    try {
4
        // do work
5
    } finally {
6
        lock.unlock();
7
    }
8
}

This is crucial when you need to cancel or stop a thread gracefully that may be waiting on a lock for resource access.

3. Fair vs. Non-Fair Locks#

A fair lock ensures that lock acquisition favors the thread that has been waiting the longest. Non-fair locks can sometimes offer higher throughput but potentially lead to thread starvation in extreme cases. You can specify fairness at construction:

1
ReentrantLock fairLock = new ReentrantLock(true);  // fair lock

4. Using Condition Objects#

ReentrantLock supports the creation of multiple Condition objects, each of which can manage its own wait set. This is more flexible than a single wait set provided by an intrinsic lock. For example:

1
private final ReentrantLock lock = new ReentrantLock();
2
private final Condition condition = lock.newCondition();
3

4
public void awaitCondition() throws InterruptedException {
5
    lock.lock();
6
    try {
7
        condition.await();  // Wait for signal
8
    } finally {
9
        lock.unlock();
10
    }
11
}
12

13
public void signalCondition() {
14
    lock.lock();
15
    try {
16
        condition.signal(); // Signal one waiting thread
17
    } finally {
18
        lock.unlock();
19
    }
20
}

You could create multiple condition objects to coordinate different state conditions within the same lock. This capability is often used in scenarios like producer-consumer, where various conditions need to be signaled independently.

Low Contention vs. High Contention#

• Low Contention: In most simple cases, synchronized is sufficient, and it tends to be optimized by the JVM’s just-in-time compiler. If you do not need advanced features (fairness, timed locks, multiple conditions), synchronized can be fast and straightforward.
• High Contention: When many threads frequently attempt to acquire the same lock, ReentrantLock can sometimes provide performance benefits due to more sophisticated queuing strategies and features like fairness.

Lock Overhead#

ReentrantLock comes with more explicit control and, therefore, a bit more overhead in some cases. For instance, you must manually lock and unlock, create Condition objects, and catch or handle InterruptedException exceptions. This overhead makes sense in more complex concurrency scenarios.

Benchmarking and Tuning#

Real concurrency performance must be measured. Your system’s behavior—due to hardware aspects, the nature of your tasks, thread counts, and data sizes—can shift which locking mechanism performs better. Profiling and stress testing will help you decide between synchronized and ReentrantLock for your use case.

1. Always Use try/finally for unlock()#

A common pitfall is forgetting to release the lock in a finally block. This can lead to deadlock or lock starvation. Always keep the following pattern:

1
lock.lock();
2
try {
3
    // critical section
4
} finally {
5
    lock.unlock();
6
}

2. Consider Using tryLock() for Non-Blocking Operations#

In some designs, you might want your thread to do something else if the lock is not immediately available. tryLock() avoids indefinite blocking and can improve responsiveness in event-driven or time-sensitive systems.

3. Beware of Fair Locks Overhead#

While fair locks help avoid starvation, they can sometimes reduce throughput. Synchronization tasks become more orderly but might queue threads more frequently. Always measure to confirm if fairness yields net benefits.

4. Avoid Holding Locks for Long Periods#

A best practice is to minimize the time a lock is held. Large or complex operations within a lock can drastically reduce concurrency. Whenever possible:

• Acquire lock.
• Perform the minimal changes.
• Release lock promptly.

5. Deadlock Avoidance#

Even reentrant locks can lead to deadlocks if multiple locks are acquired in different orders across threads. A consistent lock ordering strategy or higher-level concurrency constructs (like java.util.concurrent classes) can help mitigate these risks.

1. ReadWriteLock#

The ReadWriteLock interface (and its implementation ReentrantReadWriteLock) provides separate locks for reading and writing. This allows concurrency for multiple readers while still ensuring exclusive access for writers. If your use case involves many concurrent readers and fewer writers, a ReadWriteLock might significantly reduce lock contention.

2. StampedLock#

StampedLock, introduced in Java 8, offers even more advanced locking modes (e.g., optimistic reading). It can achieve higher throughput in many scenarios by allowing optimistic reads that only lock if a conflict is detected. However, it is more complex and requires careful usage.

3. Lock-Free and Concurrent Data Structures#

Where possible, you might reduce or eliminate the need for explicit locks by using built-in concurrent data structures:

• ConcurrentHashMap
• ConcurrentLinkedQueue
• LinkedBlockingQueue
• ConcurrentSkipListMap

These classes leverage sophisticated locking (often with lock-free or fine-grained lock designs) to handle concurrency internally.

4. Combining ReentrantLock with Executors and Pools#

When using ThreadPoolExecutor or other executor services, you can combine ReentrantLock usage within tasks. Keep in mind how locks in tasks interact with the pool’s behavior, especially regarding task cancellation or concurrency configuration.

5. Custom Synchronizers (AbstractQueuedSynchronizer - AQS)#

ReentrantLock itself is built on AbstractQueuedSynchronizer (AQS). In highly specialized scenarios, you can create your own lock or synchronization tool by extending AQS directly. This is advanced territory and is only recommended for developers comfortable with concurrency internals.