异步编程---异步取消机制CancellationToken

异步代码不加取消机制？犹如开车没有刹车

没有取消机制的异步代码，就像开车没有刹车。表面看似没问题，直到你发现应用仍在疯狂运行、消耗内存、执着地完成早已无人需要的工作。这不是健壮性，而是披着高效外衣的资源浪费。
如果你仍以“没有取消令牌也能运行”为由跳过它们，那你写的就不是健壮的异步代码——你写的是为所欲为的代码。现在可能没问题，但迟早会出事。
如果你曾点过毫无反应的取消按钮，你就会明白：这个话题值得掌握。
（第二部分现已发布）

什么是 CancellationToken？
本质上，CancellationToken 只是一个信号——一个轻量级对象，用于告知异步代码：“该停止了。”但令牌本身并不执行取消操作，它只负责接收信号。
发送信号的是 CancellationTokenSource。你创建源对象，从中获取令牌，并将令牌传递给任何需要支持取消的方法。
基本结构

usingvarcts=newCancellationTokenSource();CancellationTokentoken=cts.Token;// 可以在其他地方取消令牌：cts.Cancel();

可以这样理解：

• CancellationTokenSource = 控制器
• CancellationToken = 广播信号
• 异步方法 = 监听器（收到信号后自愿停止）

如何在异步方法中传递和使用令牌
几乎所有规范的 .NET API 都接受可选 CancellationToken 参数，这意味着你的方法也应该如此。
定义带令牌参数的方法

publicasyncTaskDoWorkAsync(CancellationTokencancellationToken){for(inti=0;i<10;i++){cancellationToken.ThrowIfCancellationRequested();Console.WriteLine($"Working...{i}");awaitTask.Delay(500,cancellationToken);}}

在调用链中传递令牌

usingvarcts=newCancellationTokenSource();Tasktask=DoWorkAsync(cts.Token);// 2秒后取消cts.CancelAfter(TimeSpan.FromSeconds(2));

注意：

• ThrowIfCancellationRequested() 用于响应取消信号
• Task.Delay(…) 也支持令牌，因此取消操作可以中断等待
• 必须将令牌传递给每个可取消操作
• 判断IsCancellationRequested 用于判断令牌是否被取消
  以下是一个支持取消的简单异步方法：

publicasyncTask<string>DownloadAsync(stringurl,CancellationTokencancellationToken){usingvarhttpClient=newHttpClient();varresponse=awaithttpClient.GetAsync(url,cancellationToken);returnawaitresponse.Content.ReadAsStringAsync();}

传递令牌让被调用方有权选择退出。调用方式如下：

varcts=newCancellationTokenSource(TimeSpan.FromSeconds(5));try{varcontent=awaitDownloadAsync("https://example.com",cts.Token);Console.WriteLine("Download succeeded!");}catch(OperationCanceledException){Console.WriteLine("Download cancelled.");}

必须单独处理 OperationCanceledException，以区分操作失败和取消。

判断IsCancellationRequested
在执行循环任务的时候可以通过IsCancellationRequested判断是否被取消任务来进行退出，这样可以不用抛出异常。

// 4. 主动判断是否取消privateasyncTaskActiveCancellationExample(){usingvarcts=newCancellationTokenSource();CancellationTokentoken=cts.Token;// 5秒触发取消cts.CancelAfter(TimeSpan.FromSeconds(5));// 启动工作任务Task<bool>workTask=DoWorkNoErrorAsync(token);try{varres=awaitworkTask;Console.WriteLine($"工作已完成:{res}");}catch(OperationCanceledException){Console.WriteLine("工作已被取消");}}privateasyncTask<bool>DoWorkNoErrorAsync(CancellationTokencancellationToken){for(inti=0;i<10;i++){// 检查是否已请求取消if(cancellationToken.IsCancellationRequested){// 可选：添加取消前的清理逻辑（如释放资源）returnfalse;}Console.WriteLine($"工作中...{i}");// 捕获Delay期间的取消异常awaitTask.Delay(500);}returntrue;}---

忽略取消机制带来的隐藏缺陷
问题在这里变得严重。忽略取消令牌不仅是错过优化，更是滋生难以复现缺陷的温床：

1. 僵尸任务
   用户取消了操作，但任务仍在后台运行：写入内存、更新状态，甚至可能随后抛出错误。
2. 应用关闭延迟
   不可取消的任务会阻塞优雅关闭，迫使你依赖 Environment.Exit(1) 而非干净的退出钩子。
3. 内存泄漏
   不释放 CancellationTokenSource 或在循环中忽略取消，可能导致内存持有时间远超预期。
4. 测试无限挂起
   依赖异步操作但无取消机制的测试没有退出策略，CI 流水线可能因小错误卡住 30 分钟。
   忽略取消不仅是懒惰，更是危险。

为何应该使用取消令牌
因为你的代码不是孤立运行的。
异步操作发生在某些生命周期内：

• 用户离开页面时
• 后台服务关闭时
• •UI 发出停止加载数据的信号时
  如果代码忽略取消：
• 浪费计算资源
• 迫使调用方使用 Hack 手段（超时、强制终止）
• 导致测试脆弱性
  如果你正在构建可复用 API，标准更高。使用者期望能传递取消令牌。如果方法签名不支持，会降低代码在实际系统中的可用性。

示例：协作式控制台应用publicstaticasyncTaskMain(){usingvarcts=newCancellationTokenSource();Console.CancelKeyPress+=(s,e)=>{e.Cancel=true;cts.Cancel();};try{awaitDoWorkAsync(cts.Token);Console.WriteLine("Work completed successfully.");}catch(OperationCanceledException){Console.WriteLine("Work was cancelled.");}}staticasyncTaskDoWorkAsync(CancellationTokentoken){for(inti=0;i<10;i++){token.ThrowIfCancellationRequested();Console.WriteLine($"Working...{i}");awaitTask.Delay(1000,token);}}

按 Ctrl+C 即可取消。这是真实场景的行为——应用按指令退出，而不是随心所欲。

忽略取消的代价
许多开发者将 CancellationToken 视为可选参数。他们将其塞入方法签名以满足分析器或库规范，却从不实际使用。这种心态会导致应用无响应、关闭缓慢、CPU 周期浪费，甚至内存泄漏。
理解取消机制不仅是编写防御性代码，更是编写专业代码：尊重用户时间、节约系统资源、在压力下保持可预测行为。
本文奠定了基础：令牌是什么、如何传递、为何重要，以及忘记使用会如何导致微妙而痛苦的缺陷。

实例的代码已经上传到Gitee：https://gitee.com/panwangvie/PwjBlogExamples/blob/master/AsyncCodeDemo/CancellationExamples.cs