ReaderWriterLockSlim到底有多“一次性”
本文关键字：一次性 ReaderWriterLockSlim | 更新日期: 2023-09-27 18:35:50
我主要遵循IDisposable模式，对于大多数类来说，这是合理的。但ReaderWriterLockSlim让我质疑应用这种模式的可行性。ReaderWriterLockSlim.Dispose所做的只是关闭一些事件句柄。那么，用如此少的资源Dispose这样的班级有多重要呢？在这种情况下，我真的不介意 GC 是否必须等待另一轮才能完成非托管资源的终结者。
但是，应用 IDisposable 模式的后果是相当大的，现在每个使用一次性类的类也必须实现IDisposable。在我的特殊情况下，我正在为HashSet实现一个包装器。我并不特别期望要求处理此类对象，因为意外地，它使用了同步器。
在这种情况下，有什么理由不违反一次性模式吗？虽然我很渴望这样做，但在实践中我不会这样做，因为违反一致性要糟糕得多。
非托管操作系统句柄的问题在于句柄来自有限的供应。总理事会不知道这一点。
句柄的纯内存消耗并不大。只不过是内核内存中的一个对象，可能是某处的哈希表条目。
你是对的，仅仅说："你必须始终处理所有一次性物品"是不够的。这个规则太简单了。例如，不需要释放Task类。如果你知道你在做什么，你可以对处置采取更宽松的立场。请注意，并非所有团队成员都理解这一点（现在您可以在源代码中留下指向此答案的链接......
如果您确定不会泄漏很多手柄，则可以安全地执行此操作。请注意，在边缘条件（负载、错误等）下，泄漏量可能会超过预期，从而导致生产问题。
如果此字段static则无需释放它，它将（righty）具有与应用程序相同的生存期。我看到不是，让我们继续前进。
处理 IDisposable 的正确方法是处置它。我认为我们需要一个很好的理由不这样做。
使用另一个锁：
我认为最好的办法是使用Monitor或其他锁，这也将具有简化代码的好处。 ConcurrentDictionary和其他框架类似乎采用这种方法。
您担心锁传达，但我不确定这是否可以通过ReaderWriterLockSlim来解决，唯一真正的解决方案是少握锁并握住它们更少的时间。
不要处置：
这需要一个理由。您能否在此处展示所需的性能优势？
如果你有一些长寿的物品，很好，并非所有一次性用品都同样重要（这不像你让word文档打开），你可能会侥幸逃脱。正如已经指出的那样，无论如何，在应用程序关闭之前处理所有这些毫秒有什么意义。我相信 IDisposable 的析构函数旨在处理未释放对象的情况，尽管您无法确定何时甚至是否调用它。
但是，如果您有一个长期的应用程序，并且有很多此类的短期用法，您可能会遇到麻烦。你正在烘焙你对代码使用的假设，只是要注意。