上個項目里遇到一個場景主進程負責從數(shù)據(jù)源拉取原始報文預處理之后要交給另一個獨立進程做深度分析。兩個進程是獨立部署的服務不能合并也不能用數(shù)據(jù)庫輪詢這種又慢又重的方案。我第一反應是命名管道壓測時發(fā)現(xiàn)數(shù)據(jù)體量大、單條報文又不算小管道在高頻傳輸場景下表現(xiàn)吃緊換TCP之后延遲能接受但連接管理、粘包拆包、斷線重連這些工作量一下子疊了上來。最后選了MemoryMappedFile內(nèi)存映射文件做共享內(nèi)存服務端和客戶端加起來不到六百行代碼穩(wěn)定跑了兩個多月。這篇就把完整的服務端客戶端范例、同步設計思路和踩過的坑整理出來。MemoryMappedFile這名字聽起來高大上本質(zhì)其實就是操作系統(tǒng)幫你在不同進程間共享同一塊物理內(nèi)存。WPF里看過大圖、做游戲加載過資源的朋友可能早就碰過它只是未必拿它做進程間通信。用它做IPC的最大優(yōu)勢是快——數(shù)據(jù)從寫方到讀方基本只有一次內(nèi)存拷貝延遲穩(wěn)定在微秒級而且沒有網(wǎng)絡協(xié)議棧開銷。本文適合正在選型IPC方案的C#開發(fā)者也適合已經(jīng)確定用共享內(nèi)存但不知道怎么設計同步邏輯、怎么寫安全代碼的新手。下面直接上干貨。1. 為什么選內(nèi)存映射文件做進程間通信1.1 原理操作系統(tǒng)怎么接管這塊內(nèi)存內(nèi)存映射文件的核心機制是把一塊磁盤文件或者系統(tǒng)分頁文件的一部分映射到進程的虛擬地址空間。進程里看到的是一段連續(xù)的字節(jié)數(shù)組讀寫它就跟讀寫普通byte[]一樣但底層物理頁由操作系統(tǒng)統(tǒng)一管理。當多個進程映射同一個命名對象時它們看到的就是同一份物理內(nèi)存A進程寫進去的字節(jié)B進程立刻就能讀到。這個過程不需要經(jīng)歷“拷貝到內(nèi)核緩沖區(qū)再拷貝回用戶態(tài)”的套路。管道和Socket在數(shù)據(jù)量大時會有多次拷貝和調(diào)度開銷而內(nèi)存映射文件在最優(yōu)情況下走的是內(nèi)存總線速度不在一個量級。我用4MB共享區(qū)、每條2KB報文做過一輪不嚴謹?shù)膲簻y吞吐能到幾百MB每秒延遲抖動的上限也比TCP穩(wěn)定得多。這里有一個關(guān)鍵細節(jié)MemoryMappedFile創(chuàng)建時可以指定容量但容量不等于實際占用物理內(nèi)存。操作系統(tǒng)按頁通常4KB管理只有真正寫入的頁才會駐留物理內(nèi)存。所以你可以放心把共享區(qū)開大一點沒有訪問到的部分基本不占資源。這也是它能支撐大緩沖區(qū)的底氣。1.2 幾種IPC方案的橫向?qū)Ρ任乙娺^不少項目明明只是本機兩個進程通信硬是引入了一套消息中間件運維成本直接翻倍。其實方案選型不需要追求復雜按數(shù)據(jù)規(guī)模、實時性、跨機器需求來定就行。方案延遲吞吐跨機器實現(xiàn)成本適用場景內(nèi)存映射文件最低微秒級最高不支持中等需設計同步大數(shù)據(jù)量、高頻、同機進程命名管道低偏低支持本機較低中小數(shù)據(jù)量、簡單命令交互TCP Socket低中支持中需處理粘包重連跨機器、網(wǎng)絡通信消息隊列高低支持低異步解耦、非實時場景從這個表能看出來內(nèi)存映射文件的定位非常明確同機、高吞吐、低延遲。如果兩個進程不在同一臺機器上那它再快也幫不上忙老老實實走Socket或消息隊列。如果在同一臺機器上它往往是性能上限最高的方案。1.3 邊界什么時候不該用它任何技術(shù)都有適用邊界。內(nèi)存映射文件不適合做“小消息多次通知”的場景比如你只想告訴另一個進程“配置變了”這種就用命名事件或者管道更輕。也不適合數(shù)據(jù)量小但頻率極高的場景因為每次寫共享區(qū)都要做偏移計算和可能的同步等待相比管道反而繁瑣。大數(shù)據(jù)場景它也有一個隱形坑就是大文件映射時的磁盤IO。如果你映射的是一個實際文件并且文件特別大操作系統(tǒng)按需加載頁首次訪問某些頁會觸發(fā)磁盤讀這會讓延遲出現(xiàn)毛刺。本文范例用的是“匿名/命名內(nèi)存映射”后端由分頁文件承載不走磁盤IO所以適合做高頻數(shù)據(jù)交換。如果業(yè)務本來就是大文件讀寫MemoryMappedFile也能做但那就是另一套優(yōu)化思路了。2. 服務端先創(chuàng)建共享內(nèi)存再把數(shù)據(jù)寫進去2.1 核心API其實就三板斧用MemoryMappedFile做服務端核心就三個動作創(chuàng)建共享區(qū)、創(chuàng)建視圖、寫入數(shù)據(jù)。創(chuàng)建共享區(qū)用MemoryMappedFile.CreateOrOpen或CreateNew第一個參數(shù)是給共享區(qū)起一個全局可見的名字第二個參數(shù)是字節(jié)容量。視圖就是拿到一段可讀寫的指針/訪問器在C#里有MemoryMappedViewAccessor和MemoryMappedViewStream兩種選擇。我強烈推薦MemoryMappedViewAccessor因為它支持按偏移量直接讀寫基礎類型和字節(jié)數(shù)組做自定義協(xié)議頭特別順手。MemoryMappedViewStream偏傳統(tǒng)流式操作適合大塊順序讀寫但在協(xié)議頭上要多寫不少轉(zhuǎn)換邏輯。如果你在別的博客里看到用Stream的寫法也不是不行只是我在這個場景里覺得Accessor更直觀。創(chuàng)建時有一個經(jīng)驗值容量建議設置成“協(xié)議頭大小 預估最大數(shù)據(jù)塊大小”并做頁大小對齊。Windows內(nèi)存映射的內(nèi)部粒度基本是系統(tǒng)頁常見4KB容量不一定要精確對齊頁對齊了能避免一些邊界上的性能損耗。我的慣例是把容量先算出來然后向上取整到4096的整數(shù)倍。2.2 服務端完整代碼范例這一節(jié)是全文的核心代碼可以直接抄下來跑。我用.NET 6的控制臺程序演示命名共享區(qū)、命名事件、命名互斥體都帶一個統(tǒng)一前綴方便客戶端定位。using System.IO.MemoryMappedFiles; using System.Text; using System.Threading; class IPC_Server { // 共享區(qū)命名和容量 private const string MapName Global\\IPC_Demo_SharedMemory; private const long Capacity 1024 * 1024; // 1MB 共享區(qū) private const int HeaderSize 20; // 協(xié)議頭字節(jié)數(shù)Magic(4)BodyLen(4)Seq(4)Timestamp(8) // 命名內(nèi)核對象一個用于通知“新數(shù)據(jù)已就緒”一個用于回執(zhí)“客戶端已讀” private static EventWaitHandle? _readyEvent; private static EventWaitHandle? _ackEvent; private static Mutex? _writeMutex; static void Main() { // 1. 創(chuàng)建共享內(nèi)存服務端用 CreateOrOpen容錯已存在的情況 using var mmf MemoryMappedFile.CreateOrOpen(MapName, Capacity); // 2. 穿創(chuàng)建視圖訪問器默認全量映射 using var accessor mmf.CreateViewAccessor(0, Capacity); // 3. 準備同步內(nèi)核對象 _readyEvent new EventWaitHandle(false, EventResetMode.AutoReset, Global\\IPC_Demo_DataReady); _ackEvent new EventWaitHandle(false, EventResetMode.AutoReset, Global\\IPC_Demo_DataAck); _writeMutex new Mutex(false, Global\\IPC_Demo_WriteLock); Console.WriteLine($[Server] 共享內(nèi)存已就緒容量 {Capacity} 字節(jié)。按任意鍵退出。); // 4. 初始化協(xié)議頭 Magic 標記表示共享區(qū)可用了 accessor.Write(0, 0x4D504349); // MPCI accessor.Write(4, 0); // BodyLen accessor.Write(8, 0); // Sequence accessor.Write(12, DateTime.Now.Ticks); // Timestamp // 5. 模擬生產(chǎn)者循環(huán)寫入500條報文 int seq 0; while (seq 500) { seq; string payloadContent $Hello from IPC server, seq{seq}, body padding........; byte[] body Encoding.UTF8.GetBytes(payloadContent); _writeMutex.WaitOne(); try { // 寫入?yún)f(xié)議頭 accessor.Write(4, body.Length); // BodyLen accessor.Write(8, seq); // Sequence accessor.Write(12, DateTime.Now.Ticks); // Timestamp // 寫入報文內(nèi)容從 HeaderSize 偏移開始 accessor.WriteArray(HeaderSize, body, 0, body.Length); } finally { _writeMutex.ReleaseMutex(); } // 通知客戶端新數(shù)據(jù)就緒并最多等2秒回執(zhí) _readyEvent!.Set(); bool acked _ackEvent!.WaitOne(2000); if (!acked) { Console.WriteLine($[Server] seq{seq} 未收到客戶端回執(zhí)繼續(xù)寫下一幀。); } else { Console.WriteLine($[Server] seq{seq} 已確認長度{body.Length}); } Thread.Sleep(20); // 模擬業(yè)務間隔實際場景按數(shù)據(jù)節(jié)奏來 } Console.WriteLine([Server] 寫入完成。); Console.ReadKey(); } }2.3 代碼里的關(guān)鍵細節(jié)逐行說先看命名空間前綴Global\。在Windows上所有有名字的內(nèi)核對象共享內(nèi)存、事件、互斥體都存在于命名空間中。普通進程創(chuàng)建的命名對象默認在Local\命名空間不同登錄會話或服務Session 0里的進程很可能互相看不見。加上Global\前綴可以讓系統(tǒng)服務和普通用戶進程跨會話共享。這是最容易踩的坑之一本地調(diào)試好好的做成Windows服務之后客戶端就是連不上多半就是命名空間和權(quán)限的問題。容量為什么設1MB而不是剛好夠一條報文因為進程間通信的共享區(qū)天然要做環(huán)形或者多幀緩沖單幀寫完后如果客戶端還沒讀服務端可以繼續(xù)寫下一幀而不必阻塞。這里為了演示方便用了“寫一幀等回執(zhí)”的簡單握手實際生產(chǎn)建議把1MB拆成幾十個固定大小的小槽位用索引區(qū)管理讀寫位置。后面第4章我會給出一套更穩(wěn)健的數(shù)據(jù)協(xié)定。再解釋一下協(xié)議頭的20個字節(jié)4字節(jié)Magic用于校驗共享區(qū)是否已經(jīng)初始化4字節(jié)BodyLen告訴客戶端本次有效負載的長度4字節(jié)Sequence用來識別幀序號和亂序雖然共享內(nèi)存天然有序但記錄序號方便排查8字節(jié)Timestamp是生產(chǎn)時間戳?？蛻舳四玫竭@20字節(jié)后才知道該從偏移20的位置讀多少數(shù)據(jù)。事件回執(zhí)的設計容易理解服務端寫完后Set()“數(shù)據(jù)就緒”事件客戶端讀到后Set()“我已讀完”事件。服務端用WaitOne(2000)等待回執(zhí)超時不強退只是記錄日志。這避免了服務端一騎絕塵把共享區(qū)寫爆也是典型的“生產(chǎn)者-消費者”協(xié)調(diào)模型只是把通行證從隊列換成了事件。3. 客戶端發(fā)現(xiàn)共享內(nèi)存、讀數(shù)據(jù)、回執(zhí)3.1 客戶端視角的三個階段客戶端做的事情可以拆成三步先找到服務端創(chuàng)建的共享內(nèi)存并打開然后不斷等待“數(shù)據(jù)就緒”事件最后讀取數(shù)據(jù)返回“已完成”回執(zhí)。比較容易被忽略的是第一步的容錯。服務端可能還沒啟動也可能正在重啟這時候客戶端直接OpenExisting就會拋FileNotFoundException。生產(chǎn)環(huán)境里我都是寫一個循環(huán)重試的邏輯首次連接失敗就每500毫秒再試一次連續(xù)失敗N次后報警。這個思路不復雜但能把啟動順序問題、服務意外重啟問題都兜住。還有一個方向問題客戶端讀數(shù)據(jù)之前一定要先校驗協(xié)議頭里的Magic。我第一次寫這個程序時省略了校驗結(jié)果服務端剛啟動、還沒寫完第一幀客戶端就已經(jīng)被事件喚醒結(jié)果讀了一堆初始化的零字節(jié)。雖然事件通知理論上不會在數(shù)據(jù)未就緒時觸發(fā)但共享內(nèi)存是“無鎖可見”的進程調(diào)度可能造成事件已設置但數(shù)據(jù)尚未可見的窗口所以Magic校驗是保險絲。3.2 客戶端完整代碼范例using System.IO.MemoryMappedFiles; using System.Text; using System.Threading; class IPC_Client { private const string MapName Global\\IPC_Demo_SharedMemory; private const int HeaderSize 20; private const int MaxBodySize 1024 * 1024 - HeaderSize; static void Main() { // 1. 連接共享內(nèi)存帶重試邏輯 MemoryMappedFile? mmf null; while (mmf null) { try { mmf MemoryMappedFile.OpenExisting(MapName); } catch (FileNotFoundException) { Console.WriteLine([Client] 共享內(nèi)存不存在服務端可能未啟動500ms后重試...); Thread.Sleep(500); } } using var accessor mmf.CreateViewAccessor(0, 0); using var readyEvent new EventWaitHandle(false, EventResetMode.AutoReset, Global\\IPC_Demo_DataReady); using var ackEvent new EventWaitHandle(false, EventResetMode.AutoReset, Global\\IPC_Demo_DataAck); using var readMutex new Mutex(false, Global\\IPC_Demo_WriteLock); Console.WriteLine([Client] 已接入共享內(nèi)存等待數(shù)據(jù)...); while (true) { // 2. 等待服務端通知5秒超時用于周期性自檢 if (!readyEvent.WaitOne(5000)) { continue; } readMutex.WaitOne(); try { // 3. 校驗 Magic防止讀到未初始化的共享區(qū) int magic accessor.ReadInt32(0); if (magic ! 0x4D504349) // MPCI { Console.WriteLine([Client] 共享區(qū)還未初始化跳過本次讀取。); continue; } // 4. 讀取協(xié)議頭和正文 int bodyLen accessor.ReadInt32(4); int seq accessor.ReadInt32(8); long ts accessor.ReadInt64(12); if (bodyLen 0 || bodyLen MaxBodySize) { Console.WriteLine($[Client] 非法的正文長度 {bodyLen}跳過。); continue; } byte[] body new byte[bodyLen]; accessor.ReadArray(HeaderSize, body, 0, bodyLen); string text Encoding.UTF8.GetString(body); Console.WriteLine($[Client] 收到 seq{seq}, len{bodyLen}, ts{ts}, 內(nèi)容前30字符: {text[..Math.Min(30, text.Length)]}); } finally { readMutex.ReleaseMutex(); } // 5. 給服務端回執(zhí)服務端可以安全寫下一幀 ackEvent.Set(); } } }3.3 心跳與超時處理客戶端里的工程細節(jié)代碼里有一個很容易被忽視的點CreateViewAccessor(0, 0)。第二個參數(shù)傳0表示映射全部。如果你傳入一個具體大小一旦共享區(qū)后續(xù)想擴容客戶端這邊的視圖就固定不變了。服務端和客戶端對共享區(qū)的“視圖大小”必須一致否則一方寫的內(nèi)容另一方根本讀不到而且不一定會報錯只是數(shù)據(jù)看起來永遠不對。我曾經(jīng)在這個問題上排查了一下午最后發(fā)現(xiàn)是服務端初始化和客戶端打開時傳入的視圖大小相差了幾個字節(jié)。客戶端的5秒超時不是為了“沒事?lián)Q換心跳”而是讓循環(huán)有機會做額外檢查。實際系統(tǒng)里我會在超時分支里統(tǒng)計“多久沒收到數(shù)據(jù)”如果超過某個閾值就觸發(fā)告警或重連邏輯。共享內(nèi)存沒有連接概念但它一樣可能“腦裂”——比如服務端崩潰后共享對象會自動回收客戶端的句柄雖然沒有立即報錯但后續(xù)讀寫都會失敗。所以客戶端不能只傻等事件還要定期用RandomAccess.Read或者簡單讀一個Magic來確認共享區(qū)對象還活著。關(guān)于回讀鎖的注釋這里客戶端也申請了_writeMutex名字看著像寫鎖實際作用是“讀寫互斥”。單生產(chǎn)者單消費者場景下事件握手已經(jīng)保證了串行這把鎖其實可有可無但我強烈建議保留。原因有兩點一是防止以后引入多個生產(chǎn)者時改出并發(fā)臭蟲二是EventWaitHandle的AutoReset模式存在信號丟失的可能兩幀之間如果客戶端處理慢服務端的Set會被合并有了鎖客戶端至少能保證在它讀的這段時間里服務端不會把同一塊內(nèi)存改掉。鎖的成本極低沒必要省。4. 同步機制與數(shù)據(jù)協(xié)定最容易翻車的地方4.1 三種同步方案的取舍我把本機共享內(nèi)存同步方式歸成三派按實際場景選第一派是命名事件互斥體也就是本文范例的做法。適合“數(shù)據(jù)到達再處理”的生產(chǎn)者-消費者模型。事件負責通知鎖負責互斥各司其職。缺點是需要兩個事件來回握手寫代碼多一點但它能把CPU占用率降到接近零。第二派是互斥體輪詢。只在共享區(qū)里維護一個“最新狀態(tài)”的數(shù)據(jù)塊比如配置快照、狀態(tài)上報。消費者開個線程每500毫秒拿一次鎖讀數(shù)據(jù)。優(yōu)點是邏輯極簡缺點是不實時、空轉(zhuǎn)耗CPU而且需要處理“讀到的數(shù)據(jù)是同一份舊的”這種語義問題。第三派是自旋鎖原子操作。適合對延遲要求極其苛刻、數(shù)據(jù)量又小的場景。C#里可以用Interlocked.CompareExchange管理寫入索引用SpinLock保護臨界區(qū)。我踩過它的坑高并發(fā)下自旋鎖容易造成CPU飆高而且寫共享內(nèi)存這種操作本身很快鎖沖突的概率不高為了一點點延遲收益引入自旋邏輯性價比其實很低。所以我的建議很明確99%的共享內(nèi)存IPC場景選“命名事件互斥體”就是最優(yōu)解它把等待、互斥、通知三件事拆得清清楚楚出問題也容易調(diào)試。4.2 數(shù)據(jù)協(xié)定固定長度協(xié)議頭 可變長度正文共享內(nèi)存本身只是字節(jié)數(shù)組進程間沒有“自動序列化”的概念所以雙方必須約定好這一塊字節(jié)的布局。這就是數(shù)據(jù)協(xié)定。本文的協(xié)定是20字節(jié)協(xié)議頭 可變長度正文。協(xié)議頭字段設計表如下偏移字節(jié)數(shù)字段說明04Magic常量0x4D504349用于校驗初始化44BodyLen有效負載長度84Sequence幀序號128Timestamp時間戳Ticks20不定Body實際數(shù)據(jù)這個協(xié)定能覆蓋大多數(shù)業(yè)務但也有一個硬限制body長度不能超過共享區(qū)容量減去協(xié)議頭。一旦單條數(shù)據(jù)超過容量就得換方案。我的擴展方案是把數(shù)據(jù)切成多個塊在協(xié)議頭里加“總長度”“塊偏移”“塊序號”。比如4MB共享區(qū)一塊數(shù)據(jù)5MB那就切成3塊第一塊頭部標記“這是分塊的還有后續(xù)”第二塊繼續(xù)寫第三塊寫完置“完成”標記?？蛻舳耸盏降谝粔K時先創(chuàng)建拼接緩沖區(qū)收到最后一塊后觸發(fā)業(yè)務邏輯。這是內(nèi)存映射文件做大數(shù)據(jù)傳輸?shù)臉藴侍茁反a量不大但能把共享區(qū)的利用率提上去。還有一個容易踩的點字節(jié)序和結(jié)構(gòu)體對齊。如果直接用Marshal.StructureToPtr把結(jié)構(gòu)體懟進共享區(qū)C#的默認布局在不同平臺上可能存在對齊差異客戶端和服務端編譯選項不一致時容易翻車。本文手動按偏移寫字段雖然啰嗦但避免了所有對齊問題也方便以后用其他語言寫客戶端時對接。4.3 生命周期與訪問權(quán)限共享內(nèi)存和內(nèi)核對象的生命周期由引用計數(shù)管理。所有打開該對象的句柄都被關(guān)閉后對象會自動銷毀即使服務端進程還在、只是把主句柄Dispose了也一樣。所以服務端要保證共享區(qū)對象的生命周期覆蓋整個通信過程不能因為創(chuàng)建視圖之后就把主句柄釋放掉。權(quán)限這塊是Windows下繞不開的坑。MemoryMappedFile默認的安全描述符只允許創(chuàng)建它的進程和同用戶的進程訪問。如果服務端是Windows服務運行在Session 0客戶端是用戶桌面進程Session 1兩邊賬戶不同OpenExisting就會拋UnauthorizedAccessException。解決辦法是在創(chuàng)建共享內(nèi)存時顯式設置安全規(guī)則var security new MemoryMappedFileSecurity(); security.AddAccessRule(new System.Security.AccessControl.AccessRuleMemoryMappedFileRights( Everyone, MemoryMappedFileRights.FullControl, AccessControlType.Allow)); var mmf MemoryMappedFile.CreateOrOpen(MapName, Capacity, MemoryMappedFileMode.ReadWrite, security);這里的“Everyone”是系統(tǒng)內(nèi)置的認證組名作用是讓任何賬戶都能讀寫。只用在本機可信環(huán)境不要把它用到暴露到外網(wǎng)的服務上。命名事件和互斥體也可以加類似的訪問規(guī)則做法一致我就不重復貼代碼了。5. 常見問題與排查技巧實錄5.1 高頻報錯對照速查異常/現(xiàn)象可能原因處理方式FileNotFoundException服務端還沒創(chuàng)建共享區(qū)或名字拼錯客戶端加重試邏輯核對MapName是否完全一致UnauthorizedAccessException服務端與客戶端賬戶不同步缺少安全規(guī)則創(chuàng)建時設置Everyone讀寫權(quán)限卡在事件等待一直不返回服務端異常退出事件對象被回收客戶端增加超時自檢定期探測共享區(qū)存活讀出的數(shù)據(jù)是初始零字節(jié)Magic未校驗或事件先于數(shù)據(jù)寫入觸發(fā)協(xié)議頭加Magic校驗失敗跳過客戶端定義視圖長度與服務端不一致創(chuàng)建視圖時傳了不同容量統(tǒng)一使用CreateViewAccessor(0, 0)或顯式傳相同容量5.2 一次線上排查實錄有次線上環(huán)境出現(xiàn)“客戶端偶爾收不到最新一幀”的現(xiàn)象本地怎么也復現(xiàn)不了。后來加了日志發(fā)現(xiàn)問題出在AutoReset事件的固有特性上服務端連續(xù)寫了兩幀每次都Set()但客戶端第一幀還沒處理完第二次Set()就把內(nèi)核對象從“有信號”變回“無信號”等客戶端處理完第一幀再來WaitOne()第二幀的通知已經(jīng)被吞掉了。解決方案有兩種。一是在客戶端處理完一幀后主動檢查“是否還有更新的數(shù)據(jù)”比如對比共享區(qū)里的Sequence和上一次讀的Sequence如果發(fā)現(xiàn)已經(jīng)更新則直接再讀一輪不需要等事件。二是改用ManualResetEvent并配合序列號判斷但這種模式下存在多個客戶端同時讀到的語義問題需要額外鎖。我在生產(chǎn)里用的是第二種思路的變體Ready事件改ManualResetEvent每次寫完數(shù)據(jù)都Set()客戶端讀完比對Sequence后主動Reset()事件。邏輯稍微復雜一點但徹底消滅了丟失通知的問題。5.3 性能觀察與調(diào)優(yōu)建議共享內(nèi)存的延遲極低但有一個容易忽略的性能瓶頸訪問器的偏移讀寫遠沒有直接指針快。在每秒幾萬次的小數(shù)據(jù)幀場景下Accessor的封裝層會占一小部分CPU。如果壓測發(fā)現(xiàn)這部分不可接受可以改用byte*指針或者引入System.Runtime.CompilerServices.Unsafe直接操作。不過我實測下來這個優(yōu)化收益通常只有個位數(shù)百分比除非共享區(qū)超大或者幀數(shù)極其密集否則沒必要。數(shù)據(jù)幀大小對性能的影響也很大。每條4KB一次寫入和每條1KB四次寫入吞吐完全不是一個概念。設計協(xié)議時盡量把多次小數(shù)據(jù)合并成一次中等大小的幀寫入減少同步握手的次數(shù)。事件Set和WaitOne本身也有內(nèi)核態(tài)切換開銷大概微秒級但高頻下會累積批量寫入能顯著攤薄這部分成本。內(nèi)存映射文件還有一個獨有優(yōu)勢它可以被幾十個進程同時映射同一個對象天然支持一對多廣播。如果你要做配置中心下發(fā)、狀態(tài)廣播這類場景內(nèi)存映射文件比TCP廣播簡單得多只要在客戶端增加一個“只讀不寫”的模式并且協(xié)議頭里做好版本號管理就行。我后面正準備把這個范例擴展成“一寫多讀”的廣播版等落地穩(wěn)定了再寫一篇詳細過程。最后再分享一點我的個人體會共享內(nèi)存IPC看起來門檻不高但真正決定它穩(wěn)不穩(wěn)定的往往是那些看起來不起眼的細節(jié)——全局命名空間、協(xié)議頭校驗、事件丟失防范、安全權(quán)限。整套方案做下來你會發(fā)現(xiàn)90%的工作量其實都在同步和容錯上。我踩過幾次坑之后的習慣是把協(xié)議頭和握手流程先畫成一張清晰的字段表再動手寫代碼后面基本不會返工。如果你按這篇文章搭好了服務端和客戶端建議第一步先做個小壓測看看進程被殺掉、服務重啟、事件超時這些異常路徑下兩邊的表現(xiàn)把這些邊界處理干凈線上才能真正睡得著覺。