在 Invoke 或者 BeginInvoke 的使用中無一例外地使用了委托 Delegate ，至于委托的本質請參考我的另一隨筆： 對 .net事件的看法 。
一、為什么 Control類提供了 Invoke和 BeginInvoke機制？
關于這個問題的最主要的原因已經是 dotnet程序員眾所周知的，我在此費點筆墨再次記錄到自己的日志，以便日后提醒一下自己。
1、 windows程序消息機制
Windows GUI程序是基于消息機制的，有個主線程維護著一個消息泵。這個消息泵讓 windows程序生生不息。
Windows GUI 程序的消息循環
Windows程序有個消息隊列，窗體上的所有消息是這個隊列里面消息的最主要來源。這里的 while循環使用了 GetMessage（）這個方法，這是個阻塞方法，也就是隊列為空時方法就會被阻塞，從而這個 while循環停止運動，這避免了一個程序把 cpu無緣無故地耗盡，讓其它程序難以得到響應。當然在某些需要 cpu最大限度運動的程序里面就可以使用另外的方法，例如某些 3d游戲或者及時戰略游戲中，一般會使用 PeekMessage（）這個方法，它不會被 windows阻塞，從而保證整個游戲的流暢和比較高的幀速。
這個主線程維護著整個窗體以及上面的子控件。當它得到一個消息，就會調用 DispatchMessage方法派遣消息，這會引起對窗體上的窗口過程的調用。窗口過程里面當然是程序員提供的窗體數據更新代碼和其它代碼。
2、 dotnet里面的消息循環
public static void Main(string[] args)
{
Form f = new Form();
Application.Run(f);
}
Dotnet窗體程序封裝了上述的 while循環，這個循環就是通過 Application.Run方法啟動的。
3、線程外操作 GUI控件的問題
如果從另外一個線程操作 windows窗體上的控件，就會和主線程產生競爭，造成不可預料的結果，甚至死鎖。因此 windows GUI編程有一個規則，就是只能通過創建控件的線程來操作控件的數據，否則就可能產生不可預料的結果。
因此， dotnet 里面，為了方便地解決這些問題， Control 類實現了 ISynchronizeInvoke 接口，提供了 Invoke 和 BeginInvoke 方法來提供讓其它線程更新 GUI 界面控件的機制。
public interface ISynchronizeInvoke
{
[HostProtection (SecurityAction .LinkDemand, Synchronization=true , ExternalThreading=true )]
IAsyncResult BeginInvoke(Delegate method, object [] args);
object EndInvoke(IAsyncResult result);
object Invoke(Delegate method, object [] args);
bool InvokeRequired { get ; }
}
}
如果從線程外操作 windows窗體控件，那么就需要使用 Invoke或者 BeginInvoke方法，通過一個委托把調用封送到控件所屬的線程上執行。
二、消息機制 ---線程間和進程間通信機制
1、 window消息發送
Windows消息機制是 windows平臺上的線程或者進程間通信機制之一。 Windows消息值其實就是定義的一個數據結構，最重要的是消息的類型，它就是一個整數；然后就是消息的參數。消息的參數可以表示很多東西。
Windows 提供了一些 api 用來向一個線程的消息隊列發送消息。因此，一個線程可以向另一個線程的消息隊列發送消息從而告訴對方做什么，這樣就完成了線程間的通信。有些 api 發送消息需要一個窗口句柄，這種函數可以把消息發送到指定窗口的主線程消息隊列；而有些則可以直接通過線程句柄，把消息發送到該線程消息隊列中。
用消息機制通信
SendMessage是 windows api，用來把一個消息發送到一個窗口的消息隊列。這個方法是個阻塞方法，也就是操作系統會確保消息的確發送到目的消息隊列，并且該消息被處理完畢以后，該函數才返回。返回之前，調用者將會被暫時阻塞。
PostMessage也是一個用來發送消息到窗口消息隊列的 api函數，但這個方法是非阻塞的。也就是它會馬上返回，而不管消息是否真的發送到目的地，也就是調用者不會被阻塞。
2、 Invoke and BeginInvoke
Invoke or BeginInvoke
Invoke或者 BeginInvoke方 法都需要一個委托對象作為參數。委托類似于回調函數的地址，因此調用者通過這兩個方法就可以把需要調用的函數地址封送給界面線程。這些方法里面如果包含了 更改控件狀態的代碼，那么由于最終執行這個方法的是界面線程，從而避免了競爭條件，避免了不可預料的問題。如果其它線程直接操作界面線程所屬的控件，那么 將會產生競爭條件，造成不可預料的結果。
使用 Invoke完成一個委托方法的封送，就類似于使用 SendMessage方法來給界面線程發送消息，是一個同步方法。也就是說在 Invoke封送的方法被執行完畢前， Invoke方法不會返回，從而調用者線程將被阻塞。
使用 BeginInvoke方法封送一個委托方法，類似于使用 PostMessage進行通信，這是一個異步方法。也就是該方法封送完畢后馬上返回，不會等待委托方法的執行結束，調用者線程將不會被阻塞。但是調用者也可以使用 EndInvoke方法或者其它類似 WaitHandle機制等待異步操作的完成。
但是在內部實現上， Invoke和 BeginInvoke都是用了 PostMessage方法，從而避免了 SendMessage帶來的問題。而 Invoke方法的同步阻塞是靠 WaitHandle機制來完成的。
3、使用場合問題
如果你的后臺線程在更新一個 UI控件的狀態后不需要等待，而是要繼續往下處理，那么你就應該使用 BeginInvoke來進行異步處理。
如果你的后臺線程需要操作 UI控件，并且需要等到該操作執行完畢才能繼續執行，那么你就應該使用 Invoke。否則，在后臺線程和主截面線程共享某些狀態數據的情況下，如果不同步調用，而是各自繼續執行的話，可能會造成執行序列上的問題，雖然不發生死鎖，但是會出現不可預料的顯示結果或者數據處理錯誤。
可以看到 ISynchronizeInvoke有一個屬性， InvokeRequired。這個屬性就是用來在編程的時候確定，一個對象訪問 UI控件的時候是否需要使用 Invoke或者 BeginInvoke來進行封送。如果不需要那么就可以直接更新。在調用者對象和 UI對象同屬一個線程的時候這個屬性返回 false。在后面的代碼分析中我們可以看到， Control類對這一屬性的實現就是在判斷調用者和控件是否屬于同一個線程的。
三、 Delegate.BeginInvoke
通過一個委托來進行同步方法的異步調用，也是 .net提供的異步調用機制之一。但是 Delegate.BeginInvoke方法是從 ThreadPool取出一個線程來執行這個方法，以獲得異步執行效果的。也就是說，如果采用這種方式提交多個異步委托，那么這些調用的順序無法得到保證。而且由于是使用線程池里面的線程來完成任務，使用頻繁，會對系統的性能造成影響。
Delegate.BeginInvoke也是講一個委托方法封送到其它線程，從而通過異步機制執行一個方法。調用者線程則可以在完成封送以后去繼續它的工作。但是這個方法封送到的最終執行線程是運行庫從 ThreadPool里面選取的一個線程。
這里需要糾正一個誤區，那就是Control類上的異步調用BeginInvoke并沒有開辟新的線程完成委托任務，而是讓界面控件的所屬線程完成委托任務的。看來異步操作就是開辟新線程的說法不一定準確。