为什么 IDisposable.Dispose()
并发调用会出问题
很多实现
IDisposable的类（比如
FileStream、自定义资源包装器）内部没有对
Dispose()做线程安全防护。多次并发调用
Dispose()可能导致：重复释放非托管句柄、
ObjectDisposedException被抛出、甚至内存损坏（尤其涉及
SafeHandle或 P/Invoke 场景）。.NET 本身不保证
Dispose()是可重入的——它只承诺「调用一次后对象进入已释放状态」，没说「调用多次是否安全」。
用 Interlocked.CompareExchange
实现原子标记
最轻量、无锁、且被 .NET 运行时广泛采用的方式是用一个
int字段做“是否已释放”标记，配合
Interlocked.CompareExchange判断并设置。这是微软在
Stream、
Timer等 BCL 类型中的实际做法。
private int _disposed = 0; // 0 = not disposed, 1 = disposed
public void Dispose()
{
if (Interlocked.CompareExchange(ref _disposed, 1, 0) == 0)
{
// 真正的释放逻辑，只执行一次
DisposeCore();
GC.SuppressFinalize(this);
}
}
private void DisposeCore()
{
// 释放托管资源（如其他 IDisposable 对象）
_stream?.Dispose();
// 释放非托管资源（如 CloseHandle、free()）
if (_handle != IntPtr.Zero)
{
NativeMethods.CloseHandle(_handle);
_handle = IntPtr.Zero;
}
}
注意 Dispose(bool)
模式下的并发陷阱
如果你沿用经典的双参数
Dispose(bool disposing)模式，**不能直接在两个入口（
Dispose()和终结器）里都加
Interlocked判断**——因为终结器线程和用户线程可能同时闯入，而
GC.SuppressFinalize(this)必须在首次
Dispose()时就调用，否则终结器仍可能运行。
Dispose()方法里必须调用
Interlocked.CompareExchange+
GC.SuppressFinalize
~MyClass()终结器里**只能调用
DisposeCore(false)，且不能做任何
Interlocked检查或再调用
GC.SuppressFinalize**（此时已无意义） 所有资源释放逻辑（包括托管和非托管）统一收口到
DisposeCore(bool disposing)，但要根据
disposing参数决定是否释放托管资源
别依赖 lock
或 Monitor
做 Dispose 同步
看似简单，但风险很高：
如果Dispose()内部释放的资源本身涉及同步（比如关闭一个正在被读写的
NetworkStream），再套一层
lock容易引发死锁 终结器线程不能获取普通锁（
Monitor.Enter在终结器中可能永久阻塞） 性能上，
Interlocked是无锁原子操作，比锁快一个数量级，且无上下文切换开销 只要确保
_disposed字段是
volatile或通过
Interlocked访问，就不需要额外
volatile声明 真正难的是判断哪些资源允许重复释放、哪些绝对不行。比如
CancellationTokenSource.Cancel()是幂等的，但
SafeHandle.SetHandleAsInvalid()不是——一旦设为无效，再次调用会抛异常。所以「只 Dispose 一次」不是为了代码好看，而是防止底层系统调用崩掉。
