c#多線程

c#多線程

電腦雜談　 發佈時間：2017-02-19 10:24:40　 來源：網絡整理

關於線程的知識點其實是很多的，比如多線程編程、線程上下文、異步編程、線程同步構造、GUI的跨線程訪問等等，本文只是從常見面試題的角度（也是開發過程中常用）去深入淺出線程相關的知識。如果想要系統的學習多線程，沒有捷徑的，也不要偷懶，還是去看書籍的比較好。

1. 描述線程與進程的區別？

2. 爲什麼GUI不支持跨線程訪問控件？一般如何解決這個問題？

3. 簡述後臺線程和前臺線程的區別？

4. 說說常用的鎖，lock是一種什麼樣的鎖？

5. lock爲什麼要鎖定一個參數，可不可鎖定一個值類型？這個參數有什麼要求？

6. 多線程和異步有什麼關係和區別？

7. 線程池的優點有哪些？又有哪些不足？

8. Mutex和lock有何不同？一般用哪一個作爲鎖使用更好？

9. 下面的代碼，調用方法DeadLockTest（20），是否會引起死鎖？並說明理由。

 

public void DeadLockTest(int i)
{
    lock (this)   //或者lock一個靜態object變量
    {
        if (i > 10)
        {
            Console.WriteLine(i--);
            DeadLockTest(i);
        }
    }
}

 

10. 用雙檢鎖實現一個單例模式Singleton。

11.下面代碼輸出結果是什麼？爲什麼？如何改進她？

 

int a = 0;
System.Threading.Tasks.Parallel.For(0, 100000, (i) =>
{
    a++; 
});
Console.Write(a);

 

我們運行一個exe，就是一個進程實例，系統中有很多個進程。每一個進程都有自己的內存地址空間，每個進程相當於一個獨立的邊界，有自己的獨佔的資源，進程之間不能共享代碼和數據空間。

每一個進程有一個或多個線程，進程內多個線程可以共享所屬進程的資源和數據，線程是操作系統調度的基本單元。線程是由操作系統來調度和執行的，她的基本狀態如下圖。

當我們創建了一個線程後，線程裏面到底有些什麼東西呢？主要包括線程內核對象、線程環境塊、1M大的用戶模式棧、內核模式棧。其中用戶模式棧對於普通的系統線程那1M是預留的，在需要的時候纔會分配，但是對於CLR線程，那1M是一開始就分類了內存空間的。

補充一句，CLR線程是直接對應於一個Windows線程的。

還記得以前學校裏學習課程裏講到，的核心計算資源就是CPU核心和CPU寄存器，這也就是線程運行的主要戰場。操作系統中那麼多線程（一般都有上千個線程，大部分都處於休眠狀態），對於單核CPU，一次只能有一個線程被調度執行，那麼多線程怎麼分配的呢？Windows系統採用時間輪詢機制，CPU計算資源以時間片(大約30ms)的形式分配給執行線程。

計算雞資源（CPU核心和CPU寄存器）一次只能調度一個線程，具體的調度流程：

把CPU寄存器內的數據保存到當前線程內部（線程上下文等地方），給下一個線程騰地方；

線程調度：程集合裏取出一個需要執行的線程；

加載新線程的上下文數據到CPU寄存器；

新線程執行，享受她自己的CPU時間片（大約30ms），完了之後繼續回到第一步，繼續輪迴；

上面線程調度的過程，就是一次線程切換，一次切換就涉及到線程上下文等數據的搬入搬出，性能開銷是很大的。因此線程不可濫用，線程的創建和消費也是很昂貴的，這也是爲什麼建議儘量使用線程池的一個主要原因。

對於Thread的使用太簡單了，這裏就不重複了，總結一下線程的主要幾點性能影響：

線程的創建、銷燬都是很昂貴的；

線程上下文切換有極大的性能開銷，當然假如需要調度的新線程與當前是同一線程的話，就不需要線程上下文切換了，效率要快很多；

這一點需要注意，GC執行回收時，首先要（安全的）掛起所有線程，遍歷所有線程棧（根），GC回收後更新所有線程的根地址，再恢復線程調用，線程越多，GC要乾的活就越多；

當然現在硬件的發展，CPU的核心越來越多，多線程技術可以極大提高應用程序的效率。但這也必須在合理利用多線程技術的前提下，了線程的基本原理，然後根據實際需求，還要注意相關資源環境，如磁盤IO、網絡等情況綜合考慮。

單線程的使用這裏就略過了，那太easy了。上面總結了線程的諸多不足，因此微軟提供了可供多線程編程的各種技術，如線程池、任務、並行等等。

線程池的使用是非常簡單的，如下面的代碼，把需要執行的代碼提交到線程池，線程池內部會安排一個空閒的線程來執行你的代碼，完全不用管理內部是如何進行線程調度的。

 

ThreadPool.QueueUserWorkItem(t => Console.WriteLine("Hello thread pool"));

 

每個CLR都有一個線程池，線程池在CLR內可以多個AppDomain共享，線程池是CLR內部管理的一個線程集合，初始是沒有線程的，在需要的時候纔會創建。線程池的主要如下圖所示，基本流程如下：

線程池內部維護一個請求列隊，用於緩存用戶請求需要執行的代碼任務，就是ThreadPool.QueueUserWorkItem提交的請求；

有新任務後，線程池使用空閒線程或新線程來執行隊列請求；

任務執行完後線程不會銷燬，留着重複使用；

線程池自己負責維護線程的創建和銷燬，當線程池中有大量閒置的線程時，線程池會自動結束一部分多餘的線程來釋放資源；

線程池是有一個容量的，因爲他是一個池子嘛，可以設置線程池的最大活躍線程數，調用方法ThreadPool.SetMaxThreads可以設置相關參數。但很多編程實踐裏都不建議程序猿們自己去設置這些參數，其實微軟爲了提高線程池性能，做了大量的優化，線程池可以很智能的確定是否要創建或是消費線程，大多數情況都可以滿足需求了。

線程池使得線程可以充分有效地被利用，減少了任務啓動的延遲，也不用大量的去創建線程，避免了大量線程的創建和銷燬對性能的極大影響。

上面瞭解了線程的基本原理和諸多優點後，如果你是一個愛思考的猿類，應該會很容易發現很多疑問，比如把任務添加到線程池隊列後，怎麼取消或掛起呢？如何知道她執行完了呢？下面來總結一下線程池的不足：

線程池內的線程不支持線程的掛起、取消等操作，如想要取消線程裏的任務，.NET支持一種協作式方式取消，使用起來也不少很方便，而且有些場景並不滿足需求；

線程內的任務沒有返回值，也不知道何時執行完成；

不支持設置線程的優先級，還包括其他類似需要對線程有更多的控制的需求都不支持；

因此微軟爲我們提供了另外一個東西叫做Task來補充線程池的某些不足。

任務Task與並行Parallel本質上內部都是使用的線程池，提供了更豐富的並行編程的方式。任務Task基於線程池，可支持返回值，支持比較強大的任務執行計劃定製等功能，下面是一個簡單的示例。Task提供了很多方法和屬性，通過這些方法和屬性能夠對Task的執行進行控制，並且能夠獲得其狀態信息。Task的創建和執行都是獨立的，因此可以對關聯操作的執行擁有完全的控制權。

 

//創建一個任務
Task<int> t1 = new Task<int>(n =>
{
    System.Threading.Thread.Sleep(1000);
    return (int)n;
}, 1000);
//定製一個延續任務計劃
t1.ContinueWith(task =>
{
    Console.WriteLine("end" + t1.Result);
}, TaskContinuationOptions.AttachedToParent);
t1.Start();
//使用Task.Factory創建並啓動一個任務
var t2 = System.Threading.Tasks.Task.Factory.StartNew(() =>
{
    Console.WriteLine("t1:" + t1.Status);
});
Task.WaitAll();
Console.WriteLine(t1.Result);

 

並行Parallel內部其實使用的是Task對象（TPL會在內部創建System.Threading.Tasks.Task的實例），所有並行任務完成後纔會返回。少量短時間任務建議就不要使用並行Parallel了，並行Parallel本身也是有性能開銷的，而且還要進行並行任務調度、創建調用方法的委託等等。

這是很多開發C/S客戶端應用程序會遇到的問題，GUI程序的界面控件不允許跨線程訪問，如果在其他線程中訪問了界面控件，運行時就會拋出一個異常，就像下面的圖示，是不是很熟悉！這其中的罪魁禍首就是，就是“GUI的線程處理模型”。

.NET支持多種不同應用程序殊線程處理模型，UI控件元素只能由創建它的線程訪問或修改，微軟這樣處理是爲了保證UI控件的線程安全。c#多線程面試題

爲什麼在UI線程中執行一個耗時的計算操作，會導致UI假死呢？這個問題要追溯到Windows的消息機制了。

因爲Windows是基於消息機制的，我們在UI上所有的鍵盤、鼠標操作都是以消息的形式發送給各個應用程序的。GUI線程內部就有一個消息隊列，GUI線程不斷的循環處理這些消息，並根據消息更新UI的呈現。如果這個時候，你讓GUI線程去處理一個耗時的操作（比如花10秒去下載一個文件），那GUI線程就沒辦法處理消息隊列了，UI界面就處於假死的狀態。

那我們該怎麼辦呢？不難想到使用線程，那程裏處理事件完成後，需要更新UI控件的狀態，又該怎麼辦呢？常用幾種方式：

① 使用GUI控件提供的方法，Winform是控件的Invoke方法，WPF中是控件的Dispatcher.Invoke方法

 

//1.Winform：Invoke方法和BeginInvoke
 this.label.Invoke(method, null); 

//2.WPF：Dispatcher.Invoke
 this.label.Dispatcher.Invoke(method, null);

 

② 使用.NET中提供的BackgroundWorker執行耗時計算操作，在其任務完成事件RunWorkerCompleted 中更新UI控件

 

using (BackgroundWorker bw = new BackgroundWorker())
{
    bw.RunWorkerCompleted += new RunWorkerCompletedEventHandler((ojb,arg) =>
    {
        this.label.Text = "anidng";
    });
    bw.RunWorkerAsync();
}

 

③ 看上去很高大上的方法：使用GUI線程處理模型的同步上下文來送封UI控件修改操作，這樣可以不需要調用UI控件元素

.NET中提供一個用於同步上下文的類SynchronizationContext，利用它可以把應用程序模型鏈接到他的線程處理模型，其實它的本質還是調用的第一步①中的方法。

實現代碼分爲三步，第一步定義一個靜態類，用於GUI線程的UI元素訪問封裝：

 

public static class GUIThreadHelper
{
    public static System.Threading.SynchronizationContext GUISyncContext
    {
        get { return _GUISyncContext; }
        set { _GUISyncContext = value; }
    }

    private static System.Threading.SynchronizationContext _GUISyncContext =
        System.Threading.SynchronizationContext.Current;

    /// <summary>
    /// 主要用於GUI線程的同步回調
    /// </summary>
    /// <param name="callback"></param>
    public static void SyncContextCallback(Action callback)
    {
        if (callback == null) return;
        if (GUISyncContext == null)
        {
            callback();
            return;
        }
        GUISyncContext.Post(result => callback(), null);
    }

    /// <summary>
    /// 支持APM異步編程模型的GUI線程的同步回調
    /// </summary>
    public static AsyncCallback SyncContextCallback(AsyncCallback callback)
    {
        if (callback == null) return callback;
        if (GUISyncContext == null) return callback;
        return asynresult => GUISyncContext.Post(result => callback(result as IAsyncResult), asynresult);
    }
}

 

第二步，在主窗口註冊當前SynchronizationContext：

 

public partial class MainWindow : Window
    {
        public MainWindow()
        {
            InitializeComponent();
            CLRTest.ConsoleTest.GUIThreadHelper.GUISyncContext = System.Threading.SynchronizationContext.Current;
        }

 

第三步，就是使用了，可以在任何地方使用

 

GUIThreadHelper.SyncContextCallback(() =>
{
    this.txtMessage.Text = res.ToString();
    this.btnTest.Content = "DoTest";
    this.btnTest.IsEnabled = true;
});

 

多線程編程中很常用、也很重要的一點就是線程同步問題，掌握線程同步對臨界資源正確使用、線程性能有至關重要的作用！基本思路是很簡單的，就是加鎖嘛，在臨界資源的門口加一把鎖，來控制多個線程對臨界資源的訪問。但在實際開發中，根據資源類型不同、線程訪問方式的不同，有多種鎖的方式或控制機制（基元用戶模式構造和基元內核模式構造）。.NET提供了兩種線程同步的構造模式，需要理解其基本原理和使用方式。

基元線程同步構造分爲：基元用戶模式構造和基元內核模式構造，兩種同步構造方式各有優缺點，而混合構造（如lock）就是綜合兩種構造模式的優點。

基元用戶殊的cpu指令來協調線程，在硬件中發生，速度很快。但也因此Windows操作系統永遠檢測不到一個線程在一個用戶模式構造上阻塞了。舉個例子來模擬一下用戶模式構造的同步方式：

線程1請求了臨界資源，並在資源門口使用了用戶模式構造的鎖；

線程2請求臨界資源時，發現有鎖，因此就在門口等待，並不停的去詢問資源是否可用；

線程1如果使用資源時間較長，則線程2會一直運行，並且佔用CPU時間。佔用CPU幹什麼呢？她會不停的輪詢鎖的狀態，直到資源可用，這就是所謂的活鎖；

缺點有沒有發現？線程2會一直使用CPU時間（假如當前系統只有這兩個線程在運行），也就意味着不僅浪費了CPU時間，而且還會有頻繁的線程上下文切換，對性能影響是很嚴重的。

當然她的優點是效率高，適合哪種對資源佔用時間很短的線程同步。.NET中爲我們提供了兩種原子性操作，利用原子操作可以實現一些簡單的用戶模式鎖（如自旋鎖）。

System.Threading.Interlocked：易失構造，它在包含一個簡單數據類型的變量上執行原子性的讀或寫操作。

Thread.VolatileRead 和 Thread.VolatileWrite：互鎖構造，它在包含一個簡單數據類型的變量上執行原子性的讀和寫操作。

以上兩種原子性操作的具體內涵這裏就細說了（有興趣可以去研究文末給出的參考書籍或資料），針對題目11，來看一下題目代碼：

 

int a = 0;
System.Threading.Tasks.Parallel.For(0, 100000, (i) =>
{
    a++; 
});
Console.Write(a);

 

上面代碼是通過並行（多線程）來更新共享變量a的值，結果肯定是於等於100000的，具體多少是不穩定的。解決方法，可以使用我們常用的Lock，還有更有效的就是使用System.Threading.Interlocked提供的原子性操作，保證對a的值操作每一次都是原子性的：

 

System.Threading.Interlocked.Add(ref a, 1);//正確

 

下面的圖是一個簡單的性能驗證測試，分別使用Interlocked、不用鎖、使用lock鎖三種方式來測試。不用鎖的結果是95，這答案肯定不是你想要的，另外兩種結果都是對的，性能差別卻很大。

爲了模擬耗時操作，對代碼稍作了修改，如下，所有的循環裏面加了代碼Thread.Sleep(20);。如果沒有Thread.Sleep(20);他們的執行時間是差不多的。

 

System.Threading.Tasks.Parallel.For(0, 100, (i) =>
{
    lock (_obj)
    {
        a++; //不正確
        Thread.Sleep(20);
    }
});

 

這是針對用戶模式的一個補充，先模擬一個內核模式構造的同步流程來理解她的工作方式：

線程1請求了臨界資源，並在資源門口使用了內核模式構造的鎖；

線程2請求臨界資源時，發現有鎖，就會被系統要求睡眠（阻塞），線程2就不會被執行了，也就不會浪費CPU和線程上下文切換了；

等待線程1使用完資源後，解鎖後會發送一個通知，然後操作系統會把線程2喚醒。假如有多個線程在臨界資源門口等待，則會挑選一個喚醒；

看上去是不是非常棒！徹底解決了用戶模式構造的缺點，但內核模式也有缺點的：將線程從用戶模式切換到內核模式（或相反）導致巨大性能損失。調用線程將從託管代碼轉換爲內核代碼，再轉回來，會浪費大量CPU時間，同時還伴隨着線程上下文切換，因此儘量不要讓線程從用戶模式轉到內核模式。

她的優點就是阻塞線程，不浪費CPU時間，適合那種需要長時間佔用資源的線程同步。

內核模式構造的主要有兩種方式，以及基於這兩種方式的常見的鎖：

基於事件：如AutoResetEvent、ManualResetEvent

基於信號量：如Semaphore

既然內核模式和用戶模式都有優缺點，混合構造就是把兩者結合，充分利用兩者的優點，把性能損失降到最低。大概的思路很好理解，就是如果是在沒有資源競爭，或線程使用資源的時間很短，就是用用戶模式構造同步，否則就升級到內核模式構造同步，其中最典型的代表就是Lock了。

常用的混合鎖還不少呢！如SemaphoreSlim、ManualResetEventSlim、Monitor、ReadWriteLockSlim，這些鎖各有特點和鎖使用的場景。這裏主要就使用最多的lock來詳細瞭解下。

lock的本質就是使用的Monitor，lock只是一種簡化的語法形式，實質的語法形式如下：

 

bool lockTaken = false;
try
{
    Monitor.Enter(obj, ref lockTaken);
    //...
}
finally
{
    if (lockTaken) Monitor.Exit(obj);
}

 

那lock或Monitor需要鎖定的那個對象是什麼呢？注意這個對象纔是鎖的關鍵，在此之前，需要先回顧一下引用對象的同步索引塊（AsynBlockIndex），這是前面文章中提到過的引用對象的標準配置之一（還有一個是類型對象指針TypeHandle），它的作用就在這裏了。

同步索引塊是.NET中解決對象同步問題的基本機制，該機制爲每個堆內的對象（即引用類型對象實例）分配一個同步索引，她其實是一個地址指針，初始值爲-1不指向任何地址。

創建一個鎖對象Object obj，obj的同步索引塊（地址）爲-1，不指向任何地址；

Exit時，重置爲-1，那個同步索引塊1可以被重複利用；

因此，鎖對象要求必須爲一個引用對象（在堆上）。

首先還是儘量避免線程同步，不管使用什麼方式都有不的性能損失。一般情況下，大多使用Lock，這個鎖是比較綜合的，適應大部分場景。在性能要求高的地方，或者根據不同的使用場景，可以選擇更符合要求的鎖。

在使用Lock時，關鍵點就是鎖對象了，需要注意以下幾個方面：

這個對象肯定要是引用類型，值類型可不可呢？值類型可以裝箱啊！你覺得可不可以？但也不要用值類型，因爲值類型多次裝箱後的對象是不同的，會導致無法鎖定；

不要鎖定this，儘量使用一個沒有意義的Object對象來鎖；

不要鎖定一個類型對象，因類型對象是全局的；

不要鎖定一個字符串，因爲字符串可能被駐留，不同字符對象可能指向同一個字符串；

不要使用[System.Runtime.CompilerServices.MethodImpl(MethodImplOptions.Synchronized)]，這個可以使用在方法上面，保證方法同一時刻只能被一個線程調用。她實質上是使用lock的，如果是實例方法，會鎖定this，如果是靜態方法，則會鎖定類型對象；

一個應用程序實例是一個進程，一個進程內包含一個或多個線程，線程是進程的一部分；

進程之間是相互獨立的，他們有各自的私有內存空間和資源，進程內的線程可以共享其所屬進程的所有資源；

因爲GUI應用程序引入了一個特殊的線程處理模型，爲了保證UI控件的線程安全，這個線程處理模型不允許其他子線程跨線程訪問UI元素。解決方法還是比較多的，如：

利用UI控件提供的方法，Winform是控件的Invoke方法，WPF中是控件的Dispatcher.Invoke方法；

使用BackgroundWorker；

使用GUI線程處理模型的同步上下文SynchronizationContext來提交UI更新操作

上面幾個方式在文中已詳細給出。

應用程序必須運行完所有的前臺線程纔可以退出，或者主動結束前臺線程，不管後臺線程是否還在運行，應用程序都會結束；而對於後臺線程，應用程序則可以不考慮其是否已經運行完畢而直接退出，所有的後臺線程在應用程序退出時都會自動結束。

通過將 Thread.IsBackground 設置爲 true，就可以將線程指定爲後臺線程，主線程就是一個前臺線程。

常用的如如SemaphoreSlim、ManualResetEventSlim、Monitor、ReadWriteLockSlim，lock是一個混合鎖，其實質是Monitor['mɒnɪtə]。

lock的鎖對象要求爲一個引用類型。她可以鎖定值類型，但值類型會被裝箱，每次裝箱後的對象都不一樣，會導致鎖定無效。

對於lock鎖，鎖定的這個對象參數纔是關鍵，這個參數的同步索引塊指針會指向一個真正的鎖（同步塊），這個鎖（同步塊）會被複用。

多線程是實現異步的主要方式之一，異步並不等同於多線程。實現異步的方式還有很多，比如利用硬件的特性、使用進程或纖程等。c#多線程面試題在.NET中就有很多的異步編程支持，比如很多地方都有Begin***、End***的方法，就是一種異步編程支持，她內部有些是利用多線程，有些是利用硬件的特性來實現的異步編程。

優點：減線程創建和銷燬的開銷，可以複用線程；也從而減少了線程上下文切換的性能損失；在GC回收時，較少的線程更有利於GC的回收效率。

缺點：線程池無法對一個線程有更多的精確的控制，如瞭解其運行狀態等；不能設置線程的優先級；加入到線程池的任務（方法）不能有返回值；對於需要長期運行的任務就不適合線程池。

Mutex是一個基於內核模式的互斥鎖，支持鎖的遞歸調用，而Lock是一個混合鎖，一般建議使用Lock更好，因爲lock的性能更好。

 

public void DeadLockTest(int i)
{
    lock (this)   //或者lock一個靜態object變量
    {
        if (i > 10)
        {
            Console.WriteLine(i--);
            DeadLockTest(i);
        }
    }
}

 

不會的，因爲lock是一個混合鎖，支持鎖的遞歸調用，如果你使用一個ManualResetEvent或AutoResetEvent可能就會發生死鎖。

 

    public static class Singleton<T> where T : class,new()
    {
        private static T _Instance;
        private static object _lockObj = new object();

        /// <summary>
        /// 獲取單例對象的實例
        /// </summary>
        public static T GetInstance()
        {
            if (_Instance != null) return _Instance;
            lock (_lockObj)
            {
                if (_Instance == null)
                {
                    var temp = Activator.CreateInstance<T>();
                    System.Threading.Interlocked.Exchange(ref _Instance, temp);
                }
            }
            return _Instance;
        }
    }

int a = 0;
System.Threading.Tasks.Parallel.For(0, 100000, (i) =>
{
    a++; 
});
Console.Write(a);

 

輸出結果不穩定，於等於100000。因爲多線程訪問，沒有使用鎖機制，會導致有更新丟失。具體原因和改進在文中已經詳細的給出了。

個人能力有限，本文內容僅供學習、探討，歡迎指正、交流。

.NET面試題解析(00)-開篇來談談面試 & 系列文章索引

書籍：CLR via C#

書籍：你必須知道的.NET

.NET基礎拾遺（5）多線程開發基礎

歸納一下:C#線程同步的幾種方法