當我們處理一些長線的調用時，經常會導致界面停止響應或者IIS線程占用過多等問題，這個時候我們需要更多的是用異步編程來修正這些問題，但是通常 都是說起來容易做起來難，誠然異步編程相對于同步編程來說，它是一種完全不同的編程思想，對于習慣了同步編程的開發(fā)者來說，在開發(fā)過程中難度更大，可控性 不強是它的特點。
我們提供的服務有：成都網(wǎng)站建設、網(wǎng)站設計、微信公眾號開發(fā)、網(wǎng)站優(yōu)化、網(wǎng)站認證、民豐ssl等。為千余家企事業(yè)單位解決了網(wǎng)站和推廣的問題。提供周到的售前咨詢和貼心的售后服務，是有科學管理、有技術的民豐網(wǎng)站制作公司
在.NET Framework5.0種，微軟為我們系統(tǒng)了新的語言特性，讓我們使用異步編程就像使用同步編程一樣相近和簡單，本文中將會解釋以前版本的Framework中基于回調道德異步編程模型的一些限制以及新型的API如果讓我們簡單的做到同樣的開發(fā)任務。
為什么要異步
一直以來，使用遠程資源的編程都是一個容易造成困惑的問題，不同于“本地資源”，遠程資源的訪問總會有很多意外的情況，網(wǎng)絡環(huán)境的不穩(wěn)定機器服務端的故障，會造成很多程序員完 全不可控的問題，所以這也就要求程序員需要更多的去保護遠程資源的調用，管理調用的取消、超市、線程的等待以及處理線程長時間沒響應的情況等。而 在.NET中我們通常忽略了這些挑戰(zhàn)，事實上我們會有多種不用的模式來處理異步編程，比如在處理IO密集型操作或者高延遲的操作時候不組測線程，多數(shù)情況 我們擁有同步和異步兩個方法來做這件事?？墒菃栴}在于當前的這些模式非常容易引起混亂和代碼錯誤，或者開發(fā)人員會放棄然后使用阻塞的方式去開發(fā)。
而在如今的.NET中，提供了非常接近于同步編程的編程體驗，不需要開發(fā)人員再去處理只會在異步編程中出現(xiàn)的很多情況，異步調用將會是清晰的且不透明的，而且易于和同步的代碼進行組合使用。
過去糟糕的體驗
最好的理解這種問題的方式是我們最常見的一種情況：用戶界面只擁有一個線程所有的工作都運行在這個線程上，客戶端程序不能對用戶的鼠標時間做出反 應，這很可能是因為應用程序正在被一個耗時的操作所阻塞，這可能是因為線程在等待一個網(wǎng)絡ID或者在做一個CPU密集型的計算，此時用戶界面不能獲得運行 時間，程序一直處于繁忙的狀態(tài)，這是一個非常差的用戶體驗。
很多年來，解決這種問題的方法都是做異步花的調用，不要等待響應，盡快的返回請求，讓其他事件可以同時執(zhí)行，只是當請求有了最終反饋的時候通知應用程序讓客戶代碼可以執(zhí)行指定的代碼。
而問題在于：異步代碼完全毀掉了代碼流程，回調代理解釋了之后如何工作，但是怎么在一個while循環(huán)里等待？一個if語句？一個try塊或者一個using塊？怎么去解釋“接下來做什么”？
看下面的一個例子：
- public int SumPageSizes(IList uris)
- {
- int total = 0;
- foreach (var uri in uris)
- {
- txtStatus.Text = string.Format("Found {0} bytes...", total);
- var data = new WebClient().DownloadData(uri);
- total += data.Length;
- }
- txtStatus.Text = string.Format("Found {0} bytes total", total);
- return total;
- }
這個方法從一個uri列表里下載文件，統(tǒng)計他們的大小并且同時更新狀態(tài)信息，很明顯這個方法不屬于UI線程因為它需要花費非常長的時間來完成，這樣它會完全的掛起UI，但是我們又希望UI能被持續(xù)的更新，怎么做呢？
我們可以創(chuàng)建一個后臺編程，讓它持續(xù)的給UI線程發(fā)送數(shù)據(jù)來讓UI來更新自身，這個看起來是很浪費的，因為這個線程把大多時間花在等下和下載上，但 是有的時候，這正是我們需要做的。在這個例子中，WebClient提供了一個異步版本的DownloadData方法— DownloadDataAsync，它會立即返回，然后在DownloadDataCompleted后觸發(fā)一個事件，這允許用戶寫一個異步版本的方法 分割所要做的事，調用立即返回并完成接下來的UI線程上的調用，從而不再阻塞UI線程。下面是第一次嘗試：
- public void SumpageSizesAsync(IList uris)
- {
- SumPageSizesAsyncHelper(uris.GetEnumerator(), 0);
- }
- public void SumPageSizesAsyncHelper(IEnumerator enumerator, int total)
- {
- if (enumerator.MoveNext())
- {
- txtStatus.Text = string.Format("Found {0} bytes...", total);
- var client = new WebClient();
- client.DownloadDataCompleted += (sender,e)=>{
- SumPageSizesAsyncHelper(enumerator, total + e.Result.Length);
- };
- client.DownloadDataAsync(enumerator.Current);
- }
- else
- {
- txtStatus.Text = string.Format("Found {0} bytes total", total);
- }
- }
然后這依然是糟糕的，我們破壞了一個整潔的foreach循環(huán)并且手動獲得了一個enumerator，每一個調用都創(chuàng)建了一個事件回調。代碼用遞歸取代了循環(huán)，這種代碼你應該都不敢直視了吧。不要著急，還沒有完 。
原始的代碼返回了一個總數(shù)并且顯示它，新的一步版本在統(tǒng)計還沒有完成之前返回給調用者。我們怎么樣才可以得到一個結果返回給調用者，答案是：調用者必須支持一個回掉，我們可以在統(tǒng)計完成之后調用它。
然而異常怎么辦？原始的代碼并沒有關注異常，它會一直傳遞給調用者，在異步版本中，我們必須擴展回掉來讓異常來傳播，在異常發(fā)生時，我們不得不明確的讓它傳播。
最終，這些需要將會進一步讓代碼混亂：
- public void SumpageSizesAsync(IList uris,Action callback)
- {
- SumPageSizesAsyncHelper(uris.GetEnumerator(), 0, callback);
- }
- public void SumPageSizesAsyncHelper(IEnumerator enumerator, int total,Action callback)
- {
- try
- {
- if (enumerator.MoveNext())
- {
- txtStatus.Text = string.Format("Found {0} bytes...", total);
- var client = new WebClient();
- client.DownloadDataCompleted += (sender, e) =>
- {
- SumPageSizesAsyncHelper(enumerator, total + e.Result.Length,callback);
- };
- client.DownloadDataAsync(enumerator.Current);
- }
- else
- {
- txtStatus.Text = string.Format("Found {0} bytes total", total);
- enumerator.Dispose();
- callback(total, null);
- }
- }
- catch (Exception ex)
- {
- enumerator.Dispose();
- callback(0, ex);
- }
- }
當你再看這些代碼的時候，你還能立馬清楚的說出這是什么JB玩意嗎？
恐怕不能，我們開始只是想和同步方法那樣只是用一個異步的調用來替換阻塞的調用，讓它包裝在一個foreach循環(huán)中，想想一下試圖去組合更多的異步調用或者有更復雜的控制結構，這不是一個SubPageSizesAsync的規(guī)模能解決的。
我們的真正問題在于我們不再可以解釋這些方法里的邏輯，我們的代碼已經完全無章可循。異步代碼中很多的工作讓整件事情看起來難以閱讀并且似乎充滿了BUG。
#p#
一個新的方式
如今，我們擁有了一個新的功能來解決上述的問題，異步版本的代碼將會如下文所示：
- public async Task SumPageSizesAsync(IList uris)
- {
- int total = 0;
- foreach (var uri in uris)
- {
- txtStatus.Text = string.Format("Found {0} bytes...", total);
- var data = await new WebClient().DownloadDataTaskAsync(uri);
- total += data.Length;
- }
- txtStatus.Text = string.Format("Found {0} bytes total", total);
- return total;
- }
除了添加的高亮的部分，上文中的代碼與同步版本的代碼非常相似,代碼的流程也從未改變，我們也沒有看到任何的回調，但是這并不代表實際上沒有回調操作，編譯器會搞定這些工作，不再需要您去關心。
異步的方法是用了Task替代了原來返回的Int類型，Task和Task是在如今的framework提供的，用來代表一個正在運行的工作。
異步的方法沒有額外的方法，依照慣例為了區(qū)別同步版本的方法，我們在方法名后添加Async作為新的方法名。上文中的方法也是異步的，這表示方法體會讓編譯器區(qū)別對待，允許其中的一部分將會變成回調，并且自動的創(chuàng)建Task作為返回類型。
關于這個方法的解釋：在方法內部，調用另外一個異步方法DownloadDataTaskAsync，它快速的返回一個 Task類型的變量，它會在下載數(shù)據(jù)完成以后被激活，到如前為止，在數(shù)據(jù)沒有完成之前，我們不想做任何事，所以我們使用 await來等待操作的完成。
看起來await關鍵字阻塞了線程直到task完成下載的數(shù)據(jù)可用，其實不然，相反它標志了任務的回調，并且立即返回，當這個任務完成之后，它會執(zhí)行回調。
Tasks
Task和Task類型已經存在于.NET Framework 4.0中，一個Task代表一個進行時的活動，它可能是一個運行在單獨線程中的一個CPU密集型的工作或者一個IO操作，手動的創(chuàng)建一個不工作在單獨線程的任務也是非常容易的：
- static Task ReadFileAsync(string filePath,out byte[] buffer)
- {
- Stream stream = File.Open(filePath, FileMode.Open);
- buffer = new byte[stream.Length];
- var tcs = new TaskCompletionSource();
- stream.BeginRead(buffer, 0, buffer.Length, arr =>
- {
- var length = stream.EndRead(arr);
- tcs.SetResult(stream.Length);
- }, null);
- return tcs.Task;
- }
- 一旦創(chuàng)建了一個TaskCompletionSource對象，你就可以返回與它關聯(lián)的Task對象，問相關的工作完成后，客戶代碼才得到最終的結果，這時Task沒有占據(jù)自己的線程。
- 如果實際任務失敗，Task從樣可以攜帶異常并且向上傳播，如果使用await將觸發(fā)客戶端代碼的異常：
- static async void ReadAssignedFile()
- {
- byte[] buffer;
- try
- {
- double length = await ReadFileAsync("SomeFileDoNotExisted.txt", out buffer);
- }
- catch (Exception ex)
- {
- Console.WriteLine(ex.Message);
- }
- }
- static Task ReadFileAsync(string filePath,out byte[] buffer)
- {
- Stream stream = File.Open(filePath, FileMode.Open);
- buffer = new byte[stream.Length];
- var tcs = new TaskCompletionSource();
- stream.BeginRead(buffer, 0, buffer.Length, arr =>
- {
- try
- {
- var length = stream.EndRead(arr);
- tcs.SetResult(stream.Length);
- }
- catch (IOException ex)
- {
- tcs.SetException(ex);
- }
- }, null);
- return tcs.Task;
- }
基于任務的異步編程模型
上文中解釋了異步方法應該是的樣子-Task-based asynchronous Pattern(TAP)，上文中異步的體現(xiàn)只需要一個調用方法和異步異步方法，后者返回一個Task或者Task。
下文中將介紹一些TAP中的約定，包括怎么處理“取消”和“進行中”，我們將進一步講解基于任務的編程模型。
Async和await
理解async方法不運行在自己的線程是非常重要的，事實上，編寫一個async方法但是沒有任何await的話，它就將會是一個不折不扣的同步方法：
- static async Task TenToSevenAsync()
- {
- await Task.Delay(3000);
- return 7;
- }
假如你調用這個方法，將會阻塞線程10秒后返回7，這也許不是你期望的，在VS中也將得到一個警告，因為這可能永遠不是想要的結果。
只有一個async方法運行到一個await語句時，它才立即把控制權返回給調用方，然而只有當?shù)却娜蝿胀瓿芍螅艜嬲姆祷亟Y果，這意味著你需要確保async方法中的代碼不會做過多的任務或者阻塞性能的調用。下面的實例才是你所期望的效果
- static async Task TenToSevenAsync()
- {
- await Task.Delay(3000);
- return 7;
- }
Task.Delay實際上是異步版本的Tread,Sleep，它返回一個Task,這個Task將會在指定的時間內完成。
時間處理程序和無返回值的異步方法
異步方法可以從其他異步方法使用await創(chuàng)建，但是異步在哪里結束？
在客戶端程序中，通常的回答是異步方法由事件發(fā)起，用戶點擊一個按鈕，一個異步方法被激活，直到它完成，事件本身并不關系方法何時執(zhí)行完成。這就是通常所說的“發(fā)后既忘”
為了適應這種模式，異步方法通常明確的被設計為“發(fā)后既忘”-使用void作為返回值替代Task類型，這就讓方法 可以直接作為一個事件處理程序。當一個void saync的方法執(zhí)行時，沒有Task被返回，調用者也無法追蹤調用是否完成。
- private async void someButton_Click(object sender, RoutedEventArgs e)
- {
- someButton.IsEnabled = false;
- await SumPageSizesAsync(GetUrls()));
- someButton.IsEnabled = true;
- }
結束語
越寫到最后，越不說人話啦。。。。。
分享題目：親身體驗及舉例來全面解析C#異步編程
文章出自：
http://uogjgqi.cn/article/dhpgcje.html
