*Lock ReentrantLock Condition
ReentrantLock可以实现synchronized关键字的功能,还可以实现停止等待线程执行,定时停止等待线程执行,通过投票获取锁等操作。在高并发条件下,相比Synchorized具有更好的性能表现。ReentrantLock类可以实现公平锁和不公平锁,默认情况下是不公平锁。不公平锁消耗的系统资源少,性能好于公平锁。
Lock方法提供了Condition来进行线程同步,Condition类包括await,signal,signalall方法对应于Object类提供的wait、notify、notifyall方法。
附件:
一、ReentrantLock 类
1.1 什么是reentrantlock
1.2 ReentrantLock与synchronized的比较
相同:ReentrantLock提供了synchronized类似的功能和内存语义。
不同:
(1)ReentrantLock 功能性方面更全面,比如时间锁等候,可中断锁等候,锁投票等,因此更有扩展性。在多个条件变量和高度竞争锁的地方,用ReentrantLock更合 适,ReentrantLock还提供了Condition,对线程的等待和唤醒等操作更加灵活,一个ReentrantLock可以有多个 Condition实例,所以更有扩展性。
(2)ReentrantLock 的性能比synchronized会好点。
(3)ReentrantLock提供了可轮询的锁请求,他可以尝试的去取得锁,如果取得成功则继续处理,取得不成功,可以等下次运行的时候处理,所以不容易产生死锁,而synchronized则一旦进入锁请求要么成功,要么一直阻塞,所以更容易产生死锁。
1.3 ReentrantLock扩展的功能
1.3.1 实现可轮询的锁请求
如果你不能获得所有需要的锁,那么使用可轮询的获取方式 使你能够重新拿到控制权,它会释放你已经获得的这些锁,然后再重新尝试。可轮询的锁获取模式,由tryLock()方法实现。此方法仅在调用时锁为空闲状 态才获取该锁。如果锁可用,则获取锁,并立即返回值true。如果锁不可用,则此方法将立即返回值false。此方法的典型使用语句如下:
- Lock lock = ...;
- if (lock.tryLock()) {
- try {
- // manipulate protected state
- } finally {
- lock.unlock();
- }
- } else {
- // perform alternative actions
- }
1.3.2 实现可定时的锁请求
动调用了阻塞方法,定时锁能够在时间预算内设定相应的超时。如果活动在期待的时间内没能获得结果,定时锁能使程序提前返回。可定时的锁获取模式,由tryLock(long, TimeUnit)方法实现。
1.3.3 实现可中断的锁获取请求
1.4 ReentrantLock不好与需要注意的地方
二、条件变量Condition
条件变量很大一个程度上是为了解决Object.wait/notify/notifyAll难以使用的问题。
条件(也称为条件队列 或条件变量)为线程提供了一个含义,以便在某个状态条件现在可能为 true 的另一个线程通知它之前,一直挂起该线程(即让其“等待”)。因为访问此共享状态信息发生在不同的线程中,所以它必须受保护,因此要将某种形式的锁与该条件相关联。等待提供一个条件的主要属性是:以原子方式 释放相关的锁,并挂起当前线程,就像 Object.wait
做的那样。
上述API说明表明条件变量需要与锁绑定,而且多个Condition需要绑定到同一锁上。前面的Lock中提到,获取一个条件变量的方法是Lock.newCondition()。
- void await() throws InterruptedException;
- void awaitUninterruptibly();
- long awaitNanos(long nanosTimeout) throws InterruptedException;
- boolean await(long time, TimeUnit unit) throws InterruptedException;
- boolean awaitUntil(Date deadline) throws InterruptedException;
- void signal();
- void signalAll();
以上是Condition接口定义的方法,await*对应于Object.wait,signal对应于Object.notify,signalAll对应于Object.notifyAll。特别说明的是Condition的接口改变名称就是为了避免与Object中的wait/notify/notifyAll的语义和使用上混淆,因为Condition同样有wait/notify/notifyAll方法。
每一个Lock可以有任意数据的Condition对象,Condition是与Lock绑定的,所以就有Lock的公平性特性:如果是公平锁,线程为按照FIFO的顺序从Condition.await中释放,如果是非公平锁,那么后续的锁竞争就不保证FIFO顺序了。
一个使用Condition实现生产者消费者的模型例子如下。
[java] view plaincopy
- import java.util.concurrent.locks.Condition;
- import java.util.concurrent.locks.Lock;
- import java.util.concurrent.locks.ReentrantLock;
- public class ProductQueue {
- private final T[] items;
- private final Lock lock = new ReentrantLock();
- private Condition notFull = lock.newCondition();
- private Condition notEmpty = lock.newCondition();
- //
- private int head, tail, count;
- public ProductQueue(int maxSize) {
- items = (T[]) new Object[maxSize];
- }
- public ProductQueue() {
- this(10);
- }
- public void put(T t) throws InterruptedException {
- lock.lock();
- try {
- while (count == getCapacity()) {
- notFull.await();
- }
- items[tail] = t;
- if (++tail == getCapacity()) {
- tail = 0;
- }
- ++count;
- notEmpty.signalAll();
- } finally {
- lock.unlock();
- }
- }
- public T take() throws InterruptedException {
- lock.lock();
- try {
- while (count == 0) {
- notEmpty.await();
- }
- T ret = items[head];
- items[head] = null;//GC
- //
- if (++head == getCapacity()) {
- head = 0;
- }
- --count;
- notFull.signalAll();
- return ret;
- } finally {
- lock.unlock();
- }
- }
- public int getCapacity() {
- return items.length;
- }
- public int size() {
- lock.lock();
- try {
- return count;
- } finally {
- lock.unlock();
- }
- }
- }
在这个例子中消费take()需要 队列不为空,如果为空就挂起(await()),直到收到notEmpty的信号;生产put()需要队列不满,如果满了就挂起(await()),直到收到notFull的信号。
可能有人会问题,如果一个线程lock()对象后被挂起还没有unlock,那么另外一个线程就拿不到锁了(lock()操作会挂起),那么就无法通知(notify)前一个线程,这样岂不是“死锁”了?
2.1 await* 操作
上一节中说过多次ReentrantLock是独占锁,一个线程拿到锁后如果不释放,那么另外一个线程肯定是拿不到锁,所以在lock.lock()和lock.unlock()之间可能有一次释放锁的操作(同样也必然还有一次获取锁的操作)。我们再回头看代码,不管take()还是put(),在进入lock.lock()后唯一可能释放锁的操作就是await()了。也就是说await()操作实际上就是释放锁,然后挂起线程,一旦条件满足就被唤醒,再次获取锁!
[java] view plaincopy
- public final void await() throws InterruptedException {
- if (Thread.interrupted())
- throw new InterruptedException();
- Node node = addConditionWaiter();
- int savedState = fullyRelease(node);
- int interruptMode = 0;
- while (!isOnSyncQueue(node)) {
- LockSupport.park(this);
- if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
- break;
- }
- if (acquireQueued(node, savedState) && interruptMode != THROW_IE)
- interruptMode = REINTERRUPT;
- if (node.nextWaiter != null)
- unlinkCancelledWaiters();
- if (interruptMode != 0)
- reportInterruptAfterWait(interruptMode);
- }
上面是await()的代码片段。上一节中说过,AQS在获取锁的时候需要有一个CHL的FIFO队列,所以对于一个Condition.await()而言,如果释放了锁,要想再一次获取锁那么就需要进入队列,等待被通知获取锁。完整的await()操作是安装如下步骤进行的:
- 将当前线程加入Condition锁队列。特别说明的是,这里不同于AQS的队列,这里进入的是Condition的FIFO队列。后面会具体谈到此结构。进行2。
- 释放锁。这里可以看到将锁释放了,否则别的线程就无法拿到锁而发生死锁。进行3。
- 自旋(while)挂起,直到被唤醒或者超时或者CACELLED等。进行4。
- 获取锁(acquireQueued)。并将自己从Condition的FIFO队列中释放,表明自己不再需要锁(我已经拿到锁了)。
这里再回头介绍Condition的数据结构。我们知道一个Condition可以在多个地方被await*(),那么就需要一个FIFO的结构将这些Condition串联起来,然后根据需要唤醒一个或者多个(通常是所有)。所以在Condition内部就需要一个FIFO的队列。
[java] view plaincopy
- private transient Node firstWaiter;
- private transient Node lastWaiter;
上面的两个节点就是描述一个FIFO的队列。我们再结合前面提到的节点(Node)数据结构。我们就发现Node.nextWaiter就派上用场了!nextWaiter就是将一系列的Condition.await*串联起来组成一个FIFO的队列。
2.2 signal/signalAll 操作
await*()清楚了,现在再来看signal/signalAll就容易多了。按照signal/signalAll的需求,就是要将Condition.await*()中FIFO队列中第一个Node唤醒(或者全部Node)唤醒。尽管所有Node可能都被唤醒,但是要知道的是仍然只有一个线程能够拿到锁,其它没有拿到锁的线程仍然需要自旋等待,就上上面提到的第4步(acquireQueued)。
[java] view plaincopy
- private void doSignal(Node first) {
- do {
- if ( (firstWaiter = first.nextWaiter) == null)
- lastWaiter = null;
- first.nextWaiter = null;
- } while (!transferForSignal(first) &&
- (first = firstWaiter) != null);
- }
- private void doSignalAll(Node first) {
- lastWaiter = firstWaiter = null;
- do {
- Node next = first.nextWaiter;
- first.nextWaiter = null;
- transferForSignal(first);
- first = next;
- } while (first != null);
- }
上面的代码很容易看出来,signal就是唤醒Condition队列中的第一个非CANCELLED节点线程,而signalAll就是唤醒所有非CANCELLED节点线程。当然了遇到CANCELLED线程就需要将其从FIFO队列中剔除。
[java] view plaincopy
- final boolean transferForSignal(Node node) {
- if (!compareAndSetWaitStatus(node, Node.CONDITION, 0))
- return false;
- Node p = enq(node);
- int c = p.waitStatus;
- if (c > 0 || !compareAndSetWaitStatus(p, c, Node.SIGNAL))
- LockSupport.unpark(node.thread);
- return true;
- }
上面就是唤醒一个await*()线程的过程,根据前面的小节介绍的,如果要unpark线程,并使线程拿到锁,那么就需要线程节点进入AQS的队列。所以可以看到在LockSupport.unpark之前调用了enq(node)操作,将当前节点加入到AQS队列。
参考文献:
http://www.ibm.com/developerworks/cn/java/j-jtp10264/index.html
http://blog.sina.com.cn/s/blog_7898b053010175qv.html
*ReentrantReadWriteLock读写锁
Java读写锁实现类是ReentrantReadWriteLock,实现高效的并发读写操作。
进入读锁的条件
1.没有其他线程获取写锁;
2.没有写请求或者有但是写请求与自身是同一线程。
进入写锁的条件
1.没有其他线程获取读锁;
2.没有其他线程获取写锁。
参考文献:
http://www.cnblogs.com/liuling/archive/2013/08/21/2013-8-21-03.html
相关推荐
java除了使用关键字synchronized外,还可以使用ReentrantLock实现独占锁的功能。而且ReentrantLock相比synchronized而言功能更加丰富,使用起来更为灵活,也更适合复杂的并发场景。这篇文章主要是从使用的角度来分析...
Java并发编程基础主要包括以下几个核心方面: 线程与线程状态:理解Java中线程的基本概念,包括线程的创建、启动、暂停、恢复和终止。熟悉线程的生命周期及其不同状态,如新建、就绪、运行、阻塞和死亡。 线程同步...
4、ReentrantLock底层实现和如何使用 5、Condition源码分析 6、ReentrantReadWriteLock底层实现原理 7、并发工具类CountDownLatch 、CyclicBarrier和Semaphore底层实现原理 8、线程池原理和如何使用线程池 9、...
1、本资源包含并发编程基础知识的使用案例,包括:线程创建、Synchronized和Reentrantlock锁的使用、线程安全问题演示、Condition的应用、CountDownLatch的应用、Cyclicbarrier的应用、Semaphore的应用、线程池的...
Java并发编程实战 本书深入浅出地介绍了Java线程和并发,是一本完美的Java并发参考手册。书中从并发性和线程安全性的基本概念出发,介绍了如何使用类库提供的基本并发构建块,用于避免并发危险、构造线程安全的类及...
【2018最新最详细】并发多线程教程,课程结构如下 ...25.大白话说java并发工具类-CountDownLatch,CyclicBarrier 26.大白话说java并发工具类-Semaphore,Exchanger 27.一篇文章,让你彻底弄懂生产者--消费者问题
│ Java并发编程.png │ ppt+源码.rar │ 高并发编程第二阶段01讲、课程大纲及主要内容介绍.wmv │ 高并发编程第二阶段02讲、介绍四种Singleton方式的优缺点在多线程情况下.wmv │ 高并发编程第二阶段03讲、...
│ Java并发编程.png │ ppt+源码.rar │ 高并发编程第二阶段01讲、课程大纲及主要内容介绍.wmv │ 高并发编程第二阶段02讲、介绍四种Singleton方式的优缺点在多线程情况下.wmv │ 高并发编程第二阶段03讲、...
ReentrantLock 源码 Condition 源码 ConcurrentHashMap 源码 Java 线程状态 JAVA 数据结构 Queue HashMap HashTable ConcurrentHashMap JAVA IO Go Redis Redis Cluster Redis 持久化方式 Redis
面试高级开发的期间整理的面试题目,记录我面试遇到过的并发题目以及答案 目录 并发 常说的并发问题是哪些;资源竞争、死锁、事务、可见性 ...实现一个阻塞队列(用Condition写生产者与消费者就)?BlockingQueue
Java 中的 ReentrantLock 类可以设置为公平锁或非公平锁。 五、读写锁 读写锁是指一个锁可以被多个线程同时读取,但是只能被一个线程写入。Java 中的 ReentrantReadWriteLock 类是一个读写锁的实现。 六、锁降级...
25 JAVA8 与元数据.................................................................................................................................25 2.4. 垃圾回收与算法 .................................
实现了常见的并发题目,包括死锁,互斥示例,阻塞队列,生产者消费者等。 2.1:AwaitSignalExample 使用java并发包里面的 ReentrantLock 和 Condition 实现了互斥示例。 2.2: WaitNotifyCase 使用object对象自带的...
25 JAVA8 与元数据.................................................................................................................................25 2.4. 垃圾回收与算法 .................................
[ReentrantLock, ReentrantReadWriteLock, ReadWriteLock源码] [Condition 条件队列和Object.wait队列] 并发同步工具类 [CountDownLatch] [CyclicBarrier] [Semaphore] [Exchanger] Atomic包 并发集合 [BlockQueue] ...
此外,Lock接口还有一个带条件的锁——Condition接口的实现类ReentrantLock。这种带条件的锁使得线程可以在一定条件下挂起等待,直到其它线程唤醒它。 在实际使用场景中,例如多个用户同时操作一个银行账户的情况,...