我將試圖對async - await進行一次演講，並且我正在創建一個流程圖，試圖顯示可能的執行順序。這是異步等待如何工作的正確圖表？
我試圖基礎，從上述段落
異步方法的開始是，就像任何其他 方法執行。也就是說，它會同步運行，直到遇到「等待」（或 引發異常）。
「await」關鍵字是事物可以異步的地方。等待是 像一個一元運算符：它需要一個參數，一個等待（一個 「awaitable」是一個異步操作）。等待檢查 等待看它是否已經完成;如果已經等待 已經完成，那麼該方法只是繼續運行 （同步，就像常規方法一樣）。
如果「等待」看到等待沒有完成，那麼它異步執行 。它告訴等待完成時運行 方法的其餘部分，然後從異步方法返回。
稍後，當等待完成時，它將執行異步方法的其餘部分 。如果您正在等待內置的等待時間（例如 任務），則異步方法的其餘部分將在返回「await」之前捕獲的 「上下文」上執行。
從http://blog.stephencleary.com/2012/02/async-and-await.html
這
是模糊的，似乎不正確。
接下來會發生什麼裏面異步方法不依賴於調用者。該方法現在是獨立運行的獨立代理（如線程）。它有返回 a Task這是一個自己的句柄。來電者可以隨心所欲地執行該任務（例如等待，等待，...）。
但是，如果調用者只是放棄該任務，則異步方法將繼續運行。
圖片的「重新進入」部分發生在等待等待的時間。通常，這是一些外部事件，例如完成的IO或計時器。異步方法現在恢復執行，不知道或關心誰重新激活它。
把每個異步方法看作一個獨立的線程。邏輯上，每個await是Thread.Join()。
雖然這整個有想法，真的是不如根本就沒有混爲一談任務 - 得到完成的東西，需要 - 與線程 - 工人是做任務。這就等於異步工作流中的連接點是一個重要的洞察力，但我認爲線程過於強調作爲思考異步的默認機制。 –
usr的答案基本上是正確的，但我認爲它使得線程和任務之間的類比太強。任務不需要像另一個線程那樣。請記住，線程是工作者，任務就是工作。你可以在你的待辦事項列表上有一百件事情，而不需要僱傭任何工作人員去做。儘量不要將任務視爲輕量級工作者，因爲他們不是。他們是需要完成的工作;他們的工作是由交給你任務的代碼決定的。
你的圖開始了罰款，但它在熄滅了導軌「並調用者完成所有獨立的工作？」調用者的延續是，無論它是什麼。如果這種延續涉及到工作，它確實有效。其中一些工作可能是安排在當前線程上運行的任務。其中一些工作可能會保持UI的響應。
而且，不要忘記，調用者線程可以終止和任務的延續可以安排到另一個線程。
有可以在這裏發生很多很多的東西;如果不知道調用者究竟做了什麼以及調用者的線程環境是什麼，就不可能說出等待返回後立即發生的事情。
BTW的方法可以是同步或異步的，並且它可以仍然awaitable。 –
你認爲談談你不明白的事情是明智的嗎？關於這個功能，有大量的錯誤信息和模糊的思考;我不確定你想創造更多。 –
參見[該圖（https://i-msdn.sec.s-msft.com/dynimg/IC612215.jpeg），從[這裏]（https://msdn.microsoft.com/en-us/library /mt674882.aspx）。 –