向 IDisposable 对象添加线程安全性的正确方法是什么？

Question

想象一下 IDisposable 接口的实现，它有一些公共方法。

如果该类型的实例在多个线程之间共享，并且其中一个线程可能会处置它，那么确保其他线程在处置后不会尝试使用该实例的最佳方法是什么？在大多数情况下，在对象被释放后，其方法必须知道它并抛出 ObjectDisposeException 或 InvalidOperationException 或至少通知调用代码做错了什么。我是否需要对每个方法进行同步 - 特别是在检查它是否被处置时？具有其他公共方法的所有 IDisposable 实现都需要是线程安全的吗？

---

这是一个例子：

public class DummyDisposable : IDisposable
{
    private bool _disposed = false;

    public void Dispose()
    {
        _disposed = true;
        // actual dispose logic
    }

    public void DoSomething()
    {
        // maybe synchronize around the if block?
        if (_disposed)
        {
            throw new ObjectDisposedException("The current instance has been disposed!");
        }

        // DoSomething logic
    }

    public void DoSomethingElse()
    {
         // Same sync logic as in DoSomething() again?
    }
}

Answer 1

我倾向于使用整数而不是布尔值作为存储已处置状态的字段，因为这样您就可以使用线程安全的 Interlocked 类来测试 Dispose 是否已被调用。

像这样的事情：

private int _disposeCount;

public void Dispose()
{
    if (Interlocked.Increment(ref _disposeCount) == 1)
    {
        // disposal code here
    }
}

这确保无论调用该方法多少次，处理代码都只被调用一次，并且是完全线程安全的。

然后每个方法都可以非常简单地使用调用此方法作为屏障检查：

private void ThrowIfDisposed()
{
   if (_disposeCount > 0) throw new ObjectDisposedException(GetType().Name);
}

关于同步每个方法 - 您是说简单的屏障检查不起作用 - 您想要停止可能已经在执行代码的其他线程在实例中。这是一个更复杂的问题。我不知道你的代码在做什么，但考虑一下你是否真的需要它 - 简单的屏障检查不行吗？

如果您只是指已处理的支票本身 - 我上面的例子就很好。

编辑：回答评论“这和 volatile bool 标志有什么区别？有一个名为 SomethingCount 的字段并允许它仅保存 0 和 1 值有点令人困惑”

Volatile 与确保读或写操作操作是原子且安全的。它不会使分配和检查值的过程线程安全。因此，例如，尽管有 volatile，以下内容也不是线程安全的：

private volatile bool _disposed;

public void Dispose()
{
    if (!_disposed)
    {
        _disposed = true

        // disposal code here
    }
}

这里的问题是，如果两个线程靠近在一起，第一个线程可能会检查 _dispose，读取 false，进入代码块并在将 _dispose 设置为 true 之前切换出去。然后第二个检查 _dispose，看到 false 并且也进入代码块。

使用 Interlocked 可确保分配和后续读取都是单个原子操作。

Answer 2

您可以做的最简单的事情是将私有已处置变量标记为 易失性 并在方法的开头检查它。如果该对象已被释放，您可以抛出ObjectDisposeException。

对此有两个注意事项：

1. 如果该方法是事件处理程序，则不应抛出ObjectDisposeException。相反，如果可能的话，您应该优雅地退出该方法。原因是存在竞争条件，在您取消订阅事件后可以引发事件。 （请参阅这篇文章 Eric Lippert 了解更多信息。）

2. 当您正在执行某个类方法时，这并不能阻止您的类被释放。因此，如果您的类具有在处置后无法访问的实例成员，您将需要设置一些锁定行为以确保对这些资源的访问受到控制。

微软关于 IDisposable 的指南说你应该检查所有方法的 Dispose，但我个人认为没有必要。问题实际上是，如果您允许在类被释放后执行方法，是否会引发异常或导致意外的副作用。如果答案是肯定的，您需要做一些工作以确保不会发生这种情况。

关于所有 IDisposable 类是否都应该是线程安全的：否。一次性类的大多数用例都涉及它们仅由单个线程访问。

话虽这么说，您可能想调查为什么需要一次性类是线程安全的，因为它增加了很多额外的复杂性。可能有一个替代实现，使您不必担心一次性类中的线程安全问题。

Answer 3

大多数 Dispose 的 BCL 实现都不是线程安全的。这个想法是由 Dispose 的调用者来确保在 Dispose 之前没有其他人在使用该实例。换句话说，它将同步责任向上推。这是有道理的，否则现在所有其他消费者都需要处理对象在使用时被处置的边界情况。

也就是说，如果您想要一个线程安全的 Disposable 类，您可以在每个公共方法（包括 Dispose）周围创建一个锁，并在顶部检查 _dispose。如果您有长时间运行的方法并且您不想持有整个方法的锁，这可能会变得更加复杂。

Answer 4

我更喜欢在整数类型对象“dispose”或“state”变量上使用整数和 Interlocked.Exchange 或 Interlocked.CompareExchange ；如果 Interlocked.Exchange 或 Interlocked.CompareExchange 可以处理此类类型，我会使用 enum，但遗憾的是它们不能。

大多数关于 IDisposable 和终结器的讨论都没有提到的一点是，虽然对象的终结器在 IDisposable.Dispose() 正在进行时不应该运行，但类无法阻止其类型的对象被声明为死亡，然后复活了。可以肯定的是，如果外部代码允许这种情况发生，显然不能要求对象“正常工作”，但是 Dispose 和 Finalize 方法应该受到足够好的保护，以确保它们不会损坏任何 其他对象的状态，这通常需要对对象状态变量使用锁或互锁操作。

Answer 5

您必须锁定对要处置的资源的所有访问权限。我还添加了我通常使用的 Dispose 模式。

public class MyThreadSafeClass : IDisposable
{
    private readonly object lockObj = new object();
    private MyRessource myRessource = new MyRessource();

    public void DoSomething()
    {
        Data data;
        lock (lockObj)
        {
            if (myResource == null) throw new ObjectDisposedException("");
            data = myResource.GetData();
        }
        // Do something with data
    }

    public void DoSomethingElse(Data data)
    {
        // Do something with data
        lock (lockObj)
        {
            if (myRessource == null) throw new ObjectDisposedException("");
            myRessource.SetData(data);
        }
    }

    ~MyThreadSafeClass()
    {
        Dispose(false);
    }
    public void Dispose() 
    { 
        Dispose(true); 
        GC.SuppressFinalize(this);
    }
    protected void Dispose(bool disposing) 
    {
        if (disposing)
        {
            lock (lockObj)
            {
                if (myRessource != null)
                {
                    myRessource.Dispose();
                    myRessource = null;
                }
            }
            //managed ressources
        }
        // unmanaged ressources
    }
}

Answer 6

FWIW，您的示例代码与我和我的同事通常处理此问题的方式相匹配。我们通常在类上定义一个私有 CheckDispose 方法：

private volatile bool isDisposed = false; // Set to true by Dispose

private void CheckDisposed()
{
    if (this.isDisposed)
    {
        throw new ObjectDisposedException("This instance has already been disposed.");
    }
}

然后我们在所有公共方法的顶部调用 CheckDispose() 方法。

如果认为可能存在线程争用，而不是错误情况，我还将添加一个公共 IsDispose() 方法（类似于 Control.IsDispose）。

---

更新：根据关于使 isDispose 易失性的值的评论，请注意，考虑到我如何使用 CheckDispose() 方法，“栅栏”问题相当微不足道。它本质上是一个故障排除工具，用于快速捕获代码在对象已被释放后调用公共方法的情况。在公共方法开始处调用 CheckDispose() 并不能保证该对象不会在该方法中被释放。如果我认为这是我的类设计中固有的风险，而不是我未能考虑到的错误条件，那么我将使用前面提到的 IsDispose 方法以及适当的锁定。