那里有很多有用的.NET API（例如Microsoft Entity Framework的API DbContext），它們提供了旨在與之一起使用的異步方法await，但據(jù)記錄它們不是線程安全的。這使其非常適合在桌面UI應(yīng)用程序中使用，但不適用于服務(wù)器端應(yīng)用程序。[編輯] 這可能實(shí)際上并不適用DbContext，這是Microsoft 關(guān)于EF6線程安全性的聲明，請自行判斷。 [/編輯]也有一些已建立的代碼模式屬于同一類別，例如使用OperationContextScope（在此處和此處詢問）調(diào)用WCF服務(wù)代理，例如：using (var docClient = CreateDocumentServiceClient())using (new OperationContextScope(docClient.InnerChannel)){    return await docClient.GetDocumentAsync(docId);}這可能會(huì)失敗，因?yàn)镺perationContextScope在其實(shí)現(xiàn)中使用線程本地存儲(chǔ)。問題的根源AspNetSynchronizationContext是在異步ASP.NET頁中使用它來以更少的線程ASP.NET池線程來滿足更多的HTTP請求。使用AspNetSynchronizationContext，await可以在與發(fā)起異步操作的線程不同的線程上排隊(duì)一個(gè)延續(xù)，同時(shí)將原始線程釋放到池中，并可以用于服務(wù)另一個(gè)HTTP請求。這大大提高了服務(wù)器端代碼的可伸縮性。該機(jī)制在必須閱讀的“關(guān)于同步上下文的全部內(nèi)容”中進(jìn)行了詳細(xì)描述。因此，盡管不涉及并發(fā)API訪問，但是潛在的線程切換仍然阻止我們使用上述API。我一直在考慮如何在不犧牲可伸縮性的情況下解決此問題。顯然，收回這些API的唯一方法是針對可能受到線程切換影響的異步調(diào)用范圍保持線程親和性。假設(shè)我們具有這種線程相似性。無論如何，這些調(diào)用中的大多數(shù)都是受IO約束的（沒有線程）。當(dāng)異步任務(wù)掛起時(shí)，它所源自的線程可用于服務(wù)另一個(gè)類似任務(wù)的延續(xù)，該結(jié)果已經(jīng)可用。因此，它不應(yīng)過多地?fù)p害可伸縮性。這種方法并不是什么新鮮事物，實(shí)際上，Node.js已成功使用了類似的單線程模型。IMO，這是使Node.js如此受歡迎的原因之一。我不明白為什么這種方法不能在ASP.NET上下文中使用。定制任務(wù)調(diào)度程序（我們稱之為ThreadAffinityTaskScheduler）可以維護(hù)一個(gè)單獨(dú)的“親和公寓”線程池，以進(jìn)一步提高可伸縮性。一旦任務(wù)已排隊(duì)到那些“公寓”線程之一中，await任務(wù)內(nèi)部的所有繼續(xù)將在同一線程上進(jìn)行。這是鏈接問題中的非線程安全API 可以與此類方法一起使用的方式ThreadAffinityTaskScheduler：// create a global instance of ThreadAffinityTaskScheduler - per web apppublic static class GlobalState {    public static ThreadAffinityTaskScheduler TaScheduler { get; private set; }    public static GlobalState     {        GlobalState.TaScheduler = new ThreadAffinityTaskScheduler(            numberOfThreads: 10);    }}// ...基于Stephen Toub的出色表現(xiàn)，我繼續(xù)進(jìn)行并作為概念證明進(jìn)行了實(shí)施ThreadAffinityTaskSchedulerStaTaskScheduler。ThreadAffinityTaskScheduler在經(jīng)典的COM意義上，由其維護(hù)的池線程不是STA線程，但是它們確實(shí)實(shí)現(xiàn)了線程的await連續(xù)性（SingleThreadSynchronizationContext對此負(fù)責(zé)）。到目前為止，我已經(jīng)將該代碼作為控制臺(tái)應(yīng)用程序進(jìn)行了測試，并且看起來可以按設(shè)計(jì)工作。我尚未在ASP.NET頁面中對其進(jìn)行測試。我沒有大量的ASP.NET生產(chǎn)開發(fā)經(jīng)驗(yàn)，所以我的問題是：在ASP.NET中非線程安全的API的簡單同步調(diào)用上使用這種方法是否有意義（主要目標(biāo)是避免犧牲可伸縮性）？除了使用同步API調(diào)用或完全避免這些APis之外，還有其他方法嗎？有沒有人在ASP.NET MVC或Web API項(xiàng)目中使用過類似的東西，并準(zhǔn)備分享他/她的經(jīng)驗(yàn)？任何有關(guān)如何使用ASP.NET進(jìn)行壓力測試和概要分析的建議都將受到贊賞。