IDisposable.Dispose() 并发调用不安全，因多数实现未加线程保护，可能导致重复释放、ObjectDisposedException 或内存损坏；应使用 Interlocked.CompareExchange 原子标记已释放状态，确保 DisposeCore 仅执行一次。
为什么 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() 时就调用，否则终结器仍可能运行。
基于 AIOZ Stream API 的免费音频上传技能，通过三步流程（Create → Upload Part → Complete）将本地音频文件上传至 AIOZ 流媒体平台。支持默认快速上传方式，使用默认编码配置，上传完成后返回 HLS 流媒体播放链接。使用 API Key (stream-publ...)进行认证。
-
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 一次」不是为了代码好看，而是防止底层系统调用崩掉。
