對於全是async await 的controller方法，實際上會一步步執行，有什麼意義呢？

有可以await等待的方法才用async，而大多數用await等待的方法都是IO非同步的，起碼庫裡面提供的必須是

如果你沒有顯示的並發操作，確實執行順序沒有變化，意義在於等待非同步方法執行玩的時候，沒有花費任何線程去等待他，前提是IO非同步，比如讓資料庫刪除一個數據，發給資料庫了要過一段時間才能得到結果，但這個時間段從網卡到資料庫到網卡，都是別人在做事情，不需要我們佔用線程去等待，就使用await等。

其實就是nodejs一直吹的無阻塞非同步，nodejs吹了半天還在寫回調，而C#早就用上了async await，好幾年後jser才真正普及async await。就是這麼個過程。

節約線程的好處就在於線程池數量有限，創建過程慢，在大並發下能節約系統資源。因為請求多了以後，每個請求是你看不見的並發。

不要為了非同步而非同步（假非同步），controller 裏有真正非同步的操作邏輯再考慮使用非同步，沒有非同步操作，直接用同步就可以了

我之前的一個回答：

如何理解ASP.MVC 5的非同步Action？?

www.zhihu.com圖標

裡面有MSDN上的鏈接，多看幾遍，注意裡面的示例。

「實際上會一步步執行」這顯然是不對的，都沒理解非同步任務的精髓，在Action中使用非同步操作的最佳姿勢是把await操作傳遞到外部，讓外部調用進行await，而不是在內部await出結果之後再返回，那就是把非同步變同步了。

一般action方法執行業務邏輯，可能涉及到資料庫訪問等操作，相對比較耗時，可以將這些操作交給其它線程去做，把處理請求的線程換下來去處理其它請求，提高吞吐量

如果不是考慮高並發，這個非同步方案不是必須的。

考慮每秒要處理上萬次請求再來考慮這個問題。

個人認為還是有必要的，非同步編程已經成為一種習慣了，在controller的action使用async, 直觀感受是沒有的，但當有大量請求同時進來，就能體現優勢了，所以弄清楚IO非同步和網路非同步也是有必要的。

謝邀

看具體情況如果在前端足夠完善的情況下，不用async也好，更直接一些。

如果訪問數量很多，不妨故意讓前端等一下減緩壓力。

第一碰到await時這個線程不會阻塞，可以處理下個請求

第二執行async的代碼，有兩種可能，一種是面向設備的，不需要新線程來處理，一種是面向線程池的，需要從線程池中重新獲取一個線程來接著處理

有，能非同步 盡量非同步 能提高並發

可以提升性能，看你需不需要高並發

推薦閱讀：
相關文章