1. 程式人生 > >Async和Await如何簡化非同步程式設計,幾個例項讓你徹底明白!

Async和Await如何簡化非同步程式設計,幾個例項讓你徹底明白!

部落格園

引言

C#5.0中async和await兩個關鍵字,這兩個關鍵字簡化了非同步程式設計,之所以簡化了,還是因為編譯器給我們做了更多的工作,下面就具體看看編譯器到底在背後幫我們做了哪些複雜的工作的。

同步程式碼存在的問題

對於同步的程式碼,大家肯定都不陌生,因為我們平常寫的程式碼大部分都是同步的,然而同步程式碼卻存在一個很嚴重的問題,例如我們向一個Web伺服器發出一個請求時,如果我們發出請求的程式碼是同步實現的話,這時候我們的應用程式就會處於等待狀態,直到收回一個響應資訊為止,然而在這個等待的狀態,對於使用者不能操作任何的UI介面以及也沒有任何的訊息,如果我們試圖去操作介面時,此時我們就會看到”應用程式為響應”的資訊(在應用程式的視窗旁),相信大家在平常使用桌面軟體或者訪問web的時候,肯定都遇到過這樣類似的情況的,對於這個,大家肯定會覺得看上去非常不舒服。引起這個原因正是因為程式碼的實現是同步實現的,所以在沒有得到一個響應訊息之前,介面就成了一個”卡死”狀態了,所以這對於使用者來說肯定是不可接受的,因為如果我要從伺服器上下載一個很大的檔案時,此時我們甚至不能對窗體進行關閉的操作的。為了具體說明同步程式碼存在的問題(造成介面開始),下面通過一個程式讓大家更形象地看下問題所在:

// 單擊事件
        private void btnClick_Click(object sender, EventArgs e)
        {
            this.btnClick.Enabled = false;

            long length = AccessWeb();
            this.btnClick.Enabled = true;
            // 這裡可以做一些不依賴回覆的操作
            OtherWork();

            this.richTextBox1.Text += String.Format("\n 回覆的位元組長度為:  {0}.\r\n"
, length); txbMainThreadID.Text = Thread.CurrentThread.ManagedThreadId.ToString(); } private long AccessWeb() { MemoryStream content = new MemoryStream(); // 對MSDN發起一個Web請求 HttpWebRequest webRequest = WebRequest.Create("http://msdn.microsoft.com/zh-cn/"
) as HttpWebRequest; if (webRequest != null) { // 返回回覆結果 using (WebResponse response = webRequest.GetResponse()) { using (Stream responseStream = response.GetResponseStream()) { responseStream.CopyTo(content); } } } txbAsynMethodID.Text = Thread.CurrentThread.ManagedThreadId.ToString(); return content.Length; }

執行程式後,當我們點選窗體的 “點選我”按鈕之後,在得到伺服器響應之前,我們不能對窗體進行任何的操作,包括移動窗體,關閉窗體等,具體執行結果如下:

傳統的非同步程式設計來改善程式的響應

上面部分我們已經看到同步方法所帶來的實際問題了,為了解決類似的問題,.NET Framework很早就提供了對非同步程式設計的支援,下面就用.NET 1.0中提出的非同步程式設計模型(APM)來解決上面的問題,具體程式碼如下(註釋的部分通過獲得GUI執行緒的同步上文物件,然後同步呼叫同步上下文物件的post方法把要呼叫的方法交給GUI執行緒去處理,因為控制元件本來就是由GUI執行緒建立的,然後由它自己執行訪問控制元件的操作就不存在跨執行緒的問題了,程式中使用的是呼叫RichTextBox控制元件的Invoke方式來非同步回撥訪問控制元件的方法,其實背後的原來和註釋部分是一樣的,呼叫RichTextBox控制元件的Invoke方法可以獲得建立RichTextBox控制元件的執行緒資訊(也就是前一種方式的同步上下文),然後讓Invoke回撥的方法在該執行緒上執行):

private void btnClick_Click(object sender, EventArgs e)
        {
            this.richTextBox1.Clear();
            btnClick.Enabled = false;
            AsyncMethodCaller caller = new AsyncMethodCaller(TestMethod);
            IAsyncResult result = caller.BeginInvoke(GetResult, null);

            //// 捕捉呼叫執行緒的同步上下文派生物件
            //sc= SynchronizationContext.Current;
        }

        # region 使用APM實現非同步程式設計
        // 同步方法
        private string TestMethod()
        {       
            // 模擬做一些耗時的操作
            // 實際專案中可能是讀取一個大檔案或者從遠端伺服器中獲取資料等。
            for (int i = 0; i < 10; i++)
            {
                Thread.Sleep(200);
            }

            return "點選我按鈕事件完成";
        }

        // 回撥方法
        private void GetResult(IAsyncResult result)
        {
            AsyncMethodCaller caller = (AsyncMethodCaller)((AsyncResult)result).AsyncDelegate;
            // 呼叫EndInvoke去等待非同步呼叫完成並且獲得返回值
            // 如果非同步呼叫尚未完成,則 EndInvoke 會一直阻止呼叫執行緒,直到非同步呼叫完成
            string resultvalue = caller.EndInvoke(result);
            //sc.Post(ShowState,resultvalue);
            richTextBox1.Invoke(showStateCallback, resultvalue);
        }

        // 顯示結果到richTextBox
        private void ShowState(object result)
        {
            richTextBox1.Text = result.ToString();
            btnClick.Enabled = true;
        }

        // 顯示結果到richTextBox
        //private void ShowState(string result)
        //{
        //    richTextBox1.Text = result;
        //    btnClick.Enabled = true;
        //}
        #endregion

執行的結果為:

C# 5.0 提供的async和await使非同步程式設計更簡單

上面部分演示了使用傳統的非同步程式設計模型(APM)來解決同步程式碼所存在的問題,然而在.NET 2.0,.NET 4.0和.NET 4.5中,微軟都有推出新的方式來解決同步程式碼的問題,他們分別為基於事件的非同步模式,基於任務的非同步模式和提供async和await關鍵字來對非同步程式設計支援。關於前兩種非同步程式設計模式,在我前面的文章中都有介紹,大家可以檢視相關文章進行詳細地瞭解,本部分就C# 5.0中的async和await這兩個關鍵字如何實現非同步程式設計的問題來給大家介紹下。下面通過程式碼來了解下如何使用async和await關鍵字來實現非同步程式設計,並且大家也可以參看前面的部落格來對比理解使用async和await是非同步程式設計更簡單。

private async void btnClick_Click(object sender, EventArgs e)
        {
            long length = await AccessWebAsync();

            // 這裡可以做一些不依賴回覆的操作
            OtherWork();

            this.richTextBox1.Text += String.Format("\n 回覆的位元組長度為:  {0}.\r\n", length);
            txbMainThreadID.Text = Thread.CurrentThread.ManagedThreadId.ToString();
        }

        // 使用C# 5.0中提供的async 和await關鍵字來定義非同步方法
        // 從程式碼中可以看出C#5.0 中定義非同步方法就像定義同步方法一樣簡單。
        // 使用async 和await定義非同步方法不會建立新執行緒,
        // 它執行在現有執行緒上執行多個任務.
        // 此時不知道大家有沒有一個疑問的?在現有執行緒上(即UI執行緒上)執行一個耗時的操作時,
        // 為什麼不會堵塞UI執行緒的呢?
        // 這個問題的答案就是 當編譯器看到await關鍵字時,執行緒會
        private async Task<long> AccessWebAsync()
        {
            MemoryStream content = new MemoryStream();

            // 對MSDN發起一個Web請求
            HttpWebRequest webRequest = WebRequest.Create("http://msdn.microsoft.com/zh-cn/") as HttpWebRequest;
            if (webRequest != null)
            {
                // 返回回覆結果
                using (WebResponse response = await webRequest.GetResponseAsync())
                {
                    using (Stream responseStream = response.GetResponseStream())
                    {
                        await responseStream.CopyToAsync(content);
                    }
                }
            }

            txbAsynMethodID.Text = Thread.CurrentThread.ManagedThreadId.ToString() ;
            return content.Length;
        }

        private void OtherWork()
        {
            this.richTextBox1.Text += "\r\n等待伺服器回覆中.................\n";
        }

執行結果如下:

async和await關鍵字剖析

我們對比下上面使用async和await關鍵字來實現非同步程式設計的程式碼和在第二部分的同步程式碼,有沒有發現使用async和await關鍵字的非同步實現和同步程式碼的實現很像,只是非同步實現中多了async和await關鍵字和呼叫的方法都多了async字尾而已。正是因為他們的實現很像,所以我在第四部分才命名為使用async和await使非同步程式設計更簡單,就像我們在寫同步程式碼一樣,並且程式碼的coding思路也是和同步程式碼一樣,這樣就避免考慮在APM中委託的回撥等複雜的問題,以及在EAP中考慮各種事件的定義。從程式碼部分我們可以看出async和await的使用確實很簡單,我們就如在寫同步程式碼一般,但是我很想知道編譯器到底給我們做了怎樣的處理的?並且從執行結果可以發現,執行非同步方法的執行緒和GUI執行緒的ID是一樣的,也就是說非同步方法的執行在GUI執行緒上,所以就不用像APM中那樣考慮跨執行緒訪問的問題了(因為通過委託的BeginInvoke方法來進行回撥方法時,回撥方法是線上程池執行緒上執行的)。下面就用反射工具看看編譯器把我們的原始碼編譯成什麼樣子的:

// 編譯器為按鈕Click事件生成的程式碼
private void btnClick_Click(object sender, EventArgs e)
{
    <btnClick_Click>d__0 d__;
    d__.<>4__this = this;
    d__.sender = sender;
    d__.e = e;
    d__.<>t__builder = AsyncVoidMethodBuilder.Create();
    d__.<>1__state = -1;
    d__.<>t__builder.Start<<btnClick_Click>d__0>(ref d__);
}

看到上面的程式碼,作為程式設計師的我想說——編譯器你怎麼可以這樣呢?怎麼可以任意篡改我的程式碼呢?這樣不是侵犯我的版權了嗎?你要改最起碼應該告訴我一聲吧,如果我的原始碼看到它在編譯器中的實現是上面那樣的,我相信我的原始碼會說——難道我中了世間上最惡毒的面目全非腳嗎? 好吧,為了讓大家更好地理清編譯器背後到底做了什麼事情,下面就順著上面的程式碼摸瓜,我也來展示耍一套還我漂漂拳來幫助大家找到編譯器程式碼和原始碼的對應關係。我的分析思路為:

1、提出問題——我的click事件的原始碼到哪裡去了呢?

  從編譯器程式碼我們可以看到,前面的7句程式碼都是對某個類進行賦值的操作,最真正起作用的就是最後Start方法的呼叫。這裡又產生了幾個疑問——d__0是什麼型別? 該型別中的<>t__builder欄位型別的Start方法到底是做什麼用的? 有了這兩個疑問,我們就點選d__0(反射工具可以讓我們直接點選檢視)來看看它是什麼型別
  

// <btnClick_Click>d__0型別的定義,從下面程式碼可以看出它是一個結構體
// 該型別是編譯器生成的一個嵌入型別
// 看到該型別的實現有沒有讓你聯想到什麼?
private struct <btnClick_Click>d__0 : IAsyncStateMachine
{
    // Fields
    public int <>1__state;
    public Form1 <>4__this;
    public AsyncVoidMethodBuilder <>t__builder;
    private object <>t__stack;
    private TaskAwaiter<long> <>u__$awaiter2;
    public long <length>5__1;
    public EventArgs e;
    public object sender;

    // Methods
    private void MoveNext()
    {
        try
        {
            TaskAwaiter<long> CS$0$0001;
            bool <>t__doFinallyBodies = true;
            switch (this.<>1__state)
            {
                case -3:
                    goto Label_010E;

                case 0:
                    break;

                default:
            // 獲取用於等待Task(任務)的等待者。你要知道某個任務是否完成,我們就需要一個等待者物件對該任務進行一個監控,所以微軟就定義了一個等待者物件的
            // 從這裡可以看出,其實async和await關鍵字背後的實現原理是基於任務的非同步程式設計模式(TAP)
                    // 這裡程式碼是線上程池執行緒上執行的
                    CS$0$0001 = this.<>4__this.AccessWebAsync().GetAwaiter();
            // 如果任務完成就調轉到Label_007A部分的程式碼
                    if (CS$0$0001.IsCompleted)
                    {
                        goto Label_007A;
                    }
           
                    // 設定狀態為0為了退出回撥方法。
                    this.<>1__state = 0;
                    this.<>u__$awaiter2 = CS$0$0001;
            // 這個程式碼是做什麼用的呢?讓我們帶著問題看下面的分析
this.<>t__builder.AwaitUnsafeOnCompleted<TaskAwaiter<long>, Form1.<btnClick_Click>d__0>(ref CS$0$0001, ref this);
                    <>t__doFinallyBodies = false;
            // 返回到呼叫執行緒,即GUI執行緒,這也是該方法不會堵塞GUI執行緒的原因,不管任務是否完成都返回到GUI執行緒
                    return;
            }
            // 當任務完成時,不會執行下面的程式碼,會直接執行Label_007A中程式碼
            CS$0$0001 = this.<>u__$awaiter2;
            this.<>u__$awaiter2 = new TaskAwaiter<long>();
            // 為了使再次回撥MoveNext程式碼
            this.<>1__state = -1;
        Label_007A:
            // 下面程式碼是在GUI執行緒上執行的
            CS$0$0001 = new TaskAwaiter<long>();
            long CS$0$0003 = CS$0$0001.GetResult();
            this.<length>5__1 = CS$0$0003;
        // 我們原始碼中的程式碼這裡的
            this.<>4__this.OtherWork();
            this.<>4__this.richTextBox1.Text = this.<>4__this.richTextBox1.Text + string.Format("\n 回覆的位元組長度為:  {0}.\r\n", this.<length>5__1);
            this.<>4__this.txbMainThreadID.Text = Thread.CurrentThread.ManagedThreadId.ToString();
        }
        catch (Exception <>t__ex)
        {
            this.<>1__state = -2;
            this.<>t__builder.SetException(<>t__ex);
            return;
        }
    Label_010E:
        this.<>1__state = -2;
        this.<>t__builder.SetResult();
    }

    [DebuggerHidden]
    private void SetStateMachine(IAsyncStateMachine param0)
    {
        this.<>t__builder.SetStateMachine(param0);
    }
}

  如果你看過我的迭代器專題的話,相信你肯定可以聯想到該結構體就是一個迭代器的一個實現,其主要方法就是MoveNext方法。從上面的程式碼的註釋應該可以幫助我們解決在第一步提到的第一個問題,即<btnClick_Click>d__0是什麼型別,下面就分析下第二個問題,從<btnClick_Click>d__0結構體的程式碼中可以發現<>t__builder的型別是AsyncVoidMethodBuilder型別,下面就看看它的Start方法的解釋——執行關聯狀態機的生成器,即呼叫該方法就可以開始執行狀態機,執行狀態機指的就是執行MoveNext方法(MoveNext方法中有我們原始碼中所有程式碼,這樣就把編譯器生成的Click方法與我們的原始碼關聯起來了)。從上面程式碼註釋中可以發現,當該MoveNext被呼叫時會立即還回到GUI執行緒中,同時也有這樣的疑問——剛開始呼叫MoveNext方法時,任務肯定是還沒有被完成的,但是我們輸出我們原始碼中的程式碼,必須等待任務完成(因為任務完成才能調轉到Label_007A中的程式碼),此時我們應該需要回調MoveNext方法來檢查任務是否完成,(就如迭代器中的,我們需要使用foreach語句一直呼叫MoveNext方法),然而我們在程式碼卻沒有找到回撥的任何程式碼啊? 對於這個疑問,回撥MoveNext方法肯定是存在的,只是首次看上面程式碼的朋友還沒有找到類似的語句而已,上面程式碼註釋中我提到了一個問題——這個程式碼是做什麼用的呢?讓我們帶著問題看下面的分析,其實註釋下面的程式碼就是起到回撥MoveNext方法的作用,AsyncVoidMethodBuilder.AwaitUnsafeOnCompleted<TAwaiter, TStateMachine> 方法就是排程狀態機去執行MoveNext方法,從而也就解決了回撥MoveNext的疑問了。

相信大家從上面的解釋中可以找到原始碼與編譯器程式碼之間的對應關係了吧, 但是我在分析完上面的之後,又有一個疑問——當任務完成時,是如何退出MoveNext方法的呢?總不能讓其一直回撥吧,從上面的程式碼的註釋可以看出,當任務執行完成之後,會把<>1__state設定為0,當下次再回調MoveNext方法時就會直接退出方法,然而任務沒完成之前,同樣也會把<>1__state設定為0,但是Switch部分後面的程式碼又把<>1__state設定為-1,這樣就保證了在任務沒完成之前,MoveNext方法可以被重複回撥,當任務完成之後,<>1__state設定為-1的程式碼將不會執行,而是調轉到Label_007A部分。

經過上面的分析之後,相信大家也可以耍出一套還我漂漂拳去分析非同步方法AccessWebAsync(),其分析思路是和btnClick_Click的分析思路是一樣的.這裡就不重複囉嗦了。

分析完之後,下面再分享下幾個關於async和await常問的問題

問題一:是不是寫了async關鍵字的方法就代表該方法是非同步方法,不會堵塞執行緒呢?

 答: 不是的,對於只標識async關鍵字的(指在方法內沒有出現await關鍵字)的方法,呼叫執行緒會把該方法當成同步方法一樣執行,所以然而會堵塞GUI執行緒,只有當async和await關鍵字同時出現,該方法才被轉換為非同步方法處理。
 

問題二:“async”關鍵字會導致呼叫方法用執行緒池執行緒執行嗎?


  答: 不會,被async關鍵字標識的方法不會影響方法是同步還是非同步執行並完成,而是,它使方法可被分割成多個片段,其中一些片段可能非同步執行,這樣這個方法可能非同步完成。這些片段界限就出現在方法內部顯示使用”await”關鍵字的位置處。所以,如果在標記了”async”的方法中沒有顯示使用”await”,那麼該方法只有一個片段,並且將以同步方式執行並完成。在await關鍵字出現的前面部分程式碼和後面部分程式碼都是同步執行的(即在呼叫執行緒上執行的,也就是GUI執行緒,所以不存在跨執行緒訪問控制元件的問題),await關鍵處的程式碼片段是線上程池執行緒上執行。總結為——使用async和await關鍵字實現的非同步方法,此時的非同步方法被分成了多個程式碼片段去執行的,而不是像之前的非同步程式設計模型(APM)和EAP那樣,使用執行緒池執行緒去執行一整個方法。