简介
ReentrantLock
和synchronized
都是提供了同步的功能,JDK1.6
之后对synchronized
性能进行了优化,所以两者的性能上几乎没什么区别,但是ReentrantLock
提供了了一些高级功能。
等待可中断:在
synchronized
中,如果一个线程在等待锁,他只用两种结果,要么获得锁执行完,要么一直保持等待。可中断的等待是通知正在等待的线程,告诉他没必要再等待后。实现公平锁:公平锁:会按照时间的先后顺序,保证先到先得。特点是它不会产生饥饿现象。而synchroized关键字进行所控制时,锁是非公平的。而重入锁可以设置为公平锁。
public ReetranLock(boolean fair)
当fair
为true
时,表示锁是公平的。实现公平锁必然要求系统维护一个有序队列,因此公平锁的成本比较高,性能也非常低向。默认情况下锁是非公平的。绑定多个条件:类似于
Object
类的wait
和notify
方法,它是与ReentrantLock
绑定的条件,可以绑定多个条件。
一个简单的例子
注意:退出临界区要释放锁,否则其他线程就没有机回访问临界区了。
1 | public class TestReentrantLock implements Runnable { |
注意:退出临界区要释放锁,否则其他线程就没有机回访问临界区了。
Lock接口
Lock
接口是JDK1.5
新加的同步工具接口,它的实现类有ReentrantLock
、WriteLock
等,接口中定义了通用的方法:
1 | void lock(); |
其中lock
和unlock
方法提供了synchronized
的功能,其他方法使得同步过程更加的灵活。
什么叫重入锁
一个线程可以多次进入,当然必须多次释放锁。
1 | rlock.lock(); |
下面根据案例主要介绍ReentrantLock
的用法,在后面的文章中介绍它的实现原理。
中断响应
如果一个线程正在等待锁,那么它可以收到一个通知,被告知无序再等待,可以停止工作了。在synchronized
中,
如果一个线程在等待锁,他只用两种结果,要么获得锁执行完,要么一直保持等待。
下面通过一个死锁的例子,介绍中断响应的过程。
1 | public class DeathLock implements Runnable{ |
执行过程是thread1
占用lock1
,休眠500毫秒,然后想占用lock2
,与此同时,thread2
占用lock2
,休眠1000毫秒后在请求lock1
。可是当thread1
,想请求lock2
时,已经被thread2
占用,因此只能进入阻塞状态,thread2
也同理进入阻塞状态。因此进入死锁。但是这里使用了lockInterruptibly()
方法。这是一个可以对中断进行响应的锁申请动作,即在等待锁的过程中可以响应中断。在thred2
调用interrupt()
方法,thread2
线程被中断,thread2
放弃对lock
的申请,同时释放已获得的lock2
,所以thread1
可以得到lock2
继续执行下去。
结果为:
thread2
先中断,抛出异常,跳入finally
块,释放资源,最终退出。
锁申请等待限时
如果给定一个等待时间,超过时间,让线程自动放弃。
1 | public class TimeLock implements Runnable { |
tryLock()
两个参数分别表示等待时长和计时单位,表示线程在请求锁的过程中,最多等待5秒,如果超过改时间则返回false,如果成果获得锁,则返回true
。
该程序中首先任意一个线程先获得锁,然后休眠5秒,然而它一直占有锁,因此另一个线程无法再2秒内获得锁,因此失败。
tryLock()
方法也可以不带参数,这种情况下,当前线程会尝试获得锁,如果锁未被其他线程占用,则申请锁会成功,把那个返回true
,如果锁被其他线程占用,则当前线程不会等待,而是立即返回false
。这种模式下不会引起线程等待,因此也不会产生死锁。
公平锁
大多数情况下,锁的申请都是非公平的,也就是说,线程1首先申请锁A,接着线程2也请求了锁A,当锁A可用时,线程1,2都有可能获得锁,系统只是在等待队列中随机挑选一个,因此不能保证公平性。
所以有了公平锁,公平锁:会按照时间的先后顺序,保证先到先得。特点是它不会产生饥饿现象。而synchroized
关键字进行所控制时,锁是非公平的。而重入锁可以设置为公平锁。public ReetranLock(boolean fair)
当fair
为true
时,表示锁是公平的。实现公平锁必然要求系统维护一个有序队列,因此公平锁的成本比较高,性能也非常低向。默认情况下锁是非公平的。
1 | public class FairLock implements Runnable { |
部分结果为:
可以看出两个线程基本上是交替获得锁。
Condition条件(搭配重入锁使用)
Condition
类似于wait()
和notify()
的功能,它是与重入锁关联使用的。Lock
接口中提供了newCondition()
方法,该方法可以返回绑定到此Lock
的Condition
实例。
方法解释:await
方法会使当前线程等待,同时释放当前锁,当其他线程中使用signal()
或signalAll()
方法时,线程会重新获得锁并继续执行,当线程被中断时,也能跳出等待。与Object
的wait()
方法相似。singal()
方法用于唤醒一个在等待中的线程。
注意:以上连个方法调用之前必须当前线程拥有锁。否则抛出IllegalMonitorStateException
异常
1 | public class ConditionDemo implements Runnable { |
thread1
线程调用await
时,要求线程持有相关的重入锁,调用后,线程释放这把锁,同理signal
方法调用时,也要求线程先获得相关的锁,在signal
方法调用后,系统会从当前的Condition
对象的等待队列中唤醒一个线程,一旦线程唤醒,它会重新尝试获得之前绑定的锁,一旦成功获取await
方法返回,继续执行。在调用signal
后先睡眠2秒,并且保持了锁,释放了锁之后,await
方法获取锁后才得以返回继续执行。因此打印出来的时间差为2000毫秒。
最后
上面结合例子介绍了ReentrantLock
主要的用法,还有一些很有意思的用法,比如正在等待锁的线程,当前线程是否拥有锁等等。
1 | //查询当前线程保持此锁的次数。 |
进入ReentrantLock
的源码发现,ReentrantLock
类的绝大部分功能是通过它的内部类Sync
来实现的,而Sync
又继承了AbstractQueuedSynchronizer
类。这就是大名鼎鼎的AQS
,Doug Lea
最著名的作品,后面的文章分析它的精华所在。
参考地址
如果大家喜欢我的文章,可以关注个人订阅号。欢迎随时留言、交流。如果想加入微信群的话一起讨论的话,请加管理员简栈文化-小助手(lastpass4u),他会拉你们进群。