為什么阻塞線程要消耗比異步/等待更多的時間？

Question

看到這個問題和答案；

當IIS已經處理請求並發時，為什么要使用異步控制器？

好的，線程比異步/等待構造消耗更多的資源，但是為什么呢？ 核心區別是什么？ 您仍然需要記住所有狀態，不是嗎？

為什么要限制線程池，但是您可以擁有更多的空閑異步/等待構造嗎？

是否因為async / await更了解您的應用程序？

Answer 1

創建一個新線程會為此線程分配一個單獨的內存區域，該線程區域專用於保留其資源，該線程主要是其調用堆棧，在Windows中占用1MB內存。

因此，如果您有1000個空閑線程，那么您至少要占用1GB的內存而無所作為。

異步操作的狀態也會占用內存，但這只是該操作和編譯器生成的狀態機所需的實際大小，並保留在堆中。

而且，使用許多線程並阻塞它們會帶來另一筆開銷（IMO會更大）。 當一個線程被阻塞時，它將被帶出CPU並與另一個線程進行切換（即上下文切換）。 這意味着您的線程在被阻塞時並未最佳地使用其時間片。 較高的上下文切換速率意味着您的計算機將執行更多的上下文切換開銷，並減少各個線程的實際工作。

適當地使用async-await可以啟用所有給定的時間片，因為線程將返回阻塞池，而不是阻塞，而是在異步操作同時繼續執行的同時執行另一個任務。

因此，總而言之，異步等待釋放的資源是CPU和內存，這使您的服務器可以使用相同數量的資源或更少資源的同時處理更多請求。

Answer 2

好吧，讓我們想象一下一個網絡服務器。 在他大部分時間里，他所做的只是等待。 通常，它實際上並沒有受CPU限制，而是有更多的I / O限制。 它等待網絡I / O，磁盤I / O等。每次等待之后，他都有一些事情（通常做的很短），然后他所做的只是再次等待。 現在，有趣的部分是他等待時發生了什么。 在最“瑣碎”的情況下（當然絕對不是生產情況），您將創建一個線程來處理您擁有的每個套接字。

現在，每個線程都有其自己的成本。 一些句柄，1 MB的堆棧空間...當然，並非所有這些線程都可以同時運行-因此OS調度程序需要處理該問題並選擇每次運行的正確線程（這意味着有很多上下文交換）。 它將為1個客戶工作。 適用於10位客戶。 但是，讓我們假設同時有10,000個客戶。 10,000個線程表示10GB內存。 這比世界上普通的Web服務器還要多。

所有這些資源，是因為您為用戶專用了一個線程。 但是，大多數這些線程什么都不做！ 他們只是在等待某些事情發生。 並且操作系統具有用於異步IO的API，該API允許您僅將要在IO操作完成后執行的操作排隊，而無需專用線程等待它。

如果使用async / await，則可以編寫將輕松使用更少線程的應用程序，並且每個線程將被更多地利用-更少的“無所事事”時間。

異步/等待不是唯一的方法。 您可以在引入異步/等待之前完成此操作。 但是，async / await允許您編寫可讀性強且易於編寫的代碼，並且看上去幾乎只在單個線程上運行（而不像以前那樣有很多回調和委托在運行）。

通過將異步/等待的簡單語法與操作系統的某些功能（如異步I / O）（通過使用IO完成端口）相結合，可以編寫更多可伸縮的代碼，而不會失去可讀性。

另一個著名的示例是WPF / WinForms。 您擁有UI線程，他所做的只是處理事件，通常沒有什么特別的事情。 但是，您不能阻止它，否則GUI會掛起，並且用戶將不喜歡它。 通過使用異步/等待並將每個“艱苦”的工作分解為簡短的操作，您可以實現負責任的UI和可讀代碼。 如果您必須訪問數據庫以執行查詢，則將從UI線程開始異步操作，然后“等待”它直到結束，並且您可以在UI線程中處理結果（因為例如，您需要將其顯示給用戶）。 您以前可能已經做過，但是使用async / await使其更具可讀性。

希望能幫助到你。

Answer 3

在這里要意識到的重要一點是，阻塞線程在解除阻塞之前不可用於執行任何其他工作。 遇到等待的線程可以自由返回線程池並進行其他工作，直到等待的值可用為止。

Answer 4

當您調用同步I / O方法時，執行代碼的線程將被阻塞，等待I / O完成。 要處理1000個並發請求，您將需要1000個線程。

當您調用異步I / O方法時，線程不會被阻塞。 它初始化I / O操作並可以處理其他事情。 它可以是方法的其余部分（如果不await ），或者可以是其他一些請求，如果您await I / O方法。 線程池不需要為新請求創建新線程，因為所有線程都可以得到最佳利用，並使CPU保持繁忙。

異步I / O操作實際上是在OS級別異步實現的。