AQS 框架之 Lock 接口
2018-09-01 05:39:15来源:博客园 阅读 ()
■ 前言 - 内存锁的不足
- 不可中断:使用内部锁(指的是 synchronized) 时,不能中断正在等待获取锁的线程
- 不可超时:使用内部锁时,在请求锁失败情况下,必须无限等待,没有超时效果
- 自动释放:使用内部锁时,内部锁必须在获取它们的代码块中被自动释放(虽然对代码来说是种简化且对异常友好)
- 不可伸缩:使用内部锁时,无法细粒度控制锁(伸缩性不足),即无法实现锁分离和锁联结,比如为每个链表节点(或部分)加锁从而允许不同的线程能够独立操作链表的不同节点(部分),遍历或修改链表时,需先获取该节点锁并直到获取下一个节点锁时才释放当前节点锁
- 性能问题:使用内部锁时,在有竞争情况下仍会出现性能问题,尽管JDK6对内部锁进行了优化,但无论是偏向锁或是轻量级锁都是针对无竞争情况的优化,无竞争情况下与 ReentractLock 性能一致,但有竞争时Lock明显更高效
■ Lock 接口综述
- 定义: JDK1.5 引入Lock接口,其定义了一些抽象的锁操作,相比synchronized,Lock 提供了无条件、可轮询、可定时、可中断的锁获取操作,所有加锁和解锁的方法都是显式的
- 实现: Lock 的实现必须提供具有与 synchronized 相同的内存语义,但加锁的语义、调度算法、顺序保证、性能特性可以有所不同
- 使用: Lock接口的实现基本是通过聚合一个同步器 AbstractQueuedSynchronized 的子类来完成线程的访问控制
- 对比内部锁: Lock缺少隐式获取/释放锁的便捷,但却拥有了锁获取与释放的可操作性、可中断的获取锁以及超时获取锁等多种内部锁不具备的同步性,甚至还支持读写锁分离,同时允许获取和释放可以不在同一个块中
- 补充:此番为 AQS 框架之综述 (排期中) 的子番,同时也是 AQS 框架之 ReentractLock (排期中) 的预备番
并发包中的Lock接口实现类,其中ReadLock和WriteLock是ReentrantReadWriteLock的静态内部类,如图:
■ Lock 接口方法标准使用
//标准用法 Lock lock = new ReentrantLock(); //获取锁应在try之前,因为若获取锁时发生异常,异常抛出同时会导致锁无故释放 lock.lock(); try{ doSometing(); }finally{ //注意:必须在finally块中释放锁,目的是保证在获取到锁之后,最终能被释放 lock.unlock(); }
■ Lock 接口方重点方法
1. lock()
- lock方法应具有与内部锁加锁相同的内存语义,即无锁阻塞和支持可重入
- lock方法必须搭配unlock方法使用,同时必须在finally中显式调用unlock方法释放锁
/** * 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被错误使用,如死锁或抛出不可查异常(即可运行期异常和Error) * 此时该实现必须用文档注明其可能出现的异常或需要的使用环境 */ void lock();
2. lockInterruptibly()
- lockInterruptibly 方法提供可中断的锁获取操作并允许在可取消的活动中使用
//样例代码
public boolean doTask throws InterruptedException(){ lock.lockInterruptibly(); try{ return cancelTask(); }finally{ lock.unlock(); } } //取消任务 private boolean cancelTask() throws InterruptedException {...}
/** * 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> * 若当前锁不可用(已被占有),当前线程会一直休眠直到以下两种情况发生: * 1.锁被当前线程获取 * 2.其他线程中断当前线程,同时锁的获取允许被中断 * <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. * 相对于返回,该方法更适合抛出一个中断响应,比如中断异常 * @throws InterruptedException if the current thread is * interrupted while acquiring the lock (and interruption * of lock acquisition is supported) */ void lockInterruptibly() throws InterruptedException;
3. tryLock()
- tryLock 方法提供可定时与可轮询的锁获取方式,与无条件的锁获取相比,具有更完善的错误恢复机制
- tryLock 方法能够有效的防止死锁的发生,比如使用轮询锁优雅失败规避死锁
- tryLock 方法同时提供定时锁的功能,其允许在限时活动内部使用独占锁,当线程获取锁、被中断或超时后返回
- tryLock 方法支持轮询获取锁:通过一个循环配合tryLock()来不断尝试获取锁,由于tryLock()非阻塞因此会立即返回是否成功获取锁的结果;当不能获取所有的锁时,应释放已获得的所有锁并重新尝试获取
- tryLock 方法同时支持响应中断
/** * Acquires the lock only if it is free at the time of invocation. * 尝试非阻塞的获取锁,调用该方法后立即返回是否成功获取锁true/false * <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}. * 当锁不可用时立即返回false * 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 */ 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}. * 没有被中断当前线程在指定超时时间内获取锁 * 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 * <li>The specified waiting time elapses * </ul> * <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. * 当前线程在以下三种情况下会返回: * 1.当前线程在超时时间内获得锁 * 2.当前线程在超时时间内被中断 * 3.超时时间结束,返回false,线程不再被阻塞 * @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 * @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;
4. unLock()
- 使用lock方法、lockInterruptibly方法、tryLock方法都必须显式调用unlock方法释放锁
- unlock方法必须在finally块中执行,这也是Lock使用的一个代码隐患(容易忘记执行)
- unlock方法允许与lock方法不在同一个块(即{})中执行,但业务代码必须保证在try-finally块中执行
/** * Releases the lock. * 释放锁 */ void unlock();
5. newCondition 方法
- Lock搭配Condition可以实现更加灵活的锁获取与释放的条件控制
/** * 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方法并释放锁 * @return A new {@link Condition} instance for this {@code Lock} instance * @throws UnsupportedOperationException if this {@code Lock} * implementation does not support conditions */ Condition newCondition();
标签:
版权申明:本站文章部分自网络,如有侵权,请联系:west999com@outlook.com
特别注意:本站所有转载文章言论不代表本站观点,本站所提供的摄影照片,插画,设计作品,如需使用,请与原作者联系,版权归原作者所有
- Java--反射(框架设计的灵魂)案例 2020-06-11
- Java--反射(框架设计的灵魂) 2020-06-11
- 与JAVA集合相遇 2020-06-11
- Java框架之Hibernate实战篇 2020-06-09
- 拼多多三面惨败,问题在于java中间件、数据库与spring框架. 2020-06-04
IDC资讯: 主机资讯 注册资讯 托管资讯 vps资讯 网站建设
网站运营: 建站经验 策划盈利 搜索优化 网站推广 免费资源
网络编程: Asp.Net编程 Asp编程 Php编程 Xml编程 Access Mssql Mysql 其它
服务器技术: Web服务器 Ftp服务器 Mail服务器 Dns服务器 安全防护
软件技巧: 其它软件 Word Excel Powerpoint Ghost Vista QQ空间 QQ FlashGet 迅雷
网页制作: FrontPages Dreamweaver Javascript css photoshop fireworks Flash