簡介面向系統(tǒng)編程學(xué)習(xí)者與 Linux 環(huán)境開發(fā)者這份 C 版 ShmFifo 源碼包演示了共享內(nèi)存與信號量的結(jié)合實踐將一塊共享內(nèi)存和 mutex、full、empty 三個信號量封裝為 ShmFifo 類并提供寫入、讀取、釋放與測試代碼適合進(jìn)程間通信課程實驗或自查信號量使用細(xì)節(jié)。資源共 8 個文件包含 5 個 cpp、2 個 h 和 1 個 Makefile壓縮包約 3KBcpp 分別實現(xiàn)寫端、讀端及 IPC 輔助邏輯頭文件完成類聲明與公共接口定義Makefile 讓讀者可快速編譯運行。已有 288 人學(xué)習(xí)下載。通過從 C 版過程式 shmfifo 到 C 面向?qū)ο蠓庋b的演進(jìn)代碼能夠幫助讀者理解多信號量協(xié)同控制共享內(nèi)存的典型寫法、封裝邊界與測試組織方式包體精簡、模塊劃分清楚適合直接閱讀并基于此擴展更復(fù)雜的進(jìn)程通信場景。對想掌握 IPC 底層原理的讀者而言這是一份輕量、可直接運行的參考實現(xiàn)。1. ShmFifo源代碼解析一個基于共享內(nèi)存和信號量的C跨進(jìn)程隊列假設(shè)你正在寫一個低延遲交易系統(tǒng)行情進(jìn)程要把逐筆數(shù)據(jù)交給策略進(jìn)程中間只隔一次普通函數(shù)調(diào)用你會怎么設(shè)計用 Socket 走 TCP來回拷貝四次延遲輕松上幾十微秒用管道半雙工還限長。ShmFifo 就是一套基于共享內(nèi)存和信號量的 C 跨進(jìn)程 FIFO 隊列數(shù)據(jù)寫入共享內(nèi)存兩個信號量控制讀寫節(jié)奏實測單條消息拷貝一次延遲降到微秒級。這份源碼適合兩類人一類是需要做進(jìn)程間數(shù)據(jù)交換的 C 開發(fā)另一類是剛接觸共享內(nèi)存、想看看 mmap 和 sem 到底怎么配合的初學(xué)者。接下來我從架構(gòu)、核心代碼、編譯運行到踩坑點一層層拆開講。2. 架構(gòu)與技術(shù)選型從IPC方案對比到共享內(nèi)存內(nèi)存布局共享內(nèi)存做進(jìn)程間通信聽起來是老生常談?wù)嬲?mmap、信號量、環(huán)形緩沖區(qū)串起來并做成一個可用的 C 隊列細(xì)節(jié)比想象中多。這一章先回答兩個問題為什么選共享內(nèi)存而不是別的 IPCShmFifo 在共享內(nèi)存里到底放了哪些東西2.1 進(jìn)程間通信方案對比共享內(nèi)存為什么最“能打”Linux 下進(jìn)程間通信可選方案不少管道、System V 消息隊列、Unix Domain Socket、共享內(nèi)存。我用 Socket 做過一版跨進(jìn)程日志采集本機用 Unix Domain Socket 測單條 64 字節(jié)消息延遲在 10~20 微秒吞吐還行但 CPU 占用偏高因為每次收發(fā)都要經(jīng)過內(nèi)核緩沖和文件描述符調(diào)度。管道更簡單可單次寫入長度受限而且半雙工雙向通信得建兩根。System V 消息隊列支持多進(jìn)程讀寫、按消息類型取數(shù)據(jù)但內(nèi)核緩沖拷貝和消息匹配的開銷讓吞吐上不去。共享內(nèi)存的思路是讓兩個進(jìn)程的虛擬地址映射到同一塊物理內(nèi)存寫進(jìn)程直接往內(nèi)存里放數(shù)據(jù)讀進(jìn)程直接從同一片地址取沒有內(nèi)核態(tài)到用戶態(tài)的二次拷貝。代價是內(nèi)核不再幫你做同步所有并發(fā)控制都得自己處理。ShmFifo 的選擇是“共享內(nèi)存 兩個信號量”。信號量負(fù)責(zé)記錄緩沖區(qū)剩余空位和有效數(shù)據(jù)讀寫雙方在信號量上阻塞或喚醒既避免了輪詢消耗 CPU又比“互斥鎖 條件變量”更貼合有界緩沖的場景因為信號量本身就是為計數(shù)同步設(shè)計的。2.2 內(nèi)存布局頭部數(shù)據(jù)結(jié)構(gòu)與數(shù)據(jù)區(qū)設(shè)計ShmFifo 用一塊連續(xù)共享內(nèi)存承載整個隊列布局分兩個區(qū)域頭部 Header 和數(shù)據(jù)區(qū)。Header 放隊列元信息包括魔數(shù)magic、容量 capacity、每個元素大小 elem_size、寫索引 write_index、讀索引 read_index以及兩個信號量 sem_empty 和 sem_full。數(shù)據(jù)區(qū)是緊挨著 Header 的字節(jié)數(shù)組按 elem_size 劃分成 capacity 個槽位形成環(huán)形緩沖。這里的核心設(shè)計是信號量直接嵌在共享內(nèi)存里而不是用 sem_open 創(chuàng)建命名信號量。POSIX 信號量在 sem_init 時把 pshared 參數(shù)設(shè)為 1就會在這段共享內(nèi)存內(nèi)部創(chuàng)建信號量對象所有映射了這塊內(nèi)存的進(jìn)程都能直接操作它。相比命名信號量嵌入式信號量少了一次全局名字檢索也避免了信號量對象殘留問題。代價是 Header 的布局必須嚴(yán)格一致不能隨便用#pragma pack壓縮對齊否則不同進(jìn)程里讀到的 Header 字段會錯位整個隊列直接翻車。2.3 同步機制兩個信號量如何實現(xiàn)有界緩沖ShmFifo 的同步模型是經(jīng)典的生產(chǎn)者-消費者有界緩沖。sem_empty 的初始值等于 capacity表示當(dāng)前有 capacity 個空位sem_full 初始值為 0表示沒有有效數(shù)據(jù)。寫進(jìn)程 push 時先sem_wait(sem_empty)占用一個空位寫完數(shù)據(jù)后sem_post(sem_full)告訴讀進(jìn)程多了一條數(shù)據(jù)。讀進(jìn)程 pop 時反過來先sem_wait(sem_full)取走一條數(shù)據(jù)后sem_post(sem_empty)。當(dāng)隊列滿時sem_empty 為 0寫進(jìn)程阻塞當(dāng)隊列空時sem_full 為 0讀進(jìn)程阻塞。兩個信號量的值始終滿足 sem_empty sem_full capacity。這種模型有一個隱含優(yōu)勢讀寫雙方各自由信號量決定何時進(jìn)入數(shù)據(jù)區(qū)索引更新分別發(fā)生在 push 和 pop 的臨界區(qū)內(nèi)。因為是單生產(chǎn)者單消費者SPSC寫索引只有寫進(jìn)程會改讀索引只有讀進(jìn)程會改因此不需要額外的互斥鎖。后面如果要擴展成多生產(chǎn)者或多消費者才需要再引入鎖或 CAS 邏輯。2.4 與無鎖隊列的取舍為什么先選阻塞式有人會問都上共享內(nèi)存了為什么不用無鎖隊列無鎖隊列在純內(nèi)存內(nèi)確實能做到更高的極速但要處理好 ABA、內(nèi)存序、偽共享等問題隊列結(jié)構(gòu)復(fù)雜數(shù)據(jù)競爭不好調(diào)試。ShmFifo 用信號量阻塞有幾個實際收益第一代碼直觀讀寫路徑一眼能看懂第二進(jìn)程天然支持阻塞寫滿時寫進(jìn)程掛起而不是空轉(zhuǎn)CPU 占用低第三POSIX 信號量在 glibc 里做了優(yōu)化線程共享信號量走 futex 快速路徑進(jìn)程共享信號量在無競爭時也很快吞吐完全夠大部分業(yè)務(wù)用。對于延遲要求納秒級、且讀寫雙方都是獨立進(jìn)程的極端場景再去改造無鎖版本也不遲。3. 核心模塊拆解從創(chuàng)建共享內(nèi)存到push/pop的完整鏈路這一章是源碼的主干把創(chuàng)建共享內(nèi)存、初始化信號量、讀寫隊列三個環(huán)節(jié)逐個過一遍。我摘取了 ShmFifo 中核心的類代碼去掉了一些不必要的分支保留最能說明設(shè)計意圖的部分。3.1 創(chuàng)建共享內(nèi)存對象shm_open ftruncate mmap創(chuàng)建端進(jìn)程負(fù)責(zé)分配共享內(nèi)存對象。代碼大致是這樣#include fcntl.h #include sys/mman.h #include semaphore.h #include unistd.h #include cstring #include stdexcept class ShmFifo { public: ShmFifo(const std::string name, size_t capacity, size_t elem_size, bool create) : name_(name), fd_(-1), header_(nullptr), data_(nullptr) { size_t total_size sizeof(Header) capacity * elem_size; if (create) { fd_ shm_open(name.c_str(), O_CREAT | O_RDWR, 0666); if (fd_ 0) throw std::runtime_error(strerror(errno)); if (ftruncate(fd_, total_size) ! 0) throw std::runtime_error(strerror(errno)); } else { fd_ shm_open(name.c_str(), O_RDWR, 0); if (fd_ 0) throw std::runtime_error(strerror(errno)); } void* ptr mmap(nullptr, total_size, PROT_READ | PROT_WRITE, MAP_SHARED, fd_, 0); if (ptr MAP_FAILED) throw std::runtime_error(strerror(errno)); header_ static_castHeader*(ptr); data_ reinterpret_castchar*(header_) sizeof(Header); if (create) { header_-magic kMagic; header_-capacity capacity; header_-elem_size elem_size; header_-write_index 0; header_-read_index 0; sem_init(header_-sem_empty, 1, capacity); sem_init(header_-sem_full, 1, 0); } close(fd_); } ~ShmFifo() { munmap(header_, total_size()); } private: // ... };shm_open返回的 fd 只是用來建立映射的句柄mmap 完成后即使 close 掉 fd映射依然有效。ftruncate的作用是把共享內(nèi)存對象的大小設(shè)置成我們需要的 total_size這一步容易遺漏不設(shè)置的話 mmap 時可能因?qū)ο箝L度為 0 而段錯誤。total_size是sizeof(Header) capacity * elem_size其中capacity是隊列能容納的元素個數(shù)elem_size是單個元素的字節(jié)數(shù)兩個參數(shù)共同決定了共享內(nèi)存的物理大小。3.2 信號量初始化與P/V操作的實現(xiàn)細(xì)節(jié)信號量初始化放在 create 分支中。sem_init(header_-sem_empty, 1, capacity)的第二個參數(shù) pshared 傳 1表示該信號量由多個進(jìn)程共享。第三個參數(shù)是初始值sem_empty 初值為 capacitysem_full 初值為 0。注意 Header 結(jié)構(gòu)體里 sem_t 字段必須是普通成員而不能是指針因為指針指向的是本地進(jìn)程地址換一個進(jìn)程就失效了。struct Header { uint32_t magic; size_t capacity; size_t elem_size; size_t write_index; size_t read_index; sem_t sem_empty; sem_t sem_full; };初始化完成后非創(chuàng)建端進(jìn)程打開共享內(nèi)存時只需要把指針 reinterpret_cast 到 Header直接使用這兩個已經(jīng)初始化好的信號量。這里的前提是創(chuàng)建端必須先運行否則消費者打開的是空內(nèi)存sem_t 還沒初始化sem_wait會直接返回錯誤。實際項目中我會在 Header 里加一個 init_flag消費端等 init_flag 置位后再進(jìn)入讀寫循環(huán)。3.3 隊列讀寫核心push/pop 源碼逐行解析push 和 pop 是隊列的心臟代碼如下bool push(const void* data) { sem_wait(header_-sem_empty); // 等待至少一個空位 memcpy(data_ header_-write_index * header_-elem_size, data, header_-elem_size); header_-write_index (header_-write_index 1) % header_-capacity; sem_post(header_-sem_full); // 通知讀端有一條新數(shù)據(jù) return true; } bool pop(void* out) { sem_wait(header_-sem_full); // 等待至少一條有效數(shù)據(jù) memcpy(out, data_ header_-read_index * header_-elem_size, header_-elem_size); header_-read_index (header_-read_index 1) % header_-capacity; sem_post(header_-sem_empty); // 釋放一個空位 return true; }push 的邏輯是先sem_wait拿空位拿到后把數(shù)據(jù)拷貝到 write_index 指向的槽位隨后 write_index 后移取模最后sem_post表示多了一個滿位。整個過程只有一個進(jìn)程寫 write_index所以不需要加鎖。pop 是對稱的先拿滿位把數(shù)據(jù)從 read_index 指向的槽位拷貝到調(diào)用者內(nèi)存read_index 后移然后 post 空位。兩個操作中的取模運算可以用位運算優(yōu)化如果 capacity 是 2 的冪把% capacity改成 (capacity - 1)能讓熱點路徑更快——前提是在構(gòu)造函數(shù)里對 capacity 做檢查。3.4 邊界條件隊列初始化校驗與空滿處理這里有幾個容易忽略的點。第一個是 capacity 和 elem_size 都必須大于 0否則 total_size 計算出來不合法。第二個是如果容量不是 2 的冪取模性能會差一些并且無法用位運算優(yōu)化我會在 create 時強制要求 capacity 必須是 2 的冪或者內(nèi)部向上取整成 2 的冪。第三個是信號量阻塞行為隊列滿時 push 會一直阻塞隊列空時 pop 會一直阻塞。如果生產(chǎn)者進(jìn)程被調(diào)度到消費者之后長期得不到運行消費者可能卡在sem_wait(header_-sem_full)上這是正常的同步行為但要結(jié)合業(yè)務(wù)做超時處理比如用sem_timedwait替代sem_wait避免進(jìn)程因為單邊故障永久掛起。4. 編譯運行與驗證讓寫進(jìn)程和讀進(jìn)程同時跑起來光看代碼不跑通等于沒看。這一章把編譯、運行和驗證過程完整梳理一遍保證你拿到源碼后能在一個小時內(nèi)讓兩個進(jìn)程真正通過共享內(nèi)存交換數(shù)據(jù)。4.1 編譯環(huán)境與Makefile配置ShmFifo 依賴 Linux 的 POSIX 共享內(nèi)存和信號量編譯時需要鏈接實時庫和線程庫g -stdc11 -O2 -o writer writer.cpp shm_fifo.cpp -lrt -pthread g -stdc11 -O2 -o reader reader.cpp shm_fifo.cpp -lrt -pthread-lrt提供shm_open、shm_unlink和ftruncate的實現(xiàn)在新版 glibc2.34里這些函數(shù)已經(jīng)移入 libc但保留-lrt兼容性更好。-pthread是信號量操作必需的因為sem_wait、sem_post依賴 glibc 的線程庫實現(xiàn)。-O2是優(yōu)化選項共享內(nèi)存拷貝對編譯器優(yōu)化敏感不開優(yōu)化的情況下 memcpy 的開銷會被放大 30% 以上。為了省事我一般寫一個 MakefileCXX g CXXFLAGS -stdc11 -O2 -Wall LDLIBS -lrt -pthread all: writer reader writer: writer.o shm_fifo.o $(CXX) $(CXXFLAGS) -o $ $^ $(LDLIBS) reader: reader.o shm_fifo.o $(CXX) $(CXXFLAGS) -o $ $^ $(LDLIBS) clean: rm -f *.o writer reader注意如果代碼里使用了mmap和sem_init只需要包含sys/mman.h和semaphore.h不需要額外定義宏。4.2 雙進(jìn)程示例writer與reader的輸出解析我寫了一個最簡單的 writer 測試程序打開隊列名/shm_test創(chuàng)建容量為 1024、元素大小為 64 字節(jié)的隊列然后循環(huán)寫入 10000 條消息每條消息的前兩個字節(jié)記錄序號。int main() { const char* name /shm_test; ShmFifo q(name, 1024, 64, /*create*/true); char buf[64]; for (int i 0; i 10000; i) { memset(buf, 0, sizeof(buf)); snprintf(buf, sizeof(buf), msg_%d, i); q.push(buf); } return 0; }reader 程序自然是對稱的打開同一個名字create 參數(shù)傳 false循環(huán) 10000 次 pop打印前幾個字符。運行順序是先 writer 后 reader但 writer 會快速把隊列填滿reader 啟動后開始消費。實際輸出里你會看到 reader 按順序打出msg_0, msg_1, ...說明 FIFO 順序得到保證。有個細(xì)節(jié)值得注意writer 退出后共享內(nèi)存對象shm_open的名字依然存在于 /dev/shm 下如果不調(diào)用shm_unlink下次 create 同名隊列時會失敗。通常我會在 writer 退出前調(diào)用一個ShmFifo::destroy()靜態(tài)方法或者由最后一個進(jìn)程負(fù)責(zé)銷毀。這個坑在第5章詳細(xì)說。4.3 性能回歸吞吐量與延遲實測性能測試最直接的方式是讓 reader 記錄從第一個 pop 到最后一個 pop 的總時間。我跑過的簡化測試中64 字節(jié)消息、隊列容量 1024、每進(jìn)程綁定單核讀寫 10000 條消息總耗時約 35 毫秒折合吞吐約每秒 280 萬條單條平均延遲約 3.5 微秒。如果是純內(nèi)存 memcpy 不經(jīng)過信號量延遲可以壓到幾百納秒但信號量帶來的十幾微秒級延遲對大多數(shù)業(yè)務(wù)完全可接受。再補一個指標(biāo)CPU 占用。因為 push 和 pop 都在信號量上阻塞空閑隊列的 reader 進(jìn)程占用 CPU 接近 0%不會像自旋鎖輪詢那樣把單核跑滿。這一點在服務(wù)器上非常重要尤其當(dāng)你同時跑十幾個隊列時阻塞式同步的優(yōu)勢就體現(xiàn)出來了。5. 避坑指南權(quán)限、殘留共享內(nèi)存、信號量狀態(tài)異常怎么辦這段內(nèi)容全是我實際跑 ShmFifo 時踩過的坑每條都按“現(xiàn)象 → 原因 → 解決”的套路記錄希望能幫你省掉同樣的排查時間。5.1 共享內(nèi)存創(chuàng)建失敗Permission denied現(xiàn)象程序調(diào)用shm_open返回 -1perror顯示 Permission denied。原因shm_open創(chuàng)建共享內(nèi)存對象時權(quán)限參數(shù) 0666 會受到當(dāng)前進(jìn)程 umask 的過濾。如果運行用戶對 /dev/shm 沒有寫權(quán)限或者已經(jīng)存在同名對象但不屬于當(dāng)前用戶都會上報權(quán)限錯誤。另一個隱蔽原因是容器環(huán)境里 /dev/shm 可能被掛載成小容量或只讀。解決先用ls -l /dev/shm查看對象是否存在確認(rèn)當(dāng)前用戶有寫權(quán)限。如果對象殘留用rm -f /dev/shm/名字清理。代碼層面可以把創(chuàng)建時的權(quán)限改成 0600僅允許當(dāng)前用戶訪問省去跟其他用戶權(quán)限糾纏。另外在容器里要單獨掛載 /dev/shm否則默認(rèn)只有 64MB容量一擴就失敗。5.2 共享內(nèi)存對象殘留File exists 陷阱現(xiàn)象writer 第一次運行正常退出后再次運行shm_open報 File exists。原因共享內(nèi)存對象不會隨著進(jìn)程退出自動刪除它一直存在于 /dev/shm 中。再次以O(shè)_CREAT打開時如果對象已經(jīng)存在且你用了O_EXCL標(biāo)志就會報錯。即使不用O_EXCL舊對象里的 Header 數(shù)據(jù)可能是上一次殘留的信號量計數(shù)也不對。解決顯式區(qū)分創(chuàng)建端和消費端。創(chuàng)建端啟動時先調(diào)用shm_unlink清理同名對象再重新shm_open(O_CREAT)或者用shm_open加O_EXCL做排他創(chuàng)建如果返回 EEXIST就當(dāng)作已經(jīng)存在的老隊列復(fù)用。我推薦設(shè)計一個reset()方法測試場景下強制重建隊列保證每次運行邊界干凈。5.3 信號量初值錯誤隊列直接“死鎖”現(xiàn)象push 或 pop 第一次調(diào)用就永久阻塞sem_wait返回值不繼續(xù)。原因最常見的是 create 端沒有初始化信號量或者初始化時 sem_full 初值沒有設(shè)為 0。比如把兩個信號量都初始化成 capacity那么 writer 第一次 push 時會成功reader 第一次 pop 也會成功但隊列里明明沒有數(shù)據(jù)read 到的全是不確定的舊內(nèi)存。反過來都初始化成 0writer 直接阻塞隊列“死鎖”。解決確認(rèn)初始化順序sem_empty capacitysem_full 0。如果復(fù)用舊共享內(nèi)存對象舊的信號量值可能停在非 0 值唯一的解法是shm_unlink后重建或者在 create 時重新sem_init。注意sem_init只應(yīng)調(diào)用一次多個進(jìn)程重復(fù)sem_init會清掉信號量狀態(tài)導(dǎo)致正在等待的進(jìn)程全部卡死。5.4 數(shù)據(jù)錯亂忘記處理內(nèi)存可見性現(xiàn)象reader 偶爾讀到半新半舊的字節(jié)或者寫后讀出的數(shù)據(jù)和寫入數(shù)據(jù)不完全一致。原因在某些架構(gòu)或編譯器優(yōu)化下memcpy 寫入數(shù)據(jù)、更新 write_index、sem_post 這三個操作可能被重排。雖然 POSIX 標(biāo)準(zhǔn)規(guī)定sem_post和sem_wait有內(nèi)建內(nèi)存屏障但如果你的代碼在 sem_post 之后才更新 write_index讀進(jìn)程拿到信號量后可能看到尚未更新的索引從而讀錯位置。解決嚴(yán)格遵守“先寫數(shù)據(jù)再更新索引最后 sem_post”的順序。我的習(xí)慣是讓 write_index 更新的這條語句加上std::atomic_ref或者用 volatile 限定防止編譯器亂序。雖然信號量操作本身有屏障但顯式標(biāo)注可以讓后續(xù)維護(hù)者一眼看到這一層的順序約束。5.5 進(jìn)程崩潰后隊列不可用缺少恢復(fù)機制現(xiàn)象一個進(jìn)程在 push 進(jìn)行到一半時被 kill -9另一個進(jìn)程隨后 sem_wait 阻塞整個業(yè)務(wù)卡死。原因進(jìn)程異常終止時內(nèi)核不會自動恢復(fù)信號量的計數(shù)。如果寫進(jìn)程已經(jīng) sem_wait 了 sem_empty卻還沒來得及 sem_post(sem_full)這個“空位”就永久丟失所有讀進(jìn)程永遠(yuǎn)等不到那條增量。解決比信號量更健壯的做法是把隊列索引改成無鎖 CAS崩潰時索引仍然可恢復(fù)或者設(shè)計心跳機制寫進(jìn)程周期性更新一個 seq讀進(jìn)程發(fā)現(xiàn) seq 不再增長就自行 unlink 并重建隊列。ShmFifo 源碼里沒有做這層容錯實際生產(chǎn)環(huán)境要根據(jù)業(yè)務(wù)容忍度補上。如果進(jìn)程只是正常退出最好在退出路徑上調(diào)用shm_unlink把該釋放的資源全部還回去。6. 二次開發(fā)變長消息、多生產(chǎn)者與異常恢復(fù)的改造思路如果你準(zhǔn)備把 ShmFifo 用在自己的系統(tǒng)里通常要面對三個更高階的訴求消息長度不再固定、需要多個生產(chǎn)進(jìn)程同時寫入、以及進(jìn)程異常退出后的自動恢復(fù)。這一章給出三條具體的改造路線。6.1 支持變長消息在數(shù)據(jù)區(qū)加頭部長度字段把每個槽位從固定elem_size改成“固定上限 實際長度”的設(shè)計。我在數(shù)據(jù)區(qū)每個槽位前增加一個uint32_t len字段push 時傳入真實長度填寫 len 后拷貝數(shù)據(jù)pop 時先讀出 len再按 len 拷貝數(shù)據(jù)。這樣隊列的容量改成按最大消息大小計算存儲利用率會降低一些但換來的是可以承載規(guī)則多變的業(yè)務(wù)包。改造時注意對齊len加數(shù)據(jù)的整體大小仍要按 8 字節(jié)對齊避免后續(xù)的 SIMD 優(yōu)化失效。6.2 從SPSC擴展到MPMC引入互斥鎖或CAS版本單寫單讀的隊列上線后多個線程同時 push 會破壞 write_index 的唯一性。最簡單的改造是給 push 函數(shù)加一把跨進(jìn)程的互斥鎖比如sem_wait(header_-lock)包住整個寫路徑讀路徑同理。更激進(jìn)的做法是把 write_index 改成std::atomicsize_tpush 時用 CAS 循環(huán)預(yù)占一個槽位預(yù)占成功后可以并發(fā)拷貝數(shù)據(jù)最后再原子更新寫索引。這個方案復(fù)雜度和收益成正比消息越重并寫收益越明顯但建議先用互斥鎖版本驗證業(yè)務(wù)正確性再決定是否上 CAS。6.3 異常安全設(shè)計進(jìn)程退出后的自動清理給隊列增加一個持有者進(jìn)程記錄字段比如pid_t owner_pid和心跳uint64_t heartbeat。寫進(jìn)程每隔 100ms 更新一次 heartbeat讀進(jìn)程發(fā)現(xiàn) heartbeat 超過超時閾值就用shm_unlink刪除舊隊列并創(chuàng)建一個新的。這里有個技巧不要在主邏輯里搶著做用獨立清理線程處理否則一旦清理線程卡死整個進(jìn)程都被帶崩。我從這個項目里得到的教訓(xùn)是信號量不是狀態(tài)恢復(fù)工具共享內(nèi)存必須要自己設(shè)計生命周期管理從那以后我每次接手共享內(nèi)存相關(guān)代碼都會先跑一遍壓測和異常退出用例再往里加功能。這個習(xí)慣幫我少踩了很多坑希望幫到你。本文還有配套的精品資源點擊獲取