使用ReaderWriterLock的真正缺点是什么？我们有针对.NET2.0RTM的项目（是的，应该是.NET2.0RTM，我们有一些正统的客户）。我只是想知道ReaderWriterLock的缺点是什么？为什么每个人都说“不要使用它，尝试使用锁定语句或其他东西”如此糟糕？如果我们可以使用.NET3.5，我肯定会使用ReaderWriterLockSlim，但是对于ReaderWriterLock，我有点害怕来自各处的所有这些警告。有没有人测量过性能或其他东西？如果存在一些性能问题，我们可以在哪些有效载荷下遇到它们？就ReaderWriterLock的主要目的而言，我们有一个经典的情况，就是读多写少。使用锁定语句会阻止所有读者。也许这对我们来说不是一个可怕的问题，但如果我可以使用ReaderWriterLock我会更开心。在我看来，引入多台显示器确实是一个非常糟糕的主意。这里有几篇文章可以让你了解你想要什么。ReaderWriterLockSlim与ReaderWriterLock的性能比较RicoMariani关于使用ReaderWriterLock部分本文解释了使用ReaderWriterLock的一些成本和场景，同时检查第1部分和第2部分JeffreyRichter是ReaderWriterLock的替代品如果您真的面临ReaderWriterLock理想用例（即许多并发读取和少量写入），然后使用它！如果您发现它太慢，还有其他选择。Sanjeevakumar在他的回答中提供了一些链接。我也会提供一个：低锁技术的实际应用：实现Reader-WriterLocks我会在这里引用那个链接：以上是C#学习教程：WhataretherealdisadvantagesofusingReaderWriterLock?分享的所有内容，如果对你有用，需要进一步了解C#学习教程，希望大家多多关注——使用我第一篇文章中建议的读写锁。如果锁定性能是一个问题，这里是作为.NETSystem.ReaderWriterLock的“直接”替代品的实现。在Microsoft修复其库中的版本之前，请随意使用此实现。扭锁是一种非常有价值的低锁技术。这里使用干净、简单但有效的读写锁，在托管代码中高效编写。这个锁比我见过的大多数实现要简单得多，但效果最好。这样做的原因是自旋锁的使用在不牺牲性能的情况下极大地简化了锁的设计和分析。随意使用此处显示的自旋锁实现来构建其他高性能并发结构。即使像Reader-Writer锁这样简单的东西也会对其行为产生微妙的影响（尤其是当您考虑性能问题时）。保持简单在这里真的很有用。本文收集自网络，不代表立场。如涉及侵权，请点击右侧联系管理员删除。如需转载请注明出处：
