在winform開發，經常會遇到需要在控件上加載大量數據，這會導致程序出現假死狀態，這個時候我們就會想到線程。
所有的 .NET Framework 應用程序都是使用單線程創建的，單線程用於執行該應用程序。在智能客戶端應用程序中，這樣的線程創建並管理用戶界面 (UI)，因而稱為 UI 線程。
可以將 UI 線程用於所有的處理，其中包括 Web 服務調用、遠程對象調用和數據庫調用。然而，以這種方式使用 UI 線程通常並不是 一個好主意。在大多數情況下，您不能預測調用 Web 服務、遠程對象或數據庫會持續多久，而且在 UI 線程等待響應時，您可能會導致 UI 凍結。
通過創建附加線程，應用程序可以在不使用 UI 線程的情況下執行額外的處理。當應用程序調用 Web 服務時，可以使用多線程來防止 UI 凍結或並行執行某些本地任務，以整體提高應用程序的效率。在大多數情況下，您應該堅持在單獨的線程上執行任何與 UI 無關的任務。
線程的異步調用不多說，我們這里說的是當獲取了大量數據后需要返回UI 線程。在將數據綁定到控件上 這里可以先創建一個新線程(或者其他的異步方法)獲取數據，當數據獲取完后轉入UI線程使用BeginInvoke()方法。
異步調用有：
1 . 委托異步調用。
2. 使用IAsyncResult接口實現異步調用
3. 基於事件的異步調用模式
4. 創建新線程的異步方式
5. 使用線程池的異步方式
6. 使用BackgroundWorker實現異步調用
1. 委托異步調用：由於它的實現是將原本需要阻塞的操作交給線程池的工作線程來處理了， 此時線程池的工作線程被阻塞了。因此，此方法對於依賴【線程池的工作線程】來處理任務的編程模型來說是沒有意義的。 比如：Asp.net, Windows Services這類服務類的編程模型。但對於WinForm這樣的單線程編程模型來說， 是比較方便的，尤其是還可以實現並行執行一些任務。
2. 使用IAsyncResult接口實現異步調用：它的實現是將原本需要阻塞的操作交給線程池的I/O完成線程來處理了， 而在.net中，還沒有任何編程模型使用此類線程來執行處理任務，因此，適合於任何編程模型。 但並不是所有的API都支持此類接口，因此適用面有限，且使用較為復雜，尤其是某個過程需要多次異步調用時。 一般說來，許多I/O操作（文件I/O操作以及網絡I/O）是支持此類API接口的。
3. 基於事件的異步調用模式：這種方式可以認為是一種封裝模式，主要是為了簡化線程模型以及簡化調用方式，增強了API的易用性。 如果此模式用於對IAsyncResult接口（並非委托異步）實現包裝，那么它具有第2種方法的所有優點。
4. 創建新線程的異步方式：這種方式有點特殊，主要和什么樣的編程模型以及創建了多少線程有關。 對於服務類的編程模型來說，如果每次的請求處理都采用這種方式，顯然會創建大量線程，反而損害性能。 反之，在其它情況下也是可以考慮的。
5. 使用線程池的異步方式：基本上與第1種相似，不適合一些服務類的編程模型，僅僅適用於與用戶交互的桌面程序。
6. 使用BackgroundWorker的方式：其實也是在使用線程池的工作線程，因此最適用的領域與1，5相似，只是它在使用上更方便而已。