Interfaces and classes providing a framework for locking and waiting for conditions that is distinct from built-in synchronization and monitors. The framework permits much greater flexibility in the use of locks and conditions, at the expense of more awkward syntax.

The {@link java.util.concurrent.locks.Lock} interface supports locking disciplines that differ in semantics (reentrant, fair, etc), and that can be used in non-block-structured contexts including hand-over-hand and lock reordering algorithms. The main implementation is {@link java.util.concurrent.locks.ReentrantLock}.

The {@link java.util.concurrent.locks.ReadWriteLock} interface similarly defines locks that may be shared among readers but are exclusive to writers. Only a single implementation, {@link java.util.concurrent.locks.ReentrantReadWriteLock}, is provided, since it covers most standard usage contexts. But programmers may create their own implementations to cover nonstandard requirements.

The {@link java.util.concurrent.locks.Condition} interface describes condition variables that may be associated with Locks. These are similar in usage to the implicit monitors accessed using `Object.wait`, but offer extended capabilities. In particular, multiple `Condition` objects may be associated with a single `Lock`. To avoid compatibility issues, the names of `Condition` methods are different than the corresponding `Object` versions.

The {@link java.util.concurrent.locks.AbstractQueuedSynchronizer} class serves as a useful superclass for defining locks and other synchronizers that rely on queuing blocked threads. The {@link java.util.concurrent.locks.AbstractQueuedLongSynchronizer} class provides the same functionality but extends support to 64 bits of synchronization state. Both extend class {@link java.util.concurrent.locks.AbstractOwnableSynchronizer}, a simple class that helps record the thread currently holding exclusive synchronization. The {@link java.util.concurrent.locks.LockSupport} class provides lower-level blocking and unblocking support that is useful for those developers implementing their own customized lock classes. @since 1.5