ReentrantReadWriteLock 的使用

概述

Java常见的多是排他锁,这些锁在同一时刻只允许一个线程进行访问 。当多个线程同时对同一个数据进行读取操作时,由于读取操作并不涉及数据的修改,若果这个给时候仍然给读操作设计锁的话无疑会降低读取数据的性能;
而且在实际运用中读操作频率远远高于写操作时,这时候就可以使用 读写锁 , 读写锁维护了一对锁,一个读锁和一个写锁,通过分离读锁和写锁,让多个只涉及读取数据的线程可以并行执行,使得并发性相比一般的排他锁有了很大提升,读写锁能有效提高读比写多的场景下的程序性能,比排它锁好。
当然了,多个线程同时涉及到读跟写或同时写的话,还是要加锁的。即读读并发,带写互斥。
类似于数据库中的 select … from … lock in share mode 表示查询可以并行执行,读写互斥;
ReadWriteLock接口管理一组锁,一个是只读的锁,一个是写锁。Java并发库中ReetrantReadWriteLock实现了ReadWriteLock接口并添加了可重入的特性。

用法

写锁的获取与释放

写锁是一个支持重进入排它锁。如果当前线程已经获取了写锁,则增加写状态。如果当前线程在获取写锁时,读锁已经被获取(读状态不为0)或者该线程不是已经获取写锁的线程,则当前线程进入等待状态。

如果存在读锁,则写锁不能被获取,原因在于:读写锁要确保写锁的操作对读锁可见,如果允许读锁在已被获取的情况下对写锁的获取,那么正在运行的其他读线程就无法感知到当前写线程的操作。
因此只有等待其他读线程都释放了读锁,写锁才能被当前线程所获取,而写锁一旦被获取,则其他读写线程的后续访问均被阻塞。
写锁的释放比较简单。 每次释放均减少写状态,当写状态为0时表示写锁已被释放,从而等待的读写线程能够继续访问读写锁,同时前次写线程的修改对后续读写线程可见。

读锁的获取与释放

读锁不是独占式锁,即同一时刻该锁可以被多个读线程获取也就是一种共享式锁。在没有其他写线程访问(或者写状态为0)时,读锁总会成功的被获取,而所做的也只是(线程安全的)增加读状态。如果当前线程已经获取了读锁,则增加读状态。如果当前线程在获取读锁时,写锁已被其他线程获取,则进入等待状态。

ReentrantReadWriteLock特性

(1)公平性选择

非公平模式(默认)
当以非公平初始化时,读锁和写锁的获取的顺序是不确定的。非公平锁主张竞争获取,可能会延缓一个或多个读或写线程,但是会比公平锁有更高的吞吐量。

公平模式
当以公平模式初始化时,线程将会以队列的顺序获取锁。当当前线程释放锁后,等待时间最长的写锁线程就会被分配写锁;或者有一组读线程组等待时间比写线程长,那么这组读线程组将会被分配读锁。

(2)重入性

可重入锁,就是说一个线程在获取某个锁后,还可以再次获取该锁,即允许一个线程多次获取同一个锁。比如synchronized内置锁就是可重入的,如果A类有2个synchornized方法method1和method2,那么method1调用method2是允许的。显然重入锁给编程带来了极大的方便。假如内置锁不是可重入的,那么导致的问题是:1个类的synchornized方法不能调用本类其他synchornized方法,也不能调用父类中的synchornized方法。与内置锁对应,JDK提供的显示锁ReentrantLock也是可以重入的,ReentrantReadWriteLock也是可以重入的。

(3)锁降级

读写锁支持锁降级,遵循按照获取写锁,获取读锁再释放写锁的次序,写锁能够降级成为读锁,不支持锁升级。

  • 重入时升级不支持:即持有读锁的情况下去获取写锁,会导致获取写锁永久等待。因为同一个线程中,在没有释放读锁的情况下,就去申请写锁,这属于锁升级,ReentrantReadWriteLock是不支持的

ReentrantLock获取到了锁之后想再次获取锁是可以的,但是ReentrantReadWriteLock 在获取到了锁的情况下再去获取锁是不可以的,会被阻塞住;比如持有读锁的情况下去获取写锁,会导致获取写锁永久等待 。

  • 重入时降级支持:即持有写锁的情况下去获取读锁 。但是从写锁降级成读锁,并不会自动释放当前线程获取的写锁,仍然需要显示的释放,否则别的线程永远也获取不到写锁。

注意:

  • 读锁不支持条件变量

使用演示

这里我们提供一个 数据容器类,其内部分别使用读锁保护数据的 read() 方法,写锁保护数据的 write() 方 法

  1. class DataContainer {
  2. //需要保护的数据
  3. private Object data;
  4. //创建读写锁对象
  5. private ReentrantReadWriteLock rw = new ReentrantReadWriteLock();
  6. //获取读锁
  7. private ReentrantReadWriteLock.ReadLock r = rw.readLock();
  8. //获取写锁
  9. private ReentrantReadWriteLock.WriteLock w = rw.writeLock();
  10. public Object read() throws InterruptedException {
  11. System.out.println("获取读锁...");
  12. r.lock();
  13. try {
  14. System.out.println("读取");
  15. Thread.sleep(1000);
  16. return data;
  17. } finally {
  18. System.out.println("释放读锁...");
  19. r.unlock();
  20. }
  21. }
  22. public void write() {
  23. System.out.println("获取写锁...");
  24. w.lock();
  25. try {
  26. System.out.println("写入");
  27. // sleep(1);
  28. } finally {
  29. System.out.println("释放写锁...");
  30. w.unlock();
  31. }
  32. }
  33. }

写完容器类之后我们来测试一下,多个线程同时进行读取时的情况,以及同时读写时的情况;

测试 读锁-读锁 是否可以并发

  1. public static void main(String[] args) {
  2. DataContainer dataContainer = new DataContainer();
  3. new Thread(() -> {
  4. try {
  5. dataContainer.read();
  6. } catch (InterruptedException e) {
  7. e.printStackTrace();
  8. }
  9. }, "t1").start();
  10. new Thread(() -> {
  11. try {
  12. dataContainer.read();
  13. } catch (InterruptedException e) {
  14. e.printStackTrace();
  15. }
  16. }, "t2").start();
  17. }

可以看出,两个读取操作并没有被阻塞
image.png
测试 读锁-写锁 是否可以并发

  1. public static void main(String[] args) throws InterruptedException {
  2. DataContainer dataContainer = new DataContainer();
  3. new Thread(() -> {
  4. try {
  5. dataContainer.read();
  6. } catch (InterruptedException e) {
  7. e.printStackTrace();
  8. }
  9. }, "t1").start();
  10. Thread.sleep(100);
  11. new Thread(() -> {
  12. try {
  13. dataContainer.write();
  14. } catch (Exception e) {
  15. e.printStackTrace();
  16. }
  17. }, "t2").start();
  18. }

可以看出,阻塞了
image.png
测试 写锁-写锁 是否可以并发

  1. public static void main(String[] args) throws InterruptedException {
  2. DataContainer dataContainer = new DataContainer();
  3. new Thread(() -> {
  4. try {
  5. dataContainer.write();
  6. } catch (Exception e) {
  7. e.printStackTrace();
  8. }
  9. }, "t1").start();
  10. Thread.sleep(100);
  11. new Thread(() -> {
  12. try {
  13. dataContainer.write();
  14. } catch (Exception e) {
  15. e.printStackTrace();
  16. }
  17. }, "t2").start();
  18. }

阻塞了
image.png

  1. //降级
  2. class CachedData {
  3. Object data;
  4. // 表示缓存数据是否有效,如果失效,需要重新计算 data
  5. volatile boolean cacheValid;
  6. final ReentrantReadWriteLock rwl = new ReentrantReadWriteLock();
  7. void processCachedData() {
  8. rwl.readLock().lock();
  9. if (!cacheValid) {
  10. // 获取写锁前必须去释放读锁
  11. rwl.readLock().unlock();
  12. rwl.writeLock().lock();
  13. try {
  14. // 判断是否有其它线程已经获取了写锁、更新了缓存, 避免重复更新;因为外层的if (!cacheValid) 不能保证其受写锁保护
  15. if (!cacheValid) {
  16. //更新数据
  17. data = ...
  18. cacheValid = true;
  19. }
  20. // 降级为读锁, 释放写锁, 这样能够让其它线程读取缓存
  21. rwl.readLock().lock();
  22. } finally {rwl.writeLock().unlock();
  23. }
  24. }
  25. // 自己用完数据, 释放读锁
  26. try {
  27. use(data);
  28. } finally {
  29. rwl.readLock().unlock();
  30. }
  31. }
  32. }

读写锁原理

读写锁同样依赖自定义同步器来实现同步功能,而读写状态就是其同步器的同步状态。 读写锁虽然有两个锁但用的是却是同一个 Sycn同步器,因此等待队列、state等也是同一个。
回想ReentrantLock中自定义同步器的实现,同步状态state表示锁被一个线程重复获取的次数,而读写锁的自定义同步器需要在同步状态(一个整型变量)上维护多个读线程和一个写线程的状态,使得该state状态的设计成为读写锁实现的关键
如果在一个整型变量上维护多种状态,就需要用“按位切割使用”的方式来使用这个变量,读写锁将变量切分成了两个部分,高16位表示读,低16位表示写,划分方式如下图所示
image.png
上图所示,当前同步状态表示一个线程已经获取了写锁,且重进入了两次,同时也连续获取了两次读锁。读写锁是如何迅速确定读和写各自的状态呢?
答案是通过位运算。假设当前同步状态值为S,写状态等于S&0x0000FFFF(将高16位全部抹去),读状态等于S>>>16(无符号补0右移16位)。当写状态增加1时,等于S+1,当读状态增加1时,等于S+(1<<16),也就是S+0x00010000。根据状态的划分能得出一个推论:S不等于0时,当写状态(S&0x0000FFFF)等于0时,则读状态(S>>>16)大于0,即读锁已被获取。

t1 w.lock t2 r.lock

这里我们就以t1线程加写锁,t2线程加读锁进行流程的讲解;

  1. 在没有其他线程的情况下t1线程添加写锁,当然 t1成功上锁,流程与ReentrantLock 加锁相比没有特殊之处,都是将state修改为1,不同的是写锁状态占了state的低16位,而读锁使用的是state的高16位

image.png

  1. //写锁
  2. public void lock() {
  3. //调用同步器的方法
  4. sync.acquire(1);
  5. }
  6. //就是AQS中的acquire方法
  7. public final void acquire(int arg) {
  8. //调用调用tryAcquire方法尝试加锁,加锁成功后面的代码就不执行了。
  9. if (!tryAcquire(arg) &&
  10. //加锁失败后尝试将其加入队列
  11. acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
  12. selfInterrupt();
  13. }
  14. //毕竟子类中重写了该方法,肯定有些不一样的东西
  15. protected final boolean tryAcquire(int acquires) {
  16. Thread current = Thread.currentThread();
  17. int c = getState();
  18. int w = exclusiveCount(c);
  19. //意味着其他线程可能加了读锁或写锁,说不定的
  20. if (c != 0) {
  21. //w==0表示别人加的是读锁;w=0不成立来到第二条件,表示判断写锁是不是当前线程加的
  22. // (Note: if c != 0 and w == 0 then shared count != 0)
  23. if (w == 0 || current != getExclusiveOwnerThread())
  24. //因为读锁跟现在要加的写锁互斥,所以返回false;或者说写锁不是当前线程加的,也互斥
  25. return false;
  26. //写锁加上1后超过写锁的最大值,抛异常(几乎不存在)
  27. if (w + exclusiveCount(acquires) > MAX_COUNT)
  28. throw new Error("Maximum lock count exceeded");
  29. // Reentrant acquire
  30. setState(c + acquires); //在写锁的基础上多次重入,发生可重入
  31. return true;
  32. }
  33. //走到这里说明state是等于0的,表示其他线程还没有进行加锁
  34. //writerShouldBlock表示写锁是否该阻塞(公平与否的体现),非公平锁总会返回false;公平锁检查是否是老二,这里看非公平的实现
  35. if (writerShouldBlock() ||
  36. //将state从0变为1
  37. !compareAndSetState(c, c + acquires))
  38. return false; //加写锁失败
  39. setExclusiveOwnerThread(current);
  40. return true;
  41. }

2) t2执行r.lock添加读锁,这时进入读锁的sync.acquireShared(1)流程,首先会进入tryAcquireShared流程; 如果有写锁占据,那么tryAcquireShared返回-1表示失败
image.png
3)这时会进入sync.doAcquireShared(1)流程,首先也是调用addWaiter添加节点,不同之处在于节点被设置为Node.SHARED模式而非Node.EXCLUSIVE模式,注意此时t2仍处于活跃状态,还没有执行park阻塞
image.png
目前为止涉及过程的源码如下:

  1. //读锁
  2. public void lock() {
  3. sync.acquireShared(1); //调用同步器方法
  4. }
  5. /*
  6. tryAcquireShared返回值表示:
  7. -1表示获取读锁失败
  8. 0表示成功,但没有后继节点,不会继续唤醒
  9. 正数表示成功,而且数值是还有几个后继节点需要唤醒,读写锁返回1(后面的信号量该方法会返回大于1的情况)
  10. */
  11. public final void acquireShared(int arg) {
  12. //尝试获取读锁,在本例中返回值是-1条件成立
  13. if (tryAcquireShared(arg) < 0)
  14. doAcquireShared(arg);
  15. }
  16. protected final int tryAcquireShared(int unused) {
  17. Thread current = Thread.currentThread();
  18. int c = getState();
  19. //查看写锁部分是否不为0,即别人是否有加写锁;在我们本例子中,因为t1线程已经加了写锁了,所以这里c不为0,条件成立,继续往后判断
  20. if (exclusiveCount(c) != 0 &&
  21. //查看是否是自己添加的写锁。因为倘若是之前自己线程添加的写锁,那么此时自己线程想要添加读锁是被允许的,因为支持锁降级(不支持锁升级)。
  22. //但是在本例中,由于添加写锁的不是自己线程所以这个条件有成立了最后返回了-1
  23. getExclusiveOwnerThread() != current)
  24. return -1; //
  25. int r = sharedCount(c);
  26. if (!readerShouldBlock() &&
  27. r < MAX_COUNT &&
  28. compareAndSetState(c, c + SHARED_UNIT)) {
  29. if (r == 0) {
  30. firstReader = current;
  31. firstReaderHoldCount = 1;
  32. } else if (firstReader == current) {
  33. firstReaderHoldCount++;
  34. } else {
  35. HoldCounter rh = cachedHoldCounter;
  36. if (rh == null || rh.tid != getThreadId(current))
  37. cachedHoldCounter = rh = readHolds.get();
  38. else if (rh.count == 0)
  39. readHolds.set(rh);
  40. rh.count++;
  41. }
  42. return 1;
  43. }
  44. return fullTryAcquireShared(current);
  45. }
  46. //这个方法里面很多流程跟独占锁里面的相似
  47. private void doAcquireShared(int arg) {
  48. //区别是添加的节点是共享类型的节点,而不是独占型节点
  49. final Node node = addWaiter(Node.SHARED);
  50. boolean failed = true;
  51. try {
  52. boolean interrupted = false;
  53. //找老二节点,才有资格去争抢锁
  54. for (;;) {
  55. final Node p = node.predecessor();
  56. if (p == head) {
  57. //若果是老二节点才会调用该方法去尝试获取锁
  58. int r = tryAcquireShared(arg);
  59. //假如获取锁失败tryAcquireShared方法会返回-1,不满足该条件
  60. if (r >= 0) {
  61. //节点的替换
  62. setHeadAndPropagate(node, r);
  63. p.next = null; // help GC
  64. if (interrupted)
  65. selfInterrupt();
  66. failed = false;
  67. return;
  68. }
  69. }
  70. //获取锁失败了是否应该将其阻塞?第一次不会park,第三次尝试还是失败就会阻塞住
  71. if (shouldParkAfterFailedAcquire(p, node) &&
  72. parkAndCheckInterrupt())
  73. interrupted = true;
  74. }
  75. } finally {
  76. if (failed)
  77. cancelAcquire(node);
  78. }
  79. }

t3 r.lock t4 w.lock

在上面分析的这种状态下,假设又有t3加读锁和t4加写锁,这期间t1仍然持有锁,就变成了下面的样子

image.png

t1 w.unlock

下面我们再来看看释放的流程,比如在上面情况的基础下,t1线程终于干完了它的活,正要调用写锁的unlock方法释放锁;这时就会走到写锁的sync.release(1)流程,里面调用tryRelease(1)方法,判断state状态的写锁部分是否减到0了,没有减到0表示有锁重入,返回false;减到0表示完全释放锁,返回成功,我们这里的例子还没有涉及锁重入,则释放锁成功,变成下面的样子

image.png
t1释放锁涉及代码

  1. public void unlock() {
  2. sync.release(1);
  3. }
  4. public final boolean release(int arg) {
  5. //本例中不涉及锁重入,释放锁成功,返回真
  6. if (tryRelease(arg)) {
  7. Node h = head;
  8. //队列中头节点不为空,且状态不为0
  9. if (h != null && h.waitStatus != 0)
  10. //唤醒后继节点
  11. unparkSuccessor(h);
  12. return true;
  13. }
  14. return false;
  15. }
  16. protected final boolean tryRelease(int releases) {
  17. if (!isHeldExclusively())
  18. throw new IllegalMonitorStateException();
  19. //在原来的基础上自减
  20. int nextc = getState() - releases;
  21. //查看state的写锁部分是否减到0了,没有减到0表示有锁重入,返回false
  22. boolean free = exclusiveCount(nextc) == 0;
  23. if (free)
  24. //减到0了就将持有者设置为null
  25. setExclusiveOwnerThread(null);
  26. setState(nextc); //重新设置状态
  27. return free;
  28. }

接下来执行唤醒流程sync.unparkSuccessor,即让老二恢复运行,这时t2在doAcquireShared内parkAndCheckInterrupt()方法处恢复运行
image.png
这回t2线程再来一次for (;;)执行tryAcquireShared 尝试获取共享读锁,成功则让读锁计数加一;我们来看看该方法内是怎么做的

  1. protected final int tryAcquireShared(int unused) {
  2. Thread current = Thread.currentThread();
  3. int c = getState();
  4. if (exclusiveCount(c) != 0 &&
  5. getExclusiveOwnerThread() != current)
  6. return -1;
  7. int r = sharedCount(c);
  8. //读锁是否阻塞
  9. if (!readerShouldBlock() &&
  10. //重入次数
  11. r < MAX_COUNT &&
  12. //用CAS操作尝试将state的高16位+1
  13. compareAndSetState(c, c + SHARED_UNIT)) {
  14. //下面的分支是去给读锁计数
  15. if (r == 0) {
  16. firstReader = current;
  17. firstReaderHoldCount = 1;
  18. } else if (firstReader == current) {
  19. firstReaderHoldCount++;
  20. } else {
  21. HoldCounter rh = cachedHoldCounter;
  22. if (rh == null || rh.tid != getThreadId(current))
  23. cachedHoldCounter = rh = readHolds.get();
  24. else if (rh.count == 0)
  25. readHolds.set(rh);
  26. rh.count++;
  27. }
  28. //表示读锁加锁成功
  29. return 1;
  30. }
  31. return fullTryAcquireShared(current);
  32. }

当读锁获取锁成功后恢复运行。但是事情还没完,在setHeadAndPropagate方法内还会检查下一个节点是否是shared状态,
image.png
如果是则调用doReleaseShared()将head 的状态从-改为О并唤醒老二,这时t3在doAcquireShared内parkAndCheckInterrupt(处恢复运行

image.png

这回t3再来一次for (;;)执行tryAcquireShared成功则让读锁计数加一,也就是state中关于读锁的部分+1,注意多个线程都可以对同一个读锁进行计数,这就是为什么这里的state读锁部分变成了2。
image.png

这时t3已经恢复运行,接下来t3调用setHeadAndPropagate(node,1),它原本所在节点被置为头节点
image.png
下一个节点不是shared 了,因此不会继续唤醒t4所在节点

t2 r.unlock,t3 r.unlock
最后再来看看读锁的释放流程,也就是刚才的t2、t3都在运行过程中,运行完了要释放读锁。
t2进入sync.releaseShared(1)中,调用tryReleaseShared(1)让计数减一,但由于计数还不为零
image.png
t3进入sync.releaseShared(1)中,调用tryReleaseShared(1)让计数减一,这回计数为零了,进入doReleaseShared()将头节点从-1改为О并唤醒老二,即t4线程
image.png
之后t4在acquireQueued 中parkAndCheckInterrupt处恢复运行,再次for (:)这次自己是老二,并且没有其他竞争,tryAcquire(l)成功,修改头结点,流程结束
image.png

  1. //读锁
  2. public void unlock() {
  3. sync.releaseShared(1);
  4. }
  5. public final boolean releaseShared(int arg) {
  6. if (tryReleaseShared(arg)) {
  7. doReleaseShared();
  8. return true;
  9. }
  10. return false;
  11. }

完整源码注释

  1. import java.util.Collection;
  2. import java.util.concurrent.TimeUnit;
  3. import java.util.concurrent.locks.Condition;
  4. import java.util.concurrent.locks.Lock;
  5. import java.util.concurrent.locks.LockSupport;
  6. import java.util.concurrent.locks.ReadWriteLock;
  7. public class ReentrantReadWriteLock implements ReadWriteLock, java.io.Serializable {
  8. private static final long serialVersionUID = -6992448646407690164L;
  9. private final ReentrantReadWriteLock.ReadLock readerLock; // 读锁
  10. private final ReentrantReadWriteLock.WriteLock writerLock;// 写锁
  11. final Sync sync; // 同步器
  12. /**
  13. * 创建默认的非公平锁
  14. */
  15. public ReentrantReadWriteLock() {
  16. this(false);
  17. }
  18. /**
  19. * 创建公平锁/非公平锁、读锁、写锁
  20. */
  21. public ReentrantReadWriteLock(boolean fair) {
  22. sync = fair ? new FairSync() : new NonfairSync(); // true则是公平锁,false则是非公平锁
  23. readerLock = new ReadLock(this); // 读锁
  24. writerLock = new WriteLock(this);// 写锁
  25. }
  26. public ReentrantReadWriteLock.WriteLock writeLock() {
  27. return writerLock;
  28. } // 返回写锁
  29. public ReentrantReadWriteLock.ReadLock readLock() {
  30. return readerLock;
  31. } // 返回读锁
  32. /**
  33. * 读写锁的同步器
  34. */
  35. abstract static class Sync extends AbstractQueuedSynchronizer {
  36. private static final long serialVersionUID = 6317671515068378041L;//序列化版本号
  37. static final int SHARED_SHIFT = 16; // 常量16,目的是将state按位右移16位得到的值就是读锁的个数
  38. static final int SHARED_UNIT = (1 << SHARED_SHIFT); // 2的16次方,实际上表示读锁加的锁次数是1
  39. static final int EXCLUSIVE_MASK = (1 << SHARED_SHIFT) - 1; // 2的16次方再减1,前面16位全0后面16位就是全1,目的就是通过&运算得到写锁的个数
  40. static final int MAX_COUNT = (1 << SHARED_SHIFT) - 1; // 2的16次方再减1,表示加锁(读/写)最大的计数超过了则抛异常
  41. private transient Thread firstReader; // 第一个获取到读锁的线程
  42. private transient int firstReaderHoldCount; // 第一个线程重入锁的次数计数
  43. private transient HoldCounter cachedHoldCounter; // 读锁计数器对象
  44. private transient ThreadLocalHoldCounter readHolds; // 在构造Sync的时候就会被赋值,重入读锁的计数器保持对象(对象中存了获取读锁的次数)
  45. /**
  46. * 构造方法
  47. */
  48. Sync() {
  49. readHolds = new ThreadLocalHoldCounter(); //
  50. setState(getState()); // 确保readHolds的可见性
  51. }
  52. /**
  53. * 读锁计数,实际存入Thread中的ThreadLocal变量中
  54. */
  55. static final class HoldCounter {
  56. int count; //获取读锁的次数,相当于线程存了线程id为key,value为获得锁的计数
  57. final long tid = LockSupport.getThreadId(Thread.currentThread());
  58. }
  59. /**
  60. * 将锁计数保持对象存入当前线程的ThreadLocal变量
  61. */
  62. static final class ThreadLocalHoldCounter extends ThreadLocal<HoldCounter> {
  63. public HoldCounter initialValue() {
  64. return new HoldCounter();
  65. }
  66. }
  67. /**
  68. * 由于读写锁的设计将state前16位用于读锁的个数,后16位标识写锁的个数因此厦门两个方法目的就是得到读锁和写锁的个数
  69. */
  70. /**
  71. * 返回读锁的个数
  72. */
  73. static int sharedCount(int c) {
  74. return c >>> SHARED_SHIFT;
  75. }
  76. /**
  77. * 返回写锁的个数
  78. */
  79. static int exclusiveCount(int c) {
  80. return c & EXCLUSIVE_MASK;
  81. }
  82. /**
  83. * 获取读锁时阻塞当前线程,由子类公平锁/非公平锁实现
  84. */
  85. abstract boolean readerShouldBlock();
  86. /**
  87. * 获取写锁时阻塞当前线程,由子类公平锁/非公平锁实现
  88. */
  89. abstract boolean writerShouldBlock();
  90. /**
  91. * 尝试释放锁
  92. */
  93. @ReservedStackAccess
  94. protected final boolean tryRelease(int releases) {
  95. if (!isHeldExclusively())//判断当前现是否是持有锁线程如果是则不执行,如果不是则需要抛异常,因为当前线程没有持有锁
  96. throw new IllegalMonitorStateException();
  97. int nextc = getState() - releases;// 计算释放锁释放合法,不允许释放超过加锁次数
  98. boolean free = exclusiveCount(nextc) == 0;//
  99. if (free) // 判断释放锁后释放锁计数是否为0,为0则说明当前线程不再是持有锁线程将其从排他线程状态清除
  100. setExclusiveOwnerThread(null);
  101. setState(nextc);// 更新锁次数计数
  102. return free;//如果释放锁后计数为0则返回true,否则返回false
  103. }
  104. /**
  105. * 这个方法是写锁调用才会执行的
  106. * 不是第一次加写锁
  107. * 因为是写锁才调用的方法,因此只需要排除前面加的都是读锁这种情况即可,也就是 c!=0 但 w==0的情况
  108. * 先判断是否加了锁c!=0,如果加了锁也就是c!=0内部的这个分支,
  109. * 是否没有加过写锁
  110. * 是否是重入写锁
  111. * 是第一次加写锁
  112. */
  113. @ReservedStackAccess
  114. protected final boolean tryAcquire(int acquires) {
  115. Thread current = Thread.currentThread();// 获取当前线程对象
  116. int c = getState(); // 获取state(前16位是读锁个数、后16位是写锁个数)
  117. int w = exclusiveCount(c);// 获得写锁的个数,w有write的含义。这个值就是写锁的个数,通过按位与 15 得到写锁个数
  118. if (c != 0) {// c!=0则说明加过锁
  119. // 如果写锁个数为0 (说明加的都是读锁,不需要阻塞因此抢占锁失败) 或者 当前线程不是持有写锁线程(w!=0说明加过写锁需要判断当前线程是否是持有写锁的那个线程,不是则说明抢占锁失败)
  120. if (w == 0 || current != getExclusiveOwnerThread())
  121. return false; // 表示抢占锁失败,这里导致了两种情况,一种是加的都是读锁,一种是加了写锁,但当前线程不是持有锁线程
  122. // 执行下面的判断都表示加过了写锁,相当于写锁的重入,因此需要将写锁计数相加也就是判断里的操作
  123. if (w + exclusiveCount(acquires) > MAX_COUNT) // 说明是重入锁,判断本次加了acquires次锁后锁计数是否超过最大值 2的16次方-1
  124. throw new Error("Maximum lock count exceeded");// 超过能加写锁的最大值则抛异常
  125. // 写锁重入,因此保留读锁加上写锁重入的acquires次,将state更新
  126. setState(c + acquires);
  127. return true;//返回true说明加锁成功
  128. }
  129. // 前面没有加过锁,需要加写锁,尝试利用CAS操作更新state进行加锁,实际上逻辑上不需要这里的if,但是应该是由于并发问题怕中途state值被改了,因此CAS操作可能失败(所以失败则return false)
  130. // c==0 说明没有加过锁,尝试将state从0更新为acquires,更新成功则说明加锁成功,因此不会返回false,而是执行后面的return true
  131. if (writerShouldBlock() || !compareAndSetState(c, c + acquires))
  132. return false;
  133. setExclusiveOwnerThread(current);// 将当前线程设置为独占线程,表示加写锁成功!
  134. return true;// 加锁成功
  135. }
  136. @ReservedStackAccess
  137. protected final boolean tryReleaseShared(int unused) {
  138. Thread current = Thread.currentThread();// 获取当前线程对象
  139. if (firstReader == current) { // 当前线程是否是第一个持有锁线程
  140. if (firstReaderHoldCount == 1) // 是否是第一次上锁后就解锁了
  141. firstReader = null; // 清除第一个读锁线程
  142. else
  143. firstReaderHoldCount--;// 将读锁计数减一
  144. } else {
  145. HoldCounter rh = cachedHoldCounter; // 得到缓存的计数器对象
  146. if (rh == null || rh.tid != LockSupport.getThreadId(current))
  147. rh = readHolds.get(); // 如果缓存的计数器对象不是当前线程的,则获取当前线程的计数器对象,重新赋值
  148. int count = rh.count; // 得到当前线程的读锁计数
  149. if (count <= 1) { // 释放锁后为0,或者过度释放,则移除计数器
  150. readHolds.remove();// 移除计数器
  151. if (count <= 0)
  152. throw unmatchedUnlockException();
  153. }
  154. --rh.count; // 锁计数减1
  155. }
  156. for (; ; ) {
  157. int c = getState(); // 获得锁计数
  158. int nextc = c - SHARED_UNIT; // 读锁计数减一
  159. if (compareAndSetState(c, nextc)) // cas操作更新state值
  160. // 释放读取锁定对读取器没有影响.但是,如果现在读和写锁都已释放,则可能允许等待的编写器继续进行.
  161. return nextc == 0;
  162. }
  163. }
  164. private static IllegalMonitorStateException unmatchedUnlockException() {
  165. return new IllegalMonitorStateException("attempt to unlock read lock, not locked by current thread");
  166. }
  167. /**
  168. * 读锁才调用的方法,当前线程尝试获取读锁
  169. */
  170. @ReservedStackAccess
  171. protected final int tryAcquireShared(int unused) {
  172. Thread current = Thread.currentThread(); // 获取当前线程
  173. int c = getState();// 获取存有读和写锁次数的state值
  174. /**
  175. * 是写锁则进入
  176. */
  177. // 通过exclusiveCount(c)得到写锁次数,如果不为0则说明加了写锁。加了写锁需要判断当前线程是否是持有写锁的线程,是则不返回-1,不是则说明是写读状态需要进行阻塞当前线程
  178. if (exclusiveCount(c) != 0 && getExclusiveOwnerThread() != current)
  179. return -1; // 说明是写读状态、返回-1,抢占读锁失败
  180. // 执行到这里说明前面没有加过写锁,可能加过读锁
  181. int r = sharedCount(c); // 获取加的读锁次数,r就是read,实际就是将state右移16位得到
  182. // 到这里说明没有加过锁,到这里c是0,因此进行加锁操作将state更新为读锁的1 实际二进制是:0000 0000 0000 0001 0000 0000 0000 0000
  183. /**
  184. * 是读锁,
  185. * 一、读是共享的情况直接执行if内
  186. */
  187. if (!readerShouldBlock() && r < MAX_COUNT && compareAndSetState(c, c + SHARED_UNIT)) {
  188. if (r == 0) { // 第一次进入,因为能到达这里就说明没有写锁,有判断r==0则说明读锁也为0,则说明是第一次调用
  189. firstReader = current; // 将第一个线程存起来
  190. firstReaderHoldCount = 1;// 计数为1
  191. } else if (firstReader == current) {
  192. firstReaderHoldCount++; // 读重入,读锁计数进行累加
  193. } else {
  194. // 说明不是获得读锁的线程进来了
  195. // tid 为key ,value为读锁次数
  196. HoldCounter rh = cachedHoldCounter;// 将当前线程初始值是null
  197. // 第一次null直接创建一个
  198. if (rh == null || rh.tid != LockSupport.getThreadId(current))
  199. cachedHoldCounter = rh = readHolds.get();// 通过ThreadLocal得到HoldCounter(计数保持器,内部存了加锁计数)
  200. else if (rh.count == 0) // 如果锁计数为0
  201. readHolds.set(rh); // 更新锁计数保持器对象
  202. rh.count++; // 计数累加
  203. }
  204. return 1;// 表示抢占读锁成功
  205. }
  206. /**
  207. * 二、读是排他的情况,调用下面这个方法
  208. */
  209. return fullTryAcquireShared(current);
  210. }
  211. /**
  212. * 读是排他的情况采用自旋方式
  213. * 完整版本的获取读,可处理CAS错误和tryAcquireShared中未处理的可重入读。
  214. */
  215. final int fullTryAcquireShared(Thread current) {
  216. /**
  217. * 该代码与tryAcquireShared中的代码部分冗余,但由于不使tryAcquireShared与重试和延迟读取保持计数之间的交互复杂化,因此整体代码更简单。
  218. */
  219. HoldCounter rh = null;
  220. for (; ; ) {// 自旋
  221. int c = getState(); // 获取读写锁计数
  222. /**
  223. * 如果存在写锁
  224. */
  225. if (exclusiveCount(c) != 0) {
  226. if (getExclusiveOwnerThread() != current)// 判断当前线程是否是持有同一把写锁的线程
  227. return -1;// 加锁失败,当前线程不是持有写锁线程
  228. }
  229. /**
  230. * 不存在写的情况
  231. */
  232. // 1.判断读是否是排他的,如果是则进入
  233. else if (readerShouldBlock()) {
  234. // 当前线程是不是第一个读锁线程,是则说明当前线程是重入的读锁线程
  235. if (firstReader == current) {
  236. // 什么也没有
  237. } else {
  238. // 如果当前线程不是第一个抢占到读锁的线程,如果锁计数存在
  239. if (rh == null) {
  240. rh = cachedHoldCounter; // 得到锁计数保持器
  241. if (rh == null || rh.tid != LockSupport.getThreadId(current)) {
  242. rh = readHolds.get(); // 得到锁计数保持器
  243. if (rh.count == 0) // 如果计数为0
  244. readHolds.remove(); // 清除保持器
  245. }
  246. }
  247. // 读锁计数保持器存在,如果等于0则抢占读锁失败,因为这个计数器在tryAcquireShared方法已经被赋值了,所以不会为0,为0说明cas操作失败了
  248. if (rh.count == 0)
  249. return -1; // 加锁失败,当前线程
  250. }
  251. }
  252. // 2.到这里说明是共享的读
  253. /**
  254. * 注意:
  255. * 如果是tryAcquireShared方法过来的其实下面不会执行到的,
  256. * 因为在tryAcquireShared方法中已经走过一遍这个逻辑了,
  257. * 这里加上这个逻辑只是处于对当前方法的封装,这样当前方法可以不用依赖tryAcquireShared方法
  258. */
  259. if (sharedCount(c) == MAX_COUNT) // 判断读锁是否超过最大值
  260. throw new Error("Maximum lock count exceeded");
  261. // 读共享,因此只需要通过cas将读锁计数累加1即可,因为CAS操作多以是单线程所以是加1
  262. if (compareAndSetState(c, c + SHARED_UNIT)) {// 更新state值
  263. // c 一开始是0,因为上面更新的不是c而是state值,如果c是0说明是第一个线程调用了这个方法,执行到了这里
  264. if (sharedCount(c) == 0) {
  265. firstReader = current; // 保存当前的第一个线程
  266. firstReaderHoldCount = 1;// 保存计数(因为是第一次进入所以是1)
  267. } else if (firstReader == current) {
  268. firstReaderHoldCount++; // 持锁的同一个线程重入读锁
  269. } else {
  270. if (rh == null)
  271. rh = cachedHoldCounter; // 其它线程尝试获取读锁,获取第一个线程产生的HoldCounter对象
  272. if (rh == null || rh.tid != LockSupport.getThreadId(current))
  273. rh = readHolds.get(); // 从ThreadLocal中获取HoldCounter对象
  274. else if (rh.count == 0)
  275. readHolds.set(rh); // 如果锁计数为0更新锁计数保持其对象
  276. rh.count++; // 读锁计数累加
  277. cachedHoldCounter = rh; // 保存读锁计数器对象
  278. }
  279. return 1; // 读锁加锁成功
  280. }
  281. }
  282. }
  283. /**
  284. * 执行tryLock进行写入,从而在两种模式下都可以进行插入。 这与tryAcquire的作用相同,只是缺少对writerShouldBlock的调用。
  285. */
  286. @ReservedStackAccess
  287. final boolean tryWriteLock() {
  288. Thread current = Thread.currentThread(); // 得到当前线程
  289. int c = getState(); // 得到锁计数
  290. if (c != 0) { // 不为0说明加过锁
  291. int w = exclusiveCount(c); // 得到写锁次数
  292. if (w == 0 || current != getExclusiveOwnerThread())
  293. return false;// 写锁被其它线程占用,当前线程抢占写锁失败
  294. if (w == MAX_COUNT)
  295. throw new Error("Maximum lock count exceeded");
  296. }
  297. // 第一次就加写锁,cas更新state值
  298. if (!compareAndSetState(c, c + 1))
  299. return false;
  300. // 将当前线程设置为独占
  301. setExclusiveOwnerThread(current);
  302. return true;// 写锁加锁成功!
  303. }
  304. /**
  305. * 执行tryLock进行读取,从而在两种模式下都可以进行插入。 除了没有调用readerReaderShouldBlock以外,这与tryAcquireShared的作用相同。
  306. */
  307. @ReservedStackAccess
  308. final boolean tryReadLock() {
  309. Thread current = Thread.currentThread(); // 获取当前线程
  310. for (; ; ) {
  311. int c = getState(); // 获取锁计数
  312. // 存在写的情况
  313. if (exclusiveCount(c) != 0 && getExclusiveOwnerThread() != current)
  314. return false;
  315. // 不存在写的情况
  316. int r = sharedCount(c); // 计算读锁的次数
  317. if (r == MAX_COUNT)
  318. throw new Error("Maximum lock count exceeded"); // 值越界
  319. if (compareAndSetState(c, c + SHARED_UNIT)) {
  320. if (r == 0) {
  321. firstReader = current; // 第一个线程进来读计数为0,保存第一个线程
  322. firstReaderHoldCount = 1; // 设置计数为1
  323. } else if (firstReader == current) { // 重入读
  324. firstReaderHoldCount++; // 读计数累加1
  325. } else {
  326. // 其它线程进入
  327. HoldCounter rh = cachedHoldCounter;// 其它线程尝试获取读锁,获取第一个线程产生的HoldCounter对象
  328. if (rh == null || rh.tid != LockSupport.getThreadId(current))
  329. cachedHoldCounter = rh = readHolds.get();// 从ThreadLocal中获取HoldCounter对象
  330. else if (rh.count == 0)
  331. readHolds.set(rh); // 如果锁计数为0更新锁计数保持其对象
  332. rh.count++; // 读计数累加
  333. }
  334. return true; // 加读锁成功
  335. }
  336. }
  337. }
  338. protected final boolean isHeldExclusively() {
  339. // 虽然我们必须在拥有者之前先阅读一下状态
  340. // 我们不需要检查当前线程是否为所有者
  341. return getExclusiveOwnerThread() == Thread.currentThread();
  342. }
  343. // 与外部有关的方法
  344. // 得到Condition对象
  345. final ConditionObject newCondition() {
  346. return new ConditionObject();
  347. }
  348. // 得到持有锁线程
  349. final Thread getOwner() {
  350. return ((exclusiveCount(getState()) == 0) ? null : getExclusiveOwnerThread());
  351. }
  352. // 得到读锁的上锁次数
  353. final int getReadLockCount() {
  354. return sharedCount(getState());
  355. }
  356. //是否上了写锁
  357. final boolean isWriteLocked() {
  358. return exclusiveCount(getState()) != 0;
  359. }
  360. // 得到写锁上锁次数
  361. final int getWriteHoldCount() {
  362. return isHeldExclusively() ? exclusiveCount(getState()) : 0;
  363. }
  364. // 得到读锁的上锁次数
  365. final int getReadHoldCount() {
  366. if (getReadLockCount() == 0) // 读锁上锁次数是否为0
  367. return 0;
  368. Thread current = Thread.currentThread(); // 获取当前线程
  369. if (firstReader == current) // 当前线程是否是第一个上读的锁线程
  370. return firstReaderHoldCount;// 返回锁计数
  371. HoldCounter rh = cachedHoldCounter; // 读计数器对象
  372. if (rh != null && rh.tid == LockSupport.getThreadId(current))
  373. return rh.count; // 返回读计数器存储的锁计数
  374. int count = readHolds.get().count; // 得到计数
  375. if (count == 0) readHolds.remove();// 清除读计数器对象
  376. return count; // 返回计数
  377. }
  378. /**
  379. * 从流中重构实例(即反序列化它)。
  380. */
  381. private void readObject(java.io.ObjectInputStream s) throws java.io.IOException, ClassNotFoundException {
  382. s.defaultReadObject();
  383. readHolds = new ThreadLocalHoldCounter();
  384. setState(0); // 重置为解锁状态
  385. }
  386. // 得到state值,读锁写锁都在
  387. final int getCount() {
  388. return getState();// 返回state
  389. }
  390. }
  391. /**
  392. * 非公平锁
  393. */
  394. static final class NonfairSync extends Sync {
  395. private static final long serialVersionUID = -8159625535654395037L;
  396. // 默认返回false
  397. final boolean writerShouldBlock() {
  398. return false;
  399. }
  400. // 阻塞当前读锁线程,如果是第一次调用就会返回false因为没有阻塞线程
  401. final boolean readerShouldBlock() {
  402. return apparentlyFirstQueuedIsExclusive(); // aqs第一个节点是排他节点则返回true,否则返回false
  403. }
  404. }
  405. /**
  406. * 公平锁
  407. */
  408. static final class FairSync extends Sync {
  409. private static final long serialVersionUID = -2274990926593161451L;
  410. final boolean writerShouldBlock() {
  411. return hasQueuedPredecessors();
  412. }
  413. final boolean readerShouldBlock() {
  414. return hasQueuedPredecessors();
  415. }
  416. }
  417. /**
  418. * ReentrantReadWriteLock.readLock()返回读锁的实例
  419. */
  420. public static class ReadLock implements Lock, java.io.Serializable {
  421. private static final long serialVersionUID = -5992448646407690164L;
  422. private final Sync sync;
  423. /**
  424. * 构造方法
  425. */
  426. protected ReadLock(ReentrantReadWriteLock lock) {
  427. sync = lock.sync;
  428. }
  429. /**
  430. * 尝试获取读锁
  431. */
  432. public void lock() {
  433. sync.acquireShared(1);
  434. }
  435. /**
  436. * 可以被中断的方式获取锁
  437. */
  438. public void lockInterruptibly() throws InterruptedException {
  439. sync.acquireSharedInterruptibly(1);
  440. }
  441. /**
  442. * 尝试获取读锁
  443. */
  444. public boolean tryLock() {
  445. return sync.tryReadLock();
  446. }
  447. /**
  448. * 超过规定的时间内抢占锁,则中断获取锁操作
  449. */
  450. public boolean tryLock(long timeout, TimeUnit unit) throws InterruptedException {
  451. return sync.tryAcquireSharedNanos(1, unit.toNanos(timeout));
  452. }
  453. /**
  454. * 释放锁
  455. */
  456. public void unlock() {
  457. sync.releaseShared(1);
  458. }
  459. /**
  460. * 不允许操作,在这里是由于实现了Lock接口不得不写这个方法,如果调用则直接抛异常
  461. */
  462. public Condition newCondition() {
  463. throw new UnsupportedOperationException();
  464. }
  465. /**
  466. * toString方法
  467. */
  468. public String toString() {
  469. int r = sync.getReadLockCount();
  470. return super.toString() +
  471. "[Read locks = " + r + "]";
  472. }
  473. }
  474. /**
  475. * 通过ReentrantReadWriteLock.writeLock()返回该对象的实例
  476. */
  477. public static class WriteLock implements Lock, java.io.Serializable {
  478. private static final long serialVersionUID = -4992448646407690164L;
  479. private final Sync sync;
  480. /**
  481. * 构造方法
  482. */
  483. protected WriteLock(ReentrantReadWriteLock lock) {
  484. sync = lock.sync;
  485. }
  486. /**
  487. * 尝试获取锁
  488. * 调用的是带一个参数的acquire方法,因此里面会进行一次尝试抢占锁,失败则进入aqs队列
  489. */
  490. public void lock() {
  491. sync.acquire(1);
  492. }
  493. /**
  494. * 以可以被中断的方式抢占锁
  495. */
  496. public void lockInterruptibly() throws InterruptedException {
  497. sync.acquireInterruptibly(1);
  498. }
  499. /**
  500. * 尝试获取锁
  501. */
  502. public boolean tryLock() {
  503. return sync.tryWriteLock();
  504. }
  505. /**
  506. * 超过规定时间则中断获取锁操作
  507. */
  508. public boolean tryLock(long timeout, TimeUnit unit)
  509. throws InterruptedException {
  510. return sync.tryAcquireNanos(1, unit.toNanos(timeout));
  511. }
  512. /**
  513. * 释放锁
  514. */
  515. public void unlock() {
  516. sync.release(1);
  517. }
  518. /**
  519. * 由于实现Lock接口不得不实现的方法,如果直接调用则直接抛异常
  520. */
  521. public Condition newCondition() {
  522. return sync.newCondition();
  523. }
  524. /**
  525. * toString方法
  526. */
  527. public String toString() {
  528. Thread o = sync.getOwner();
  529. return super.toString() + ((o == null) ?
  530. "[Unlocked]" :
  531. "[Locked by thread " + o.getName() + "]");
  532. }
  533. /**
  534. * 判断当前线程是否持有锁
  535. */
  536. public boolean isHeldByCurrentThread() {
  537. return sync.isHeldExclusively();
  538. }
  539. /**
  540. * 如果当前线程没有持有锁则返回0,否则返回加锁计数
  541. */
  542. public int getHoldCount() {
  543. return sync.getWriteHoldCount();
  544. }
  545. }
  546. /**
  547. * 是否是公平锁
  548. */
  549. public final boolean isFair() {
  550. return sync instanceof FairSync;
  551. }
  552. /**
  553. * 返回当前持有锁的线程
  554. */
  555. protected Thread getOwner() {
  556. return sync.getOwner();
  557. }
  558. /**
  559. * 获取读锁的计数
  560. */
  561. public int getReadLockCount() {
  562. return sync.getReadLockCount();
  563. }
  564. /**
  565. * 是否是写锁上的锁
  566. */
  567. public boolean isWriteLocked() {
  568. return sync.isWriteLocked();
  569. }
  570. /**
  571. * 当前线程是否是获取到写锁的线程
  572. */
  573. public boolean isWriteLockedByCurrentThread() {
  574. return sync.isHeldExclusively();
  575. }
  576. /**
  577. * 获取当前线程写锁上锁的次数
  578. */
  579. public int getWriteHoldCount() {
  580. return sync.getWriteHoldCount();
  581. }
  582. /**
  583. * 获取当前线程读锁上锁的次数
  584. */
  585. public int getReadHoldCount() {
  586. return sync.getReadHoldCount();
  587. }
  588. /**
  589. * 获取正在获取写锁的线程的集合
  590. */
  591. protected Collection<Thread> getQueuedWriterThreads() {
  592. return sync.getExclusiveQueuedThreads();
  593. }
  594. /**
  595. * 获取正在获取读锁的线程的集合
  596. */
  597. protected Collection<Thread> getQueuedReaderThreads() {
  598. return sync.getSharedQueuedThreads();
  599. }
  600. /**
  601. * 是否有线程正在等待获取 读锁或写锁
  602. */
  603. public final boolean hasQueuedThreads() {
  604. return sync.hasQueuedThreads();
  605. }
  606. /**
  607. * 判断线程是否在等待队列中
  608. */
  609. public final boolean hasQueuedThread(Thread thread) {
  610. return sync.isQueued(thread);
  611. }
  612. /**
  613. * 返回等待读或者等待写的线程的估计值
  614. */
  615. public final int getQueueLength() {
  616. return sync.getQueueLength();
  617. }
  618. /**
  619. * 返回等待读或写的线程的集合
  620. */
  621. protected Collection<Thread> getQueuedThreads() {
  622. return sync.getQueuedThreads();
  623. }
  624. /**
  625. * 是否有等待线程,有则返回true
  626. */
  627. public boolean hasWaiters(Condition condition) {
  628. if (condition == null)
  629. throw new NullPointerException();
  630. if (!(condition instanceof AbstractQueuedSynchronizer.ConditionObject))
  631. throw new IllegalArgumentException("not owner");
  632. return sync.hasWaiters((AbstractQueuedSynchronizer.ConditionObject) condition);
  633. }
  634. /**
  635. * 返回等待线程的估计数量
  636. */
  637. public int getWaitQueueLength(Condition condition) {
  638. if (condition == null)
  639. throw new NullPointerException();
  640. if (!(condition instanceof AbstractQueuedSynchronizer.ConditionObject))
  641. throw new IllegalArgumentException("not owner");
  642. return sync.getWaitQueueLength((AbstractQueuedSynchronizer.ConditionObject) condition);
  643. }
  644. /**
  645. * 返回符合Condition条件的等待线程的集合
  646. */
  647. protected Collection<Thread> getWaitingThreads(Condition condition) {
  648. if (condition == null)
  649. throw new NullPointerException();
  650. if (!(condition instanceof AbstractQueuedSynchronizer.ConditionObject))
  651. throw new IllegalArgumentException("not owner");
  652. return sync.getWaitingThreads((AbstractQueuedSynchronizer.ConditionObject) condition);
  653. }
  654. /**
  655. * toString方法
  656. */
  657. public String toString() {
  658. int c = sync.getCount();
  659. int w = Sync.exclusiveCount(c);
  660. int r = Sync.sharedCount(c);
  661. return super.toString() +
  662. "[Write locks = " + w + ", Read locks = " + r + "]";
  663. }
  664. }