Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>A <a href="http://docs.oracle.com/javase/8/docs/api/java/util/concurrent/locks/ReentrantLock.html" rel="noreferrer">ReentrantLock</a> is <em>unstructured</em>, unlike <code>synchronized</code> constructs -- i.e. you don't need to use a block structure for locking and can even hold a lock across methods. An example:</p> <pre><code>private ReentrantLock lock; public void foo() { ... lock.lock(); ... } public void bar() { ... lock.unlock(); ... } </code></pre> <p>Such flow is impossible to represent via a single monitor in a <code>synchronized</code> construct.</p> <hr> <p>Aside from that, <code>ReentrantLock</code> supports <a href="http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/locks/ReentrantLock.html#tryLock()" rel="noreferrer">lock polling</a> and <a href="http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/locks/ReentrantLock.html#tryLock(long,%20java.util.concurrent.TimeUnit)" rel="noreferrer">interruptible lock waits that support time-out</a>. <code>ReentrantLock</code> also has support for <a href="http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/locks/ReentrantLock.html#ReentrantLock(boolean)" rel="noreferrer">configurable <em>fairness</em> policy</a>, allowing more flexible thread scheduling.</p> <blockquote> <p>The constructor for this class accepts an optional <em>fairness</em> parameter. When set <code>true</code>, 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 <code>tryLock</code> method does not honor the fairness setting. It will succeed if the lock is available even if other threads are waiting.</p> </blockquote> <hr> <p><code>ReentrantLock</code> <strong>may</strong> also be <a href="http://lycog.com/concurency/performance-reentrantlock-synchronized/" rel="noreferrer"><strong>more scalable</strong></a>, performing much better under higher contention. You can read more about this <a href="http://www.ibm.com/developerworks/java/library/j-jtp10264/" rel="noreferrer">here</a>.</p> <p>This claim has been contested, however; see the following comment:</p> <blockquote> <p>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. </p> </blockquote> <hr> <p>When should you use <code>ReentrantLock</code>s? According to that developerWorks article...</p> <blockquote> <p>The answer is pretty simple -- use it when you actually need something it provides that <code>synchronized</code> doesn't, like timed lock waits, interruptible lock waits, non-block-structured locks, multiple condition variables, or lock polling. <code>ReentrantLock</code> 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 <code>synchronized</code> 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 "the performance will be better" if you use <code>ReentrantLock</code>. 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.</p> </blockquote>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload