在objc.io Issue 2作者用阅读和写作谈饥饿问题：
就在您认为有足够多的问题需要考虑的时候，一个新的问题就出现了。锁定共享资源会导致读写器问题。在许多情况下，将对资源的读取访问限制为一次访问是一种浪费。因此，只要资源上没有写锁，就可以使用读锁。在这种情况下，等待获取写锁的线程可能会被同时发生的更多读锁饿死。
我假设一个读锁只允许锁定它的东西读取值，而所有其他人都不能访问它？我知道只有在没有写锁的情况下才能读锁（因为值可能会发生变化），但是在它使用的方式上，它似乎暗示“只有在没有写锁的情况下才允许读锁”被用作效率/不浪费的手段。读锁和浪费有什么关系？
另外，谁能解释一下最后一句是什么意思？我不明白读锁会产生什么影响，或者读锁会打开什么。
【问题讨论】：
标签： multithreading
基本上它的意思是读锁允许其他项目同时读取数据。 所以想象一下下面的场景。
A 获取读取锁并开始读取。
然后 X 出现并尝试获取写锁，但不能，因为它已经被锁定了。
同时，在 A 读完之前，B 过来并获得了读锁。这是允许的，因为读锁可以是并发的。
然后，A 完成了，但是 X 仍然不能写，因为它被 B 锁定了。
然后，在 B 完成之前，C 出现并取出一个读锁。等等。
【讨论】：
当您拥有“共享读取”和“独占写入”锁时，就会出现问题。多个“共享读取”锁可以同时应用于实体，它们将阻止任何“独占写入”锁获得访问权限。
“饥饿”发生在新的“共享读取”锁不断到达时，在所有现有锁被释放之前。这可以无限期地阻止“独占写入”锁定。
有几种策略可以处理这个问题，例如，如果有“独占写入”锁等待，则阻止应用任何新的“共享读取”锁。
【讨论】：
1) 如果在共享资源上只允许一个读锁，那将是“浪费的”，因为任何只想读取共享资源的线程都必须排队并一次读取一个资源。
2) 读锁不会阻止其他线程获取读锁，但会阻止其他线程获取写锁。
3) 由于你不能写锁一个有一个或多个读锁的共享资源，如果多个线程不断请求读锁（想象它们以重叠的方式），就会发生饥饿的事情；想要写锁的线程永远无法获得它，因为总会有一个读锁。
【讨论】：