Lock framework vs Thread synchronization in Java
Thread synchronization mechanism can be achieved using Lock framework, which is present in java.util.concurrent package. Lock framework works like synchronized blocks except locks can be more sophisticated than Java’s synchronized blocks. Locks allow more flexible structuring of synchronized code. This new approach was introduced in Java 5 to tackle the below-mentioned problem of synchronization.
Let’s look at an Vector class, which has many synchronized methods. When there are 100 synchronized methods in a class, only one thread can be executed of these 100 methods at any given point in time. Only one thread is allowed to access only one method at any given point of time using a synchronized block. This is a very expensive operation. Locks avoid this by allowing configuration of various locks for different purpose. One can have couple of methods synchronized under one lock and other methods under a different lock. This allows more concurrency and also increases overall performance.
Lock lock = new ReentrantLock(); lock.lock(); // Critical section lock.unlock();
A lock is acquired via the lock() method and released via the unlock() method. Invoking an unlock() without lock() will throw an exception. As already mentioned the Lock interface is present in java.util.concurrent.locks package and the ReentrantLock implements the Lock interface.
Note: The number of lock() calls should always be equal to the number of unlock() calls.
In the below code, the user has created one resource named “TestResource” which has two methods and two different locks for each respectively. There are two jobs named “DisplayJob” and “ReadJob”. The LockTest class creates 5 threads to accomplish ‘DisplayJob’ and 5 threads to accomplish ‘ReadJob’. All the 10 threads share single resource “TestResource”.
Thread 5: TestResource: reading a Job during 4 seconds :: Time – Wed Feb 27 15:49:53 UTC 2019
Thread 0: TestResource: display a Job during 6 seconds :: Time – Wed Feb 27 15:49:53 UTC 2019
Thread 5: The document has been read
Thread 6: TestResource: reading a Job during 4 seconds :: Time – Wed Feb 27 15:49:58 UTC 2019
In the above example, DisplayJob not required to wait for ReadJob threads to complete the task as ReadJob and Display job uses two different locks. This can not be possible with “synchronized”.
Differences are as follows:
|Across Methods||Yes, Locks can be implemented across the methods, you can invoke lock() in method1 and invoke unlock() in method2.||Not possible|
|try to acquire lock||yes, trylock(timeout) method is supported by Lock framework, which will get the lock on the resource if it is available, else it returns false and Thread wont get blocked.||Not possible with synchronized|
|Fair lock management||Yes, Fair lock management is available in case of lock framework. It hands over the lock to long waiting thread. Even in fairness mode set to true, if trylock is coded, it is served first.||Not possible with synchronized|
|List of waiting threads||Yes, List of waiting threads can be seen using Lock framework||Not possible with synchronized|
|Release of lock in exceptions|
unlock() cant be executed in this code if any exception being thrown from myMethod().
|Synchronized works clearly in this case. It releases the lock|
Attention reader! Don’t stop learning now. Get hold of all the important Java Foundation and Collections concepts with the Fundamentals of Java and Java Collections Course at a student-friendly price and become industry ready. To complete your preparation from learning a language to DS Algo and many more, please refer Complete Interview Preparation Course.