Java StampedLock:当有人阅读时，作者会发生什么？

Question

从文档中还不清楚，当readLock被保存时，读者和编写线程会发生什么情况。

我说的是这个时机：

1. 读取器线程(或一些读取器线程)来获取readlock，目的是在某个多字段对象上调用一些getter。
2. 在getter群的中间有Writer线程，需要writeLock，并打算显着地更改对象状态
3. 另外，更多的读取器的目的是获取readlock并调用所有getter。

因此，问题是：

• (似乎是)，作者线程是否在等待来自第一组的所有读者调用unlockRead(邮票)？因此，每个读者都可以在保存readLock时看到一致的状态(与tryOptimisticRead ->相反，如果作者来了，可能会出现不一致)？

我对19位读者和1位作家进行了一次测试，几乎每一次，作者线程的表现都是等待了一段时间，然后才完成了它的虚拟工作。作者代码在下面，读者代码非常相似。

// lock is a shared StampedLock  
// state is an AtomicBoolean that readers tried to 'dirty read'
def start = currentTimeMillis()
def stamp = lock.writeLock() 
try {
  state.set(!state.get()) 
  def sleepTime = ThreadLocalRandom.current().nextInt(100,200)
  sleep(sleepTime)
  println("WRITER: I waited for ${currentTimeMillis() - start - sleepTime} ms and worked for ${sleepTime}")
} finally {
  lock.unlock(stamp)
}

• (最肯定的是，是的，但仍然提到)第3组的所有读者都会等待unlockWrite(邮票)的撰稿人吗？

所以，打电话给unlockRead(.)有两个意图:防止同一个线程中的死锁，并允许作者获得独占的写入器锁？

更新:下面是一个ReadWriteLock上的视频逻辑，非常类似于踩踏锁。

Answer 1

任何数量的线程都可以在没有保存readLock的情况下获取writeLock。一旦请求一个写入线程，就会发生三件事(假设readLock由一个或多个线程持有)

1. 挂起writeLock线程
2. 来自非读锁线程的任何readLock请求都会排在writeLock线程的后面(防止编写器饥饿)。
3. 任何读锁线程都可以在同一锁(重入)上readLock。

一旦解除了所有readLock的锁定，最后一个要解锁的线程将通知/释放等待在writeLock上的线程。

对你的问题：

作者线程是否在等待来自第一组的所有读者调用unlockRead(邮票)？因此，每个读者都可以在保存readLock时看到一致的状态(与tryOptimisticRead ->相反，如果作者来了，可能会出现不一致)？

是的，假设所有修改线程都是在writeLock下进行的，那么当线程持有一个readLock时，可以安全地假定它不会改变。

第三组的所有读者都会等待unlockWrite(邮票)的作者吗？

是的，当一个readLock被持有时，writeLock会阻塞。