.NET取消令牌实战：原理、陷阱与性能优化

1. 项目概述：为什么需要关注.NET取消令牌？

在构建高并发、高可用的.NET应用时，取消令牌（CancellationToken）是每个开发者必须掌握的武器。我在处理一个日均百万级请求的电商系统时，曾因为忽略取消令牌的合理使用，导致服务器资源被无效请求大量占用，最终引发连锁雪崩。那次事故后，我花了三个月系统研究CancellationToken的每个细节。

取消令牌本质上是一种协作式取消模式，它允许我们将取消请求从调用方传播到异步操作链中的每个环节。与强制终止线程不同，这种机制更安全、更可控。想象一下餐厅用餐场景：当顾客按下"取消订单"按钮（触发取消请求），服务员（调用方）不会直接抢走你手中的餐具（强制终止），而是礼貌地告知厨师（异步任务）停止当前菜品制作（协作式取消）。

2. 核心机制深度解析

2.1 令牌传播的底层原理

CancellationToken的核心是共享的CancellationTokenSource（CTS）。当调用Cancel()时，CTS通过内存屏障（Memory Barrier）确保状态变更立即对所有线程可见。以下是一个典型的生产者-消费者模式实现：

csharp复制var cts = new CancellationTokenSource();
var token = cts.Token;

// 生产者
Task.Run(() => {
    while (!token.IsCancellationRequested) {
        var item = ProduceItem();
        buffer.Add(item);
    }
}, token);

// 消费者
Task.Run(() => {
    foreach (var item in buffer.GetConsumingEnumerable(token)) {
        ProcessItem(item);
    }
}, token);

关键点在于GetConsumingEnumerable内部会周期性地检查token状态，这种模式比轮询IsCancellationRequested更高效。

2.2 超时控制的实现细节

生产环境中经常需要设置操作超时，但直接使用CancellationTokenSource.CreateLinkedTokenSource可能隐藏资源泄漏风险：

csharp复制// 危险示例：未释放的Timer
using var cts = new CancellationTokenSource();
cts.CancelAfter(TimeSpan.FromSeconds(5));

// 正确做法：显式处理Timer
var cts = new CancellationTokenSource();
var timer = new Timer(_ => cts.Cancel(), null, 5000, Timeout.Infinite);
try {
    await LongRunningOperationAsync(cts.Token);
} finally {
    timer.Dispose();
}

3. 生产环境五大陷阱与解决方案

3.1 陷阱一：未传播取消令牌

最常见的错误是在异步调用链中丢失令牌。我曾见过一个案例：前端请求超时后，后端仍在执行完整的SQL查询。解决方法是在每个方法签名中显式传递token：

csharp复制public async Task ProcessOrderAsync(Order order, CancellationToken token) {
    await ValidateOrderAsync(order, token);
    await ChargePaymentAsync(order, token);
    await SaveToDatabaseAsync(order, token); // 确保每个方法都接收token
}

3.2 陷阱二：忽略资源清理

取消操作时经常忘记释放非托管资源。正确的模式应该是：

csharp复制await using var file = new FileStream("data.bin", FileMode.Open);
try {
    var buffer = new byte[1024];
    await file.ReadAsync(buffer, 0, buffer.Length, token);
} catch (OperationCanceledException) {
    // 自动调用DisposeAsync()
}

3.3 陷阱三：过度轮询检查

频繁检查IsCancellationRequested会导致性能问题。对于CPU密集型循环，建议每N次迭代检查一次：

csharp复制for (int i = 0; i < 1_000_000; i++) {
    if (i % 1000 == 0 && token.IsCancellationRequested) {
        break;
    }
    // 计算逻辑
}

3.4 陷阱四：错误处理顺序

异常处理顺序直接影响系统健壮性。标准模式应该是：

csharp复制try {
    await operation.ExecuteAsync(token);
} catch (OperationCanceledException) when (token.IsCancellationRequested) {
    // 显式取消的专用处理
} catch (OperationCanceledException) {
    // 超时等其他取消类型
} catch (Exception ex) {
    // 其他异常
}

3.5 陷阱五：令牌生命周期管理

长时间运行的令牌可能导致内存泄漏。对于Web应用，建议将令牌与请求生命周期绑定：

csharp复制// ASP.NET Core中的正确用法
[HttpGet]
public async Task<IActionResult> GetData(CancellationToken requestAborted) {
    var data = await _service.GetLargeDataAsync(requestAborted);
    return Ok(data);
}

4. 高级应用场景

4.1 分布式系统中的取消传播

在微服务架构中，取消请求需要跨服务传播。我们可以通过HTTP头传递取消信息：

csharp复制// 发送方
using var cts = new CancellationTokenSource();
var request = new HttpRequestMessage();
request.Headers.Add("X-Cancellation-Token", cts.Token.GetHashCode().ToString());

// 接收方
if (Request.Headers.TryGetValue("X-Cancellation-Token", out var tokenHash)) {
    var linkedCts = CancellationTokenSource.CreateLinkedTokenSource(
        HttpContext.RequestAborted,
        GetTokenFromCache(tokenHash)
    );
}

4.2 与并行编程的结合

Parallel.ForEachAsync是.NET 6引入的强力工具，但需要特别注意取消处理：

csharp复制await Parallel.ForEachAsync(items, new ParallelOptions {
    CancellationToken = token,
    MaxDegreeOfParallelism = 4
}, async (item, innerToken) => {
    await ProcessItemAsync(item, innerToken);
});

5. 性能优化技巧

5.1 注册回调的代价

每个Register回调都会产生内存分配。高频场景下建议使用回调池：

csharp复制class CallbackPool : IDisposable {
    private readonly List<Action> _callbacks = new();
    
    public CancellationTokenRegistration Register(
        Action callback, 
        CancellationToken token) 
    {
        var registration = token.Register(() => {
            lock (_callbacks) {
                _callbacks.Add(callback);
            }
        });
        return registration;
    }
    
    public void ExecuteCallbacks() {
        lock (_callbacks) {
            foreach (var cb in _callbacks) cb();
            _callbacks.Clear();
        }
    }
}

5.2 令牌检查的性能对比

实测不同检查方式的性能差异（单位ns/op）：

6. 诊断与调试

6.1 获取调用栈信息

当取消操作发生时，获取调用栈有助于诊断问题：

csharp复制var cts = new CancellationTokenSource();
cts.Token.Register(() => {
    var stack = new StackTrace(fNeedFileInfo: true);
    LogCancellationStack(stack);
});

6.2 Activity追踪集成

与System.Diagnostics.Activity结合实现端到端追踪：

csharp复制using var activity = _activitySource.StartActivity("ProcessData");
using var cts = new CancellationTokenSource();
cts.Token.Register(() => activity?.AddTag("canceled", true));

7. 实战经验总结

在金融交易系统中，我们实现了分级取消策略：当检测到系统负载超过阈值时，首先取消低优先级的查询操作，保留关键交易处理。这需要精心设计令牌层次结构：

csharp复制var globalCts = new CancellationTokenSource();
var criticalCts = CancellationTokenSource.CreateLinkedTokenSource(globalCts.Token);

// 监控线程
_ = Task.Run(async () => {
    while (true) {
        if (SystemLoad > 0.8) {
            globalCts.Cancel(); // 保留criticalCts
        }
        await Task.Delay(1000);
    }
});

另一个重要经验是：永远不要忽略OperationCanceledException。我们曾在日志中发现大量未处理的取消异常，调查后发现是某个第三方库在取消时没有正确清理TCP连接，最终导致端口耗尽。现在的处理标准是：

重要：所有取消操作必须记录到审计日志，包括取消来源（用户/系统/超时）和影响范围