每個人都知道異步可以為您提供“更好的吞吐量”、“可擴展性”以及在資源消耗方面更高效。在進行下面的實驗之前，我也想到了這種（簡單的）方式。它基本上告訴我們，如果我們考慮異步代碼的所有開銷并將其與正確配置的同步代碼進行比較，它幾乎不會產生性能/吞吐量/資源消耗優勢。問題：與正確配置線程池的同步代碼相比，異步代碼實際上執行得更好嗎？可能是我的性能測試以某種戲劇性的方式存在缺陷？測試設置：兩個 ASP.NET Web API 方法，JMeter 試圖用 200 個線程線程組調用它們（30 秒恢復時間）。[HttpGet][Route("async")]public async Task<string> AsyncTest(){    await Task.Delay(_delayMs);    return "ok";}[HttpGet][Route("sync")]public string SyncTest(){    Thread.Sleep(_delayMs);    return "ok";}這是響應時間（對數刻度）。請注意，當線程池注入足夠多的線程時，同步代碼如何變得更快。如果我們事先（通過SetMinThreads）設置線程池，它會從一開始就表現出色async。你會問資源消耗怎么樣?！熬€程在 CPU 時間調度、上下文切換和 RAM 占用方面的成本很高”。沒那么快。線程調度和上下文切換是高效的。就堆棧使用而言，線程不會立即消耗 RAM，而只是保留虛擬地址空間并僅提交實際需要的一小部分。讓我們看看數據怎么說。即使線程數量更多，同步版本的內存占用也更?。ㄓ成涞轿锢韮却娴墓ぷ骷?。