ReentrantLock学习
对于并发工作,你需要某种方式来防止两个任务访问相同的资源,至少在关键阶段不能出现这种冲突情况。防止这种冲突的方法就是当资源被一个任务使用时,在其上加锁。在前面的文章--synchronized学习中,我们学习了Java中内建的同步机制synchronized的基本用法,在本文中,我们来学习Java中另一种锁ReentrantLock。
ReentrantLock介绍
ReentrantLock,通常译为再入锁,是Java 5中新加入的锁实现,它与synchronized基本语义相同。再入锁通过代码直接调用lock()方法获取,代码书写更加灵活。与此同时,ReentrantLock提供了很多实用的方法,能够实现很多synchronized无法做到的细节控制,比如可以控制fairness,也就是公平性,或者利用定义条件等。但是,编码中也需要注意,必须要明确调用unlock()方法释放锁,不然就会一直持有该锁。
我们先看一个简单例子体验一下:
public class ReLockTest {private Lock lock = new ReentrantLock();public int shareState;public void add() {shareState ++ ;}public void printState() {System.out.println("shareState-->" + shareState); }public static void main(String[] args) throws Exception{ReLockTest reLockTest = new ReLockTest();Thread t1 = new Thread(()->{for(int i = 0; i<10000 ; i++)reLockTest.add();});Thread t2 = new Thread(()->{for(int i = 0; i<10000 ; i++)reLockTest.add();});t1.start();t2.start();t1.join();t2.join();Thread.sleep(2000);reLockTest.printState();} }/** 输出结果
* shareState-->14012
*/
我们看到输出结果小于20000,这就是线程不安全,我们加上同步之后再看结果:
public class ReLockTest {private Lock lock = new ReentrantLock();public int shareState;public void add() {lock.lock();try {shareState ++ ;}catch(Exception e) {e.printStackTrace();}finally {lock.unlock();}}public void printState() {System.out.println("shareState-->" + shareState); }public static void main(String[] args) throws Exception{ReLockTest reLockTest = new ReLockTest();Thread t1 = new Thread(()->{for(int i = 0; i<10000 ; i++)reLockTest.add();});Thread t2 = new Thread(()->{for(int i = 0; i<10000 ; i++)reLockTest.add();});t1.start();t2.start();t1.join();t2.join();Thread.sleep(2000);reLockTest.printState();} }
/** 输出结果
* shareState-->20000
*/
我们看到在将自增操作上锁之后,输出结果就达到预期了。这就是ReentrantLock的基本用法,为了保证锁释放,每个lock()动作都对应一个try-catch-finally,这可以说是一个惯用法:
ReentrantLock lock = new ReentrantLock(); lock.lock(); try {// do something } finally {lock.unlock(); }ReentrantLock用法
ReentrantLock相比synchronized,虽然所需的代码比synchronized关键字要多,但也是因为可以像普通对象一样使用,所以可以利用其提供的各种便利方法,进行精细的同步操作,甚至是synchronized难以表达的用例,如:
带超时的获取锁尝试
通过tryLock(long timeout, TimeUnit unit)方法实现,这是一个具有超时参数的尝试申请锁的方法,阻塞时间不会超过给定的值;如果成功则返回true。
可以指定公平性
在创建ReentrantLock对象时往构造器中传入true即指定创建公平锁,这里所谓的公平是指在竞争场景中,当公平性为真时,会倾向于将锁赋予等待时间最久的线程。公平性是减少线程“饥饿”(个别线程长期等待锁,但始终无法获取)情况的发生的一个办法。
如果使用synchronized,我们根本无法进行公平性的选择,其永远是不公平的,这也是主流操作系统线程调度的选择。通用场景中,公平性未必有想象中的那么重要,Java默认的调度策略很少会导致“饥饿”发生。与此同时,若要保证公平性则会引入额外开销,自然会导致一定的吞吐量下将。所以,只有当程序确实有公平性需要的时候,才有必要指定它。
可以响应中断请求
通过lockInterruptibly()获得锁,但是会不确定地发生阻塞。如果线程被中断,抛出一个InterruptedException异常。
可以创建条件变量,将复杂晦涩的同步操作转变为直观可控的对象行为
如果说ReentrantLock是synchronized的替代选择,Conition则是将wait、notify、notifyAll等操作转化为相应的对象,将复杂而晦涩的同步操作转变为直观可控的对象行为。
可以通过Condition上调用await()来挂起一个任务,当外部条件发生变化,你可以通过调用signal()来通知这个任务,从而唤醒一个任务,或者调用signAll()来唤醒所有在这个Condition上被其自身挂起的任务,这是Condition最常见的用法。一个典型的应用场景就是标准类库中的ArrayBlockingQueue,下面我们结合部分其源码来分析一下:
首先,在构造函数中初始化lock,在从lock中创建两个条件变量Condition分别是notEmpty和notFull。
/** Main lock guarding all access */ 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 = new Object[capacity];lock = new ReentrantLock(fair);notEmpty = lock.newCondition();notFull = lock.newCondition(); }然后在take方法中,判断和等待条件满足:
public E take() throws InterruptedException {final ReentrantLock lock = this.lock;lock.lockInterruptibly();try {while (count == 0)notEmpty.await();return dequeue();} finally {lock.unlock();} }在take方法中,如果队列为空,ArrayBlockingQueue的本义是获取对象的线程会阻塞,等待入队的发生,而不是直接返回,代码中是通过调用Condition的await方法来实现的,而当有元素入队之后又是如何触发被阻塞的take操作的呢?我们看看enqueue:
private void enqueue(E x) {// assert lock.getHoldCount() == 1;// assert items[putIndex] == null;final Object[] items = this.items;items[putIndex] = x;if (++putIndex == items.length)putIndex = 0;count++;notEmpty.signal(); // 通知等待的线程 }
最后一行代码中就是通知等待的线程,这行执行结束后,被take阻塞的线程就会继续执行了。
通过signal/await的组合,完成了条件判断和通知等待线程,非常顺畅就完成了状态流转。signal和await成对调用非常重要,不然假设只有await动作,线程会一直等待直到被打断(interrupt)。
ReentrantLock与Synchronized
使用synchronized关键字时,需要写的代码量更少,而ReentrantLock的使用往往和try-catch-finally一起配套使用,代码量增加了。
从性能角度,synchronized早期的实现比较低效,对比ReentrantLock,大多数场景性能都相差较大。但是在Java 6中对其进行了非常多的改进(可以参考synchronized底层实现学习),在高竞争情况下,ReentrantLock仍然有一定优势。
我们知道synchronized获取的锁是monitor对象,而ReentrantLock获取的锁是什么呢,是否也是同一把锁呢?下文中,我们会深入源码去探究ReentrantLock获取锁的实现细节。
转载于:https://www.cnblogs.com/volcano-liu/p/10262183.html
总结
以上是生活随笔为你收集整理的ReentrantLock学习的全部内容,希望文章能够帮你解决所遇到的问题。
- 上一篇: Flink编程入门(二)
- 下一篇: size - 列出段节大小和总共大小