Java Doc for ReentrantLock.java in  » 6.0-JDK-Core » Collections-Jar-Zip-Logging-regex » java » util » concurrent » locks » Java Source Code / Java DocumentationJava Source Code and Java Documentation

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. This can be checked using methods ReentrantLock.isHeldByCurrentThread , and ReentrantLock.getHoldCount .

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 ReentrantLock.tryLock() tryLock method does not honor the fairness setting. It will succeed if the lock is available even if other threads are waiting.

It is recommended practice to always immediately follow a call to lock with a try block, most typically in a before/after construction such as:

 class X {
 private final ReentrantLock lock = new ReentrantLock();
 // ...
 public void m() {
 lock.lock();  // block until condition holds
 try {
 // ... method body
 } finally {
 lock.unlock()
 }
 }
 }
 

In addition to implementing the Lock interface, this class defines methods isLocked and getLockQueueLength , as well as some associated protected access methods that may be useful for instrumentation and monitoring.

Serialization of this class behaves in the same way as built-in locks: a deserialized lock is in the unlocked state, regardless of its state when serialized.

This lock supports a maximum of 2147483647 recursive locks by the same thread. Attempts to exceed this limit result in Error throws from locking methods.
since:
   1.5
author:
   Doug Lea

A thread has a hold on a lock for each lock action that is not matched by an unlock action.

The hold count information is typically only used for testing and debugging purposes.

Analogous to the Thread.holdsLock method for built-in monitor locks, this method is typically used for debugging and testing.

Acquires the lock if it is not held by another thread and returns immediately with the value true , setting the lock hold count to one.

Acquires the lock if it is not held by another thread and returns immediately with the value true , setting the lock hold count to one.

If the current thread is the holder of this lock then the hold count is decremented.

A thread has a hold on a lock for each lock action that is not matched by an unlock action.

The hold count information is typically only used for testing and debugging purposes. For example, if a certain section of code should not be entered with the lock already held then we can assert that fact:

 class X {
 ReentrantLock lock = new ReentrantLock();
 // ...
 public void m() {
 assert lock.getHoldCount() == 0;
 lock.lock();
 try {
 // ... method body
 } finally {
 lock.unlock();
 }
 }
 }
 

Analogous to the Thread.holdsLock method for built-in monitor locks, this method is typically used for debugging and testing. For example, a method that should only be called while a lock is held can assert that this is the case:

 class X {
 ReentrantLock lock = new ReentrantLock();
 // ...
 public void m() {
 assert lock.isHeldByCurrentThread();
 // ... method body
 }
 }
 

It can also be used to ensure that a reentrant lock is used in a non-reentrant manner, for example:

 class X {
 ReentrantLock lock = new ReentrantLock();
 // ...
 public void m() {
 assert !lock.isHeldByCurrentThread();
 lock.lock();
 try {
 // ... method body
 } finally {
 lock.unlock();
 }
 }
 }
 

Acquires the lock if it is not held by another thread and returns immediately, setting the lock hold count to one.

If the current thread already holds the lock then the hold count is incremented by one and the method returns immediately.

If the lock is held by another thread then the current thread becomes disabled for thread scheduling purposes and lies dormant until the lock has been acquired, at which time the lock hold count is set to one.

Acquires the lock if it is not held by another thread and returns immediately, setting the lock hold count to one.

If the current thread already holds this lock then the hold count is incremented by one and the method returns immediately.

If the lock is held by another thread then the current thread becomes disabled for thread scheduling purposes and lies dormant until one of two things happens:

• The lock is acquired by the current thread; or
• Some other thread the current thread.

If the lock is acquired by the current thread then the lock hold count is set to one.

If the current thread:

• has its interrupted status set on entry to this method; or
• is while acquiring the lock,

In this implementation, as this method is an explicit interruption point, preference is given to responding to the interrupt over normal or reentrant acquisition of the lock.
throws:
  InterruptedException - if the current thread is interrupted

The returned Condition instance supports the same usages as do the Object monitor methods ( Object.wait wait , Object.notify notify , and Object.notifyAll notifyAll ) when used with the built-in monitor lock.

• If this lock is not held when any of the Condition or methods are called, then an IllegalMonitorStateException is thrown.
• When the condition methods are called the lock is released and, before they return, the lock is reacquired and the lock hold count restored to what it was when the method was called.
• If a thread is while waiting then the wait will terminate, an InterruptedException will be thrown, and the thread's interrupted status will be cleared.
• Waiting threads are signalled in FIFO order.
• The ordering of lock reacquisition for threads returning from waiting methods is the same as for threads initially acquiring the lock, which is in the default case not specified, but for fair locks favors those threads that have been waiting the longest.

Acquires the lock if it is not held by another thread and returns immediately with the value true , setting the lock hold count to one. Even when this lock has been set to use a fair ordering policy, a call to tryLock() will immediately acquire the lock if it is available, whether or not other threads are currently waiting for the lock. This "barging" behavior can be useful in certain circumstances, even though it breaks fairness. If you want to honor the fairness setting for this lock, then use ReentrantLock.tryLock(long,TimeUnit) tryLock(0, TimeUnit.SECONDS) which is almost equivalent (it also detects interruption).

If the current thread already holds this lock then the hold count is incremented by one and the method returns true .

If the lock is held by another thread then this method will return immediately with the value false . true if the lock was free and was acquired by thecurrent thread, or the lock was already held by the currentthread; and false otherwise

Acquires the lock if it is not held by another thread and returns immediately with the value true , setting the lock hold count to one. If this lock has been set to use a fair ordering policy then an available lock will not be acquired if any other threads are waiting for the lock. This is in contrast to the ReentrantLock.tryLock() method. If you want a timed tryLock that does permit barging on a fair lock then combine the timed and un-timed forms together:

if (lock.tryLock() || lock.tryLock(timeout, unit) ) { ... }
 

If the current thread already holds this lock then the hold count is incremented by one and the method returns true .

If the lock is held by another thread then the current thread becomes disabled for thread scheduling purposes and lies dormant until one of three things happens:

• The lock is acquired by the current thread; or
• Some other thread the current thread; or
• The specified waiting time elapses

If the lock is acquired then the value true is returned and the lock hold count is set to one.

If the current thread:

• has its interrupted status set on entry to this method; or
• is while acquiring the lock,

If the specified waiting time elapses then the value false is returned. If the time is less than or equal to zero, the method will not wait at all.

In this implementation, as this method is an explicit interruption point, preference is given to responding to the interrupt over normal or reentrant acquisition of the lock, and over reporting the elapse of the waiting time.
Parameters:
  timeout - the time to wait for the lock
Parameters:
  unit - the time unit of the timeout argument true if the lock was free and was acquired by thecurrent thread, or the lock was already held by the currentthread; and false if the waiting time elapsed beforethe lock could be acquired
throws:
  InterruptedException - if the current thread is interrupted
throws:
  NullPointerException - if the time unit is null

If the current thread is the holder of this lock then the hold count is decremented. If the hold count is now zero then the lock is released. If the current thread is not the holder of this lock then IllegalMonitorStateException is thrown.
throws:
  IllegalMonitorStateException - if the current thread does nothold this lock