17370845950

CancellationToken 不能直接取消 IAsyncDisposable.DisposeAsync()，因为其签名固定为 ValueTask DisposeAsync()，不接收 CancellationToken 参数；需手动保存并检查 token，在清理逻辑中显式传递或响应。

为什么 CancellationToken 不能直接取消 IAsyncDisposable.DisposeAsync()

因为 IAsyncDisposable.DisposeAsync() 本身不接收 CancellationToken 参数——它的签名固定为 ValueTask DisposeAsync()。你无法像 HttpClient.GetAsync(uri, cancellationToken) 那样传入 token 来中断释放逻辑。这意味着：如果 DisposeAsync() 内部执行了耗时的异步清理（比如等待远端服务确认断连、刷盘、关闭长连接），它不会响应外部取消请求。

在 DisposeAsync 中手动检查 CancellationToken 的正确姿势

必须把 CancellationToken 持有为字段或闭包变量，并在 DisposeAsync() 实现里显式轮询或传递给可取消的子操作。常见错误是只在构造时捕获 token，却没在释放路径中使用它。

• 把 CancellationToken 存为私有只读字段（如 private readonly CancellationToken _ct;），构造时传入并保存
• 在 DisposeAsync() 中优先检查 _ct.IsCancellationRequested，快速返回
• 将 _ct 传给所有支持 cancel 的子调用，例如 stream.WriteAsync(buffer, _ct)、semaphore.WaitAsync(_ct)
• 避免在 DisposeAsync() 中启动新 Task.Run 或忽略 token 的阻塞调用（如 Thread.Sleep、无 token 版 Wait()）

public class ResilientResource : IAsyncDisposable
{
    private readonly CancellationTokenSource _cts;
    private readonly Stream _stream;

    public ResilientResource(Stream stream, CancellationToken ct = default)
    {
        _stream = stream;
        _cts = CancellationTokenSource.CreateLinkedTokenSource(ct);
    }

    public async ValueTask DisposeAsync()
    {
        if (_cts.Token.IsCancellationRequested)
            return;

        try
        {
            await _stream.FlushAsync(_cts.Token).ConfigureAwait(false);
            await _stream.DisposeAsync().ConfigureAwait(false);
        }
        catch (OperationCanceledException) when (_cts.Token.IsCancellationRequested)
        {
            // 预期行为：子操作因 token 被取消，静默处理
        }
        finally
        {
            _cts.Dispose();
        }
    }
}

结合 using await 和 CancellationToken 的实际调用方式

调用方必须确保 CancellationToken 在整个生命周期内

有效，且不能在 using await 块外提前触发 Cancel()，否则 DisposeAsync() 可能刚进入就立即退出，导致资源未清理。

• 不要用 var cts = new CancellationTokenSource(); cts.Cancel(); using await ... —— token 已失效
• 推荐在 async 方法内统一管理：用 using var cts = new CancellationTokenSource(timeoutMs);，再传入构造函数和后续逻辑
• using await 语句本身不接受 token，取消只能靠资源内部响应，所以依赖上面的手动检查机制
• 若需“强制超时取消 DisposeAsync”，得在外层套一层 WaitAsync(ct) 包装，但要注意这会丢失原生 ValueTask 性能优势

await using var resource = new ResilientResource(stream, cts.Token);
await DoWorkAsync(resource, cts.Token);

// 此处 cts.Cancel() 触发后，resource.DisposeAsync() 内部会响应

容易被忽略的线程安全与状态竞争点

DisposeAsync() 可能被多次调用（尤其在异常路径或并发场景下），而 CancellationToken 的检查和清理逻辑若没加锁或状态标记，会导致重复释放、NullReference 或竞态取消。

• 添加私有 private volatile bool _disposed; 字段，首次进入时设为 true，后续直接 return
• 不要在 DisposeAsync() 中修改共享状态后再检查 IsCancellationRequested —— 顺序错乱会导致漏响应
• CancellationToken.Register() 是危险操作：注册的回调可能在 token 已取消后仍执行，且难以控制执行上下文；优先用 ThrowIfCancellationRequested() 或 WaitAsync(ct)
• 如果底层资源（如 NetworkStream）本身不支持 cancel on dispose，强行注入 token 也无效——得换更底层可控的实现

CancellationToken 和 IAsyncDisposable 的结合不是自动生效的魔法，关键在于你是否在 DisposeAsync 的每一行清理代码里，都把它当作一个需要主动倾听的信号。