我先說一個(gè)前提如果你寫過多線程 C你遲早會(huì)遇到這么一種崩潰——日志上沒有任何明顯異常報(bào)錯(cuò)位置每次都不一樣甚至同一個(gè)版本跑了幾天才出現(xiàn)一次。某個(gè)項(xiàng)目組曾經(jīng)有個(gè)采集模塊十幾個(gè)工作線程會(huì)同時(shí)更新一個(gè)保存統(tǒng)計(jì)結(jié)果的靜態(tài)成員變量代碼量不大邏輯也不復(fù)雜但壓測(cè)跑到兩千萬請(qǐng)求量的時(shí)候進(jìn)程開始偶發(fā)異常退出。查了幾天最后定位到根因我才真正意識(shí)到一個(gè)很多人沒當(dāng)回事的事實(shí)靜態(tài)成員變量的線程安全問題從來不只是“結(jié)果不對(duì)”那么簡單。從一個(gè)普通類成員開始靜態(tài)成員變量和普通成員變量在內(nèi)存與生命周期上的差異決定了它天然就是多線程程序的雷區(qū)。這篇內(nèi)容適合正在寫或維護(hù)多線程 C 服務(wù)的開發(fā)者也適合把 C11 之后新特性當(dāng)黑盒在用的朋友。我會(huì)先講清楚為什么靜態(tài)成員變量容易出問題再給出鎖、原子變量、線程局部存儲(chǔ)和單例場(chǎng)景的正確做法最后用 ThreadSanitizer 演示一次真實(shí)的競態(tài)定位過程。整個(gè)過程盡量少堆標(biāo)準(zhǔn)條文多給能直接落地的結(jié)論。1. 靜態(tài)成員變量與普通成員變量的本質(zhì)區(qū)別——線程不安全的根源1.1 它根本不在對(duì)象里內(nèi)存與生命周期先講一個(gè)經(jīng)常被忽視的事實(shí)靜態(tài)成員變量并不存在任何對(duì)象實(shí)例里。類里面的非靜態(tài)數(shù)據(jù)成員每個(gè)對(duì)象都有一份整體存放在對(duì)象的內(nèi)存布局中靜態(tài)成員變量則完全不同它在程序的數(shù)據(jù)段或 BSS 段分配空間生命周期從程序加載開始一直持續(xù)到進(jìn)程退出。用一個(gè)不嚴(yán)謹(jǐn)?shù)芎糜浀念惐绕胀ǔ蓡T變量是每個(gè)對(duì)象自己的私人物品靜態(tài)成員變量是類名下的公共倉庫所有對(duì)象共用同一扇門、同一份庫存。這個(gè)差異直接帶來兩個(gè)結(jié)果。第一sizeof(對(duì)象)完全不包含靜態(tài)成員你把實(shí)例創(chuàng)建、銷毀多少次它都紋絲不動(dòng)進(jìn)程不結(jié)束它就不釋放。第二任何線程都能通過類名訪問這同一個(gè)實(shí)體不需要先拿到對(duì)象指針也不需要經(jīng)過實(shí)例方法。從多線程的角度看它和一個(gè)用 extern 聲明的全局變量沒有任何區(qū)別區(qū)別只在于名字前面多了一個(gè)類的作用域前綴。所以當(dāng)你想“把它當(dāng)作類的一部分因此天然受到類設(shè)計(jì)的保護(hù)”時(shí)這種保護(hù)并不存在。它不是對(duì)象成員它是全局狀態(tài)。全局狀態(tài)一旦允許寫就必須在所有寫者和讀者之間建立同步否則就是在走鋼絲。1.2 共享帶來的一觸即發(fā)一個(gè)副本和 N 個(gè)線程共享帶來的問題用一個(gè)最樸素的場(chǎng)景就能說明。假設(shè)你寫了這樣一個(gè)類class Metrics { public: static long total; }; long Metrics::total 0;然后八個(gè)線程各自執(zhí)行Metrics::total;跑十萬次按直覺總該是八十萬了吧實(shí)測(cè)大概率不是數(shù)值可能小于八十萬而且每次都不一樣。之所以這樣是因?yàn)閠otal在底層并不是一步操作。它要先從內(nèi)存把total讀到寄存器加一再寫回內(nèi)存。兩個(gè)線程可能同時(shí)讀到同一個(gè)舊值然后各自加一寫回兩次加一只有一次生效。這就是數(shù)據(jù)競爭的最小雛形。如果你覺得這只是數(shù)值誤差那還不夠嚴(yán)重。C 標(biāo)準(zhǔn)把這種并發(fā)訪問定義為未定義行為意味著編譯器可以做任何它認(rèn)為合理的優(yōu)化結(jié)果甚至不一定是“數(shù)值偏小”。這一點(diǎn)放到第二章細(xì)講。1.3 早就該破除的誤區(qū)volatile 不解決線程安全這里必須先破除一個(gè)流傳很久的誤解加個(gè) volatile 就能解決。volatile 告訴編譯器“這個(gè)變量可能在別處被修改不要把它優(yōu)化到寄存器里”它確實(shí)能讓一些極端場(chǎng)景下更容易觀察到正確值但它既不能保證操作的原子性也不能提供多線程之間的順序約束。在 C 的內(nèi)存模型里volatile 和線程同步機(jī)制是兩個(gè)維度。想達(dá)到線程安全要么用原子操作要么用互斥量要么在線程內(nèi)部私有一份數(shù)據(jù)。volatile 幫不上忙反而可能給你一種“我已經(jīng)處理過了”的錯(cuò)覺讓隱患繼續(xù)潛伏。2. 數(shù)據(jù)競爭是未定義行為不是“結(jié)果不對(duì)”2.1count在匯編層面到底做了什么我們前面看到了total不是一步這里把它看成三條指令會(huì)更清楚讀、改、寫。CPU 執(zhí)行時(shí)會(huì)加載load修改modify存儲(chǔ)store。無論是編譯器還是 CPU都不會(huì)因?yàn)槟銓懥恕耙痪浯a”就保證三者之間沒有別人插進(jìn)來。更麻煩的是編譯器在優(yōu)化時(shí)可以把不相關(guān)的代碼重排可以在滿足“單線程可觀察語義”的前提下自由安排讀寫順序多線程環(huán)境下的觀察結(jié)果就和源代碼順序沒什么必然關(guān)系了。所以兩個(gè)線程分別執(zhí)行total可能出現(xiàn)兩個(gè)線程都讀到 0、都寫回 1最終total是 1 而不是 2。這個(gè)結(jié)果在單線程世界里不可能出現(xiàn)但在并發(fā)世界里是完全合法的未定義行為。不要把這種錯(cuò)誤歸類為“精度損失”它不屬于任何數(shù)值誤差范疇。2.2 CPU 緩存、指令重排與 happened-before即使沒有編譯器重排CPU 這一層也有自己的脾氣。現(xiàn)代多核處理器每個(gè)核都有獨(dú)立的 L1/L2 緩存一個(gè)核寫入total后新的值可能還在自己的緩存行里還沒有同步到共享內(nèi)存另一個(gè)核在另一個(gè)時(shí)刻讀到的仍舊是舊值。硬件會(huì)通過緩存一致性協(xié)議最終保持一致但“最終”是多長時(shí)間、什么順序程序如果不使用同步原語觀察不到確定的邊界。C 內(nèi)存模型引入了一個(gè)核心概念happens-before。你只有在兩個(gè)線程之間建立某種同步關(guān)系讓一個(gè)線程的寫操作在另一個(gè)線程的讀操作之前發(fā)生數(shù)據(jù)競爭才被排除。能夠建立這種關(guān)系的機(jī)制只有少數(shù)幾種互斥鎖的加鎖與解鎖、std::atomic 的讀寫以及相應(yīng)的內(nèi)存序、線程的 join 等。普通的賦值和讀取無法建立這種關(guān)系。這也就是說判斷一段代碼是否線程安全不能靠“我運(yùn)行了好幾次都沒出事”。你只是沒有撞上那個(gè)時(shí)機(jī)并不代表它沒有發(fā)生數(shù)據(jù)競爭。2.3 “崩潰在很遠(yuǎn)的地方”是怎么發(fā)生的數(shù)據(jù)競爭最坑的地方在于問題不一定出現(xiàn)在肇事代碼附近。線程 A 先寫了共享靜態(tài)對(duì)象線程 B 在另一個(gè)函數(shù)里讀它中間隔著大量調(diào)用。編譯器發(fā)現(xiàn)某個(gè)字段只在個(gè)別路徑被寫而其他路徑讀出來可能是個(gè)未初始化或部分更新的值于是大膽把看起來很冗余的代碼刪掉或者把分支重排。最終表現(xiàn)是某個(gè)不相關(guān)的邏輯點(diǎn)開始出錯(cuò)離源頭十萬八千里。我開頭說的那個(gè)服務(wù)崩潰堆棧在日志模塊和對(duì)象析構(gòu)里真正原因卻是另一個(gè)線程在改緩存。這就是為什么這類問題特別難查。你盯著崩潰堆棧找原因找三天也可能找不到因?yàn)橐蚬湕l已經(jīng)被編譯器和緩存切碎了。3. 靜態(tài)成員初始化階段的線程安全魔法靜態(tài)與隱藏的坑3.1 C11 之后的局部靜態(tài)變量魔法靜態(tài)先說一個(gè)好消息C11 之后的函數(shù)局部靜態(tài)變量其初始化是線程安全的。標(biāo)準(zhǔn)要求當(dāng)控制流并發(fā)進(jìn)入某個(gè)局部靜態(tài)變量的聲明時(shí)初始化必須只發(fā)生一次其他線程要等待這次初始化完成。編譯器通常會(huì)在變量旁邊生成一個(gè) guard 標(biāo)志第一次進(jìn)入時(shí)加鎖并判斷狀態(tài)后續(xù)進(jìn)入直接跳過初始化。你對(duì)這個(gè)機(jī)制最常見的感知就是所謂“魔法靜態(tài)”。來看最典型的寫法class Logger { public: static Logger get() { static Logger instance; return instance; } private: Logger() { /* ... */ } };多個(gè)線程第一次同時(shí)調(diào)用get()會(huì)有一個(gè)線程真正構(gòu)造instance其余線程阻塞等待。構(gòu)造完成之后后續(xù)調(diào)用不再有任何加鎖開銷。這個(gè)特性后來成為安全單例的基石第五章會(huì)再提到。這里值得注意的是線程安全保障僅限于“初始化那一次”。如果你之后還在多線程里修改instance的內(nèi)部狀態(tài)那依然是數(shù)據(jù)競爭。魔法靜態(tài)只負(fù)責(zé)把對(duì)象造出來不負(fù)責(zé)你后續(xù)怎么用。3.2 類靜態(tài)數(shù)據(jù)成員初始化時(shí)機(jī)與靜態(tài)初始化順序問題那類里直接定義的靜態(tài)成員變量呢比如static Metrics metrics;這種非常量表達(dá)式初始化通常發(fā)生在程序啟動(dòng)的動(dòng)態(tài)初始化階段。絕大多數(shù)程序在這個(gè)階段還沒有創(chuàng)建業(yè)務(wù)線程所以并發(fā)初始化的問題不突出但另一個(gè)問題隨之而來不同編譯單元的靜態(tài)對(duì)象初始化順序在 C 標(biāo)準(zhǔn)里是不確定的。假如Metrics的構(gòu)造函數(shù)依賴另一個(gè)全局配置對(duì)象的初始化結(jié)果而那個(gè)對(duì)象恰好在你這個(gè)編譯單元之后才初始化就會(huì)出現(xiàn)“構(gòu)造時(shí)訪問未初始化對(duì)象”的經(jīng)典故障通常叫靜態(tài)初始化順序問題。解決思路有兩個(gè)方向。一是把非平凡的初始化延遲到第一次使用時(shí)函數(shù)局部靜態(tài)是現(xiàn)成的工具二是消除依賴構(gòu)造時(shí)不依賴其他全局狀態(tài)。如果項(xiàng)目里有多個(gè) .cpp 都定義了帶有動(dòng)態(tài)初始化的靜態(tài)成員并且它們之間存在依賴不要指望鏈接順序救你標(biāo)準(zhǔn)層面就不可靠。3.3 類模板里的靜態(tài)成員延遲實(shí)例化的特殊場(chǎng)景類模板的靜態(tài)成員還有一處容易被忽略多數(shù)情況下模板靜態(tài)成員的定義是在頭文件里實(shí)例化發(fā)生在第一次使用某個(gè)具體模板參數(shù)時(shí)。也就是說它可能不是在程序啟動(dòng)階段初始化的而是在運(yùn)行中某個(gè)線程第一次觸發(fā)實(shí)例化時(shí)才進(jìn)行動(dòng)態(tài)初始化。如果你在頭文件里寫了這樣的東西template typename T struct Registry { static std::mapT, int table; }; template typename T std::mapT, int RegistryT::table;那么Registryint::table這個(gè)對(duì)象到底在哪個(gè)線程第一次被實(shí)例化取決于哪段代碼先被調(diào)用。多個(gè)線程同時(shí)首次觸碰不同實(shí)例時(shí)編譯器需要保證靜態(tài)成員初始化線程安全但實(shí)現(xiàn)細(xì)節(jié)可能比局部靜態(tài)更微妙。我的建議是別讓模板靜態(tài)成員承載非平凡的動(dòng)態(tài)初始化需要時(shí)就放在一個(gè)函數(shù)局部靜態(tài)對(duì)象后面讓那個(gè)標(biāo)準(zhǔn)保證的守衛(wèi)機(jī)制來兜底template typename T struct Registry { static std::mapT, int table() { static std::mapT, int table; return table; } };這樣得到的仍然是你想要的進(jìn)程級(jí)唯一實(shí)例但初始化時(shí)機(jī)由函數(shù)局部靜態(tài)統(tǒng)一接管行為更可控。4. 鎖、原子變量、線程局部存儲(chǔ)——三類做法怎么選4.1 互斥鎖最簡單也最容易被用錯(cuò)的方案如果共享靜態(tài)成員是一段需要保持多個(gè)字段一致的復(fù)雜數(shù)據(jù)直接用互斥鎖是最穩(wěn)的方案。原則很樸素凡是可能發(fā)生讀寫的入口全部經(jīng)過同一個(gè)鎖。寫要鎖讀也要鎖。很多人只給寫加鎖讀不加鎖認(rèn)為“讀一下問題不大”實(shí)際上讀線程和寫線程之間沒有任何同步關(guān)系讀線程完全可能讀到寫了一半的數(shù)據(jù)這依然是數(shù)據(jù)競爭。一個(gè)常見的類是這樣class Metrics { public: static void Add(long v) { std::lock_guardstd::mutex lock(mu_); total_ v; count_ 1; } static long Snapshot() { std::lock_guardstd::mutex lock(mu_); return total_ / count_; } private: static std::mutex mu_; static long total_; static int count_; }; std::mutex Metrics::mu_; long Metrics::total_ 0; int Metrics::count_ 0;這里Add和Snapshot都走mu_保證讀的時(shí)候看到的是完整快照。優(yōu)點(diǎn)是簡單正確容易給不熟悉內(nèi)存模型的同事看懂缺點(diǎn)是每次調(diào)用都要經(jīng)過鎖如果這是熱點(diǎn)路徑可能成為性能瓶頸。補(bǔ)充一個(gè)工程經(jīng)驗(yàn)鎖的粒度要盡量小。把鎖放在單個(gè)函數(shù)內(nèi)部只保護(hù)真正共享的字段操作不要在外部“幫別人加鎖”。例如有些人喜歡讓調(diào)用方自己 lock這個(gè)約定很容易被后來的人漏掉代碼腐化速度極快。不如把共享字段設(shè)為私有只暴露已經(jīng)加好鎖的靜態(tài)方法。4.2 原子變量讓簡單的計(jì)數(shù)和標(biāo)志位不再需要鎖如果共享靜態(tài)成員只是一個(gè)計(jì)數(shù)器、一個(gè)標(biāo)志位或一個(gè)可以單獨(dú)讀寫的數(shù)值優(yōu)先用std::atomic。它用底層的原子指令把讀改寫打包成一個(gè)不可分割的操作從語言層面規(guī)定了對(duì)該變量的并發(fā)訪問是良定義的不需要再額外加鎖。例如剛才的累計(jì)計(jì)數(shù)可以寫成這樣class Metrics { public: static void Add(long v) { total_.fetch_add(v, std::memory_order_relaxed); } static long Get() { return total_.load(std::memory_order_relaxed); } private: static std::atomiclong total_; }; std::atomiclong Metrics::total_{0};fetch_add是原子操作不會(huì)出現(xiàn)兩個(gè)線程同時(shí)讀到舊值的情況最終結(jié)果必然等于所有線程成功執(zhí)行的累加之合。代碼里用了 relaxed 內(nèi)存序很多教材會(huì)告訴你這是性能最高的寫法但請(qǐng)一定確認(rèn)你真的不需要跨線程順序約束。如果你只關(guān)心“總數(shù)是多少”不在乎它和其他事件的先后關(guān)系relaxed 沒問題如果某個(gè)線程要先更新完一批數(shù)據(jù)再讓另一個(gè)線程通過這個(gè)原子變量看到“數(shù)據(jù)已經(jīng)準(zhǔn)備好了”那么需要 release/acquire 或更強(qiáng)的 seq_cst。新手階段統(tǒng)一用默認(rèn)的 seq_cst正確性優(yōu)先性能瓶頸出現(xiàn)后再回頭摳這些細(xì)節(jié)。還有一個(gè)坑std::atomic并不等于“把一個(gè)結(jié)構(gòu)體塞進(jìn)去就完事”。只有那些在目標(biāo)平臺(tái)上有原子指令支持的寬度才免鎖超過機(jī)器字長的結(jié)構(gòu)體std::atomic內(nèi)部會(huì)退化到鎖而且不同平臺(tái)的鎖實(shí)現(xiàn)不可見。這種場(chǎng)景直接用專門的互斥鎖反而更清楚。4.3 線程局部存儲(chǔ)能不分就不分并不是所有共享數(shù)據(jù)都必須被所有線程共享。如果每個(gè)線程都只需要自己的那份副本事后各自統(tǒng)計(jì)或合并那最干凈的做法是用thread_local靜態(tài)成員。語法上就是static thread_local或者類外定義class Worker { public: static void AppendLog(const std::string s) { log_buffer_ s; } private: static thread_local std::string log_buffer_; }; thread_local std::string Worker::log_buffer_;初看可能覺得奇怪它和static不矛盾嗎一點(diǎn)都不矛盾。thread_local決定的是線程維度每個(gè)線程都有一份獨(dú)立拷貝static決定的是生命周期這份拷貝不對(duì)應(yīng)任何對(duì)象實(shí)例只對(duì)應(yīng)線程和類名。也就是說不同線程修改的都是自己的log_buffer_彼此天然隔離不需要鎖?，F(xiàn)實(shí)項(xiàng)目里線程局部存儲(chǔ)非常適合日志緩沖、臨時(shí)緩存、線程池上的會(huì)話數(shù)據(jù)處理這類場(chǎng)景。不過有兩個(gè)注意點(diǎn)。第一線程退出時(shí)thread_local 對(duì)象會(huì)析構(gòu)不要在析構(gòu)函數(shù)里依賴另一個(gè)線程的 thread_local 數(shù)據(jù)。第二線程池中的線程任務(wù)邊界不明顯線程局部緩存在任務(wù)結(jié)束后如果不清理容易把上一個(gè)任務(wù)的數(shù)據(jù)帶到下一個(gè)任務(wù)里必須在任務(wù)入口或出口顯式重置。4.4 選型的底層原則總結(jié)一下常見場(chǎng)景下我一般按這個(gè)表選型場(chǎng)景推薦方案原因復(fù)雜對(duì)象多個(gè)字段需要保持一致mutex / scoped_lock鎖定一段邏輯操作整體狀態(tài)計(jì)數(shù)器、標(biāo)志、單一數(shù)值std::atomic免鎖吞吐高語義清晰讀多寫少的高頻查詢std::shared_mutex多讀者并發(fā)寫者互斥每個(gè)線程獨(dú)立處理數(shù)據(jù)static thread_local物理上不再共享免同步初始化后不再修改constexpr / 只讀不可變靜態(tài)成員沒有寫操作天然安全選型之外還有一條更底層的心法能減少共享就不要增加鎖。鎖不是免費(fèi)的就算無鎖的原子變量也會(huì)增加指令數(shù)和緩存一致性壓力。如果一段數(shù)據(jù)其實(shí)沒必要被所有線程共享優(yōu)先通過任務(wù)拆分、線程私有副本或不可變數(shù)據(jù)把它變成“不需要同步”的結(jié)構(gòu)這比任何同步原語都高效。我自己在評(píng)審代碼時(shí)看到有人往共享靜態(tài)成員上加鎖第一反應(yīng)不是夸他會(huì)加鎖而是先問這一步真的需要共享嗎5. 單例模式的經(jīng)典重災(zāi)區(qū)雙重檢查鎖與安全的單例實(shí)現(xiàn)5.1 為什么靜態(tài)成員變量是單例的最常見載體靜態(tài)成員變量最常見的用途之一就是單例。單例的本質(zhì)是進(jìn)程內(nèi)只有一個(gè)實(shí)例這個(gè)事實(shí)和靜態(tài)存儲(chǔ)區(qū)天然契合用靜態(tài)成員指針或引用持有那個(gè)唯一的對(duì)象是幾乎所有實(shí)現(xiàn)的第一步。也正因?yàn)槿绱藛卫龑?shí)現(xiàn)里線程安全的坑特別密集。尤其是“雙重檢查鎖”它幾乎是 C 社區(qū)反復(fù)踩了十幾年的經(jīng)典雷區(qū)。我先解釋它為什么吸引人再解釋它為什么沒那么好用。5.2 看看這段“老江湖”代碼為什么錯(cuò)雙重檢查鎖的出發(fā)點(diǎn)是單例創(chuàng)建一次之后每次讀取都是熱點(diǎn)路徑如果每次都加鎖開銷太大能不能先無鎖判斷指針是否為空為空才加鎖創(chuàng)建于是出現(xiàn)類似下面的代碼static Singleton* inst nullptr; static std::mutex mu; Singleton* GetInstance() { if (inst nullptr) { // 第一次無鎖讀 std::lock_guardstd::mutex lock(mu); if (inst nullptr) { // 第二次判斷 inst new Singleton(); // 創(chuàng)建 } } return inst; }問題在于inst的第一次無鎖讀和另一個(gè)線程里的new Singleton()之間沒有任何同步關(guān)系。new 表達(dá)式本來就是三步分配內(nèi)存、在內(nèi)存上構(gòu)造對(duì)象、把地址寫入inst。編譯器或 CPU 可能把“寫入 inst”提前到構(gòu)造完成之前也可能把它推遲線程 B 在第 1 行看到inst不為空時(shí)線程 A 可能還沒完成構(gòu)造。于是 B 返回了一個(gè)半成品指針調(diào)用成員函數(shù)時(shí)讀取的是未初始化的字段。在某些編譯器上它可能“看起來能用”但跨平臺(tái)、跨優(yōu)化等級(jí)之后就會(huì)在運(yùn)行期炸掉。而如果第 1 行看到的inst仍為空多個(gè)線程會(huì)依次進(jìn)入并重復(fù)創(chuàng)建對(duì)象單例退化成多例內(nèi)存泄漏都算輕的。很多人覺得加 volatile 就能解決。volatile 不能提供原子性和內(nèi)存順序前面說過這里同樣不成立。甚至static volatile Singleton* inst;也不能保證構(gòu)造完成的 happens-before它只是讓編譯器不緩存這個(gè)指針變量而已。真正的解法要么讓標(biāo)準(zhǔn)機(jī)制直接保證初始化要么使用原子量配合 memory_order。5.3 三套可靠實(shí)現(xiàn)函數(shù)局部靜態(tài)、call_once、只讀單例最省事的寫法C11 以后的函數(shù)局部靜態(tài)變量已經(jīng)幫你把初始化競態(tài)解決了class Singleton { public: static Singleton Get() { static Singleton instance; return instance; } private: Singleton() default; Singleton(const Singleton) delete; Singleton operator(const Singleton) delete; };多線程第一次調(diào)用Get()時(shí)初始化由編譯器生成的 guard 保證只執(zhí)行一次后續(xù)訪問無鎖。這個(gè)模式因?yàn)楹啙嵉綆缀醪豢赡軐戝e(cuò)強(qiáng)烈優(yōu)先推薦。唯一限制單例對(duì)象的構(gòu)造函數(shù)不能依賴另一處同樣需要復(fù)雜初始化的全局狀態(tài)否則你不過是從線程安全問題換到了初始化順序問題。如果需要給單例傳參數(shù)或者初始化邏輯比較復(fù)雜可以用std::call_onceclass Singleton { public: static Singleton Get(int input 0) { std::call_once(once_, [] { inst_ new Singleton(input); }); return *inst_; } private: explicit Singleton(int v) { /* ... */ } static std::once_flag once_; static Singleton* inst_; }; std::once_flag Singleton::once_; Singleton* Singleton::inst_ nullptr;call_once的承諾是即使多個(gè)線程同時(shí)調(diào)用初始化回調(diào)也只會(huì)執(zhí)行一次其他線程會(huì)阻塞等待這次回調(diào)完成。注意回調(diào)里不能提前返回once_flag 一旦執(zhí)行成功后續(xù)所有線程看到的都是已初始化的狀態(tài)。如果你非要在回調(diào)里拋異常異常會(huì)傳播給當(dāng)前線程once_flag 會(huì)重置下一次調(diào)用會(huì)重試這是標(biāo)準(zhǔn)行為寫代碼時(shí)要考慮清楚。還有一類更極端的場(chǎng)景單例對(duì)象沒有任何可變狀態(tài)或者所有字段都是編譯期常量。這種時(shí)候直接用constexpr靜態(tài)成員或函數(shù)內(nèi)static constexpr對(duì)象就行沒有運(yùn)行時(shí)初始化也就不存在初始化競態(tài)。很多人一聽到單例就條件反射寫鎖實(shí)際上一個(gè)全 constexpr 的消息格式描述符完全不需要任何同步設(shè)施。5.4 關(guān)于析構(gòu)順序的提醒函數(shù)局部靜態(tài)對(duì)象在程序退出時(shí)會(huì)自動(dòng)析構(gòu)析構(gòu)順序與構(gòu)造順序相反。如果單例在析構(gòu)時(shí)還依賴另一個(gè)局部靜態(tài)對(duì)象而對(duì)方已經(jīng)析構(gòu)就可能踩到空指針或未初始化數(shù)據(jù)。我的建議是單例析構(gòu)函數(shù)保持簡單不要訪問其他可能先析構(gòu)的全局狀態(tài)如果主線程之外還有工作線程在運(yùn)行必須在 main 里先 join 所有線程再退出而不是讓進(jìn)程在還有線程運(yùn)行時(shí)走到靜態(tài)析構(gòu)階段。還有一類懲罰是我見過不少團(tuán)隊(duì)踩過的為了嚴(yán)格“禁止拷貝”把單例基類寫成宏或者一大堆代碼反倒是構(gòu)造函數(shù)忘記私有化了。其實(shí) C11 之后delete 拷貝構(gòu)造和賦值就夠了Singleton(const Singleton) delete; Singleton operator(const Singleton) delete;別為這種小事發(fā)明新框架。6. 跑一遍才踏實(shí)ThreadSanitizer 實(shí)測(cè)與排查心得6.1 一個(gè)能穩(wěn)定暴露競態(tài)的測(cè)試用例理論講再多不如讓工具在眼前把競態(tài)抓出來。我常用的做法是先寫一個(gè)很小的復(fù)現(xiàn)程序規(guī)模不大但循環(huán)次數(shù)足夠多保證競爭窗口能被撞上。比如前面那個(gè)計(jì)數(shù)器例子的完整版#include thread #include iostream struct Stats { static long counter; }; long Stats::counter 0; int main() { std::thread threads[8]; for (int i 0; i 8; i) { threads[i] std::thread([] { for (int j 0; j 1000000; j) { Stats::counter; } }); } for (auto t : threads) t.join(); std::cout Stats::counter \n; return 0; }按正常邏輯輸出應(yīng)該是 8000000直接編譯運(yùn)行你大概率會(huì)得到一個(gè)更小的數(shù)甚至偶爾看起來像 8000000因?yàn)楦偁幋翱诓皇敲看窝h(huán)都能命中。所以靠數(shù)值猜“是不是競態(tài)”很不靠譜數(shù)值對(duì)也不能證明線程安全。想要穩(wěn)定暴露問題得用專門工具。6.2 編譯并運(yùn)行 TSan看它怎樣報(bào)告ThreadSanitizer簡稱 TSan是 GCC 和 Clang 都內(nèi)置的競態(tài)檢測(cè)工具思路是在編譯時(shí)做插樁運(yùn)行時(shí)記錄每次內(nèi)存訪問再判斷是否存在兩個(gè)線程對(duì)同一地址的無同步訪問。編譯命令很簡單g -stdc17 -fsanitizethread -g -O1 -pthread race.cpp -o race_tsan注意這里務(wù)必加上-g否則報(bào)告里的棧信息沒有行號(hào)-O1是 TSan 官方推薦的優(yōu)化等級(jí)既能暴露多數(shù)問題又不會(huì)像-O0那樣把代碼拍得太平。跑起來之后如果存在數(shù)據(jù)競爭程序會(huì)在控制臺(tái)打出類似這樣的信息WARNING: ThreadSanitizer: data race Read of size 8 at 0x... by thread T2 #0 main::$_0::operator() ... Previous write of size 8 at 0x... by thread T1 #1 main::$_0::operator() ... Location is global Stats::counter它會(huì)準(zhǔn)確標(biāo)出參與競態(tài)的兩個(gè)訪問、各自的線程棧以及出問題的變量名Stats::counter?？吹竭@份報(bào)告已經(jīng)不需要我們?cè)偃シ瓍R編猜“會(huì)不會(huì)真是這里”。修復(fù)之后再編譯運(yùn)行直到 TSan 零告警我才敢說這個(gè)復(fù)現(xiàn)用例的事情結(jié)束了。TSan 在使用上有兩個(gè)小坑值得提前說。一是它和 ASanAddressSanitizer不能混用加了-fsanitizeaddress再同時(shí)開sanitizethread行為不可預(yù)期可能直接鏈接失敗。二是 TSan 對(duì)運(yùn)行時(shí)環(huán)境有額外要求在部分老內(nèi)核或容器里需要額外配置如果直接跑報(bào)“FATAL: ThreadSanitizer: unexpected memory mapping”通常和環(huán)境不支持有關(guān)換個(gè)常規(guī)環(huán)境或者更新工具鏈一般就能解決。這屬于檢測(cè)工具本身的環(huán)境問題不要因?yàn)樗鼒?bào)錯(cuò)就懷疑自己的代碼。6.3 真實(shí)項(xiàng)目里的排查思路和預(yù)防措施真實(shí)項(xiàng)目里的靜態(tài)成員變量不會(huì)像復(fù)現(xiàn)程序這么干凈。我的排查習(xí)慣是先把所有帶 static 且可寫的成員列出來按“是否在多于一個(gè)線程里出現(xiàn)”分類只讀的定義為安全寫者只有啟動(dòng)階段的可以重點(diǎn)檢查初始化順序運(yùn)行期有多個(gè)寫者的直接進(jìn)觀察名單。第二步找出所有訪問入口看看讀和寫是否有共同的同步對(duì)象。讀加鎖、寫加鎖但用的是兩把不同的鎖等于沒鎖。第三步上 TSan 跑一輪覆蓋主要業(yè)務(wù)路徑的壓測(cè)通常十分鐘就能抓到第一塊視野盲區(qū)。修復(fù)時(shí)也要小心修復(fù)動(dòng)作本身引入新問題。很多人第一反應(yīng)是在每個(gè)方法入口加鎖但忘了靜態(tài)成員變量可能被外部通過返回值獲得引用然后繞過方法直接改。正確做法是讓靜態(tài)成員盡可能私有對(duì)外只暴露加好鎖的靜態(tài)方法如果實(shí)在需要返回引用必須返回一個(gè)同樣受鎖保護(hù)的代理或者直接返回副本。我現(xiàn)在設(shè)計(jì)任何類時(shí)遇到靜態(tài)成員變量的第一個(gè)問題都是這個(gè)變量是只讀的嗎如果不是只讀下一個(gè)問題就是什么時(shí)候?qū)懩男┚€程讀用什么同步如果回答不上來我就不讓它作為裸的靜態(tài)成員存在。寧可多寫一層函數(shù)局部靜態(tài)的間接層把初始化和訪問都收口到一個(gè)地方。見過太多因?yàn)殪o態(tài)成員線程安全翻車的案例之后我的體會(huì)是數(shù)據(jù)競爭很少是“運(yùn)氣不好”它是共享、可變、缺少同步三個(gè)條件同時(shí)成立的必然結(jié)果。把這三者拆掉任何一個(gè)問題就能從根上消失。診斷時(shí)可以靠工具防御時(shí)還是得靠設(shè)計(jì)習(xí)慣。希望你下次看到static關(guān)鍵字時(shí)能多停留兩秒。