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