CancellationTokenSource取消任务方法

C#中任务取消的协作式原理是通过CancellationTokenSource发送取消信号，任务需主动检查CancellationToken或调用ThrowIfCancellationRequested响应，而非强制终止。

C#中，CancellationTokenSource 提供了一种优雅且协作式的机制来取消正在执行的任务。它不是强制中断，而是向任务发出“请停止”的信号，任务本身需要主动监听并响应这个信号。这就像你给一个正在工作的同事发消息说“你手头的事可以先放下了”，至于他什么时候放下，以什么方式放下，最终还是由他自己决定和执行。

要实现任务取消，我们通常会遵循一套流程。 首先，你需要创建一个 CancellationTokenSource 的实例。这个对象就是取消操作的“发令员”。

var cts = new CancellationTokenSource();

接着，从 CancellationTokenSource 中获取一个 CancellationToken。这个 Token 就像一张通行证，你需要把它传递给你想要取消的任务或方法。

CancellationToken token = cts.Token;

在你的任务或长时间运行的方法内部，你需要周期性地检查这个 token 的状态。最直接的方式是检查 token.IsCancellationRequested 属性。

// 示例：一个长时间运行的任务
Task.Run(() =>
{
    while (true)
    {
        if (token.IsCancellationRequested)
        {
            Console.WriteLine("任务收到取消请求，准备退出...");
            // 在这里执行一些清理工作
            break; // 退出循环
        }
        Console.WriteLine("任务正在执行...");
        Thread.Sleep(500); // 模拟耗时操作
    }
}, token); // 也可以将token传递给Task.Run，这样如果token被取消，Task会进入Canceled状态

更推荐的做法是使用 token.ThrowIfCancellationRequested() 方法。当 token 被取消时，这个方法会立即抛出一个 OperationCanceledException。这种方式能更简洁、更符合异常处理范式地中断任务执行。

Task.Run(() =>
{
    try
    {
        for (int i = 0; i < 100; i++)
        {
            token.ThrowIfCancellationRequested(); // 如果取消，这里会抛异常
            Console.WriteLine($"任务执行到第 {i} 步...");
            Thread.Sleep(200);
        }
    }
    catch (OperationCanceledException)
    {
        Console.WriteLine("任务因取消请求而终止。");
    }
}, token);

当你想取消任务时，只需调用 CancellationTokenSource 实例的 Cancel() 方法即可。

cts.Cancel();

最后，别忘了 CancellationTokenSource 实现了 IDisposable 接口。用完之后，最好调用 Dispose() 方法释放资源，或者更常见的做法是将其包裹在 using 语句中。

using (var cts = new CancellationTokenSource()) { /* ... */ }

C#中任务取消的协作式原理是什么？

我们谈到 CancellationTokenSource，很多人会把它想象成一个“急停按钮”，一按任务就立马停了。但实际上，它更像是一个“请示停止”的信号灯。这背后的核心理念就是“协作式取消”。与过去 Thread.Abort() 那种粗暴、不安全的强制终止方式（现在已经废弃，也不推荐使用）截然不同，协作式取消要求被取消的任务本身要“配合”。

简单来说，CancellationTokenSource 发出的 CancellationToken 只是一个请求，一个意图。任务代码内部必须主动去检查这个 token 的状态，并根据 IsCancellationRequested 的值或者 ThrowIfCancellationRequested() 抛出的异常来决定何时、何地停止执行。这种设计，在我看来，是C#并发编程中一个非常成熟和负责任的选择。它避免了强制终止可能带来的各种问题，比如资源泄露（文件句柄、网络连接没来得及关闭）、数据损坏（操作进行到一半，数据处于不一致状态），以及死锁等难以预料的副作用。

通过协作，任务可以在收到取消请求时，有机会完成当前的原子操作、释放已持有的资源、回滚未提交的事务，或者至少记录下当前状态，然后才优雅地退出。这给了开发者极大的控制权，确保了程序的健壮性和稳定性。当然，这也意味着如果你的任务代码里没有检查 CancellationToken，那么即便你调用了 Cancel()，任务也可能会继续运行，直到它自然结束。所以，开发者在编写长时间运行或可取消的任务时，肩负着主动响应取消请求的责任。

在异步方法中如何正确捕获和处理OperationCanceledException？

当 CancellationToken 被取消，并且你的代码中调用了 ThrowIfCancellationRequested()，或者你将 CancellationToken 传递给了 Task.Run、HttpClient.GetAsync 等支持取消的方法，那么当取消发生时，通常会抛出 OperationCanceledException。处理这种异常，我觉得需要一些特别的思考，因为它和我们平时处理的“错误”不太一样。

OperationCanceledException 并不是一个指示程序出错的信号，它更多的是一种预期的控制流。它表明任务按照设计被取消了，这通常不是一个需要崩溃或记录为严重错误的情况。因此，在 async/await 结构中，我们应该用 try-catch 块来捕获它，并进行适当的处理，而不是让它传播出去导致程序崩溃。

看一个例子：

public async Task DoSomethingCancellableAsync(CancellationToken token)
{
    try
    {
        Console.WriteLine("异步任务开始...");
        for (int i = 0; i < 10; i++)
        {
            token.ThrowIfCancellationRequested(); // 检查取消
            await Task.Delay(500, token); // 这里的Task.Delay也支持取消
            Console.WriteLine($"异步任务进行到 {i + 1} 步。");
        }
        Console.WriteLine("异步任务完成。");
    }
    catch (OperationCanceledException ex)
    {
        // 这是一个预期的取消，不是错误
        Console.WriteLine($"异步任务被取消了: {ex.Message}");
        // 在这里可以进行一些清理工作，比如关闭文件、释放网络连接等
        // 如果需要，可以重新抛出，但通常不需要
        // throw; 
    }
    catch (Exception ex)
    {
        // 处理其他非取消引起的错误
        Console.WriteLine($"异步任务发生未知错误: {ex.Message}");
    }
    finally