Java Lock源码总结 Lock源码注释翻译和解析中英文对照版
2021/9/28 20:12:29
本文主要是介绍Java Lock源码总结 Lock源码注释翻译和解析中英文对照版,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!
版本
JDK8(JDK1.8)
Lock接口源码重点
1.Lock实现提供了比使用synchronized方法和语句更广泛的锁操作。它们允许更灵活的结构,可能具有完全不同的属性,并且可能支持多个关联的Condition对象。
2.随着灵活性的提高,还需要承担更多的责任。由于没有synchronized块结构锁,因此方法和语句不会自动释放锁。在大多数情况下,应使用以下模式:
Lock l = ...; l.lock(); try { // 访问受此锁保护的资源 } finally { l.unlock(); }
3.Lock接口定义了三种比较特别获取锁的方式
- 获取非阻塞锁(即没获取到锁,线程也不阻塞等待)
- 获取可被中断的锁
- 获取可超时的锁
4.Lock 接口定义的部分方法
方法名 | 作用 |
---|---|
void lock() | 获得锁,没成功则使用该方法的线程阻塞,直到获取锁 |
void lockInterruptibly() | 获得锁,没成功则使用该方法的线程阻塞,直到获取锁或其他线程对当前线程调用了Thread.interrupt()使该线程进入中断状态(可中断锁) |
boolean tryLock() | 尝试获得锁,成功则获得锁并返回true,否则返回false(非阻塞锁) |
boolean tryLock(long time, TimeUnit unit) | 在给定时间内尝试获得锁,成功则获得锁并返回true,超时返回false(超时锁) |
void unlock() | 释放锁,通常只有获得锁的线程可以释放锁 |
Lock接口源码
package java.util.concurrent.locks; import java.util.concurrent.TimeUnit; /** * {@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方法和语句更广泛的锁操作。 * 它们允许更灵活的结构,可能具有完全不同的属性,并且可能支持多个关联的Condition对象。 * * * * <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}. * 锁是一种工具,用于控制多个线程对共享资源的访问。 * 通常,锁提供对共享资源的独占访问:一次只有一个线程可以获取锁, * 所有对共享资源的访问都要求首先获取锁。但是,某些锁可能允许并发访问共享资源, * 例如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. * synchronized方法或语句的使用提供了对与每个对象关联的隐式监视器锁的访问, * 但强制所有锁的获取和释放以块结构的方式进行: * 当获取多个锁时,必须以相反的顺序释放它们, * 所有锁都必须在获取它们的相同词法范围内释放。 * * * * * <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 * "hand-over-hand" or "chain locking": 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. * 虽然synchronized方法和语句的作用域机制使使用监视器锁编程变得更加容易, * 并有助于避免许多涉及锁的常见编程错误,但在某些情况下, * 您需要以更灵活的方式使用锁。例如,一些遍历并发访问的数据结构的算法需要使用 * “移交”或“链条锁紧”,获取节点A的锁,然后获取节点B, * 然后释放A并获取C,然后释放B并获取D,依此类推。 * lock接口的实现允许在不同的范围内获取和释放锁, * 并允许以任何顺序获取和释放多个锁,从而允许使用此类技术。 * * * * * * * <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: * 随着灵活性的提高,还需要承担更多的责任。由于没有synchronized块结构锁, * 因此方法和语句不会自动释放锁。 * 在大多数情况下,应使用以下习语: * * <pre> {@code * Lock l = ...; * l.lock(); * try { * // access the resource protected by this lock 访问受此锁保护的资源 * } finally { * l.unlock(); * }}</pre> * * 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)}). * Lock实现通过提供 * 获取锁的非阻塞尝试tryLock()、 * 获取可被中断的锁的尝试lockInterruptibly() * 获取可超时的锁的尝试tryLock(long, TimeUnit), * 在使用synchronized方法和语句的基础上提供了额外的功能 * * * * * <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. * Lock类还可以提供与隐式监视器锁截然不同的行为和语义, * 例如保证顺序、不可重入使用或死锁检测。 * 如果一个实现提供了这种专门的语义,那么该实现必须记录这些语义。 * * * * * <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. * 请注意,Lock实例只是普通对象,它们本身可以用作synchronized语句中的目标。 * 获取lock实例的监视器锁与调用该实例的任何lock方法没有指定的关系。 * 为了避免混淆,建议不要以这种方式使用Lock实例,除非在它们自己的实现中使用。 * * * * * <p>Except where noted, passing a {@code null} value for any * parameter will result in a {@link NullPointerException} being * thrown. * 除非另有说明,否则为任何参数传递null值将导致抛出NullPointerException * * * <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/se8/html/jls-17.html#jls-17.4"> * Chapter 17 of * 所有lock实现必须强制执行内置监视器锁提供的相同内存同步语义,如中所述 * * * * * <cite>The Java™ Language Specification</cite></a>: * <ul> * <li>A successful {@code lock} operation has the same memory * synchronization effects as a successful <em>Lock</em> action. * 成功的lock操作与成功的锁定操作具有相同的内存同步效果。 * * <li>A successful {@code unlock} operation has the same * memory synchronization effects as a successful <em>Unlock</em> action. * 成功的unlock操作与成功的解锁操作具有相同的内存同步效果。 * * </ul> * * 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. * 锁获取的三种形式(可中断、不可中断和定时)在性能特征、顺序保证 * 或其他实现质量方面可能有所不同。 * 此外,在给定的lock类中,中断正在进行的锁获取的能力可能不可用。 * 因此,实现不需要为所有三种形式的锁获取定义完全相同的保证或语义, * 也不需要支持正在进行的锁获取的中断。 * 需要一个实现来清楚地记录每个锁定方法提供的语义和保证。 * 它还必须遵守此接口中定义的中断语义, * 以支持锁获取的中断:要么完全中断,要么仅在方法条目上中断。 * * * * * * * <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. * 由于中断通常意味着取消,并且对中断的检查通常不经常发生, * 所以实现可能更倾向于响应中断而不是正常的方法返回。 * 即使可以显示中断发生在另一个操作解除线程阻塞后,这也是正确的。实现应该记录这种行为。 * * * @see ReentrantLock * @see Condition * @see ReadWriteLock * * @since 1.5 * @author Doug Lea */ public interface 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. * Lock实现可能能够检测锁的错误使用,例如可能导致死锁的调用, * 并且在这种情况下可能抛出(未经检查的)异常。 * Lock实现必须记录环境和异常类型。 * * */ void lock(); /** * Acquires the lock unless the current thread is * {@linkplain Thread#interrupt interrupted}. * 获取锁,除非当前线程调用了thread.interrupt()呈现中断状态 * * * <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. * 其他一些线程对当前线程调用thread.interrupt,并且支持中断锁获取。 * </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, * 获取锁时已经调用过Thread.interrupt()设置成中断,支持中断获取锁, * * * </ul> * then {@link InterruptedException} is thrown and the current thread's * interrupted status is cleared. * 然后抛出InterruptedException,并清除当前线程的中断状态。 * * * <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. * Lock实现可能能够检测锁的错误使用,例如可能导致死锁的调用, * 并且在这种情况下可能抛出(未经检查的)异常。Lock实现必须记录环境和异常类型。 * * * * @throws InterruptedException if the current thread is * interrupted while acquiring the lock (and interruption * of lock acquisition is supported) * 如果当前线程在获取锁时中断(并且支持中断锁获取) * */ void lockInterruptibly() throws InterruptedException; /** * 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> * * 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 */ boolean tryLock(); /** * Acquires the lock if it is free within the given waiting time and the * current thread has not been {@linkplain Thread#interrupt interrupted}. * 如果锁在给定的等待时间内空闲,并且当前线程未被thread.interrupt()中断,则获取锁。 * * * <p>If the lock is available this method returns immediately * with the value {@code true}. * 如果锁可用,此方法立即返回值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: * 如果锁不可用,则出于线程调度目的,当前线程将被禁用, * 并处于休眠状态,直到发生以下三种情况之一: * * * <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 * 其他一些线程thread.interrupt()当前线程,支持中断锁获取;或 * * * <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, * 获取锁时已经使用Thread.interrupt()设置为中断状态,支持中断获取锁, * * </ul> * then {@link InterruptedException} is thrown and the current thread's * interrupted status is cleared. * 然后抛出InterruptedException,并清除当前线程的中断状态。 * * * * <p>If the specified waiting time elapses then the value {@code false} * is returned. * 如果指定的等待时间已过,则返回false。 * * If the time is * less than or equal to zero, the method will not wait at all. * 如果时间小于或等于零,则该方法根本不会等待。 * * <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, 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. * Lock实现可能能够检测锁的错误使用,例如可能导致死锁的调用, * 并且在这种情况下可能抛出(未经检查的)异常。 * Lock实现必须记录环境和异常类型。 * * * @param time the maximum time to wait for the lock 等待锁定的最长时间 * @param unit the time unit of the {@code time} argument * time参数的时间单位 * @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) * 如果当前线程在获取锁时中断(并且支持中断锁获取) */ boolean tryLock(long time, TimeUnit unit) throws InterruptedException; /** * 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. * Lock实现通常会对哪个线程可以释放锁施加限制(通常只有锁的持有者可以释放锁), * 如果违反限制,则可能抛出(未检查的)异常。 * Lock实现必须记录任何限制和异常类型。 */ void unlock(); /** * Returns a new {@link Condition} instance that is bound to this * {@code Lock} instance. * 返回绑定到此Lock实例的新Condition实例。 * * <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. * 对Condition.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. * Condition实例的确切操作取决于Lock实现,并且必须由该实现记录。 * * @return A new {@link Condition} instance for this {@code Lock} instance * 此Lock实例的新Condition实例 * @throws UnsupportedOperationException if this {@code Lock} * implementation does not support conditions * 如果此Lock实现不支持条件 * */ Condition newCondition(); }
这篇关于Java Lock源码总结 Lock源码注释翻译和解析中英文对照版的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!
- 2024-11-26Mybatis官方生成器资料详解与应用教程
- 2024-11-26Mybatis一级缓存资料详解与实战教程
- 2024-11-26Mybatis一级缓存资料详解:新手快速入门
- 2024-11-26SpringBoot3+JDK17搭建后端资料详尽教程
- 2024-11-26Springboot单体架构搭建资料:新手入门教程
- 2024-11-26Springboot单体架构搭建资料详解与实战教程
- 2024-11-26Springboot框架资料:新手入门教程
- 2024-11-26Springboot企业级开发资料入门教程
- 2024-11-26SpringBoot企业级开发资料详解与实战教程
- 2024-11-26Springboot微服务资料:新手入门全攻略