Explain lock vs synchronized.

In Java, both the `synchronized` keyword and the `Lock` interface (from `java.util.concurrent.locks` package) are mechanisms for controlling concurrent access to shared resources, preventing race conditions, and ensuring thread safety. While they serve the same fundamental purpose, they offer different levels of flexibility, control, and features.

1. `synchronized` Keyword

The synchronized keyword is a built-in language construct in Java. It can be applied to methods or blocks of code. When a thread enters a synchronized method or block, it automatically acquires a monitor lock (also known as intrinsic lock or monitor) associated with the object (for instance methods/blocks) or the class (for static methods/blocks). The lock is automatically released when the thread exits the synchronized block/method, either normally or due to an exception.

Key characteristics of synchronized:

• Automatic Lock Management: The JVM handles the acquisition and release of the lock, reducing the risk of forgotten unlock() calls.
• Reentrancy: A thread that already holds a lock can re-acquire it without deadlocking itself.
• Simplicity: Easy to use for basic synchronization needs.
• Limited Flexibility: Does not allow for trying to acquire a lock (non-blocking), interruptible lock acquisition, or setting a timeout for lock acquisition.
• Single Condition Variable: Only one implicit condition variable is available per monitor (managed via wait(), notify(), notifyAll()).

2. `Lock` Interface (java.util.concurrent.locks)

The Lock interface, introduced in Java 5 as part of the java.util.concurrent.locks package, provides a more flexible and robust alternative to synchronized. ReentrantLock is the most commonly used concrete implementation of Lock.

Unlike synchronized, Lock operations are explicit. You must call lock() to acquire the lock and unlock() to release it. This explicit management requires the unlock() call to be placed in a finally block to ensure the lock is always released, even if exceptions occur.

• Explicit Lock Management: Requires manual lock() and unlock() calls, typically within a try-finally block.
• Greater Flexibility: Offers advanced features not available with synchronized.
• Interruptible Lock Acquisition: lockInterruptibly() allows a thread waiting for a lock to be interrupted.
• Non-blocking Lock Acquisition: tryLock() attempts to acquire the lock without waiting indefinitely. It can also accept a timeout.
• Fairness Policy: ReentrantLock can be constructed with a fairness parameter (e.g., new ReentrantLock(true)) to grant access to the longest-waiting thread, though this can sometimes reduce throughput.
• Multiple Condition Variables: A single Lock instance can support multiple Condition objects, allowing for more fine-grained control over thread waiting and notification.

3. Key Differences and Use Cases

4. When to Use Which

• Use synchronized when: * You need simple, basic synchronization for method or code blocks. * You prefer automatic lock management, reducing the chance of forgetting to release the lock. * You don't require the advanced features like fair locking, non-blocking lock acquisition, or multiple condition variables.
• Use Lock when: * You need more advanced control over lock acquisition and release. * You require non-blocking lock acquisition (e.g., tryLock()). * You need interruptible lock acquisition (e.g., lockInterruptibly()). * You need multiple condition variables associated with a single lock. * You need a fair locking policy. * You are dealing with high-contention scenarios where Lock implementations might offer better performance or scalability due to their internal algorithms and ability to configure fairness.

In summary, synchronized is a robust and easy-to-use solution for many common concurrency problems. Lock provides a more powerful and flexible framework, offering features not available with synchronized, but it also introduces the responsibility of explicit lock management.