北京哪里可以做网站,排名好的徐州网站建设,制作微信小程序商城,手机网站设计推荐对于并发工作#xff0c;你需要某种方式来防止两个任务访问相同的资源#xff0c;至少在关键阶段不能出现这种冲突情况。防止这种冲突的方法就是当资源被一个任务使用时#xff0c;在其上加锁。在前面的文章--synchronized学习中#xff0c;我们学习了Java中内建的同步机制… 对于并发工作你需要某种方式来防止两个任务访问相同的资源至少在关键阶段不能出现这种冲突情况。防止这种冲突的方法就是当资源被一个任务使用时在其上加锁。在前面的文章--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; i10000 ; i)reLockTest.add();});Thread t2 new Thread(()-{for(int i 0; i10000 ; 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; i10000 ; i)reLockTest.add();});Thread t2 new Thread(()-{for(int i 0; i10000 ; 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
