我主要遵循IDisposable模式，对于大多数合理的类。但ReaderWriterLockSlim让我质疑应用这种模式的可行性。所有ReaderWriterLockSlim.Dispose都关闭了一些事件句柄。那么资源如此之少的Dispose这样的课程有多重要？在这种情况下，我真的不介意GC是否必须等待另一轮非完整资源的终结者才能完成。
应用IDisposable模式的后果相当可观，但是现在每个使用一次性类的类都必须实现IDisposable。在我的特定情况下，我正在为HashSet实现一个包装器。我并不特别期望处理这种物体的要求，因为它意外地使用了同步器。
在这种情况下，是否有任何理由不违反一次性模式？虽然我很渴望，但在实践中我不会这样做，因为违反一致性会更糟。
答案 0 :(得分：4)
非托管操作系统句柄的问题是handles come from a limited supply. GC不知道这一点。
句柄的纯内存消耗并不是那么大。只不过是内核内存中的对象，可能是某处的哈希表条目。
你是对的，仅仅说：＆＃34;你必须总是处理所有一次性物品＆＃34;。这个规则太简单了。 For example the Task class does not need to be disposed.如果你知道自己在做什么，你可以对处置采取更宽松的立场。请注意，并非所有团队成员都能理解这一点（现在您可以在源代码中留下此答案的链接......）。
如果您确定不会泄漏大量手柄，则可以安全地执行此操作。请注意，在边缘条件下（负载，错误，......），您可能会泄漏更多的预期导致生产问题。
答案 1 :(得分：1)
如果此字段为static you don't need to dispose of it，则它（右）与您的应用具有相同的生命周期。我看到它不是，让我们继续前进。
处理IDisposable的正确方法是处理它。我认为我们需要一个很好的理由不这样做。
使用其他锁：
我认为最好的办法是使用Monitor或其他锁，这样可以简化您的代码。 ConcurrentDictionary和其他框架类似乎采用这种方法。
你担心锁定传达，但我不确定这是否由ReaderWriterLockSlim解决，唯一真正的解决方案是保持较少的锁并保持它们的时间较短。
不要处置：
这需要一个理由。你能在这里证明所需的性能优势吗？
如果你有一些这些长寿的物品，很好，不是所有的一次性物品都具有同等重量（它不像你打开一个word文件），你可能会侥幸逃脱它。正如已经指出的那样，在应用程序关闭之前处理所有这几毫秒的重点是什么。我相信IDisposable的析构函数是为了处理没有处理对象的情况，尽管你无法确定何时或甚至是否被调用。
但是，如果你有一个长期存在的应用程序，并且有很多这种类的短命用法，那么你可能会遇到麻烦。您正在烘焙关于代码使用的假设，请注意。