快捷導(dǎo)航

C#線程同步的三類情景分析

更新時(shí)間：2014年10月27日 08:59:28 投稿：shichen2014

這篇文章主要介紹了C#線程同步的三類情景分析,較為詳細(xì)生動(dòng)的講述了C#線程同步的三類情況,讓大家對(duì)C#多線程程序設(shè)計(jì)有一個(gè)深入的了解,需要的朋友可以參考下

本文實(shí)例講述了C#線程同步的三類情景，分享給大家供大家參考。具體分析如下：

C# 已經(jīng)提供了我們幾種非常好用的類庫(kù)如 BackgroundWorker、Thread、Task等，借助它們，我們就能夠分分鐘編寫(xiě)出一個(gè)多線程的應(yīng)用程序。

比如這樣一個(gè)需求：有一個(gè) Winform 窗體，點(diǎn)擊按鈕后，會(huì)將窗體中的數(shù)據(jù)導(dǎo)出到一個(gè) output.pdf 文件中。原先的代碼沒(méi)有采用多線程技術(shù)，所以當(dāng)點(diǎn)擊按鈕后，整個(gè)窗體就變成無(wú)響應(yīng)了。為了解決這個(gè)問(wèn)題，可以使用 Task.Run(()=>{...導(dǎo)出文件的代碼});

上面的代碼看似簡(jiǎn)單，卻隱藏著種種危機(jī)。如果在導(dǎo)出的期間，窗體的數(shù)據(jù)被修改了，那會(huì)怎么樣？如果多個(gè)窗體同時(shí)導(dǎo)出到同一個(gè)文件，又會(huì)怎么樣？

在看完本系列后，你就會(huì)清楚了。

有點(diǎn)了解的朋友都知道線程同步有多種手段，什么 mutex、moniter、seamphore、event 等等，我把它們歸為三類，對(duì)應(yīng)三種需要線程同步的情景。

情景一：此茅坑有主了

當(dāng)一個(gè)資源同時(shí)被多個(gè)線程訪問(wèn)時(shí)，有可能會(huì)造成資源沖突（尤其是在存在多個(gè)寫(xiě)線程的時(shí)候）的情景。遇到這種情況，在 C# 中，我們可以使用 Interlocked、lock、Moniter、SpinLock、ReadWriteLockSlim、Mutex 來(lái)處理問(wèn)題。

什么情況下會(huì)被認(rèn)為是情景一？

　　當(dāng)你設(shè)計(jì)的類中出現(xiàn)靜態(tài)變量、IO操作時(shí)，就會(huì)遇到情景一。因?yàn)檫@些資源是由多個(gè)對(duì)象共享的，不同的線程很同時(shí)去訪問(wèn)這些資源時(shí)，就可能會(huì)出現(xiàn)爭(zhēng)用。

　　當(dāng)一個(gè)類被設(shè)計(jì)成單例，且包含實(shí)例變量時(shí)，也會(huì)遇到情景一。因?yàn)閷?shí)例變量屬于這個(gè)單例，當(dāng)多個(gè)線程操縱此單例時(shí)，該變量可能會(huì)被爭(zhēng)用。

　　當(dāng)一個(gè)類中的方法調(diào)用線程操作某個(gè)實(shí)例變量時(shí)，也會(huì)遇到情景一。

情景二：數(shù)量有限，先到先得

情景一強(qiáng)調(diào)的是一對(duì)多的情形，而在情景二中，資源的數(shù)量并不唯一。相比于情景一，情景二側(cè)重的是數(shù)量上的限制。而用于實(shí)現(xiàn)這一需求的類有：Semaphore、SemaphoreSlim。

什么情況下會(huì)被認(rèn)為是情景二？

　　當(dāng)所操作的公共資源存在并發(fā)數(shù)限制的時(shí)候（如數(shù)據(jù)庫(kù)連接、IIS連接數(shù)限制等），就被認(rèn)為是情景二。

情景三：我讓你動(dòng)，你才能動(dòng)！

情景三關(guān)注的是線程執(zhí)行過(guò)程中的先后順序，而用于保證這種先后順序的方式就是通過(guò)線程通信的方式：ManualResetEventSlim、ManualResetEvent、AutoResetEvent。

什么情況下會(huì)被認(rèn)為是情景三？

當(dāng)兩個(gè)線程所處理的事情有先后的依賴時(shí)，比如線程二的執(zhí)行過(guò)程依賴線程一的執(zhí)行結(jié)果，那就認(rèn)為是情景三。

不限使用情景

上面的各種方案并不是絕對(duì)只限于某一場(chǎng)景，比如 AutoResetEvent 即可以用于情景三，也可以用于情景一。但是，殺雞焉用牛刀，雖然使用 AutoResetEvent 能夠?qū)崿F(xiàn)情景一的需求，但是用不了 AutoResetEvent 的線程通信能力，同時(shí)又會(huì)有一些額外的限制（每個(gè)線程必須保證 wait 和 set 的成對(duì)使用，否則一個(gè)線程在鎖定資源后就可能被另一個(gè)線程解鎖）。

復(fù)制代碼代碼如下:

    lock (m)
    {
        //....
    }

    //等價(jià)于如下方式
    autoResetEvent.WaitOne();
    //....
    autoResetEvent.Set();

　　也有朋友說(shuō)，可以用情景一中的 lock 方案來(lái)實(shí)現(xiàn)情景三的需求。

    AutoResetEvent autoReset = new AutoResetEvent(false);
    private void button1_Click(object sender, EventArgs e)
    {
        Task.Run(() =>
        {
            autoReset.WaitOne();
            Console.WriteLine("步驟二");
        });

        Thread.Sleep(1000);//故意延遲從而保證第二個(gè)線程是在第一個(gè)線程之后才執(zhí)行
        Task.Run(() =>
        {
            Console.WriteLine("步驟一");
            autoReset.Set();
        });
    }

　　上面這個(gè)例子最終輸出的結(jié)果可想而知。此實(shí)例說(shuō)明，不管線程實(shí)際的執(zhí)行順序如何，AutoResetEvent 都能很容易的保證兩個(gè)線程的執(zhí)行順序。

如果用 lock 呢？

復(fù)制代碼代碼如下:

    private void button1_Click(object sender, EventArgs e)

    {

        Task.Run(() =>

        {

            lock (s)

            {

                Console.WriteLine("步驟一");

            }

        });

        Thread.Sleep(1000);//必須人為確保步驟二的線程要在步驟一的線程之后執(zhí)行

        Task.Run(() =>

        {

            lock (s)

            {

                Console.WriteLine("步驟二");

            }

        });

    }