Explore Topics

Core Concepts

Locks

When working with multithreading in Java, ensuring thread safety is a crucial concern. While synchronization is often the go-to mechanism for managing thread access to shared resources, Java provides more advanced concurrency control mechanisms such as Locks, which offer greater flexibility and control over thread synchronization than traditional synchronization blocks.

A Lock is a Java interface that provides a more advanced mechanism than the synchronized keyword to control access to critical sections of code. It allows us to explicitly acquire and release locks on shared resources. Locks are part of the java.util.concurrent.locks package and give developers more control over the locking mechanism, allowing for features like trying to acquire a lock without blocking, or interrupting a thread while it’s waiting for a lock.

While the synchronized keyword is easy to use and sufficient for many cases, it comes with certain limitations:

No Timeout Mechanism: Once a thread enters a synchronized block, it holds the lock until it exits the block. There’s no way to set a timeout or interrupt the thread if it’s waiting for a long time.
No Lock Polling: With synchronized, you can’t check if a thread is already holding a lock or try to acquire a lock without blocking the thread.
No Reentrant Locking: In certain scenarios, you might need to acquire a lock multiple times in the same thread. synchronized doesn’t handle this well, but Lock implementations like ReentrantLock do.

Locks provide solutions to all the above listed issues and more.

Types of Locks in Java

Java’s java.util.concurrent.locks package provides several types of locks. The most commonly used ones include:

ReentrantLock

The ReentrantLock class is the most widely used implementation of the Lock interface. It’s called “reentrant” because it allows the thread that holds the lock to acquire the lock again without causing a deadlock. If a thread has already acquired a ReentrantLock, it can enter the lock again without blocking itself.

Lock lock = new ReentrantLock();

lock.lock(); // Acquiring the lock

try {

// Critical section

} finally {

lock.unlock(); // Releasing the lock

}

ReadWriteLock

The ReadWriteLock interface allows for a more granular lock. It provides separate locks for reading and writing. Multiple threads can acquire the read lock simultaneously, but only one thread can acquire the write lock at a time, and it excludes other threads from acquiring either the read or write lock.

ReadWriteLock rwLock = new ReentrantReadWriteLock();

Lock readLock = rwLock.readLock();

Lock writeLock = rwLock.writeLock();

StampedLock

The StampedLock provides a more sophisticated locking mechanism, allowing for optimistic locking as well. It provides three modes: writing, reading, and optimistic reading. Optimistic reading allows a thread to assume that no other thread will write to the resource and check later if it was interrupted.

StampedLock stampedLock = new StampedLock();

long stamp = stampedLock.tryOptimisticRead();

if (stampedLock.validate(stamp)) {

// Optimistic lock succeeded

}

Locking and Deadlock Prevention

While locks provide flexibility, improper usage can lead to deadlocks. A deadlock occurs when two or more threads are blocked forever, each waiting on the other to release the lock. To prevent deadlocks:

Always acquire locks in a consistent order.
Use timeouts when trying to acquire a lock to prevent waiting indefinitely.
Use tools like tryLock() to avoid blocking.

Here’s an example of using tryLock() to avoid blocking:

Lock lock = new ReentrantLock();

boolean isLockAcquired = lock.tryLock(100, TimeUnit.MILLISECONDS);

if (isLockAcquired) {

try {

// Critical section

} finally {

lock.unlock();

}

} else {

System.out.println("Could not acquire lock within the timeout period.");

}

Lock vs Synchronization

While both synchronized and Lock help in ensuring thread safety, here are some key differences:

Feature	Lock	Synchronized
Lock Acquisition	Explicit locking (`lock()` and `unlock()`)	Implicit via `synchronized` blocks
Timeout	Yes, supports timeout (`tryLock()`)	No
Interrupt Handling	Yes, supports interrupting waiting threads	No
Reentrancy	Supports reentrant locks (`ReentrantLock`)	Supports reentrancy
Multiple Locks	Can acquire multiple locks at once	No

Best Practices for Using Locks

Use Locks When We Need More Control: If we need more flexibility (like acquiring a lock with a timeout, or non-blocking locks), consider using ReentrantLock or ReadWriteLock.
Always Release Locks in a Finally Block: Just like with synchronized, always release locks in a finally block to ensure that the lock is released even if an exception occurs within the critical section.
Avoid Nested Locks: If we need to acquire multiple locks, always acquire them in the same order to avoid deadlocks.
Consider Using Higher-Level Concurrency Utilities: In some cases, high-level concurrency utilities like ExecutorService, CountDownLatch, or Semaphore may provide a better solution than manually managing locks.