[[414358]]

本文轉(zhuǎn)載自微信公眾號「精益碼農(nóng)」，作者有態(tài)度的馬甲。轉(zhuǎn)載本文請聯(lián)系精益碼農(nóng)公眾號。

先說結(jié)論

1.首先兩者對于并發(fā)的風(fēng)格模型不一樣。

共享內(nèi)存利用多核CPU的優(yōu)勢，使用強一致的鎖機制控制并發(fā)， 各種鎖交織，稍不注意可能出現(xiàn)死鎖，更適合熟手。

Actor模型易于控制和管理，以消息觸發(fā)、流水線挨個處理，天然分布式，思路清晰。

2.真要說性能，求100_000 以內(nèi)的素數(shù)的個數(shù)]場景 & 電腦8c 16g的配置

• 2.1 理論上如果以默認(rèn)的Actor并發(fā)模型來做這個事情，共享內(nèi)存模型是優(yōu)于Actor模型的;
• 2.2 上文中我對于Actor做了多線程優(yōu)化，Actor模型性能慢慢追上來了。

下面請聽我嘮嗑。

默認(rèn)Actor模型

計算[100_000內(nèi)素數(shù)的個數(shù)]， 分為兩步：

(1) 迭代判斷當(dāng)前數(shù)字是不是素數(shù)

(2) 如果是素數(shù)，執(zhí)行sum++

完成以上兩步，共享內(nèi)存模型均能充分利用CPU多核心。

Actor模型：與TPL中的原語不同，TPL Datflow中的所有塊默認(rèn)是單線程的，這就意味著完成以上兩步的TransfromBlock和ActionBlock都是以一個線程挨個處理消息數(shù)據(jù) (這也是Dataflow的設(shè)計初衷，形成清晰單純的流水線)。

猜測此時：共享內(nèi)存相比默認(rèn)的Actor模型更具優(yōu)勢。

使用NUnit做單元測試，數(shù)據(jù)量從小到大: 10_000,50_000,100_000,200_000,300_000,500_000

using NUnit.Framework; 
using System; 
using System.Threading.Tasks; 
using System.Collections.Generic; 
using System.Threading; 
using System.Threading.Tasks.Dataflow; 
 
namespace TestProject2 
{ 
    public class Tests 
    { 
        [TestCase(10_000)] 
        [TestCase(50_000)] 
        [TestCase(100_000)] 
        [TestCase(200_000)] 
        [TestCase(300_000)] 
        [TestCase(500_000)] 
        public void ShareMemory(int num) 
        { 
            var sum = 0; 
            Parallel.For(1, num + 1, (x, state) => 
            { 
                var f = true; 
                if (x == 1) 
                    f = false; 
                for (int i = 2; i <= x / 2; i++) 
                { 
                    if (x % i == 0)  // 被[2,x/2]任一數(shù)字整除，就不是質(zhì)數(shù) 
                        f = false; 
                } 
                if (f == true) 
                { 
                    Interlocked.Increment(ref sum);// 共享了sum對象，“++”就是調(diào)用sum對象的成員方法 
                } 
            }); 
            Console.WriteLine($"1-{num}內(nèi)質(zhì)數(shù)的個數(shù)是{sum}"); 
        } 
 
        [TestCase(10_000)] 
        [TestCase(50_000)] 
        [TestCase(100_000)] 
        [TestCase(200_000)] 
        [TestCase(300_000)] 
        [TestCase(500_000)] 
        public async Task Actor(int num) 
        { 
            var linkOptions = new DataflowLinkOptions { PropagateCompletion = true }; 
            var bufferBlock = new BufferBlock<int>(); 
            var transfromBlock = new TransformBlock<int, bool>(x => 
            { 
                var f = true; 
                if (x == 1) 
                    f = false; 
                for (int i = 2; i <= x / 2; i++) 
                { 
                    if (x % i == 0)  // 被[2,x/2]任一數(shù)字整除，就不是質(zhì)數(shù) 
                        f = false; 
                } 
                return f; 
            }, new ExecutionDataflowBlockOptions { EnsureOrdered = false }); 
 
            var sum = 0; 
            var actionBlock = new ActionBlock<bool>(x => 
            { 
                if (x == true) 
                    sum++; 
            }, new ExecutionDataflowBlockOptions {  EnsureOrdered = false }); 
            transfromBlock.LinkTo(actionBlock, linkOptions); 
            // 準(zhǔn)備從pipeline頭部開始投遞 
            try 
            { 
                var list = new List<int> { }; 
                for (int i = 1; i <= num; i++) 
                { 
                    var b = await transfromBlock.SendAsync(i); 
                    if (b == false) 
                    { 
                        list.Add(i); 
                    } 
                } 
                if (list.Count > 0) 
                { 
                    Console.WriteLine($"md，num post failure，num:{list.Count},post again"); 
                    // 再投一次 
                    foreach (var item in list) 
                    { 
                        transfromBlock.Post(item); 
                    } 
                } 
                transfromBlock.Complete();  // 通知頭部，不再投遞了; 會將信息傳遞到下游。 
                actionBlock.Completion.Wait();  // 等待尾部執(zhí)行完 
                Console.WriteLine($"1-{num} Prime number include {sum}"); 
            } 
            catch (Exception ex) 
            { 
                Console.WriteLine($"1-{num} cause exception.",ex); 
            }    
        } 
    } 
} 

測試結(jié)果如下：

測試結(jié)果印證我說的結(jié)論2.1

優(yōu)化后的Actor模型

那后面我對Actor做了什么優(yōu)化呢? 能產(chǎn)生下圖的2.2結(jié)論。

請重新回看《三分鐘掌握共享內(nèi)存 & Actor并發(fā)模型》 TransfromBlock 塊的細(xì)節(jié)：

var transfromBlock = new TransformBlock<int, bool>(x => 
    { 
          var f = true; 
          if (x == 1) 
             f = false; 
          for (int i = 2; i <= x / 2; i++) 
          { 
                if (x % i == 0)  // 被[2,x/2]任一數(shù)字整除，就不是質(zhì)數(shù) 
                   f = false; 
           } 
           return f; 
     }, new ExecutionDataflowBlockOptions { MaxDegreeOfParallelism=50, EnsureOrdered = false }); // 這里開啟多線程并發(fā) 

上面說到默認(rèn)的Actor是以單線程處理輸入的消息，此次我們對這個TransfromBlock 塊設(shè)置了MaxDegreeOfParallelism 參數(shù)，

這個參數(shù)能在Actor中開啟多線程并發(fā)執(zhí)行，但是這里面就不能有共享變量(否則你又得加鎖)，恰好我們完成 (1) 迭代判斷當(dāng)前數(shù)字是不是素數(shù)這一步并不依賴共享對象，所以這(1)步開啟多線程以后性能與共享內(nèi)存模型基本沒差別。

那為什么總體性能慢慢超過共享內(nèi)存?

這是因為執(zhí)行第二步(2) 如果是素數(shù)，執(zhí)行sum++， 共享內(nèi)存要加/解鎖，線程切換; 而Actor單線程挨個處理, 總體上Actor就略勝共享內(nèi)存模型了。

這里再次強調(diào)，Actor模型執(zhí)行第二步(2) 如果是素數(shù)，執(zhí)行sum++，不可開啟MaxDegreeOfParallelism,因為依賴了共享變量sum

結(jié)束語

That's All， 感謝.NET圈紀(jì)檢委@懶得勤快促使我重溫了單元測試的寫法 & 深度分析Actor模型風(fēng)格。 

請大家仔細(xì)對比結(jié)論和上圖，脫離場景和硬件環(huán)境談性能就是耍流氓，理解不同并發(fā)模型的風(fēng)格和能力是關(guān)鍵， 針對場景和未來的拓展性、可維護性、可操作性做技術(shù)選型 。