C# 線程同步的三類情景

　　C# 已經提供了咱們幾種很是好用的類庫如 BackgroundWorker、Thread、Task等，藉助它們，咱們就可以分分鐘編寫出一個多線程的應用程序。

　　好比這樣一個需求：有一個 Winform 窗體，點擊按鈕後，會將窗體中的數據導出到一個 output.pdf 文件中。原先的代碼沒有采用多線程技術，因此當點擊按鈕後，整個窗體就變成無響應了。爲了解決這個問題，可使用 Task.Run(()=>{...導出文件的代碼}); 

　　上面的代碼看似簡單，卻隱藏着種種危機。若是在導出的期間，窗體的數據被修改了，那會怎麼樣？若是多個窗體同時導出到同一個文件，又會怎麼樣？

　　在看完本系列後，你就會清楚了。

 

　　有點了解的朋友都知道線程同步有多種手段，什麼 mutex、moniter、seamphore、event 等等，我把它們歸爲三類，對應三種須要線程同步的情景。

 

情景一：此茅坑有主了

 　　當一個資源同時被多個線程訪問時，有可能會形成資源衝突（尤爲是在存在多個寫線程的時候）的情景。遇到這種狀況，在 C# 中，咱們可使用 Interlocked、lock、Moniter、SpinLock、ReadWriteLockSlim、Mutex 來處理問題。

關於不一樣方案間的區別，請猛擊這裏。

 

　　什麼狀況下會被認爲是情景一？

　　當你設計的類中出現靜態變量、IO操做時，就會遇到情景一。由於這些資源是由多個對象共享的，不一樣的線程很同時去訪問這些資源時，就可能會出現爭用。

　　當一個類被設計成單例，且包含實例變量時，也會遇到情景一。由於實例變量屬於這個單例，當多個線程操縱此單例時，該變量可能會被爭用。

　　當一個類中的方法調用線程操做某個實例變量時，也會遇到情景一。

 

情景二：數量有限，先到先得

 　　情景一強調的是一對多的情形，而在情景二中，資源的數量並不惟一。相比於情景一，情景二側重的是數量上的限制。而用於實現這一需求的類有：Semaphore、SemaphoreSlim。

　　關於不一樣方案間的區別，請猛擊這裏。

 

　　什麼狀況下會被認爲是情景二？

　　當所操做的公共資源存在併發數限制的時候（如數據庫鏈接、IIS鏈接數限制等），就被認爲是情景二。

 

情景三：我讓你動，你才能動！

 　　情景三關注的是線程執行過程當中的前後順序，而用於保證這種前後順序的方式就是經過線程通訊的方式：ManualResetEventSlim、ManualResetEvent、AutoResetEvent。

　　關於不一樣方案間的區別，請猛擊這裏。

 

　　什麼狀況下會被認爲是情景三？

　　當兩個線程所處理的事情有前後的依賴時，好比線程二的執行過程依賴線程一的執行結果，那就認爲是情景三。

 

不限使用情景

　　上面的各類方案並非絕對只限於某一場景，好比 AutoResetEvent 便可以用於情景三，也能夠用於情景一。可是，殺雞焉用牛刀，雖然使用 AutoResetEvent 可以實現情景一的需求，可是用不了 AutoResetEvent 的線程通訊能力，同時又會有一些額外的限制（每一個線程必須保證 wait 和 set 的成對使用，不然一個線程在鎖定資源後就可能被另外一個線程解鎖）。 

    lock (m)
    {
        //....
    }
     
    //等價於以下方式
    autoResetEvent.WaitOne();
    //....
    autoResetEvent.Set();

　　也有朋友說，能夠用情景一中的 lock 方案來實現情景三的需求。 

    AutoResetEvent autoReset = new AutoResetEvent(false);
    private void button1_Click(object sender, EventArgs e)
    {      
        Task.Run(() =>
        {
            autoReset.WaitOne();
            Console.WriteLine("步驟二");
        });
 
        Thread.Sleep(1000);//故意延遲從而保證第二個線程是在第一個線程以後才執行
        Task.Run(() =>
        {
            Console.WriteLine("步驟一");
            autoReset.Set();
        });
    }

　　上面這個例子最終輸出的結果可想而知。此實例說明，無論線程實際的執行順序如何，AutoResetEvent 都能很容易的保證兩個線程的執行順序。

 

　　若是用 lock 呢？ 

    private void button1_Click(object sender, EventArgs e)
    {
        Task.Run(() =>
        {
            lock (s)
            {
                Console.WriteLine("步驟一");
            }
        });
 
        Thread.Sleep(1000);//必須人爲確保步驟二的線程要在步驟一的線程以後執行
        Task.Run(() =>
        {
            lock (s)
            {
                Console.WriteLine("步驟二");
            }
        });
    }

　　雖然能實現，可是須要花費額外的代碼去人爲保證兩個線程的執行順序。

 

　　如何在這麼多方案中肯定最終所使用的，須要你能對項目的各類情景進行分析，根據實際情景選擇對應的方案，而不至於大材小用。

 

總 結

 　　經過本系列文章的介紹，但願讓你們能對多線程中可能碰到的情景有一個概念，不至於在面臨多線程的時候手忙腳亂。

 

　　本文來自《C# 基礎回顧: 線程同步的三類情景》