Java ~ Lock【源码】

2024-05-05 17:26
10人已看

前言

涉及内容

《Java ~ AQS ~ Condition【总结】》
《Java ~ Lock ~ ReentrantLock【总结】》
《Java ~ JVM ~ synchronized【总结】》

一 Lock（锁）接口源码及机制详解

接口

Lock（锁）接口定义了API层面上锁的概念。谈到锁，我们很容易能联想到关键字synchronized，其是Java在JVM层面上提供的用于在多线程环境下对共享资源进行同步访问的锁实现。因此自然而然地，我们会将锁接口与之进行对比。但实际上如果从功能的角度来说，将两者进行对比是不合适的。因为synchronized关键字是真正能够提供锁功能的实现，而锁接口仅仅是在API层面上对锁进行了定义，并无法提供实际的锁功能。因此两者在维度上是不平等的，如果真的要与synchronized关键字在具体功能上进行对比的话，使用锁接口的经典实现类ReentrantLock（可重入锁）会更合适，因为两者都是基于重入/排它特性的实现。但话虽如此，如果从结构的角度来看，将两者进行对比也并非完全不可行。例如相比synchronized关键字只加不解（其解锁由JVM自动实现，在手动的角度上只有加锁而没有解锁的说法）的结构而言，锁接口将加/解锁都定义为了人为操作。该结构定义使得锁接口实现类的使用变得稍显复杂，因为开发者需要人为保证“加锁后一定解锁，解锁前必须加锁”的行为准则不被破坏，因此锁接口实现类通常都需要搭配try-catch-finally使用。但相对地这也令锁接口实现类在使用上具备了更强的灵活性，使得多个锁域间的交互除了包含外还可以出现如下图般的交叉情况存在。

/**
 * {@code Lock} implementations provide more extensive locking operations than can be obtained using
 * {@code synchronized} methods and statements.  They allow more flexible structuring, may have quite different
 * properties, and may support multiple associated {@link Condition} objects.
 * 锁实现提供比使用synchronized修饰的方法和语句更广泛的锁操作。它们允许更灵活的结构，可能有完全不同的属性，以
 * 及可能支持多关联条件对象。
 * <p>
 * A lock is a tool for controlling access to a shared resource by multiple threads. Commonly, a lock provides exclusive
 * access to a shared resource: only one thread at a time can acquire the lock and all access to the shared resource
 * requires that the lock be acquired first. However, some locks may allow concurrent access to a shared resource, such
 * as the read lock of a {@link ReadWriteLock}.
 * 锁是一个控制通过多线程访问一个共享资源的工具。通常，一个锁提供排斥访问一个共享资源：一个时间只有一个线程可
 * 以获得锁并且访问所有的共享资源需要先获得锁。此外，某些锁可能允许并发访问共享资源，例如读写锁的读锁。
 * <p>
 * The use of {@code synchronized} methods or statements provides access to the implicit monitor lock associated with
 * every object, but forces all lock acquisition and release to occur in a block-structured way: when multiple locks are
 * acquired they must be released in the opposite order, and all locks must be released in the same lexical scope in
 * which they were acquired.
 * 同步方法或语句的使用可对任何对象关联的隐式监控锁进行访问，但它逼迫所有锁获取和释放都在一个阻塞结构的方法中
 * 发生：当获取多个锁时他们必须按相对的顺序释放（即按获取锁的相反顺序释放，FILO），并且所有锁必须在它们获取的
 * （同步块中）按相同的词汇范围（作用域）释放。
 * <p>
 * While the scoping mechanism for {@code synchronized} methods and statements makes it much easier to program with
 * monitor locks, and helps avoid many common programming errors involving locks, there are occasions where you need
 * to work with locks in a more flexible way. For example, some algorithms for traversing concurrently accessed data
 * structures require the use of &quot;hand-over-hand&quot; or &quot;chain locking&quot;: you acquire the lock of node
 * A, then node B, then release A and acquire C, then release B and acquire D and so on.  Implementations of the
 * {@code Lock} interface enable the use of such techniques by allowing a lock to be acquired and released in different
 * scopes, and allowing multiple locks to be acquired and released in any order.
 * 虽然同步方法和语句的范围机制令其对于监控锁问题变非常简单，并且有助于避免一些涉及锁的常规编程错误，但偶尔你
 * 也需要以一种更加灵活的方式使用锁来工作。例如：某些遍历算法并发访问数据结构需要稳步地使用，或者链式加锁：你
 * 获取了节点A的锁，然后节点B，然后释放A并获取C，然后释放B获取D等等。锁接口的实现开启了允许锁的获取和释放在
 * 不同的域，并且允许多个锁按任意顺序获取和释放的使用方式。
 * <p>
 * With this increased flexibility comes additional responsibility. The absence of block-structured locking removes the
 * automatic release of locks that occurs with {@code synchronized} methods and statements. In most cases, the
 * following idiom should be used:
 * 随着增长的灵活性带来的额外责任。缺乏阻塞结构的锁移除了同步方法和语句的锁自动释放。在大多数情况中，应该使用
 * 以下习语：
 * <pre> {@code
 * Lock l = ...;
 * l.lock();
 * try {
 *   // access the resource protected by this lock
 * } finally {
 *   l.unlock();
 * }}</pre>
 * <p>
 * When locking and unlocking occur in different scopes, care must be taken to ensure that all code that is executed while
 * the lock is held is protected by try-finally or try-catch to ensure that the lock is released when necessary.
 * 当锁和解锁在不同的域中发生，必须小心确保所有代码在被try-finally或try-catch保护以确保当必要时释放的锁被持有期间
 * 执行。
 * <p>
 * {@code Lock} implementations provide additional functionality over the use of {@code synchronized} methods and
 * statements by providing a non-blocking attempt to acquire a lock ({@link #tryLock()}), an attempt to acquire the lock
 * that can be interrupted ({@link #lockInterruptibly}, and an attempt to acquire the lock that can timeout (
 * {@link #tryLock(long, TimeUnit)}).
 * 锁实现提供额外的功能通过尝试无阻塞获取锁tryLock()，尝试可被中断的获取锁，尝试超时的获取锁tryLock(long, TimeUnit)
 * 来超过同步方法和语句。
 * <p>
 * A {@code Lock} class can also provide behavior and semantics that is quite different from that of the implicit monitor
 * lock, such as guaranteed ordering, non-reentrant usage, or deadlock detection. If an implementation provides such
 * specialized semantics then the implementation must document those semantics.
 * 一个锁类还可以提供与隐式监控锁截然不同的行为和语义，例如保证顺序，不可重入用法或者死锁检查。如果一个实现提
 * 供如此专业的语义那么该实现必须记录该语义（就是必须写文档）。
 * <p>
 * Note that {@code Lock} instances are just normal objects and can themselves be used as the target in a
 * {@code synchronized} statement. Acquiring the monitor lock of a {@code Lock} instance has no specified relationship
 * with invoking any of the {@link #lock} methods of that instance. It is recommended that to avoid confusion you never
 * use {@code Lock} instances in this way, except within their own implementation.
 * 注意：锁实例只是普通的对象，并且自身可在一个同步语句中用作目标（即作为同步对象）。获取锁实例的监控锁与调用
 * 该实例的任意锁方法没有特殊关联。建议是为了避免混淆你永远不要用这种方式（即将锁对象作为同步对象）使用锁对象，
 * 除非在它们拥有的实现中（即除非锁类使用synchronized作为底层的实现机制，因为通常我们都会将当前实例作为
 * synchronized的默认同步对象）。
 * <p>
 * Except where noted, passing a {@code null} value for any parameter will result in a {@link NullPointerException} being
 * thrown.
 * 除非另有说明：否则任意参数传递一个null至都会导致抛出空指针异常。
 * <h3>Memory Synchronization</h3>
 * 内存同步
 * <p>
 * All {@code Lock} implementations <em>must</em> enforce the same memory synchronization semantics as provided by
 * the built-in monitor lock, as described in
 * <a href="https://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.4"> The Java Language Specification
 * (17.4 Memory Model)</a>:
 * 所有锁实现必须强迫内置监控锁提供相同的内存同步语义，像The Java Language Specification(17.4 Memory Model)描述
 * 的那样。
 * <ul>
 * <li>A successful {@code lock} operation has the same memory synchronization effects as a successful <em>Lock</em>
 * action.
 * 一个成功的锁操作像从成功的锁活动一样有相同的内存同步效果。
 * <li>A successful {@code unlock} operation has the same memory synchronization effects as a successful
 * <em>Unlock</em> action.
 * </ul>
 * 一个成功的解锁操作像成功的解锁活动一样有着相同的内部同步效果。
 * <p>
 * Unsuccessful locking and unlocking operations, and reentrant locking/unlocking operations, do not require any memory
 * synchronization effects.
 * 不成功的锁和解锁操作，以及诚如锁/解锁操作，无法获得任意内存同步效果。
 * <h3>Implementation Considerations</h3>
 * 实现注意事项
 * <p>
 * The three forms of lock acquisition (interruptible, non-interruptible, and timed) may differ in their performance
 * characteristics, ordering guarantees, or other implementation qualities.  Further, the ability to interrupt the
 * <em>ongoing</em> acquisition of a lock may not be available in a given {@code Lock} class.  Consequently, an
 * implementation is not required to define exactly the same guarantees or semantics for all three forms of lock
 * acquisition, nor is it required to support interruption of an ongoing lock acquisition.  An implementation is required
 * to clearly document the semantics and guarantees provided by each of the locking methods. It must also obey the
 * interruption semantics as defined in this interface, to the extent that interruption of lock acquisition is supported:
 * which is either totally, or only on method entry.
 * 锁获取的三种形式（可中断，不可中断，超时）在它们的执行特性，顺序保证货其它实现特性上有所不同。进一步说：有能
 * 力在指定锁类中中断锁的持续获取。因此，实现不要求为锁获取的三种形式准确定义相同的保证或语义，也不要求支持一个
 * 持续锁获取的中断。一个实现被要求明确的记录由每个锁方法提供的语义和保证。它还必须像接口定义的那样遵守中断语义，
 * 要么全部，要么只在方法入口。
 * <p>
 * As interruption generally implies cancellation, and checks for interruption are often infrequent, an implementation can
 * favor responding to an interrupt over normal method return. This is true even if it can be shown that the interrupt
 * occurred after another action may have unblocked the thread. An implementation should document this behavior.
 * 中断通常意味着取消，并且检查中断往往是不频繁的，因此实现可以倾向于响应中断而不是普通的方法返回。这是正确的，
 * 即使它可能显示中断发生在另一个活动可能已经解除线程阻塞之后（作者你要不要看看你自己说在说些什么...）。一个实现
 * 应该记录这些行为。
 *
 * @author Doug Lea
 * @see ReentrantLock
 * @see Condition
 * @see ReadWriteLock
 * @since 1.5
 */
public interface Lock {
    ...
}

方法

void lock() —— 加锁 —— 令当前线程持有当前锁，如果当前锁允许被持有则直接持有并返回；否则等待至当前锁允许被持有为止。如果当前线程在等待加锁的过程中被中断不会抛出中断异常，但当前线程的中断状态可能会被保留，这具体看子类的实现。

    /**
     * Acquires the lock.
     * 获取锁。
     * <p>
     * If the lock is not available then the current thread becomes disabled for thread scheduling purposes and lies dormant
     * until the lock has been acquired.
     * 如果锁不可用那么当前线程处于调度目的变得无效并潜伏至锁被获取。
     * <p><b>Implementation Considerations</b>
     * 实现注意事项
     * <p>
     * A {@code Lock} implementation may be able to detect erroneous use of the lock, such as an invocation that would
     * cause deadlock, and may throw an (unchecked) exception in such circumstances. The circumstances and the exception
     * type must be documented by that {@code Lock} implementation.
     * 一个锁实现应该能够检测出锁的错误使用，如此一个导致死锁的调用在该情况中可以抛出一个（不受检查）异常。该情
     * 况及异常必须由锁实现记录。
     *
     * @Description: ----------------------------------------------------------- 名称 -----------------------------------------------------------
     * 加锁
     * @Description: ----------------------------------------------------------- 作用 -----------------------------------------------------------
     * 令当前线程持有当前锁，如果当前锁允许被持有则直接持有并返回；否则等待至当前锁允许被持有为止。如果当前线程
     * 在等待加锁的过程中被中断不会抛出中断异常，但当前线程的中断状态可能会被保留，这具体看子类的实现。
     * @Description: ----------------------------------------------------------- 逻辑 -----------------------------------------------------------
     * ~
     */
    void lock();

void lockInterruptibly() throws InterruptedException —— 加锁（中断） —— 令当前线程持有当前锁，如果当前锁允许被持有则直接持有并返回；否则等待至当前锁允许被持有为止。如果当前线程在调用该方法时已被中断或在等待加锁的过程中被中断会抛出中断异常，且当前线程的中断状态会被清除，前提是子类实现在设计上支持中断，否则该方法与lock()将没有差别。

    /**
     * Acquires the lock unless the current thread is {@linkplain Thread#interrupt interrupted}.
     * 获取锁除非当前线程被中断。
     * <p>
     * Acquires the lock if it is available and returns immediately.
     * 如果锁是可用的【即没有被其它线程独占持有】则获取锁并立即返回。
     * <p>
     * If the lock is not available then the current thread becomes disabled for thread scheduling purposes and lies
     * dormant until one of two things happens:
     * 如果锁不可用【即被其它线程独占持有】则当前线程处于线程调度的目的会变得无效并浅复制两种情况的其中一种发生：
     * <ul>
     * <li>The lock is acquired by the current thread; or
     * <li>Some other thread {@linkplain Thread#interrupt interrupts} the current thread, and interruption of lock
     * acquisition is supported.
     * </ul>
     * 锁被当前线程获取；或者某些其它线程中断当前线程，并且锁获取支持中断。
     * <p>
     * If the current thread:
     * 如果当前线程：
     * <ul>
     * <li>has its interrupted status set on entry to this method; or
     * <li>is {@linkplain Thread#interrupt interrupted} while acquiring the lock, and interruption of lock acquisition is
     * supported,
     * </ul>
     * then {@link InterruptedException} is thrown and the current thread's interrupted status is cleared.
     * 在进入方法时已被中断；或在获取锁期间被中断，并且锁获取支持终端，那么抛出中断异常并且当前线程的中断状态将
     * 被清理。
     * <p>
     * <b>Implementation Considerations</b>
     * 实现注意事项
     * <p>
     * The ability to interrupt a lock acquisition in some implementations may not be possible, and if possible may be an
     * expensive operation. The programmer should be aware that this may be the case. An implementation should
     * document when this is the case.
     * 中断锁获取的能力在某些实现中可能不可行【即无法实现】，并且如果可行也可能是昂贵的操作。程序员应该意识到这
     * 种可能的情况。当这种情况【发生时】实现应该记录下来。
     * <p>
     * An implementation can favor responding to an interrupt over normal method return.
     * 一个实现应该倾向于回应中断而不是普通的方法返回【即在实现中需要判断线程是否被中断，即使判断后只是抛出一个
     * 中断异常】。
     * <p>
     * A {@code Lock} implementation may be able to detect erroneous use of the lock, such as an invocation that would
     * cause deadlock, and may throw an (unchecked) exception in such circumstances.  The circumstances and the
     * exception type must be documented by that {@code Lock} implementation.
     * 一个锁实现可能能够检查锁的错误使用，例如会导致死锁，以及在如此情况中可能抛出（不受检查）异常的调用。该情
     * 况和异常类型必须由锁实现记录。
     *
     * @throws InterruptedException if the current thread is interrupted while acquiring the lock (and interruption of lock
     *                              acquisition is supported)
     *                              中断异常：如果当前线程在获取锁期间被中断（并且锁获取支持终端）
     * @Description: ----------------------------------------------------------- 名称 -----------------------------------------------------------
     * 加锁（中断）
     * @Description: ----------------------------------------------------------- 作用 -----------------------------------------------------------
     * 令当前线程持有当前锁，如果当前锁允许被持有则直接持有并返回；否则等待至当前锁允许被持有为止。如果当前线程
     * 在调用该方法时已被中断或在等待加锁的过程中被中断会抛出中断异常，且当前线程的中断状态会被清除，前提是子类
     * 实现在设计上支持中断，否则该方法与lock()将没有差别。
     * @Description: ----------------------------------------------------------- 逻辑 -----------------------------------------------------------
     * ~
     */
    void lockInterruptibly() throws InterruptedException;

boolean tryLock() —— 尝试加锁 —— 尝试令当前线程持有当前锁，如果当前锁未被其它线程持有或允许共享持有则直接持有并返回true；否则直接返回false。

    /**
     * Acquires the lock only if it is free at the time of invocation.
     * 只在调用时自由的情况下获取锁。
     * <p>
     * Acquires the lock if it is available and returns immediately with the value {@code true}. If the lock is not available
     * then this method will return immediately with the value {@code false}.
     * 如果可用则获取锁并立即返回true。如果锁不可用那么方法将立即返回false。
     * <p>
     * A typical usage idiom for this method would be:
     * 该方法的一个典型使用案例：
     * <pre> {@code
     * Lock lock = ...;
     * if (lock.tryLock()) {
     *   try {
     *     // manipulate protected state
     *   } finally {
     *     lock.unlock();
     *   }
     * } else {
     *   // perform alternative actions
     * }}</pre>
     * <p>
     * This usage ensures that the lock is unlocked if it was acquired, and doesn't try to unlock if the lock was not
     * acquired.
     * 该用法保证了锁如果被获取则一定会解锁，并且如果锁没有被获取则无需要尝试解锁。
     *
     * @return {@code true} if the lock was acquired and {@code false} otherwise
     * 如果锁被获取则返回true；否则返回false。
     * @Description: ----------------------------------------------------------- 名称 -----------------------------------------------------------
     * 尝试加锁
     * @Description: ----------------------------------------------------------- 作用 -----------------------------------------------------------
     * 尝试令当前线程持有当前锁，如果当前锁未被其它线程持有或允许共享持有则直接持有并返回true；否则直接返回false。
     * @Description: ----------------------------------------------------------- 逻辑 -----------------------------------------------------------
     * ~
     */
    boolean tryLock();

boolean tryLock(long time, TimeUnit unit) throws InterruptedException —— 尝试加锁 —— 尝试令当前线程持有当前锁，如果当前锁未被其它线程持有或允许共享持有则直接持有并返回true；否则在指定等待时间内等待至允许持有为止，超出指定等待时间则返回false。如果当前线程在调用该方法时已被中断或在等待加锁的过程中被中断会抛出中断异常，且当前线程的中断状态会被清除。前提是子类实现在设计上是支持中断的，否则该方法与lock()将没有差别。

    /**
     * Acquires the lock if it is free within the given waiting time and the current thread has not been
     * {@linkplain Thread#interrupt interrupted}.
     * 如果锁在指定等待时间内自由并且当前线程没有被中断获取锁。
     * <p>
     * If the lock is available this method returns immediately with the value {@code true}. If the lock is not available
     * then the current thread becomes disabled for thread scheduling purposes and lies dormant until one of three things
     * happens:
     * 如果锁可用则当前返回理解返回true。如果锁不可用则当前线程处于线程调度的目的变得无效并潜伏至三种情况之一发
     * 生：
     * <ul>
     * <li>The lock is acquired by the current thread; or
     * 锁被当前线程获取；
     * <li>Some other thread {@linkplain Thread#interrupt interrupts} the current thread, and interruption of lock
     * acquisition is supported; or
     * 某些线程中断当前线程，并且锁获取支持中断；
     * <li>The specified waiting time elapses
     * 指定等待时间消逝
     * </ul>
     *
     * <p>
     * If the lock is acquired then the value {@code true} is returned.
     * 如果锁被获取那么返回true。
     * <p>
     * If the current thread:
     * 如果当前线程：
     * <ul>
     * <li>has its interrupted status set on entry to this method; or
     * 在进入方法时已被中断；
     * <li>is {@linkplain Thread#interrupt interrupted} while acquiring the lock, and interruption of lock acquisition is
     * supported,
     * 在获取锁期间被中断并且锁获取支持终端，
     * </ul>
     * then {@link InterruptedException} is thrown and the current thread's
     * interrupted status is cleared.
     * 那么抛出中断异常并且当前线程的中断状态会被清除。
     * <p>
     * If the specified waiting time elapses then the value {@code false} is returned. If the time is less than or equal to
     * zero, the method will not wait at all.
     * 如果指定等待时间消逝那么返回false。如果时间小于或等于0那么方法将不会等待。
     * <p>
     * <b>Implementation Considerations</b>
     * 实现注意事项
     * The ability to interrupt a lock acquisition in some implementations may not be possible, and if possible may be an
     * expensive operation. The programmer should be aware that this may be the case. An implementation should
     * document when this is the case.
     * 中断锁获取的能力在某些实现中可能不可行【即无法实现】，并且如果可行也可能是昂贵的操作。程序员应该意识到这
     * 种可能的情况。当这种情况【发生时】实现应该记录下来。
     * <p>
     * An implementation can favor responding to an interrupt over normal method return, or reporting a timeout.
     * 实现应该倾向于回应一个异常而不是普通的方法但会，或者报告超时。
     * <p>
     * A {@code Lock} implementation may be able to detect erroneous use of the lock, such as an invocation that would
     * cause deadlock, and may throw an (unchecked) exception in such circumstances.  The circumstances and the
     * exception type must be documented by that {@code Lock} implementation.
     * 一个锁实现可能能够检查锁的错误使用，例如会导致死锁，以及在如此情况中可能抛出（不受检查）异常的调用。该情
     * 况和异常类型必须由锁实现记录。
     *
     * @param time the maximum time to wait for the lock  等待锁的最大时间
     * @param unit the time unit of the {@code time} argument 时间参数的单位
     * @return {@code true} if the lock was acquired and {@code false} if the waiting time elapsed before the lock was
     * acquired
     * 如果锁被获取则返回true；如果锁被获取之前等待时间消逝则返回false。
     * @throws InterruptedException if the current thread is interrupted while acquiring the lock (and interruption of lock
     *                              acquisition is supported)
     *                              中断异常：如果当前线程在获取锁期间被中断（并且锁获取支持中断）
     * @Description: ----------------------------------------------------------- 名称 -----------------------------------------------------------
     * 尝试加锁
     * @Description: ----------------------------------------------------------- 作用 -----------------------------------------------------------
     * 尝试令当前线程持有当前锁，如果当前锁未被其它线程持有或允许共享持有则直接持有并返回true；否则在指定等待时
     * 间内等待至允许持有为止，超出指定等待时间则返回false。如果当前线程在调用该方法时已被中断或在等待加锁的过程
     * 中被中断会抛出中断异常，且当前线程的中断状态会被清除。前提是子类实现在设计上是支持中断的，否则该方法与
     * lock()将没有差别。
     * @Description: ----------------------------------------------------------- 逻辑 -----------------------------------------------------------
     * ~
     */
    boolean tryLock(long time, TimeUnit unit) throws InterruptedException;

void unlock() —— 释放 —— 令当前线程解除对当前锁的持有或退出一层重入（如果子类实现支持重入）。如果在释放当前锁之前当前线程未能成功持有当前锁的话该方法将抛出不受检查异常。

    /**
     * Releases the lock.
     * 释放锁。
     * <p>
     * <b>Implementation Considerations</b>
     * 实现注意事项
     * <p>
     * A {@code Lock} implementation will usually impose restrictions on which thread can release a lock (typically only
     * the holder of the lock can release it) and may throw an (unchecked) exception if the restriction is violated. Any
     * restrictions and the exception type must be documented by that {@code Lock} implementation.
     * 一个锁实现通常将强迫限制线程可以释放锁的情况（典型地只有持有锁的持有者才可以释放它），并且如果限制被违背
     * 可能抛出（不受检查异常）。
     *
     * @Description: ----------------------------------------------------------- 名称 -----------------------------------------------------------
     * 释放
     * @Description: ----------------------------------------------------------- 作用 -----------------------------------------------------------
     * 令当前线程解除对当前锁的持有或退出一层重入（如果子类实现支持重入）。如果在释放当前锁之前当前线程未能成功
     * 持有当前锁的话该方法将抛出不受检查异常。
     * @Description: ----------------------------------------------------------- 逻辑 -----------------------------------------------------------
     * ~
     */
    void unlock();

Condition newCondition() —— 新条件 —— 创建一个基于当前锁的新条件，用于对持有当前锁期间一次性中途释放的线程进行管理。

    /**
     * Returns a new {@link Condition} instance that is bound to this {@code Lock} instance.
     * 返回一个绑定当前锁实例的新条件实例。
     * <p>
     * Before waiting on the condition the lock must be held by the current thread. A call to {@link Condition#await()} will
     * atomically release the lock before waiting and re-acquire the lock before the wait returns.
     * 在条件中等待前所必须被当前线程持有。调用await()方法将在等待前原子性地释放锁并在等待返回前重新获取锁。
     * <p>
     * <b>Implementation Considerations</b>
     * 实现注意事项
     * <p>
     * The exact operation of the {@link Condition} instance depends on the {@code Lock} implementation and must be
     * documented by that implementation.
     * 条件实例的准确操作依赖于锁实现并且必须由实现来记录。
     *
     * @return A new {@link Condition} instance for this {@code Lock} instance 一个当前锁对象的条件对象
     * @throws UnsupportedOperationException if this {@code Lock} implementation does not support conditions
     *                                       不支持操作异常：如果所实现不支持条件
     * @Description: ----------------------------------------------------------- 名称 -----------------------------------------------------------
     * 新条件
     * @Description: ----------------------------------------------------------- 作用 -----------------------------------------------------------
     * 创建一个基于当前锁的新条件，用于对持有当前锁期间一次性中途释放的线程进行管理。
     * @Description: ----------------------------------------------------------- 逻辑 -----------------------------------------------------------
     * ~
     */
    Condition newCondition();

个人技术分享

Java ~ Lock【源码】

前言

相关系列

涉及内容

一 Lock（锁）接口源码及机制详解

接口

方法