Java StampedLock：当有人阅读时作者会发生什么

Question

从文档中不清楚，reader 和 writer 线程会发生什么情况，以防在 readLock 被持有时尝试进行写入。

我说的是这个时机：

Reader 线程（或一些 reader 线程）来获取读锁，目的是在某个多字段对象上调用一些 getter
在 getters swarm 中间出现了 Writer 线程并需要 writeLock，并打算显着改变对象状态
此外，更多 reader 的目的是获取读锁并调用所有 getters

所以，问题是：

(似乎是) writer线程是否在等待第1组的所有readers调用unlockRead(stamp)？所以每个 reader 是 gua运行teed 在持有 readLock 的同时看到一致的状态（反对 tryOptimisticRead -> 它声明如果 writer 来了可能会出现不一致）？

我运行测试了 19 个 reader 和 1 个 writer，几乎每次发生 writer thread 在执行它的虚拟工作之前等待一段时间。作者代码如下，reader的代码很相似

// 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 组的所有 reader 是否会等待作者解锁写入（戳记）？

那么，调用 unlockRead(...) 有两个目的：防止同一线程中出现死锁，并允许写入者获得独占写入者锁？

更新：这里是 video on ReadWriteLock - 逻辑与 stampedlock

非常相似

Answer 1

任何数量的线程都可以获得 readLock 而没有 writeLock 被持有。一旦请求写入线程，就会发生三件事（假设 readLock 被一个或多个线程占用）

writeLock线程挂起
来自非读锁定线程的任何 readLock 请求都在 writeLock 线程后面排队（防止写入器饥饿）
任何读锁定线程都能够 readLock 同一锁（可重入）。

一旦所有 readLock 解锁，最后一个要解锁的线程将 notify/release 线程等待 writeLock。

针对您的问题：

Is writer thread waiting for all readers from group 1 to call unlockRead(stamp)? So each reader is guaranteed to see consistent state while holding readLock (opposed to tryOptimisticRead -> it's stated that inconsistencies may occur if a writer comes)?

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

will all readers from group 3 wait for writer to unlockWrite(stamp) ?

是的，readLock 将在持有 writeLock 时阻止。

Java StampedLock：当有人阅读时作者会发生什么

Java StampedLock: what happens to writer while someone is reading

java

concurrency

groovy

multithreading

stampedlock