環(huán)境的 5 個(gè)取消陷阱與解決模板)
最近接手一個(gè)訂單處理服務(wù)的時(shí)候我發(fā)現(xiàn)一個(gè)很奇怪的現(xiàn)象接口偶爾會(huì)返回 200但是數(shù)據(jù)庫里的訂單狀態(tài)卻一直停在“處理中”而且日志里根本看不到任何異常。排查了兩天最后定位到一個(gè)很不起眼的地方——某個(gè)異步任務(wù)里有人寫了await Task.Delay(TimeSpan.FromSeconds(30))沒傳CancellationToken。結(jié)果就是請求超時(shí)被網(wǎng)關(guān)斷開后后端服務(wù)還在傻等等完之后繼續(xù)往下寫狀態(tài)。你說這算不算生產(chǎn)環(huán)境事故嚴(yán)格來說不算宕機(jī)但用戶那邊看到的就是“訂單卡住了”或者“按鈕點(diǎn)了沒反應(yīng)”。這個(gè)項(xiàng)目讓我下決心把 .NET 取消令牌機(jī)制徹底梳理一遍。很多人對CancellationToken的理解停留在“能取消 Task 就行”的層面可真上了生產(chǎn)環(huán)境坑比想象中多得多。這篇文章不講教科書只講我從實(shí)際故障里總結(jié)出來的 5 個(gè)大坑以及每個(gè)坑背后的原理、排查思路和最終解法。如果你是寫 ASP.NET Core 服務(wù)、后臺(tái)任務(wù)、網(wǎng)關(guān)或中間件的人這篇文章值得你花十分鐘讀完并且直接抄走最后的公共模板。1. 取消令牌的工作方式它不只是一個(gè)“拋異常開關(guān)”先花點(diǎn)時(shí)間把底層機(jī)制講清楚。CancellationTokenSource下面簡稱 CTS是“總開關(guān)”它通過Cancel()觸發(fā)取消信號(hào)CancellationToken是分發(fā)給各個(gè)任務(wù)和方法的“信使”。這個(gè)設(shè)計(jì)把“取消的發(fā)起者”和“取消的響應(yīng)者”徹底解耦——調(diào)用方不需要知道誰在處理任務(wù)被調(diào)用的方法也不需要知道是誰發(fā)起的取消。1.1 從 CTS 到 Token 的傳播鏈一個(gè)典型的取消鏈路是這樣的using var cts new CancellationTokenSource(TimeSpan.FromSeconds(10)); // 分發(fā) token 給下游任務(wù) var result await ProcessOrderAsync(orderId, cts.Token);在ProcessOrderAsync內(nèi)部又會(huì)把這個(gè) token 繼續(xù)傳給更底層的數(shù)據(jù)庫操作、HTTP 調(diào)用等public async TaskOrderResult ProcessOrderAsync(int orderId, CancellationToken cancellationToken) { // 先檢查任務(wù)是否已經(jīng)被取消 cancellationToken.ThrowIfCancellationRequested(); // 傳給數(shù)據(jù)庫 var order await _db.GetOrderAsync(orderId, cancellationToken); // 傳給下游 HTTP 服務(wù) var stock await _stockClient.CheckStockAsync(orderId, cancellationToken); return BuildResult(order, stock); }這里的關(guān)鍵點(diǎn)是取消信號(hào)必須沿著調(diào)用鏈一層一層傳下去。任何一個(gè)環(huán)節(jié)丟失 token整條取消鏈路就會(huì)在這里斷掉。你可能在 Controller 層接到 token 后傳給了第一個(gè) Service但那個(gè) Service 內(nèi)部調(diào)私有方法時(shí)忘了傳后續(xù)所有耗時(shí)操作就都失去取消能力了。1.2 回調(diào)注冊與主動(dòng)檢查的取舍CancellationToken內(nèi)部有兩種機(jī)制讓你“感知取消”一種是通過Register注冊回調(diào)另一種是在代碼里主動(dòng)調(diào)用ThrowIfCancellationRequested或者檢查IsCancellationRequested。Register更像“訂閱通知”——取消發(fā)生時(shí)回調(diào)會(huì)被執(zhí)行。這個(gè)回調(diào)可能被注冊到任意線程上由 CTS 內(nèi)部通過線程池調(diào)度執(zhí)行。適合做清理工作比如關(guān)閉文件流、釋放連接、寫日志。主動(dòng)檢查則更適合“每執(zhí)行一段操作就停下來看看”的場景。比如你要循環(huán)處理幾萬條數(shù)據(jù)每處理 100 條就檢查一次 token避免一個(gè)超長循環(huán)把人家的取消請求晾在一邊。這兩者不是互斥的實(shí)際代碼里應(yīng)該組合使用。但很多人只用了其中一個(gè)或者把回調(diào)注冊當(dāng)擺設(shè)后面我會(huì)展開講。1.3 鏈條的斷裂點(diǎn)才是事故高發(fā)地生產(chǎn)環(huán)境里最常見的問題不是 CTS 用不對而是“信號(hào)發(fā)了但沒人聽到”。舉個(gè)例子// 錯(cuò)誤示范 public async Taskbyte[] ReadFileAsync(string path) { var data await File.ReadAllBytesAsync(path); // 沒有 token return data; }這個(gè)方法如果被一個(gè)耗時(shí)的文件讀取卡住調(diào)用方就算取消了請求這個(gè)文件讀取也會(huì)繼續(xù)執(zhí)行直到讀完為止。如果同時(shí)有大量這種請求進(jìn)來線程池很快就會(huì)被這些“僵尸任務(wù)”占滿。所以排查取消問題的時(shí)候我第一步會(huì)順著調(diào)用鏈把所有方法簽名翻一遍看看 token 是在哪一層開始“消失”的。這一步做完大概率能找出 70% 的問題。2. 陷阱一Token 只在入口處檢查底層 IO 根本聽不到取消指令這是所有坑里最隱蔽、也最影響系統(tǒng)穩(wěn)定性的一種。2.1 生產(chǎn)故障的典型現(xiàn)場某個(gè)內(nèi)部系統(tǒng)在高峰期偶爾會(huì)有接口卡頓。表象是明明客戶端已經(jīng)斷開連接了但服務(wù)端的任務(wù)日志顯示這個(gè)方法一直沒結(jié)束。更詭異的是進(jìn)程里的線程數(shù)持續(xù)上漲任務(wù)積壓越來越多。用工具抓了 dump 之后發(fā)現(xiàn)大量線程卡在Task.Delay上還有一部分卡在 HTTP 調(diào)用的等待響應(yīng)上。我當(dāng)時(shí)一眼就看明白了入口方法簽名里有CancellationToken但調(diào)用鏈往下走三層之后token 就再也沒出現(xiàn)過了。public async Taskstring FirstLayerAsync(CancellationToken token) { var item await SecondLayerAsync(); // 忘了傳 token return item; } private async Taskstring SecondLayerAsync() { // 這里有一個(gè)遠(yuǎn)程調(diào)用可能持續(xù)幾十秒 return await _client.GetStringAsync(url); // 同樣沒 token }2.2 把 Token 傳到位才是第一優(yōu)先級(jí)方法簽名里加一個(gè)CancellationToken參數(shù)看起來是小改動(dòng)但對整個(gè)系統(tǒng)的影響是決定性的。我給自己定了兩條規(guī)矩現(xiàn)在每次寫代碼都會(huì)遵守所有可能耗時(shí)超過 100ms 的方法都必須接收CancellationToken。調(diào)用下游方法時(shí)只要對方提供了帶 token 的重載就一定要傳。這兩條聽起來像廢話但很多代碼老手都會(huì)犯“嫌麻煩”的毛病。尤其是項(xiàng)目里如果積累了老代碼很多方法從一開始就沒設(shè)計(jì) token后來人接 try 的時(shí)候想傳也沒參數(shù)可傳最后就只能停留在“入口處檢查一下”的程度。2.3 數(shù)據(jù)庫和 HTTP 調(diào)用怎么正確傳遞以 EF Core 為例支持 token 的寫法很多人在用但用不完整var orders await _db.Order .Where(o o.UserId userId) .ToListAsync(cancellationToken); // 查詢時(shí)帶上其實(shí)SaveChangesAsync、FirstOrDefaultAsync、SingleOrDefaultAsync這些都有帶 token 的重載。如果是原生 ADO.NET 的話SqlCommand也支持CancellationTokenvar command new SqlCommand(sql, connection); // ... await command.ExecuteReaderAsync(cancellationToken);HTTP 調(diào)用方面HttpClient的所有異步方法也都支持傳 token。有一個(gè)非常容易被忽略的死角是GetAsync如果不傳 token內(nèi)部用的是HttpClient.Timeout控制的超時(shí)但超時(shí)和取消是兩個(gè)概念。超時(shí)是指“我再也不等你了”取消是“調(diào)用方主動(dòng)不要了”。如果你只靠HttpClient.Timeout兜底客戶端斷開后請求依然會(huì)在服務(wù)端跑完只是等到超時(shí)那一刻你才知道。2.4 遇到不支持的 SDK 怎么辦總有一些老第三方 SDK 的方法沒有 token 參數(shù)。這時(shí)候有幾種常見的兜底方案把調(diào)用包在Task.WhenAny里和“等待取消”的任務(wù)賽跑private static async TaskT WithCancellationAsyncT(TaskT task, CancellationToken token) { var tcs new TaskCompletionSourcebool(); using (token.Register(() tcs.TrySetResult(true))) { var completedTask await Task.WhenAny(task, tcs.Task); if (completedTask ! task) { throw new OperationCanceledException(token); } return await task; } }用Task.WaitAsync.NET 6給一個(gè)固定的超時(shí)和取消組合var result await task.WaitAsync(TimeSpan.FromSeconds(10), token);不過說實(shí)話上面這些方案都不如“改 SDK”來得干凈。第三方庫如果不支持取消優(yōu)先給作者提 issue 或者換一個(gè)維護(hù)更活躍的庫包一層WhenAny終究是權(quán)宜之計(jì)因?yàn)樗鼤?huì)把取消信號(hào)“吞掉”底層任務(wù)可能仍然在跑只是調(diào)用方不再等它了。如果你非用不可得確保這個(gè)底層任務(wù)不會(huì)持有關(guān)鍵共享資源否則照樣泄漏。3. 陷阱二把取消異常當(dāng)成普通錯(cuò)誤處理導(dǎo)致超時(shí)統(tǒng)計(jì)全部失真第二個(gè)坑集中在異常處理上但它影響的不只是穩(wěn)定性還有監(jiān)控指標(biāo)的正確性。3.1 OperationCanceledException 和 TaskCanceledException 的關(guān)系先厘清一個(gè)基礎(chǔ)概念TaskCanceledException繼承自O(shè)perationCanceledException。前者通常表示一個(gè)任務(wù)因?yàn)槿∠兄购笳吒鼘挿喊小安僮鞅蝗∠钡那闆r。生產(chǎn)環(huán)境里的常見誤操作是一個(gè) catch 塊把所有OperationCanceledException都當(dāng)成了“業(yè)務(wù)失敗”記錄錯(cuò)誤日志、增加失敗計(jì)數(shù)、甚至返回 500 狀態(tài)碼。結(jié)果就是調(diào)用方明明是因?yàn)槌瑫r(shí)/主動(dòng)取消而斷開服務(wù)端卻把它記成一次“系統(tǒng)異?！备婢粩啾O(jiān)控圖全花。3.2 “取消”和“失敗”混淆的后果舉個(gè)例子。一個(gè)下訂單接口設(shè)置了 5 秒超時(shí)using var cts new CancellationTokenSource(TimeSpan.FromSeconds(5)); try { var result await _orderService.CreateAsync(orderId, cts.Token); return Ok(result); } catch (Exception ex) { _logger.Error(ex, 創(chuàng)建訂單失敗); // 取消也被記成了失敗 return StatusCode(500); }如果下游數(shù)據(jù)庫壓力大5 秒內(nèi)沒響應(yīng)cts到時(shí)間自動(dòng)取消CreateAsync就會(huì)拋OperationCanceledException。上面的代碼把這個(gè)異常當(dāng)成了創(chuàng)建失敗接口返回 500?？蛻舳耸盏?500 后可能觸發(fā)重試重試又打來一波請求進(jìn)一步加劇數(shù)據(jù)庫壓力——一個(gè)純粹的取消場景硬生生變成了雪崩的導(dǎo)火索。3.3 一套可落地的異常區(qū)分模板正確做法是在 catch 時(shí)區(qū)分“真正的失敗”和“取消”。我通常這樣處理try { var result await _orderService.CreateAsync(orderId, cts.Token); return Ok(result); } catch (OperationCanceledException) when (cts.IsCancellationRequested) { // 主動(dòng)取消或超時(shí)取消不記錯(cuò)誤日志按 499 或直接返回 _logger.LogInformation(訂單創(chuàng)建已被取消訂單號(hào) {OrderId}, orderId); return StatusCode(499); } catch (Exception ex) { _logger.LogError(ex, 創(chuàng)建訂單失敗訂單號(hào) {OrderId}, orderId); return StatusCode(500); }注意when (cts.IsCancellationRequested)這個(gè)過濾條件。有些情況下OperationCanceledException是下游某個(gè)操作自己拋的不代表當(dāng)前這個(gè)請求被取消。通過判斷當(dāng)前 CTS 的狀態(tài)可以精確區(qū)分“外部取消”和“內(nèi)部異?！?。還有一個(gè)細(xì)節(jié)如果你在自己的業(yè)務(wù)代碼里主動(dòng)ThrowIfCancellationRequested()異常堆棧上會(huì)有明確的調(diào)用點(diǎn)但如果你依賴框架層自動(dòng)拋出的取消異常通常會(huì)在異步狀態(tài)機(jī)層面比較難看。為了便于排查我建議在業(yè)務(wù)關(guān)鍵路徑上主動(dòng)調(diào)一次ThrowIfCancellationRequested這樣一旦出問題堆棧能直接指到業(yè)務(wù)代碼位置。至于日志和指標(biāo)取消不應(yīng)該記入錯(cuò)誤率。我們會(huì)單獨(dú)記一個(gè)canceled指標(biāo)用來觀察是哪些接口高頻被取消這往往是上游超時(shí)設(shè)置不合理或者下游響應(yīng)過慢的預(yù)警信號(hào)。把取消和錯(cuò)誤混在一起統(tǒng)計(jì)的監(jiān)控大屏很容易讓你在復(fù)盤時(shí)做出完全錯(cuò)誤的判斷。4. 陷阱三注冊回調(diào)的線程安全隱患與任務(wù)假死這個(gè)坑主要出在Register的濫用和異步等待的誤用上。很多人一旦知道“取消時(shí)可以注冊回調(diào)”就會(huì)興奮地在回調(diào)里塞一堆邏輯結(jié)果反而制造了新的問題。4.1 Register 回調(diào)里不要執(zhí)行耗時(shí)操作Register回調(diào)默認(rèn)運(yùn)行在調(diào)用了Cancel()的那個(gè)線程上也就是說誰觸發(fā)取消誰就要順帶把這些回調(diào)執(zhí)行完。如果你的回調(diào)里有阻塞操作——比如等鎖、調(diào)數(shù)據(jù)庫、刷日志——那么發(fā)起取消的那個(gè)線程會(huì)被阻塞住。更隱蔽的是如果回調(diào)里拋出了異常這個(gè)異常會(huì)傳播到調(diào)用Cancel()的線程上很可能直接導(dǎo)致某個(gè)后臺(tái)任務(wù)崩潰。清理回調(diào)的正確姿勢是只做輕量級(jí)的標(biāo)記、信號(hào)量釋放或者TaskCompletionSource的TrySetResult把真正的耗時(shí)清理放到等待任務(wù)的本體里。// 這是推薦的寫法 token.Register(() cleanupSignal.TrySetResult(true)); // 而不是 token.Register(async () { await _db.SaveChangesAsync(); });異步 lambda 更不能直接注冊。Register的回調(diào)類型是Action異步 lambda 編譯后會(huì)變成async void異常直接拋到線程池根本抓不到。如果你真的需要在取消時(shí)做異步清理請?jiān)谕饷嫦萢wait一個(gè)等待取消的任務(wù)再執(zhí)行清理。4.2 同步上下文死鎖是最膈應(yīng)人的事故ASP.NET Core 默認(rèn)沒有同步上下文所以現(xiàn)代 Web 應(yīng)用一般不踩這個(gè)坑。但在 WPF、WinForms、Xamarin 或者一些需要依賴同步上下文的項(xiàng)目中死鎖依舊存在。典型的場景UI 線程里直接.Result或.Wait()等待一個(gè)異步任務(wù)而這個(gè)任務(wù)內(nèi)部又在取消回調(diào)里嘗試回到 UI 線程執(zhí)行于是兩邊互相等任務(wù)假死。這其實(shí)是“取消”放大了原本就存在的異步阻塞問題。你在生產(chǎn)環(huán)境里尤其要小心那些“偽異步”代碼——比如在BackgroundService里同步等待、在事件處理器里.Wait()。4.3 Task.WaitAsync 不是萬能鑰匙.NET 6引入了Task.WaitAsync允許你給一個(gè)任務(wù)同時(shí)指定超時(shí)和取消令牌。很多人拿它解決“SDK 不支持取消”的問題但它有個(gè)副作用WaitAsync取消之后底層任務(wù)并不會(huì)被取消它還在跑。也就是說WaitAsync只是“我不等你了”不是“讓任務(wù)停下來”。后來我養(yǎng)成了一個(gè)習(xí)慣只用WaitAsync作為最后防線同時(shí)一定跟蹤底層任務(wù)的狀態(tài)。如果是用WhenAnyRegister的自定義 wrapper我會(huì)在 wrapper 里保證最終把底層任務(wù)的異?；蛘呓Y(jié)果消費(fèi)掉避免 UnobservedTaskException 的產(chǎn)生。這里還要補(bǔ)一句打斷阻塞任務(wù) ≠ 取消任務(wù)。Thread.Interrupt、Thread.Abort這些就別再用了CancellationToken是協(xié)作式取消不是強(qiáng)制殺死線程。指導(dǎo)思想是“讓任務(wù)自己意識(shí)到該停了”而不是“把任務(wù)連根拔起”。5. 陷阱四Cts 不釋放導(dǎo)致的定時(shí)器堆積與內(nèi)存壓力如果前面的坑屬于“功能不對”這個(gè)坑屬于“性能耗損”。它很慢但會(huì)在高并發(fā)下悄悄壓垮你的進(jìn)程。5.1 CancelAfter 背后的 TimerQueue 機(jī)制CancellationTokenSource有一個(gè)構(gòu)造函數(shù)帶TimeSpan參數(shù)也可以調(diào)用CancelAfter實(shí)現(xiàn)“到時(shí)自動(dòng)取消”。這背后的實(shí)現(xiàn)不是簡單的Thread.Sleep而是基于 .NET 內(nèi)置的定時(shí)器隊(duì)列TimerQueue。每個(gè) CTS 被創(chuàng)建并設(shè)置CancelAfter后它內(nèi)部就會(huì)在TimerQueue上注冊一個(gè)定時(shí)器節(jié)點(diǎn)。大量短期 CTS 如果頻繁創(chuàng)建但不釋放定時(shí)器節(jié)點(diǎn)就一直在隊(duì)列里掛著。每次設(shè)置CancelAfter都會(huì)觸發(fā)定時(shí)器鏈表的插入、排序、掃描當(dāng)并發(fā)量上來之后這些操作會(huì)積累成肉眼可見的 CPU 和內(nèi)存開銷。5.2 LinkedCts 與回調(diào)訂閱泄漏CancellationTokenSource.CreateLinkedTokenSource是一個(gè)很常用的 API用來把多個(gè) token 合并成一個(gè)。它內(nèi)部會(huì)在每個(gè)被連接的源上注冊回調(diào)。如果你創(chuàng)建了很多 LinkedCts但用完之后沒有Dispose這些回調(diào)引用會(huì)一直存在導(dǎo)致外層 CTS 無法被 GC 回收形成內(nèi)存泄漏。這個(gè)泄漏特別隱蔽因?yàn)槟憧床坏揭粋€(gè)單獨(dú)的“大對象”而是無數(shù)個(gè)小對象互相引用用 dotMemory 或者 dump 分析才能揪出來。定位到之后你會(huì)發(fā)現(xiàn)某個(gè)長期運(yùn)行的服務(wù)內(nèi)存只增不減就是因?yàn)橐粋€(gè)CreateLinkedTokenSource沒有釋放。5.3 高吞吐場景下的統(tǒng)一釋放策略我現(xiàn)在的做法是CTS 一律用using包裹并且Dispose和Cancel的順序要謹(jǐn)慎。共享一個(gè)剛改過的模板public async TaskResponse HandleAsync(Request request, CancellationToken requestToken) { // 先把外部 token 和本地超時(shí)合并 using var timeoutCts CancellationTokenSource.CreateLinkedTokenSource(requestToken); timeoutCts.CancelAfter(TimeSpan.FromSeconds(10)); // 業(yè)務(wù)處理 try { return await Process(request, timeoutCts.Token); } catch (OperationCanceledException) when (!requestToken.IsCancellationRequested) { // 本地超時(shí)導(dǎo)致的取消可以單獨(dú)處理 return Response.Timeout(); } }這里有兩條經(jīng)驗(yàn)外部傳入的 token 不要自行Dispose。它由創(chuàng)建者管理你只負(fù)責(zé)使用。自己創(chuàng)建的 CTS 一定要Dispose。using是最省心的方式。如果有些地方實(shí)在不能用using就在finally里手動(dòng)Dispose。釋放這個(gè)動(dòng)作還有一個(gè)隱藏的好處它會(huì)觸發(fā)內(nèi)部清理邏輯斷開注冊的回調(diào)引用讓 GC 能更早回收相關(guān)對象。在高并發(fā)場景下這一步做與不做內(nèi)存曲線的差別非常大。6. 陷阱五取消成功之后的“半完成狀態(tài)”沒有兜底最后一個(gè)坑嚴(yán)格來說是“取消后的善后邏輯”沒有設(shè)計(jì)好。很多人以為取消令牌只影響任務(wù)的“提前終止”但生產(chǎn)環(huán)境里更常見的問題是任務(wù)被取消了但是數(shù)據(jù)被寫進(jìn)了一個(gè)半完成的狀態(tài)或者后續(xù)邏輯因?yàn)檫@次取消產(chǎn)生了錯(cuò)誤數(shù)據(jù)。6.1 Finally 里的清理邏輯是否冪等一份比較典型的錯(cuò)誤代碼長這樣var order await _db.GetOrderAsync(orderId, token); try { order.Status OrderStatus.Processing; await _db.SaveChangesAsync(token); // 遠(yuǎn)程扣庫存這個(gè)調(diào)用比較慢 await _inventoryClient.DeductAsync(orderId, token); order.Status OrderStatus.Completed; await _db.SaveChangesAsync(token); } finally { // 這里如果被取消order.Status 還是 Processing而且可能壓根沒保存 // 如果你在 finally 里做了補(bǔ)償又可能因?yàn)榫W(wǎng)絡(luò)重試導(dǎo)致重復(fù)扣庫存 }假設(shè)DeductAsync在執(zhí)行到一半時(shí)被取消catch沒有兜底finally也沒做任何狀態(tài)修正整個(gè)訂單就停留在Processing。如果下游有一個(gè)掃描“處理中超過 5 分鐘”的定時(shí)任務(wù)它會(huì)把這條訂單撈出來重新處理重新去扣庫存——這就是經(jīng)典的重復(fù)扣款問題。解決思路不是讓finally越復(fù)雜越好而是把整個(gè)操作設(shè)計(jì)成“階段化 冪等”的每個(gè)階段開始前檢查 token確保不進(jìn)入一個(gè)注定無法完成的分支。取消發(fā)生后把當(dāng)前狀態(tài)寫清楚比如PendingRecovery并單獨(dú)記錄一條“補(bǔ)償日志”。補(bǔ)償操作必須有全局唯一的業(yè)務(wù)鍵數(shù)據(jù)庫加唯一索引保證任何重試都不會(huì)重復(fù)扣款。6.2 取消后更新狀態(tài)記錄的競態(tài)還有一個(gè)小型競態(tài)取消回調(diào)里你更新了內(nèi)存標(biāo)記而業(yè)務(wù)代碼同時(shí)在寫數(shù)據(jù)庫。如果取消發(fā)生在SaveChangesAsync的提交期間EF Core 會(huì)怎么處理實(shí)際上它會(huì)在內(nèi)部檢測到取消并回滾當(dāng)前事務(wù)可能拋出的并不是OperationCanceledException而是DbUpdateException具體取決于運(yùn)行時(shí)內(nèi)部流程。這個(gè)問題在低版本運(yùn)行時(shí)里面出現(xiàn)過所以不要假設(shè)“取消了就一定能收到取消異?！?。6.3 干凈的三態(tài)設(shè)計(jì)完成、失敗、取消到我手上的項(xiàng)目我會(huì)建議業(yè)務(wù)接口在設(shè)計(jì)階段就把“取消”定義為一種顯式的終態(tài)而不是“未知”。比如訂單狀態(tài)枚舉里必須有Canceled這個(gè)值并且取消之后如果還有未完成的子任務(wù)發(fā)短信、推送、發(fā)送 webhook需要走專門的“延遲重試隊(duì)列”而不是當(dāng)作失敗立刻重試。“取消”本身是可以作為一次合法業(yè)務(wù)流程結(jié)束的——業(yè)務(wù)方主動(dòng)放棄、超時(shí)未完成都應(yīng)該有對應(yīng)的狀態(tài)收斂。切忌把取消當(dāng)成異常、把異常當(dāng)成失敗、把失敗當(dāng)成重試信號(hào)。一個(gè)只含Success/Failed兩態(tài)的系統(tǒng)碰上取消必出幺蛾子。7. 生產(chǎn)環(huán)境可復(fù)用的取消策略一個(gè)公共模板到了收尾的部分我把自己常用的一套取消策略框架寫在這里。它不是銀彈但至少能幫你把前面 5 個(gè)坑都堵上大部分。7.1 公共 TokenHandler 的設(shè)計(jì)我習(xí)慣封裝一個(gè)CancellationContext類把 CTS、外部 token、超時(shí)策略和清理回調(diào)統(tǒng)一管理起來。大致骨架如下public sealed class CancellationContext : IDisposable { private readonly CancellationTokenSource _linkedCts; public CancellationToken Token _linkedCts.Token; public CancellationContext(CancellationToken externalToken, TimeSpan timeout) { _linkedCts CancellationTokenSource.CreateLinkedTokenSource(externalToken); _linkedCts.CancelAfter(timeout); } public void Cancel() _linkedCts.Cancel(); public void Dispose() _linkedCts.Dispose(); }使用的時(shí)候using var ctx new CancellationContext(requestToken, TimeSpan.FromSeconds(10)); var result await DoWorkAsync(ctx.Token);這個(gè)封裝帶來的統(tǒng)一好處是超時(shí)、外部取消、主動(dòng)調(diào)用Cancel()全都會(huì)觸發(fā)同一個(gè) token。你不需要在每個(gè)業(yè)務(wù)方法里都去構(gòu)建 CTS。7.2 壓測與診斷手段再分享一個(gè)診斷經(jīng)驗(yàn)。如果懷疑取消沒生效先別急著加代碼。我會(huì)先做一輪壓測在壓測過程中手動(dòng)觸發(fā)取消模擬客戶端斷開然后看兩件事線程池活動(dòng)線程數(shù)是否回落。如果不回落說明有不少任務(wù)仍然阻塞著取消信號(hào)沒起效。進(jìn)程內(nèi)存是否持續(xù)增長。如果增長重點(diǎn)檢查所有創(chuàng)建了 CTS 的地方有沒有釋放。一些診斷命令對這類問題很有用比如查看線程池狀態(tài)、抓 dump 分析任務(wù)堆棧等等。如果任務(wù)堆棧全都停在等待庫函數(shù)調(diào)用的地方那基本就是 token 沒傳到底層如果停在Task.Delay或同步等待上那就是內(nèi)部有阻塞調(diào)用沒走異步。7.3 分享幾條個(gè)人經(jīng)驗(yàn)文章寫到這我最后想說的經(jīng)驗(yàn)可能有點(diǎn)反常識(shí)取消令牌設(shè)計(jì)的重點(diǎn)不在于“怎么取消”而在于“取消之后怎么收場”。一開始我也愛研究Register、ThrowIfCancellationRequested、WaitAsync這些 API 的底層實(shí)現(xiàn)但真正把生產(chǎn)環(huán)境搞崩的往往不是 API 不會(huì)用而是整個(gè)鏈路少了某幾個(gè) token或者在 catch 里把取消當(dāng)成異常。你在代碼評審的時(shí)候可以專門多問一句“如果這個(gè)操作被取消了數(shù)據(jù)庫里會(huì)留下什么狀態(tài)”很多問題當(dāng)場就能暴露。另外盡量把超時(shí)和取消分開理解。超時(shí)是可以預(yù)測的放棄取消是不可預(yù)測的中斷。兩者都需要收斂到明確終態(tài)。把超時(shí)也設(shè)計(jì)成一種“內(nèi)部原因的取消”是常見做法但必須能區(qū)分它和外部取消否則監(jiān)控?cái)?shù)據(jù)和用戶反饋會(huì)互相矛盾。這個(gè)領(lǐng)域還有很多細(xì)節(jié)可以聊比如自定義 Awaitable 的取消響應(yīng)、分布式任務(wù)里如何把取消信號(hào)傳遍集群等等。先把手頭的 5 個(gè)坑填平比摸更多花哨 API 更實(shí)在。希望這篇文章能讓你在下一次代碼評審里少看到一行Task.Delay(3000)后面沒跟 token。 深入 .NET CancellationToken：生產(chǎn)環(huán)境的 5 個(gè)取消陷阱與解決模板
最近接手一個(gè)訂單處理服務(wù)的時(shí)候我發(fā)現(xiàn)一個(gè)很奇怪的現(xiàn)象接口偶爾會(huì)返回 200但是數(shù)據(jù)庫里的訂單狀態(tài)卻一直停在“處理中”而且日志里根本看不到任何異常。排查了兩天最后定位到一個(gè)很不起眼的地方——某個(gè)異步任務(wù)里有人寫了await Task.Delay(TimeSpan.FromSeconds(30))沒傳CancellationToken。結(jié)果就是請求超時(shí)被網(wǎng)關(guān)斷開后后端服務(wù)還在傻等等完之后繼續(xù)往下寫狀態(tài)。你說這算不算生產(chǎn)環(huán)境事故嚴(yán)格來說不算宕機(jī)但用戶那邊看到的就是“訂單卡住了”或者“按鈕點(diǎn)了沒反應(yīng)”。這個(gè)項(xiàng)目讓我下決心把 .NET 取消令牌機(jī)制徹底梳理一遍。很多人對CancellationToken的理解停留在“能取消 Task 就行”的層面可真上了生產(chǎn)環(huán)境坑比想象中多得多。這篇文章不講教科書只講我從實(shí)際故障里總結(jié)出來的 5 個(gè)大坑以及每個(gè)坑背后的原理、排查思路和最終解法。如果你是寫 ASP.NET Core 服務(wù)、后臺(tái)任務(wù)、網(wǎng)關(guān)或中間件的人這篇文章值得你花十分鐘讀完并且直接抄走最后的公共模板。1. 取消令牌的工作方式它不只是一個(gè)“拋異常開關(guān)”先花點(diǎn)時(shí)間把底層機(jī)制講清楚。CancellationTokenSource下面簡稱 CTS是“總開關(guān)”它通過Cancel()觸發(fā)取消信號(hào)CancellationToken是分發(fā)給各個(gè)任務(wù)和方法的“信使”。這個(gè)設(shè)計(jì)把“取消的發(fā)起者”和“取消的響應(yīng)者”徹底解耦——調(diào)用方不需要知道誰在處理任務(wù)被調(diào)用的方法也不需要知道是誰發(fā)起的取消。1.1 從 CTS 到 Token 的傳播鏈一個(gè)典型的取消鏈路是這樣的using var cts new CancellationTokenSource(TimeSpan.FromSeconds(10)); // 分發(fā) token 給下游任務(wù) var result await ProcessOrderAsync(orderId, cts.Token);在ProcessOrderAsync內(nèi)部又會(huì)把這個(gè) token 繼續(xù)傳給更底層的數(shù)據(jù)庫操作、HTTP 調(diào)用等public async TaskOrderResult ProcessOrderAsync(int orderId, CancellationToken cancellationToken) { // 先檢查任務(wù)是否已經(jīng)被取消 cancellationToken.ThrowIfCancellationRequested(); // 傳給數(shù)據(jù)庫 var order await _db.GetOrderAsync(orderId, cancellationToken); // 傳給下游 HTTP 服務(wù) var stock await _stockClient.CheckStockAsync(orderId, cancellationToken); return BuildResult(order, stock); }這里的關(guān)鍵點(diǎn)是取消信號(hào)必須沿著調(diào)用鏈一層一層傳下去。任何一個(gè)環(huán)節(jié)丟失 token整條取消鏈路就會(huì)在這里斷掉。你可能在 Controller 層接到 token 后傳給了第一個(gè) Service但那個(gè) Service 內(nèi)部調(diào)私有方法時(shí)忘了傳后續(xù)所有耗時(shí)操作就都失去取消能力了。1.2 回調(diào)注冊與主動(dòng)檢查的取舍CancellationToken內(nèi)部有兩種機(jī)制讓你“感知取消”一種是通過Register注冊回調(diào)另一種是在代碼里主動(dòng)調(diào)用ThrowIfCancellationRequested或者檢查IsCancellationRequested。Register更像“訂閱通知”——取消發(fā)生時(shí)回調(diào)會(huì)被執(zhí)行。這個(gè)回調(diào)可能被注冊到任意線程上由 CTS 內(nèi)部通過線程池調(diào)度執(zhí)行。適合做清理工作比如關(guān)閉文件流、釋放連接、寫日志。主動(dòng)檢查則更適合“每執(zhí)行一段操作就停下來看看”的場景。比如你要循環(huán)處理幾萬條數(shù)據(jù)每處理 100 條就檢查一次 token避免一個(gè)超長循環(huán)把人家的取消請求晾在一邊。這兩者不是互斥的實(shí)際代碼里應(yīng)該組合使用。但很多人只用了其中一個(gè)或者把回調(diào)注冊當(dāng)擺設(shè)后面我會(huì)展開講。1.3 鏈條的斷裂點(diǎn)才是事故高發(fā)地生產(chǎn)環(huán)境里最常見的問題不是 CTS 用不對而是“信號(hào)發(fā)了但沒人聽到”。舉個(gè)例子// 錯(cuò)誤示范 public async Taskbyte[] ReadFileAsync(string path) { var data await File.ReadAllBytesAsync(path); // 沒有 token return data; }這個(gè)方法如果被一個(gè)耗時(shí)的文件讀取卡住調(diào)用方就算取消了請求這個(gè)文件讀取也會(huì)繼續(xù)執(zhí)行直到讀完為止。如果同時(shí)有大量這種請求進(jìn)來線程池很快就會(huì)被這些“僵尸任務(wù)”占滿。所以排查取消問題的時(shí)候我第一步會(huì)順著調(diào)用鏈把所有方法簽名翻一遍看看 token 是在哪一層開始“消失”的。這一步做完大概率能找出 70% 的問題。2. 陷阱一Token 只在入口處檢查底層 IO 根本聽不到取消指令這是所有坑里最隱蔽、也最影響系統(tǒng)穩(wěn)定性的一種。2.1 生產(chǎn)故障的典型現(xiàn)場某個(gè)內(nèi)部系統(tǒng)在高峰期偶爾會(huì)有接口卡頓。表象是明明客戶端已經(jīng)斷開連接了但服務(wù)端的任務(wù)日志顯示這個(gè)方法一直沒結(jié)束。更詭異的是進(jìn)程里的線程數(shù)持續(xù)上漲任務(wù)積壓越來越多。用工具抓了 dump 之后發(fā)現(xiàn)大量線程卡在Task.Delay上還有一部分卡在 HTTP 調(diào)用的等待響應(yīng)上。我當(dāng)時(shí)一眼就看明白了入口方法簽名里有CancellationToken但調(diào)用鏈往下走三層之后token 就再也沒出現(xiàn)過了。public async Taskstring FirstLayerAsync(CancellationToken token) { var item await SecondLayerAsync(); // 忘了傳 token return item; } private async Taskstring SecondLayerAsync() { // 這里有一個(gè)遠(yuǎn)程調(diào)用可能持續(xù)幾十秒 return await _client.GetStringAsync(url); // 同樣沒 token }2.2 把 Token 傳到位才是第一優(yōu)先級(jí)方法簽名里加一個(gè)CancellationToken參數(shù)看起來是小改動(dòng)但對整個(gè)系統(tǒng)的影響是決定性的。我給自己定了兩條規(guī)矩現(xiàn)在每次寫代碼都會(huì)遵守所有可能耗時(shí)超過 100ms 的方法都必須接收CancellationToken。調(diào)用下游方法時(shí)只要對方提供了帶 token 的重載就一定要傳。這兩條聽起來像廢話但很多代碼老手都會(huì)犯“嫌麻煩”的毛病。尤其是項(xiàng)目里如果積累了老代碼很多方法從一開始就沒設(shè)計(jì) token后來人接 try 的時(shí)候想傳也沒參數(shù)可傳最后就只能停留在“入口處檢查一下”的程度。2.3 數(shù)據(jù)庫和 HTTP 調(diào)用怎么正確傳遞以 EF Core 為例支持 token 的寫法很多人在用但用不完整var orders await _db.Order .Where(o o.UserId userId) .ToListAsync(cancellationToken); // 查詢時(shí)帶上其實(shí)SaveChangesAsync、FirstOrDefaultAsync、SingleOrDefaultAsync這些都有帶 token 的重載。如果是原生 ADO.NET 的話SqlCommand也支持CancellationTokenvar command new SqlCommand(sql, connection); // ... await command.ExecuteReaderAsync(cancellationToken);HTTP 調(diào)用方面HttpClient的所有異步方法也都支持傳 token。有一個(gè)非常容易被忽略的死角是GetAsync如果不傳 token內(nèi)部用的是HttpClient.Timeout控制的超時(shí)但超時(shí)和取消是兩個(gè)概念。超時(shí)是指“我再也不等你了”取消是“調(diào)用方主動(dòng)不要了”。如果你只靠HttpClient.Timeout兜底客戶端斷開后請求依然會(huì)在服務(wù)端跑完只是等到超時(shí)那一刻你才知道。2.4 遇到不支持的 SDK 怎么辦總有一些老第三方 SDK 的方法沒有 token 參數(shù)。這時(shí)候有幾種常見的兜底方案把調(diào)用包在Task.WhenAny里和“等待取消”的任務(wù)賽跑private static async TaskT WithCancellationAsyncT(TaskT task, CancellationToken token) { var tcs new TaskCompletionSourcebool(); using (token.Register(() tcs.TrySetResult(true))) { var completedTask await Task.WhenAny(task, tcs.Task); if (completedTask ! task) { throw new OperationCanceledException(token); } return await task; } }用Task.WaitAsync.NET 6給一個(gè)固定的超時(shí)和取消組合var result await task.WaitAsync(TimeSpan.FromSeconds(10), token);不過說實(shí)話上面這些方案都不如“改 SDK”來得干凈。第三方庫如果不支持取消優(yōu)先給作者提 issue 或者換一個(gè)維護(hù)更活躍的庫包一層WhenAny終究是權(quán)宜之計(jì)因?yàn)樗鼤?huì)把取消信號(hào)“吞掉”底層任務(wù)可能仍然在跑只是調(diào)用方不再等它了。如果你非用不可得確保這個(gè)底層任務(wù)不會(huì)持有關(guān)鍵共享資源否則照樣泄漏。3. 陷阱二把取消異常當(dāng)成普通錯(cuò)誤處理導(dǎo)致超時(shí)統(tǒng)計(jì)全部失真第二個(gè)坑集中在異常處理上但它影響的不只是穩(wěn)定性還有監(jiān)控指標(biāo)的正確性。3.1 OperationCanceledException 和 TaskCanceledException 的關(guān)系先厘清一個(gè)基礎(chǔ)概念TaskCanceledException繼承自O(shè)perationCanceledException。前者通常表示一個(gè)任務(wù)因?yàn)槿∠兄购笳吒鼘挿喊小安僮鞅蝗∠钡那闆r。生產(chǎn)環(huán)境里的常見誤操作是一個(gè) catch 塊把所有OperationCanceledException都當(dāng)成了“業(yè)務(wù)失敗”記錄錯(cuò)誤日志、增加失敗計(jì)數(shù)、甚至返回 500 狀態(tài)碼。結(jié)果就是調(diào)用方明明是因?yàn)槌瑫r(shí)/主動(dòng)取消而斷開服務(wù)端卻把它記成一次“系統(tǒng)異?！备婢粩啾O(jiān)控圖全花。3.2 “取消”和“失敗”混淆的后果舉個(gè)例子。一個(gè)下訂單接口設(shè)置了 5 秒超時(shí)using var cts new CancellationTokenSource(TimeSpan.FromSeconds(5)); try { var result await _orderService.CreateAsync(orderId, cts.Token); return Ok(result); } catch (Exception ex) { _logger.Error(ex, 創(chuàng)建訂單失敗); // 取消也被記成了失敗 return StatusCode(500); }如果下游數(shù)據(jù)庫壓力大5 秒內(nèi)沒響應(yīng)cts到時(shí)間自動(dòng)取消CreateAsync就會(huì)拋OperationCanceledException。上面的代碼把這個(gè)異常當(dāng)成了創(chuàng)建失敗接口返回 500?？蛻舳耸盏?500 后可能觸發(fā)重試重試又打來一波請求進(jìn)一步加劇數(shù)據(jù)庫壓力——一個(gè)純粹的取消場景硬生生變成了雪崩的導(dǎo)火索。3.3 一套可落地的異常區(qū)分模板正確做法是在 catch 時(shí)區(qū)分“真正的失敗”和“取消”。我通常這樣處理try { var result await _orderService.CreateAsync(orderId, cts.Token); return Ok(result); } catch (OperationCanceledException) when (cts.IsCancellationRequested) { // 主動(dòng)取消或超時(shí)取消不記錯(cuò)誤日志按 499 或直接返回 _logger.LogInformation(訂單創(chuàng)建已被取消訂單號(hào) {OrderId}, orderId); return StatusCode(499); } catch (Exception ex) { _logger.LogError(ex, 創(chuàng)建訂單失敗訂單號(hào) {OrderId}, orderId); return StatusCode(500); }注意when (cts.IsCancellationRequested)這個(gè)過濾條件。有些情況下OperationCanceledException是下游某個(gè)操作自己拋的不代表當(dāng)前這個(gè)請求被取消。通過判斷當(dāng)前 CTS 的狀態(tài)可以精確區(qū)分“外部取消”和“內(nèi)部異?！?。還有一個(gè)細(xì)節(jié)如果你在自己的業(yè)務(wù)代碼里主動(dòng)ThrowIfCancellationRequested()異常堆棧上會(huì)有明確的調(diào)用點(diǎn)但如果你依賴框架層自動(dòng)拋出的取消異常通常會(huì)在異步狀態(tài)機(jī)層面比較難看。為了便于排查我建議在業(yè)務(wù)關(guān)鍵路徑上主動(dòng)調(diào)一次ThrowIfCancellationRequested這樣一旦出問題堆棧能直接指到業(yè)務(wù)代碼位置。至于日志和指標(biāo)取消不應(yīng)該記入錯(cuò)誤率。我們會(huì)單獨(dú)記一個(gè)canceled指標(biāo)用來觀察是哪些接口高頻被取消這往往是上游超時(shí)設(shè)置不合理或者下游響應(yīng)過慢的預(yù)警信號(hào)。把取消和錯(cuò)誤混在一起統(tǒng)計(jì)的監(jiān)控大屏很容易讓你在復(fù)盤時(shí)做出完全錯(cuò)誤的判斷。4. 陷阱三注冊回調(diào)的線程安全隱患與任務(wù)假死這個(gè)坑主要出在Register的濫用和異步等待的誤用上。很多人一旦知道“取消時(shí)可以注冊回調(diào)”就會(huì)興奮地在回調(diào)里塞一堆邏輯結(jié)果反而制造了新的問題。4.1 Register 回調(diào)里不要執(zhí)行耗時(shí)操作Register回調(diào)默認(rèn)運(yùn)行在調(diào)用了Cancel()的那個(gè)線程上也就是說誰觸發(fā)取消誰就要順帶把這些回調(diào)執(zhí)行完。如果你的回調(diào)里有阻塞操作——比如等鎖、調(diào)數(shù)據(jù)庫、刷日志——那么發(fā)起取消的那個(gè)線程會(huì)被阻塞住。更隱蔽的是如果回調(diào)里拋出了異常這個(gè)異常會(huì)傳播到調(diào)用Cancel()的線程上很可能直接導(dǎo)致某個(gè)后臺(tái)任務(wù)崩潰。清理回調(diào)的正確姿勢是只做輕量級(jí)的標(biāo)記、信號(hào)量釋放或者TaskCompletionSource的TrySetResult把真正的耗時(shí)清理放到等待任務(wù)的本體里。// 這是推薦的寫法 token.Register(() cleanupSignal.TrySetResult(true)); // 而不是 token.Register(async () { await _db.SaveChangesAsync(); });異步 lambda 更不能直接注冊。Register的回調(diào)類型是Action異步 lambda 編譯后會(huì)變成async void異常直接拋到線程池根本抓不到。如果你真的需要在取消時(shí)做異步清理請?jiān)谕饷嫦萢wait一個(gè)等待取消的任務(wù)再執(zhí)行清理。4.2 同步上下文死鎖是最膈應(yīng)人的事故ASP.NET Core 默認(rèn)沒有同步上下文所以現(xiàn)代 Web 應(yīng)用一般不踩這個(gè)坑。但在 WPF、WinForms、Xamarin 或者一些需要依賴同步上下文的項(xiàng)目中死鎖依舊存在。典型的場景UI 線程里直接.Result或.Wait()等待一個(gè)異步任務(wù)而這個(gè)任務(wù)內(nèi)部又在取消回調(diào)里嘗試回到 UI 線程執(zhí)行于是兩邊互相等任務(wù)假死。這其實(shí)是“取消”放大了原本就存在的異步阻塞問題。你在生產(chǎn)環(huán)境里尤其要小心那些“偽異步”代碼——比如在BackgroundService里同步等待、在事件處理器里.Wait()。4.3 Task.WaitAsync 不是萬能鑰匙.NET 6引入了Task.WaitAsync允許你給一個(gè)任務(wù)同時(shí)指定超時(shí)和取消令牌。很多人拿它解決“SDK 不支持取消”的問題但它有個(gè)副作用WaitAsync取消之后底層任務(wù)并不會(huì)被取消它還在跑。也就是說WaitAsync只是“我不等你了”不是“讓任務(wù)停下來”。后來我養(yǎng)成了一個(gè)習(xí)慣只用WaitAsync作為最后防線同時(shí)一定跟蹤底層任務(wù)的狀態(tài)。如果是用WhenAnyRegister的自定義 wrapper我會(huì)在 wrapper 里保證最終把底層任務(wù)的異?；蛘呓Y(jié)果消費(fèi)掉避免 UnobservedTaskException 的產(chǎn)生。這里還要補(bǔ)一句打斷阻塞任務(wù) ≠ 取消任務(wù)。Thread.Interrupt、Thread.Abort這些就別再用了CancellationToken是協(xié)作式取消不是強(qiáng)制殺死線程。指導(dǎo)思想是“讓任務(wù)自己意識(shí)到該停了”而不是“把任務(wù)連根拔起”。5. 陷阱四Cts 不釋放導(dǎo)致的定時(shí)器堆積與內(nèi)存壓力如果前面的坑屬于“功能不對”這個(gè)坑屬于“性能耗損”。它很慢但會(huì)在高并發(fā)下悄悄壓垮你的進(jìn)程。5.1 CancelAfter 背后的 TimerQueue 機(jī)制CancellationTokenSource有一個(gè)構(gòu)造函數(shù)帶TimeSpan參數(shù)也可以調(diào)用CancelAfter實(shí)現(xiàn)“到時(shí)自動(dòng)取消”。這背后的實(shí)現(xiàn)不是簡單的Thread.Sleep而是基于 .NET 內(nèi)置的定時(shí)器隊(duì)列TimerQueue。每個(gè) CTS 被創(chuàng)建并設(shè)置CancelAfter后它內(nèi)部就會(huì)在TimerQueue上注冊一個(gè)定時(shí)器節(jié)點(diǎn)。大量短期 CTS 如果頻繁創(chuàng)建但不釋放定時(shí)器節(jié)點(diǎn)就一直在隊(duì)列里掛著。每次設(shè)置CancelAfter都會(huì)觸發(fā)定時(shí)器鏈表的插入、排序、掃描當(dāng)并發(fā)量上來之后這些操作會(huì)積累成肉眼可見的 CPU 和內(nèi)存開銷。5.2 LinkedCts 與回調(diào)訂閱泄漏CancellationTokenSource.CreateLinkedTokenSource是一個(gè)很常用的 API用來把多個(gè) token 合并成一個(gè)。它內(nèi)部會(huì)在每個(gè)被連接的源上注冊回調(diào)。如果你創(chuàng)建了很多 LinkedCts但用完之后沒有Dispose這些回調(diào)引用會(huì)一直存在導(dǎo)致外層 CTS 無法被 GC 回收形成內(nèi)存泄漏。這個(gè)泄漏特別隱蔽因?yàn)槟憧床坏揭粋€(gè)單獨(dú)的“大對象”而是無數(shù)個(gè)小對象互相引用用 dotMemory 或者 dump 分析才能揪出來。定位到之后你會(huì)發(fā)現(xiàn)某個(gè)長期運(yùn)行的服務(wù)內(nèi)存只增不減就是因?yàn)橐粋€(gè)CreateLinkedTokenSource沒有釋放。5.3 高吞吐場景下的統(tǒng)一釋放策略我現(xiàn)在的做法是CTS 一律用using包裹并且Dispose和Cancel的順序要謹(jǐn)慎。共享一個(gè)剛改過的模板public async TaskResponse HandleAsync(Request request, CancellationToken requestToken) { // 先把外部 token 和本地超時(shí)合并 using var timeoutCts CancellationTokenSource.CreateLinkedTokenSource(requestToken); timeoutCts.CancelAfter(TimeSpan.FromSeconds(10)); // 業(yè)務(wù)處理 try { return await Process(request, timeoutCts.Token); } catch (OperationCanceledException) when (!requestToken.IsCancellationRequested) { // 本地超時(shí)導(dǎo)致的取消可以單獨(dú)處理 return Response.Timeout(); } }這里有兩條經(jīng)驗(yàn)外部傳入的 token 不要自行Dispose。它由創(chuàng)建者管理你只負(fù)責(zé)使用。自己創(chuàng)建的 CTS 一定要Dispose。using是最省心的方式。如果有些地方實(shí)在不能用using就在finally里手動(dòng)Dispose。釋放這個(gè)動(dòng)作還有一個(gè)隱藏的好處它會(huì)觸發(fā)內(nèi)部清理邏輯斷開注冊的回調(diào)引用讓 GC 能更早回收相關(guān)對象。在高并發(fā)場景下這一步做與不做內(nèi)存曲線的差別非常大。6. 陷阱五取消成功之后的“半完成狀態(tài)”沒有兜底最后一個(gè)坑嚴(yán)格來說是“取消后的善后邏輯”沒有設(shè)計(jì)好。很多人以為取消令牌只影響任務(wù)的“提前終止”但生產(chǎn)環(huán)境里更常見的問題是任務(wù)被取消了但是數(shù)據(jù)被寫進(jìn)了一個(gè)半完成的狀態(tài)或者后續(xù)邏輯因?yàn)檫@次取消產(chǎn)生了錯(cuò)誤數(shù)據(jù)。6.1 Finally 里的清理邏輯是否冪等一份比較典型的錯(cuò)誤代碼長這樣var order await _db.GetOrderAsync(orderId, token); try { order.Status OrderStatus.Processing; await _db.SaveChangesAsync(token); // 遠(yuǎn)程扣庫存這個(gè)調(diào)用比較慢 await _inventoryClient.DeductAsync(orderId, token); order.Status OrderStatus.Completed; await _db.SaveChangesAsync(token); } finally { // 這里如果被取消order.Status 還是 Processing而且可能壓根沒保存 // 如果你在 finally 里做了補(bǔ)償又可能因?yàn)榫W(wǎng)絡(luò)重試導(dǎo)致重復(fù)扣庫存 }假設(shè)DeductAsync在執(zhí)行到一半時(shí)被取消catch沒有兜底finally也沒做任何狀態(tài)修正整個(gè)訂單就停留在Processing。如果下游有一個(gè)掃描“處理中超過 5 分鐘”的定時(shí)任務(wù)它會(huì)把這條訂單撈出來重新處理重新去扣庫存——這就是經(jīng)典的重復(fù)扣款問題。解決思路不是讓finally越復(fù)雜越好而是把整個(gè)操作設(shè)計(jì)成“階段化 冪等”的每個(gè)階段開始前檢查 token確保不進(jìn)入一個(gè)注定無法完成的分支。取消發(fā)生后把當(dāng)前狀態(tài)寫清楚比如PendingRecovery并單獨(dú)記錄一條“補(bǔ)償日志”。補(bǔ)償操作必須有全局唯一的業(yè)務(wù)鍵數(shù)據(jù)庫加唯一索引保證任何重試都不會(huì)重復(fù)扣款。6.2 取消后更新狀態(tài)記錄的競態(tài)還有一個(gè)小型競態(tài)取消回調(diào)里你更新了內(nèi)存標(biāo)記而業(yè)務(wù)代碼同時(shí)在寫數(shù)據(jù)庫。如果取消發(fā)生在SaveChangesAsync的提交期間EF Core 會(huì)怎么處理實(shí)際上它會(huì)在內(nèi)部檢測到取消并回滾當(dāng)前事務(wù)可能拋出的并不是OperationCanceledException而是DbUpdateException具體取決于運(yùn)行時(shí)內(nèi)部流程。這個(gè)問題在低版本運(yùn)行時(shí)里面出現(xiàn)過所以不要假設(shè)“取消了就一定能收到取消異?！?。6.3 干凈的三態(tài)設(shè)計(jì)完成、失敗、取消到我手上的項(xiàng)目我會(huì)建議業(yè)務(wù)接口在設(shè)計(jì)階段就把“取消”定義為一種顯式的終態(tài)而不是“未知”。比如訂單狀態(tài)枚舉里必須有Canceled這個(gè)值并且取消之后如果還有未完成的子任務(wù)發(fā)短信、推送、發(fā)送 webhook需要走專門的“延遲重試隊(duì)列”而不是當(dāng)作失敗立刻重試。“取消”本身是可以作為一次合法業(yè)務(wù)流程結(jié)束的——業(yè)務(wù)方主動(dòng)放棄、超時(shí)未完成都應(yīng)該有對應(yīng)的狀態(tài)收斂。切忌把取消當(dāng)成異常、把異常當(dāng)成失敗、把失敗當(dāng)成重試信號(hào)。一個(gè)只含Success/Failed兩態(tài)的系統(tǒng)碰上取消必出幺蛾子。7. 生產(chǎn)環(huán)境可復(fù)用的取消策略一個(gè)公共模板到了收尾的部分我把自己常用的一套取消策略框架寫在這里。它不是銀彈但至少能幫你把前面 5 個(gè)坑都堵上大部分。7.1 公共 TokenHandler 的設(shè)計(jì)我習(xí)慣封裝一個(gè)CancellationContext類把 CTS、外部 token、超時(shí)策略和清理回調(diào)統(tǒng)一管理起來。大致骨架如下public sealed class CancellationContext : IDisposable { private readonly CancellationTokenSource _linkedCts; public CancellationToken Token _linkedCts.Token; public CancellationContext(CancellationToken externalToken, TimeSpan timeout) { _linkedCts CancellationTokenSource.CreateLinkedTokenSource(externalToken); _linkedCts.CancelAfter(timeout); } public void Cancel() _linkedCts.Cancel(); public void Dispose() _linkedCts.Dispose(); }使用的時(shí)候using var ctx new CancellationContext(requestToken, TimeSpan.FromSeconds(10)); var result await DoWorkAsync(ctx.Token);這個(gè)封裝帶來的統(tǒng)一好處是超時(shí)、外部取消、主動(dòng)調(diào)用Cancel()全都會(huì)觸發(fā)同一個(gè) token。你不需要在每個(gè)業(yè)務(wù)方法里都去構(gòu)建 CTS。7.2 壓測與診斷手段再分享一個(gè)診斷經(jīng)驗(yàn)。如果懷疑取消沒生效先別急著加代碼。我會(huì)先做一輪壓測在壓測過程中手動(dòng)觸發(fā)取消模擬客戶端斷開然后看兩件事線程池活動(dòng)線程數(shù)是否回落。如果不回落說明有不少任務(wù)仍然阻塞著取消信號(hào)沒起效。進(jìn)程內(nèi)存是否持續(xù)增長。如果增長重點(diǎn)檢查所有創(chuàng)建了 CTS 的地方有沒有釋放。一些診斷命令對這類問題很有用比如查看線程池狀態(tài)、抓 dump 分析任務(wù)堆棧等等。如果任務(wù)堆棧全都停在等待庫函數(shù)調(diào)用的地方那基本就是 token 沒傳到底層如果停在Task.Delay或同步等待上那就是內(nèi)部有阻塞調(diào)用沒走異步。7.3 分享幾條個(gè)人經(jīng)驗(yàn)文章寫到這我最后想說的經(jīng)驗(yàn)可能有點(diǎn)反常識(shí)取消令牌設(shè)計(jì)的重點(diǎn)不在于“怎么取消”而在于“取消之后怎么收場”。一開始我也愛研究Register、ThrowIfCancellationRequested、WaitAsync這些 API 的底層實(shí)現(xiàn)但真正把生產(chǎn)環(huán)境搞崩的往往不是 API 不會(huì)用而是整個(gè)鏈路少了某幾個(gè) token或者在 catch 里把取消當(dāng)成異常。你在代碼評審的時(shí)候可以專門多問一句“如果這個(gè)操作被取消了數(shù)據(jù)庫里會(huì)留下什么狀態(tài)”很多問題當(dāng)場就能暴露。另外盡量把超時(shí)和取消分開理解。超時(shí)是可以預(yù)測的放棄取消是不可預(yù)測的中斷。兩者都需要收斂到明確終態(tài)。把超時(shí)也設(shè)計(jì)成一種“內(nèi)部原因的取消”是常見做法但必須能區(qū)分它和外部取消否則監(jiān)控?cái)?shù)據(jù)和用戶反饋會(huì)互相矛盾。這個(gè)領(lǐng)域還有很多細(xì)節(jié)可以聊比如自定義 Awaitable 的取消響應(yīng)、分布式任務(wù)里如何把取消信號(hào)傳遍集群等等。先把手頭的 5 個(gè)坑填平比摸更多花哨 API 更實(shí)在。希望這篇文章能讓你在下一次代碼評審里少看到一行Task.Delay(3000)后面沒跟 token。