lovebet国际官方手机版
  咨询电话:15265177872

lovebet集团备用登录

并发编程学习笔记之显示锁(十一)

ReentrantLock(重进入锁)并不是作为内部锁(synchronized)机制的替代,而是当内部锁被证明受到局限时,提供可选择的高级特性.

1. Lock 和 ReentrantLock

Lock接口:

public interface Lock { void lock(); void lockInterruptibly() throws InterruptedException; boolean tryLock(); boolean tryLock(long time, TimeUnit unit) throws InterruptedException; void unlock(); Condition newCondition();}

与内部加锁机制不同,Lock提供了无条件的、可轮询的、定时的、可中断的锁获取操作,所有加锁和解锁的方法都是显示的.

Lock的实现必须提供具有与内部加锁相同的内存可见性的语义.但是加锁的语义、调度算法、顺序保证,性能特性这些可以不同.

ReentrantLock实现了Lock接口,提供了与synchronized相同的互斥和内存可见性的保证.

获得ReentrantLock的锁与进入synchronized块有着相同的内存语义,释放ReentrantLock锁与退出synchronized块有相同的内存语义.

ReentrantLock提供了与synchronized一样的可重入加锁的语义.ReentrantLock支持Lock接口定义的所有获取锁的模式.

一句话synchronized能做的,ReentrantLock都能做,但是ReentrantLock为处理不可用的锁提供了更多灵活性(好吧,ReentrantLock写起来比较麻烦)

为什么要使用显示锁

内部锁在大部分情况下都能很好地工作,但是有一些功能上的局限--不能中断那些正在等待获取锁的线程,并且在请求锁失败的情况下,必须无限等待.

内部锁必须在获取他们的代码块中被释放:这很好地简化了代码,与异常处理机制能够良好的互动,但是在某些情况下,一个更灵活的加锁机制提供了更好的活跃度和性能.

public class LockTest { Lock lock = new ReentrantLock(); public void testLock(){ lock.Lock(); try { // 需要加锁的代码.. }finally { lock.unlock(); } }}

这个模式在某种程度上比使用内部锁更加复杂:锁必须在finally块中释放.

另一方面,如果锁守护的代码在try块之外抛出了异常,它将永远都不会被释放了;

如果对象能够被置于不一致的状态,可能需要额外的try-catch,或try-finally块.

显示的lock的缺点

使用lock之后必须unlock释放锁,这也是ReentrantLock不能完全替代synchronized的原因.

它更加危险,因为当程序的控制权离开了守护的块时,不会自动清除锁.

1.1 可轮询和可定时的锁请求

可定时的与可轮询的锁获取模式,是由tryLock方法实现,与无条件的锁获取相比,它具有更完善的错误恢复机制.

使用内部锁,发生死锁时唯一的恢复方法是重启程序,唯一的预防方法是在构建程序时不要出错,所以不可能允许不一致的锁顺序.

可定时的与可轮询的锁提供了另一个选择,可以规避死锁的发生.

使用方式:

public class LockSample { //创建一个锁的实例 Lock lock = new ReentrantLock(); public void methodA(){ lock.lock(); try { System.out.println("执行了方法A"); Thread.sleep(100000); } catch (InterruptedException e) { e.printStackTrace(); } finally { lock.unlock(); } } public void methodB(){ lock.lock(); try { System.out.println("执行了方法B"); Thread.sleep(100000); } catch (InterruptedException e) { e.printStackTrace(); } finally { lock.unlock(); } } public static void main(String [] args){ LockSample lockSample = new LockSample(); lockSample.methodA(); //methodB()方法必须在锁可用的时候才会执行 lockSample.methodB(); } }

使用tryLock能解决第九篇博客死锁,提到过的动态的顺序死锁问题.

public class LockTest { public static void main(String [] args){ LockTest lockTest = new LockTest(); Account fromAccount = new Account(); Account toAccount = new Account(); Account account = new Account(); //开启一个新线程,获取两个用户的锁,这个方法是假设,对象的锁已经被获得用的. new Thread(){ @Override public void run(){ //这两个方法的内部实现就是Thread.sleep()将代码阻塞住. fromAccount.credit(account); toAccount.dedit(account); } }.start(); lockTest.transferMoney(fromAccount,toAccount,account); } public void transferMoney(Account fromAccount,Account toAccount,Account account){ while(true){ // lock.tryLock()返回一个布尔值,告诉你当前的锁是否可用,如果可用往下走 if(fromAccount.lock.tryLock()){ try { if (toAccount.lock.tryLock()){ try { //走到这里,证明两个锁都可用,可以进行转账操作. fromAccount.credit(account); toAccount.dedit(account); }finally { toAccount.lock.unlock(); } } }finally { fromAccount.lock.unlock(); } } } }}

Account的内部实现:

public class Account { public Lock lock = new ReentrantLock(); public void credit(Account account) { lock.lock(); try { try { Thread.sleep(1000000); } catch (InterruptedException e) { e.printStackTrace(); } } finally { lock.unlock(); } } public void dedit(Account account) { lock.lock(); try { try { Thread.sleep(1000000); } catch (InterruptedException e) { e.printStackTrace(); } } finally { lock.unlock(); } }

定时锁可以在时间预算内设定相应的超时,如果活动子啊期待的时间内没能获得结果,这个机制是程序能够提前返回.

而使用内部锁一旦开始请求,锁就不能停止了,所以内部锁为实现具有时限的活动带来了风险.

.tryLock方法还有一个重载版本,可以设定等待的时间:

lock.tryLock(4, TimeUnit.SECONDS)

1.2 可中断的锁获取操作

lock.lockInterruptibly上的锁,是可以响应中断的:

public class LockSample { //创建一个锁的实例 Lock lock = new ReentrantLock(); public void testInterruptibly(){ try { lock.lockInterruptibly(); Thread.sleep(5000); } catch (InterruptedException e) { e.printStackTrace(); }finally { lock.unlock(); } } public void test(){ System.out.println("lock.tryLock() = " + lock.tryLock()); try { System.out.println("lock.tryLock(4,TimeUnit.SECONDS) = " + lock.tryLock(4, TimeUnit.SECONDS));; } catch (InterruptedException e) { e.printStackTrace(); } } public void methodA(){ lock.lock(); try { System.out.println("执行了方法A"); Thread.sleep(4000); } catch (InterruptedException e) { e.printStackTrace(); } finally { lock.unlock(); } } public void methodB(){ lock.lock(); try { System.out.println("执行了方法B"); Thread.sleep(4000); } catch (InterruptedException e) { e.printStackTrace(); } finally { lock.unlock(); } } public static void main(String [] args){ Long startTime = System.nanoTime(); LockSample lockSample = new LockSample(); Thread thread = Thread.currentThread(); new Thread(){ @Override public void run(){ try { //休眠两秒,执行中断 Thread.sleep(2000); thread.interrupt(); } catch (InterruptedException e) { e.printStackTrace(); } } }.start(); //这里本来是休眠5秒的,因为上面直接中断了,可以看下面的endtime是两秒,证明了可以被中断 lockSample.testInterruptibly(); Long endTime = startTime - System.nanoTime(); System.out.println("endTime = " + endTime); }}

2. 对性能的考量

ReentrantLock提供的竞争上的性能要远远优于内部锁.

对于同步原语而言,竞态时的性能是可伸缩性的关键:若果有越多的资源花费在锁的管理和调度上,那程序执行的时间就越少.

在Java5.0中,ReentrantLock相比于synchronized能给吞吐量带来相当不错的提升,但是在Java6中,这两者非常接近.

也就是说之前选择显示锁,还有性能方面的考量,但是现在显示锁和synchronized已经差不多了.

3. 公平性

ReentrantLock构造函数提供了两种公平性的选择:

创建非公平锁(默认)公平锁

公平锁:如果锁已经被其他线程占有,新的请求线程会加入到等待队列,或者已经有一些线程在等待锁了;

非公平锁: 非公平锁允许闯入,当请求这样的锁时,如果锁的状态变为可用,线程的请求可以在等待线程的队列中向前跳跃,获得该锁.(Semaphore同样提供了公平和非公平的获取顺序).在非公平的锁中,线程只有当锁正在被占用时才会等待.

为什么要使用不公平锁

当发生加锁的时候,公平会因为挂起和重新开始线程的代价带来巨大的性能开销.

在多数情况下,非公平锁的优势超过了公平的排队.

在竞争激烈的情况下,闯入锁比公平锁性能好的原因之一是:挂起的线程重新开始,与它真正开始运行,两者之间会产生严重的延迟.

比较公平锁和非公平锁,使用的例子:

假设线程A持有一个锁,线程B请求该锁.因为此时锁正在使用中,线程B被挂起,当A释放锁后,B重新开始.与此同时,如果C请求锁,那么C得到了很好的机会获得这个锁,使用它,并且甚至可能在B被唤醒前就已经释放该锁了.

在这样的情况下,各方面都获得了成功:B并没有比其他任何线程晚得到锁,C更早的得到了锁,吞吐量得到了改进.

如果持有锁的时间相对较长,或者请求锁的平均时间间隔较长,那么使用公平锁是比较好的.

4. 在synchronized和ReentrantLock之间进行选择

在内部锁不能够满足使用时,ReentrantLock才被作为更高级的工具,当你需要以下高级特性时,才应该使用:可定时的、可轮询的与可中断的锁获取操作,公平队列,或者非块结构的锁,否则,请使用synchronized.

5. 读-写锁

读-写锁:一个资源能够被多个读者访问,或者被一个写者访问,两者不能同时进行.

public interface ReadWriteLock { /** * Returns the lock used for reading. * * @return the lock used for reading */ Lock readLock(); /** * Returns the lock used for writing. * * @return the lock used for writing */ Lock writeLock();}

ReadWriteLock暴露了两个Lock对象,一个用来读,另一个用来写.读取ReadWriteLock锁守护的数据,你必须首先获得读取的锁,当需要修改ReadWriteLock守护的数据时,你必须首先获得写入的锁.

读-写锁实现的加锁策略允许多个同时存在的读者,但是只允许一个写者.

读-写锁的设计是用来进行性能改进的,使得特定情况下能够有更好的并发性.

多处理器系统中,频繁的访问主要为读取数据结构的时候,读-写锁能够改进性能;

在其他情况下运行的情况比独占的锁要稍差一些,这归因于它更大的复杂性.

ReentrantReadWriteLock也能被构造为非公平(默认)或公平的.

公平: 在公平的锁中,选择权交给等待时间最长的线程;如果锁由读者获得,而一个线程请求写入锁,那么不在允许读者获得读取锁,直到写者被受理,并且已经释放了写入锁.

非公平: 线程允许访问的顺序是不定的.由写者降级为读者是允许的;从读者升级为写者是不允许的(尝试这样的行为会导致死锁).

使用读写锁的情况

当锁被持有的时间相对较长,并且大部分操作都不会改变锁守护的资源,那么读-写锁能够改进并发性.

使用读-写锁包装map:

public class ReadWriteMap<K,V> { private final Map<K,V> map; private final ReadWriteLock lock = new ReentrantReadWriteLock(); private final Lock r = lock.readLock(); private final Lock w = lock.writeLock(); public ReadWriteMap(Map<K, V> map) { this.map = map; } public V put(K key,V value){ w.lock(); try { return map.put(key,value); }finally { w.unlock(); } } //remove(),putAll(),clear()使用w.lock public V get(Object key){ r.lock(); try { return map.get(key); }finally { r.unlock(); } } //其他的只读map使用r.lock}

总结

显示的Lock与内部锁相比提供了一些扩展的特性,包括处理不可用的锁时更好的灵活性,以及对队列行为更好的控制,但是ReentrantLock不能完全替代synchronized;只有当你需要synchronized没能提供的特性时才应该使用.

读-写锁允许多个读者并发访问被守护的对象,当访问多为读取数据结构的时候,它具有改进可伸缩性的能力.

, 1, 0, 9);