多线程基础总结七－－ReentrantLock

核心提示： 在这个例子中，辅助类SampleSupport提供一个倒计时的功能startTheCountdown()，多线程基础总结七－－ReentrantLock(2)，这里倒计时5s左右， SampleSupport1,SampleSupport2继承其并分别的具有doSomething()方法，当然在

在这个例子中，辅助类SampleSupport提供一个倒计时的功能startTheCountdown()，这里倒计时5s左右。 SampleSupport1,SampleSupport2继承其并分别的具有doSomething()方法，任何进入方法的线程会运行5s左右之后 counter++然后离开方法释放锁。SampleSupport1是使用ReentrantLock机制，SampleSupport2是使用 synchronized机制。

testSynchronized()和testReentrantLock()都分别开启两个线程执行测试方法executeTest()，这个方法会让一个线程先启动，另一个过100ms左右启动，并且隔1s左右试图中断后者。结果正如之前提到的第二点：interrupt()对于 synchronized是没有作用的,它依然会等待5s左右获得锁执行counter++;而ReentrantLock机制可以保证在线程还未获得并且试图获得锁时如果发现线程中断，则抛出异常清除中断标记退出竞争。所以testReentrantLock()中second线程不会继续去竞争锁,执行异常内的打印语句后线程运行结束。

这里我是用了ReentrantLock的lockInterruptibly()方法，在SampleSupport1的代码(1)处。这个方法保证了中断线程的响应，如果仅仅是lock()则不会有此功能。但是不管怎么说ReentrantLock提供了解决方案。至于提到的第一点“多条件”的机制我通过java.util.concurrent.ArrayBlockingQueue(源码参考1.6.0.17内的实现)简单的介绍一下：

Java代码

public　class　ArrayBlockingQueue<E>　extends　AbstractQueue<E>　implements　BlockingQueue<E>,　java.io.Serializable　{　
　　...　
　　/**　Main　lock　guarding　all　access　*/　
　　private　final　ReentrantLock　lock;　
　
　　/**　Condition　for　waiting　takes　*/　
　　private　final　Condition　notEmpty;　
　
　　/**　Condition　for　waiting　puts　*/　
　　private　final　Condition　notFull;　
　
　　...　
　　public　ArrayBlockingQueue(int　capacity,　boolean　fair)　{　
　　　　if　(capacity　<=　0)　
　　　　　　throw　new　IllegalArgumentException();　
　　　　this.items　=　(E[])　new　Object[capacity];　
　　　　lock　=　new　ReentrantLock(fair);　
　　　　notEmpty　=　lock.newCondition();　
　　　　notFull　=　lock.newCondition();　
　　}　
　
　　public　void　put(E　e)　throws　InterruptedException　{　
　　　　if　(e　==　null)　throw　new　NullPointerException();　
　　　　final　E[]　items　=　this.items;　
　　　　final　ReentrantLock　lock　=　this.lock;　
　　　　lock.lockInterruptibly();　
　　　　try　{　
　　　　　　try　{　
　　　　　　　　while　(count　==　items.length)　
　　　　　　　　　　notFull.await();　
　　　　　　}　catch　(InterruptedException　ie)　{　
　　　　　　　　notFull.signal();　//　propagate　to　non-interrupted　thread　
　　　　　　　　throw　ie;　
　　　　　　}　
　　　　　　insert(e);　
　　　　}　finally　{　
　　　　　　lock.unlock();　
　　　　}　
　　}　
　
　　private　void　insert(E　x)　{　
　　　　items[putIndex]　=　x;　
　　　　putIndex　=　inc(putIndex);　
　　　　++count;　
　　　　notEmpty.signal();　
　　}　
　
　　public　E　take()　throws　InterruptedException　{　
　　　　final　ReentrantLock　lock　=　this.lock;　
　　　　lock.lockInterruptibly();　
　　　　try　{　
　　　　　　try　{　
　　　　　　　　while　(count　==　0)　
　　　　　　　　　　notEmpty.await();　
　　　　　　}　catch　(InterruptedException　ie)　{　
　　　　　　　　notEmpty.signal();　//　propagate　to　non-interrupted　thread　
　　　　　　　　throw　ie;　
　　　　　　}　
　　　　　　E　x　=　extract();　
　　　　　　return　x;　
　　　　}　finally　{　
　　　　　　lock.unlock();　
　　　　}　
　　}　
　
　　private　E　extract()　{　
　　　　final　E[]　items　=　this.items;　
　　　　E　x　=　items[takeIndex];　
　　　　items[takeIndex]　=　null;　
　　　　takeIndex　=　inc(takeIndex);　
　　　　--count;　
　　　　notFull.signal();　
　　　　return　x;　
　　}　
　　...　
}

这里notEmpty和notFull作为lock的两个条件是可以分别负责管理想要加入元素的线程和想要取出元素的线程的wait和notify分别通过await()和signal(),signalAll()方法，有效的分离了不同职责的线程。例如put()方法在元素个数达到最大限制时会使用 notFull条件把试图继续插入元素的线程都扔到等待集中，而执行了take()方法时如果顺利进入extract()则会空出空间，这时 notFull负责随机的通知被其扔到等待集中的线程执行插入元素的操作。这样的设计使得线程按照功能行为职责管理成为了现实。

通过上述的总结，对于ReentrantLock的优点有了一定的认识，但是它也是实现了与synchronized相同语义和行为的可重用完全互斥锁，所以在竞争机制上不会有什么性能提高，功能倒是强大了不少。不过使用它要配合try{...}finally{...}显式的释放锁，这点是决定如果业务实现没有需要使用其特有的功能，更好的方式是使用synchronized。后者毕竟不用自己去释放锁，降低了开发的失误率。当然在 java.util.concurrent.locks包内还一个很有意思的锁：ReentrantReadWriteLock，其提供了部分互斥的锁实现，以后的总结会有介绍。