轉自：http://www.cnblogs.com/smartls/archive/2011/04/08/2008981.html#2457370

?

引言

　　在之前的《創建無阻塞的異步調用》中，已經介紹過異步調用的編寫步驟和實施原理。異步調用是CLR為開發者提供的一種重要的編程手段，它也是構建高性能、可伸縮應用程序的關鍵。在多核CPU越來越普及的今天，異步編程允許使用非常少的線程執行很多操作。我們通常使用異步完成許多計算型、IO型的復雜、耗時操作，去取得我們的應用程序運行所需要的一部分數據。在取得這些數據后，我們需要將它們綁定在UI中呈現。當數據量偏大時，我們會發現窗體變成了空白面板。此時如果用鼠標點擊，窗體標題將會出現”失去響應”的字樣，而實際上UI線程仍在工作著，這對用戶來說是一種極度糟糕的體驗。如果你希望了解其中的原因(并不復雜:))，并徹底解決該問題，那么花時間讀完此文也許是個不錯的選擇。 　　一般來說，窗體阻塞分為兩種情況。一種是在UI線程上調用耗時較長的操作，例如訪問數據庫，這種阻塞是UI線程被占用所導致，可以通過delegate.BeginInvoke的異步編程解決；另一種是窗體加載大批量數據，例如向ListView、DataGridView等控件中添加大量的數據。本文主要探討后一種阻塞。

基礎理論

　　這部分簡單介紹CLR對跨線程UI訪問的處理。作為基礎內容，相信大部分.NET開發者對它并不陌生，讀者可根據實際情況略過此處。

控件的線程安全檢測

　　在傳統的窗體編程中，UI中的控件元素與其他工作線程互相隔離，每次我們訪問一個UI控件，實際上都是在UI線程中進行。如果嘗試在其他線程中訪問控件，CLR針對不同的.NET Framework版本，會有不同的處理。在Framework1.x中，CLR允許應用程序以跨線程的方式運行，而在Framework2.0及以后版本中，System.Windows.Form.Control新增了CheckForIllegalCrossThreadCalls屬性，它是一個可讀寫的bool常量，標記我們是否需要對非UI線程對控件的調用做出檢測。如果指定true，當以其他線程訪問UI，CLR會跑出一個”InvalidOperationException:線程間操作無效，從不是創建控件***的線程訪問它”；如果為false，則不對該錯誤線程的調用進行捕獲，應用程序依然運行。 　　在Framework1.x版本中，這個值默認是false。問什么之后的版本會加入這個屬性來約束我們的UI呢？實際上官方對此的解釋是當有多個并發線程嘗試對UI進行讀寫時，容易造成線程爭用資源帶來的死鎖。所以，CLR默認不允許以非UI線程訪問控件。 　　然而，我們常常需要在窗體中使用異步線程來處理一些操作，例如IO和Socket通訊等。這時跨線程的UI訪問又是必須的，對此，.NET給我們的補充方案就是Control的Invoke和BeginInvoke。

Control的Invoke和BeginInvoke

對于這兩個方法，首先我們要有以下的認識：

Control.Invoke，Control.BeginInvoke和delegate.Invoke，delegate.BeginInvoke是不同的。

Control.Invoke中的委托方法，執行在主線程，也就是我們的UI線程。而Control.BeginInvoke從命名上來看雖然具有異步調用的特征(Begin)，但也仍然執行在UI線程。

如果在UI線程中直接調用Invoke和BeginInvoke，數據量偏大時，依然會造成UI的假死。

　　有很多開發者在初次接觸這兩個函數時，很容易就將它們同異步聯系起來、有些人會認為他們是獨立于UI線程之外的工作線程，實際上，他們都被這兩個函數的命名所蒙蔽了。如果以傳統調用異步的方式，直接調用Control.BeginInvoke，與同步函數的執行無異，UI線程還是會處理所有辛苦的操作，造成我們的應用程序阻塞。 　　Control.Invoke的調用模型很明確：在UI線程中以代碼順序同步執行，因此，拋開工作線程調用UI元素的干擾，我們可以將Control.Invoke視為同步，本文不做過多介紹。 　　很多開發者在接觸異步后，再來處理窗體假死的問題，很容易想當然的將Control.BeginInvoke視為WinForm封裝的異步。所以我們重點關注這個方法。

體驗BeginInvoke

　　前面說過，BeginInvoke除了命名上來看像異步，其實很多時候我們調用起來根本沒有異步的”非阻塞”特性，我用下面這個例子簡單的嘗試一次對BeginInvoke的調用。 　　如你所見，我現在創建了一個簡陋的Form，其中放置了一個Lable控件lable1,一個Button控件btn_Start，下面，開始code: privatevoid?btn_Start_Click(object?sender, EventArgs e)
{
//?儲存UI線程的標識符
int?curThreadID?=?Thread.CurrentThread.ManagedThreadId;

new?Thread((ThreadStart)delegate()
{
PrintThreadLog(curThreadID);
})
.Start();
}

privatevoid?PrintThreadLog(int?mainThreadID)
{
//?當前線程的標識符
//?A代碼塊
int?asyncThreadID?=?Thread.CurrentThread.ManagedThreadId;

//?輸出當前線程的扼要信息，及與UI線程的引用比對結果
//?B代碼塊
label1.BeginInvoke((MethodInvoker)delegate()
{
//?執行BeginInvoke內的方法的線程標識符
int?curThreadID?=?Thread.CurrentThread.ManagedThreadId;

label1.Text?=string.Format("Async Thread ID:{0},Current Thread ID:{1},Is UI Thread:{2}",
asyncThreadID, curThreadID, curThreadID.Equals(mainThreadID));
});

//?掛起當前線程3秒，模擬耗時操作
//?C代碼塊
Thread.Sleep(3000);
} 　　這段代碼在新的線程中訪問了UI，所以我們使用了label1.BeginInvoke函數。新的線程中，我們取得了當前工作線程的線程標識符，也取得了BeginInvoke函數內的線程。然后，將它與UI線程的標志符作比對，將結果輸出于Label1控件上。最后，我們掛起當前工作線程3秒，用于模擬一些常見的耗時操作。 　　為了便于區分，我們將這段代碼分為A、B、C三個代碼塊。 運行結果： 我們能得到以下結論： ●? PrintThreadLog函數主體(A、C代碼塊)執行在新的線程，它執行了不被BeginInvoke所包含的其他代碼。 ●? 當我們調用了Control.BeginInvoke之后，線程調度權回歸到了UI線程。也就是說，BeginInvoke內部的代碼(B代碼塊)均執行在UI線程。 ●? 在UI線程執行BeginInvok中封裝的代碼時，工作線程內的剩余代碼(C代碼塊)同時進行。它與BeginInvoke中的UI線程并行執行，互不干擾。 ●? 由于Thread.Sleep(3000)是隔離在UI線程外的工作線程，因此這行代碼帶來的線程阻塞實際上阻塞了工作線程，不會給UI帶來任何影響。

Control.BeginInvoke的真正含義

　　既然Control.BeginInvoke其中的委托函數仍執行在UI線程內，那這個”異步”到底指的是什么？話題回到本文最初：我們在上文已經提到了”控件的線程安全檢測”概念，相信大家對這種工作線程內調用Control.BeginInvoke的做法已經太熟悉了。我們也提到了”CLR不喜歡工作線程調用UI元素”。微軟的決心如此之大，以至于CLR團隊在.NET Framework2.0中添加了CheckForIllegalCrossThreadCalls和Control.Invoke、Control.BeginInvoke方法。這是一次相當重大的改革，CLR團隊希望達到這樣的效果： 　　如果不申明CheckForIllegalCrossThreadCalls = false;這樣的”不安全”代碼，你就只能使用Control.Invoke和Control.BeginInvoke；而只要使用后兩者，不論它們的上下文運行環境是其它工作線程還是UI線程，它們封裝的代碼都會執行在UI線程內。 所以，msdn對Control.BeginInvoke給出了這樣的解釋：在創建控件的基礎句柄所在線程上異步執行指定委托。 它的真正含義是：BeginInvoke所謂的異步，是相對于調用線程的異步，而不是相對于UI線程的異步。 　　CLR把Control.BeginInvoke(delegate method)中的異步函數執行在UI內，如果你像我上文那樣用新線程調用BeginInvoke，那么method相對于這個新線程內的其他函數是異步的。畢竟method執行在了UI線程，新線程立即回調，不必等待Control.BeginInvoke的完成。所以，這個后臺線程充分享受了”異步”的好處，不再阻塞，只是我們看不到而已；當然，如果你在BeginInvoke內執行一段耗時的代碼，無論是從遠程服務器獲取數據庫資料、IO讀取，還是在控件內加載一大批數據，UI線程還是阻塞的。 　　正如傳統的Delegate.BeginInvoke的異步工作線程取自于.NET線程池，Control.BeginInvoke的異步工作線程就是UI線程。 　　現在您明白兩種BeginInvoke的區別了嗎？

Control.Invoke、BeginInvoke與Windows消息

　　實際上，Invoke和BeginInvoke的原理是將調用的方法Marshal成消息，然后調用Win32Api的RegisterWindowMessage()向UI發送消息。我們使用Reflector，可以看到以下代碼： Control.Invoke: publicobject?Invoke(Delegate method,?paramsobject[] args)
{
using?(new?MultithreadSafeCallScope())
{
returnthis.FindMarshalingControl().MarshaledInvoke(this, method, args,?true);
}
} Control.BeginInvoke: [EditorBrowsable(EditorBrowsableState.Advanced)]
public?IAsyncResult BeginInvoke(Delegate method,?paramsobject[] args)
{
using?(new?MultithreadSafeCallScope())
{
return?(IAsyncResult)this.FindMarshalingControl().MarshaledInvoke(this, method, args,?false);
}
} 　　在以上代碼中我們看到Control.Invoke和BeginInvoke的不同之處，在于調用MarshaledInvoke時，Invoke向最后一個參數傳遞了true，而BeginInvoke則是false。 MarshaledInvoke的結構是這樣的： privateobject?MarshaledInvoke(Control caller, Delegate method,?object[] args,?bool?synchronous) 　　很明顯，最后一個參數synchronous表示是否按照同步處理。MarshaledInvoke內部這樣處理這個參數： if?(!synchronous)
{
return?entry;
}
if?(!entry.IsCompleted)
{
this.WaitForWaitHandle(entry.AsyncWaitHandle);
} 　　所以，BeginInvoke的處理就是直接回調，Invoke卻在等待異步函數執行完后，才繼續執行。 　　到此為止，Invoke和BeginInvoke的工作就結束了，其余的工作就是UI對消息的處理，它由Control的WndProc(ref Message m)來執行。消息處理到底會給我們的UI帶來什么樣的影響？接著來看Application.DoEvents()函數。

Application.DoEvents

　　Application.DoEvents()函數是WinForm編程中極為重要的函數，但實際編程中，大多數開發者極少調用它。如果您對這個函數缺乏了解，那很可能會在以后長期的編程中對“窗體假死”這樣的現象陷入迷惑。 　　當運行 Windows 窗體時，它將創建新窗體，然后該窗體等待處理事件。該窗體在每次處理事件時，均將處理與該事件關聯的所有代碼。所有其他事件在隊列中等待。當代碼處理事件時，應用程序不會響應。例如，如果將甲窗口拖到乙窗口之上，則乙窗口不會重新繪制。 　　如果在代碼中調用 DoEvents，則您的應用程序可以處理其他事件。 例如，如果您有向ListBox添加數據的窗體，并將 DoEvents 添加到代碼中，那么當將另一窗口拖到您的窗體上時，該窗體將重新繪制。如果從代碼中移除 DoEvents，那么在按鈕的單擊事件處理程序執行結束以前，您的窗體不會重新繪制。 　　因此，如果我們在窗體執行事件時，不處理消息隊列中的windows消息，窗體必然會失去響應。而上文已經介紹過，Control.Invoke和BeginInvoke都會向UI發送消息，造成UI對消息的處理，因此，這為我們解決窗體加載大量數據時的假死提供了思路。

解決方案

嘗試”無假死”

　　這次我們使用開發中出現頻率極高的ListView控件，體驗一次理想的”異步刷新”,窗體中有一個ListView控件命名為listView1,并將View設置為Detail，添加兩個ColumnHeader；一個Button命名為btn_Start，設計視圖如下： 開始code：??
privatereadonlyint?Max_Item_Count?=10000;

privatevoid?button1_Click(object?sender, EventArgs e)
{
new?Thread((ThreadStart)(delegate()
{
for?(int?i?=0; i?<?Max_Item_Count; i++)
{
//?此處警惕值類型裝箱造成的"性能陷阱"
listView1.Invoke((MethodInvoker)delegate()
{
listView1.Items.Add(new?ListViewItem(newstring[]?
{ i.ToString(),?string.Format("This is No.{0} item", i.ToString()) }));
});?
};
}))
.Start();
} 　　代碼運行后，你將會看到一個飛速滾動的ListView列表，在加載的過程中，列表以令人眼花繚亂的速度添加數據，此時你嘗試拉動滾動條，或者移動窗體，都會發現這次的效果與以往的”白板”、”假死”截然不同！這是一個令人欣喜的變化。 運行過程： 　　從我的截圖中可以看出，窗體在加載數據的過程中，依然繪制界面，并沒有出現”假死”。 　　如果上述代碼調用的是Control.BeginInvoke，程序會發生些奇怪的現象，想想是為什么？ ? 好吧，到了現在，我們終于可以松了一口氣了，界面響應的問題已經被解決，一切美好。但是，這樣的窗體還是暴漏出兩個大問題： 1．? 比起傳統加載，”無假死窗體”加載速度明顯減慢。 2．? 加載數據過程中，窗體發生劇烈閃爍現象。

問題分析

　　我們在調用Control.Invoke時，強迫窗體處理消息，從而使界面得到了響應，同時也產生了一些副作用。其中之一就是消息處理使得窗體發生了在循環中發生了重繪，”閃爍”現象就是窗體重繪引發的，有過GDI+開發經驗的開發者應該比較熟悉。同時，每次調用Invoke都會使UI處理消息，也直接增加了控件對數據處理的時間成本，導致了性能問題。 　　對于”性能問題”，我并沒有什么解決方案(有自己見解的朋友歡迎提出)。有些控件(ListView、ListBox)具有BeginUpdate和EndUpdate函數，可以臨時掛起刷新，加快性能。但畢竟我們這里創建了一個會滾動的界面，這種數據的”動態加載”方式是前者無法比擬的。 　　對于”閃爍”，我先來解釋問題的原因。通常，控件的繪制包括兩個環節：擦出原對象與繪制新對象。首先windows發送一個消息，通知控件擦除原圖像，然后進行繪制。如果要在控件面板上以SolidBrush繪制，控件就會在其面板上直接繪制內容。當用戶改變了控件尺寸，Windows將會調用很多繪制回收操作，當每次回收和繪制發生時，由于”繪制”較”擦除”更為延后，才會給用戶帶來”閃爍”的感覺。以往我們為解決此類問題，往往需要在Control.WndProc中作出復雜的處理。而.NET Framework為我們提供了更為優雅的一種方案，那就是雙緩沖，我們直接調用它即可。

最終方案

新建Windows組件DBListView.cs,讓它繼承自ListView。

在控件中添加如下代碼：

public?DBListView()
{
//?打開控件的雙緩沖
SetStyle(ControlStyles.OptimizedDoubleBuffer?|?ControlStyles.AllPaintingInWmPaint,?true);
} 　　將項目重新生成，然后從工具箱中拖出新增的組建DBListView到窗體上，命名為dbListView1，執行以下代碼： privatevoid?button1_Click(object?sender, EventArgs e)
{
new?Thread((ThreadStart)(delegate()
{
for?(int?i?=0; i?<?Max_Item_Count; i++)
{
//?此處警惕值類型裝箱造成的"性能陷阱"
dbListView1.Invoke((MethodInvoker)delegate()
{
dbListView1.Items.Add(new?ListViewItem(newstring[]
{ i.ToString(),?string.Format("This is No.{0} item", i.ToString()) }));
});
};
}))
.Start();
} 　　現在”閃爍”的問題是不是已經得到了解決？ 　　在我們的實際應用中，這種加載數據引起的阻塞是很常見的，在用戶對界面性能關注度不高的情況下，使用本文介紹的方式處理這種阻塞是一種不錯的選擇，如果以類似IE8、迅雷等軟件的載入動畫配合，效果會更理想。

轉載于:https://www.cnblogs.com/jayying/p/3172618.html

總結

以上是生活随笔為你收集整理的谈.Net委托与线程——解决窗体假死的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。