Why use a ReentrantLock if one can use synchronized this

Question

I m trying to understand what makes the lock in concurrency so important if one can use synchronized  this   In the dummy code below  I can do either    synchronized the entire method or synchronize the vulnerable area  synchronized this        OR lock the vulnerable code area with a ReentrantLock    Code       private final ReentrantLock lock   new ReentrantLock         private static List lt Integer gt  ints       public Integer getResult String name                                           lock lock            try               if  ints size    3                    ints null                  return -9                                for  int x 0  x lt ints size    x                      System out println     name      x     ints size      values  gt  gt  gt  gt   ints get x                             finally               lock unlock                       return random

User · Answer

From oracle documentation page about ReentrantLock:

A reentrant mutual exclusion Lock with the same basic behaviour and semantics as the implicit monitor lock accessed using synchronized methods and statements, but with extended capabilities.

A ReentrantLock is owned by the thread last successfully locking, but not yet unlocking it. A thread invoking lock will return, successfully acquiring the lock, when the lock is not owned by another thread. The method will return immediately if the current thread already owns the lock.
The constructor for this class accepts an optional fairness parameter. When set true, under contention, locks favor granting access to the longest-waiting thread. Otherwise this lock does not guarantee any particular access order.

ReentrantLock key features as per this article

Ability to lock interruptibly.
Ability to timeout while waiting for lock.
Power to create fair lock.
API to get list of waiting thread for lock.
Flexibility to try for lock without blocking.

You can use ReentrantReadWriteLock.ReadLock, ReentrantReadWriteLock.WriteLock to further acquire control on granular locking on read and write operations.

Have a look at this article by Benjamen on usage of different type of ReentrantLocks

User · Answer

Lets assume this code is running in a thread   private static ReentrantLock lock   new ReentrantLock     void accessResource         lock lock        if  checkSomeCondition               accessResource              lock unlock        Because the thread owns the lock it will allow multiple calls to lock    so it re-enter the lock  This can be achieved with a reference count so it doesn t has to acquire lock again

User · Answer

One thing to keep in mind is    The name  ReentrantLock  gives out a wrong message about other locking mechanism that they are not re-entrant  This is not true  Lock acquired via  synchronized  is also re-entrant in Java    Key difference is that  synchronized  uses intrinsic lock   one that every Object has   while Lock API doesn t

User · Answer

I think the wait notify notifyAll methods don t belong on the Object class as it pollutes all objects with methods that are rarely used   They make much more sense on a dedicated Lock class   So from this point of view  perhaps it s better to use a tool that is explicitly designed for the job at hand - ie ReentrantLock

User · Answer

You can use reentrant locks with a fairness policy  or timeout to avoid thread starvation   You can apply a  thread fairness policy    it will help avoid a thread waiting forever to get to your resources    private final ReentrantLock lock   new ReentrantLock true     the param true turns on the fairness policy     The  fairness policy  picks the next runnable thread to execute  It is based on priority  time since last run  blah blah  also  Synchronize can block indefinitely if it cant escape the block  Reentrantlock can have timeout set

User · Answer

ReentrantReadWriteLock is a specialized lock whereas synchronized this  is a general purpose lock  They are similar but not quite the same   You are right in that you could use synchronized this  instead of ReentrantReadWriteLock but the opposite is not always true   If you d like to better understand what makes ReentrantReadWriteLock special look up some information about producer-consumer thread synchronization   In general you can remember that whole-method synchronization and general purpose synchronization  using the synchronized keyword  can be used in most applications without thinking too much about the semantics of the synchronization but if you need to squeeze performance out of your code you may need to explore other more fine-grained  or special-purpose synchronization mechanisms   By the way  using synchronized this  - and in general locking using a public class instance - can be problematic because it opens up your code to potential dead-locks because somebody else not knowingly might try to lock against your object somewhere else in the program

User · Answer

Synchronized locks does not offer any mechanism of waiting queue in which after the execution of one thread any thread running in parallel can acquire the lock  Due to which the thread which is there in the system and running for a longer period of time never gets chance to access the shared resource thus leading to starvation   Reentrant locks are very much flexible and has a fairness policy in which if a thread is waiting for a longer time and after the completion of the currently executing thread we can make sure that the longer waiting thread gets the chance of accessing the shared resource hereby decreasing the throughput of the system and making it more time consuming

User · Answer

A ReentrantLock is unstructured  unlike synchronized constructs -- i e   you don t need to use a block structure for locking and can even hold a lock across methods  An example  private ReentrantLock lock   public void foo             lock lock             public void bar             lock unlock             Such flow is impossible to represent via a single monitor in a synchronized construct   Aside from that  ReentrantLock supports lock polling and interruptible lock waits that support time-out  ReentrantLock also has support for configurable fairness policy  allowing more flexible thread scheduling   The constructor for this class accepts an optional fairness parameter  When set true  under contention  locks favor granting access to the longest-waiting thread  Otherwise this lock does not guarantee any particular access order  Programs using fair locks accessed by many threads may display lower overall throughput  i e   are slower  often much slower  than those using the default setting  but have smaller variances in times to obtain locks and guarantee lack of starvation  Note however  that fairness of locks does not guarantee fairness of thread scheduling  Thus  one of many threads using a fair lock may obtain it multiple times in succession while other active threads are not progressing and not currently holding the lock  Also note that the untimed tryLock method does not honor the fairness setting  It will succeed if the lock is available even if other threads are waiting    ReentrantLock may also be more scalable  performing much better under higher contention  You can read more about this here  This claim has been contested  however  see the following comment   In the reentrant lock test  a new lock is created each time  thus there is no exclusive locking and the resulting data is invalid  Also  the IBM link offers no source code for the underlying benchmark so its impossible to characterize whether the test was even conducted correctly    When should you use ReentrantLocks  According to that developerWorks article     The answer is pretty simple -- use it when you actually need something it provides that synchronized doesn t  like timed lock waits  interruptible lock waits  non-block-structured locks  multiple condition variables  or lock polling  ReentrantLock also has scalability benefits  and you should use it if you actually have a situation that exhibits high contention  but remember that the vast majority of synchronized blocks hardly ever exhibit any contention  let alone high contention  I would advise developing with synchronization until synchronization has proven to be inadequate  rather than simply assuming  quot the performance will be better quot  if you use ReentrantLock  Remember  these are advanced tools for advanced users   And truly advanced users tend to prefer the simplest tools they can find until they re convinced the simple tools are inadequate   As always  make it right first  and then worry about whether or not you have to make it faster    One final aspect that s gonna become more relevant in the near future has to do with Java 15 and Project Loom  In the  new  world of virtual threads  the underlying scheduler would be able to work much better with ReentrantLock than it s able to do with synchronized  that s true at least in the initial Java 15 release but may be optimized later   In the current Loom implementation  a virtual thread can be pinned in two situations  when there is a native frame on the stack     when Java code calls into native code  JNI  that then calls back into Java     and when inside a synchronized block or method  In those cases  blocking the virtual thread will block the physical thread that carries it  Once the native call completes or the monitor released  the synchronized block method is exited  the thread is unpinned    If you have a common I O operation guarded by a synchronized  replace the monitor with a ReentrantLock to let your application benefit fully from Loom   s scalability boost even before we fix pinning by monitors  or  better yet  use the higher-performance StampedLock if you can

[java] Why use a ReentrantLock if one can use synchronized(this)?

Examples related to java

Examples related to multithreading

Examples related to concurrency

Examples related to synchronize

Examples related to reentrantlock