为什么无法检查当前线程是否持有 ReentrantReadWriteLock 的读锁？答案

【问题标题】：Why there is no way to check if current thread holds the read lock of ReentrantReadWriteLock?为什么无法检查当前线程是否持有 ReentrantReadWriteLock 的读锁？
【发布时间】：2012-12-05 23:15:30
【问题描述】：

我发现ReentrantReadWriteLock的写锁提供了isHeldByCurrentThread()方法来检查调用线程是否持有那个锁。

但是读锁没有对应的isHeldByCurrentThread()方法。为什么不呢？

【问题讨论】：

标签： java multithreading concurrency java.util.concurrent concurrent-programming

【解决方案1】：

ReentrantReadWriteLock.getReadHoldCount() 似乎可以完成这项工作。

【讨论】：

只要您的代码不执行可重入读锁，这将起作用
不，它没有。假设 ThreadA 获得了读锁。现在计数为 1。在 ThreadA 释放锁之前，ThreadB 依赖 getReadHoldCount() > 0 并进入“受保护”代码。现在 ThreadA a 释放了锁，但 ThreadB 仍然在受保护的代码中。 ThreadC 发挥作用，获取写锁，获取它（因为读者计数为零），并更新一些数据。 -> ThreadB 看到不一致的数据。

【解决方案2】：

我认为答案在 Doug Leas 对此问题的评论中：http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6207928。

道格·李写道：

当前的设计和行为是有意的。读锁通常没有定义为具有所有权的概念，因此无法测试所有权。 ... JSR166 EG 已收到一些请求，以可选地支持每线程读取保持跟踪。这样做会显着增加锁开销，因此需要由可选的构造参数控制。我们正在调查。

【讨论】：

好的，我明白了。不过我希望有一些方法可以检查当前线程是否持有 ReentrantReadWriteLock 的读锁。