做C開發(fā)這些年內(nèi)存管理一直是繞不開的話題。很多人剛接觸智能指針的時(shí)候覺得它不過是用起來方便但真到了排查線上內(nèi)存泄漏、設(shè)計(jì)復(fù)雜對象生命周期時(shí)只停留在會用層面遠(yuǎn)遠(yuǎn)不夠。這篇筆記是我自己反復(fù)踩坑之后的整理圍繞C里三個(gè)核心智能指針——unique_ptr、shared_ptr、weak_ptr把怎么用、為什么這么用、底層原理是什么、多線程下有哪些坑一次性說透。這篇文章適合兩類人一類是剛學(xué)完C基礎(chǔ)、開始接觸現(xiàn)代C的初學(xué)者另一類是已經(jīng)在項(xiàng)目里用智能指針但遇到問題找不到根因的進(jìn)階開發(fā)者。我不打算堆概念而是直接從實(shí)際代碼場景切入把RAII思想、引用計(jì)數(shù)機(jī)制、循環(huán)引用陷阱這些內(nèi)容串起來幫你看清智能指針的全貌。1. 從裸指針到RAII為什么需要智能指針1.1 裸指針的幾大痛點(diǎn)手動管理內(nèi)存這件事本質(zhì)上是在跟人的記憶力做對抗。你new了一個(gè)對象就得記著在哪里delete如果中間某個(gè)分支提前return了delete就可能被跳過如果同一塊內(nèi)存被兩個(gè)指針同時(shí)持有釋放順序錯(cuò)了就會崩潰。我早年寫業(yè)務(wù)代碼時(shí)最常見的就是函數(shù)體里new了一個(gè)臨時(shí)對象做著做著某個(gè)條件不滿足直接return結(jié)果delete那句話永遠(yuǎn)沒機(jī)會執(zhí)行。內(nèi)存泄漏不會立刻讓你崩潰但日積月累進(jìn)程內(nèi)存持續(xù)上漲到最后只能重啟服務(wù)來續(xù)命。除了忘記釋放還有重復(fù)釋放。兩個(gè)指針指向同一塊堆內(nèi)存前面先delete了一次后面又delete一次這是典型的未定義行為——運(yùn)氣好只是報(bào)錯(cuò)運(yùn)氣差直接拖垮整個(gè)進(jìn)程。更隱蔽的是懸空指針delete之后指針本身還保留著原來的地址值但你不可能保證這塊內(nèi)存沒有被別人重新使用。只要邏輯再從這里讀一次數(shù)據(jù)拿到的就是臟數(shù)據(jù)排查起來異常痛苦。再看看異常安全。C的異常機(jī)制讓控制流變得不那么直白如果在new之后、delete之前拋出了異常棧就開始回退delete代碼根本執(zhí)行不到。手動處理需要層層try/catch代碼丑到?jīng)]眼看還不一定能覆蓋全部分支。裸指針的問題不是程序員不夠小心而是這個(gè)方案本身就逼著你在每個(gè)可能的失控點(diǎn)上做防御總會有漏網(wǎng)之魚。1.2 RAII思想用對象生命周期綁定資源生命周期現(xiàn)代化C解決內(nèi)存管理問題靠的不是繼續(xù)加強(qiáng)小心程度而是改變資源的歸屬方式。核心思想就是RAIIResource Acquisition Is Initialization通常翻譯成資源獲取即初始化。聽起來很學(xué)術(shù)實(shí)際上非常簡單把資源放進(jìn)一個(gè)對象的內(nèi)部讓這個(gè)對象的構(gòu)造函數(shù)負(fù)責(zé)獲取資源析構(gòu)函數(shù)負(fù)責(zé)釋放資源。對象是棧上的只要它的作用域結(jié)束編譯器就一定調(diào)用析構(gòu)函數(shù)不管你是正常走完還是因?yàn)楫惓；赝说?。拿?nèi)存舉例你不需要手動delete只需要讓一個(gè)智能指針對象持有那塊內(nèi)存的地址。智能指針自己會實(shí)現(xiàn)析構(gòu)函數(shù)在析構(gòu)函數(shù)里調(diào)用delete。于是內(nèi)存的釋放就綁定了智能指針對象的生命周期而智能指針本身是棧對象作用域一結(jié)束自動析構(gòu)內(nèi)存自然就釋放了。這個(gè)思路徹底繞開了記得delete的問題因?yàn)獒尫胚壿嬍蔷幾g器幫你保證執(zhí)行的。這也是為什么現(xiàn)代C項(xiàng)目里裸指針被限制在很小的范圍內(nèi)。RAII不僅適用于內(nèi)存還適用于文件句柄、互斥鎖、數(shù)據(jù)庫連接等所有需要配對獲取/釋放的資源。理解了這個(gè)底層邏輯后面看unique_ptr、shared_ptr這些具體實(shí)現(xiàn)就會覺得一切都是順理成章的事。它們本質(zhì)上都是資源管理對象只是對資源的所有權(quán)模型設(shè)計(jì)得不同從而適配不同的使用場景。2. 三種智能指針的核心原理與適用場景2.1 unique_ptr獨(dú)占所有權(quán)std::unique_ptr是所有智能指針里最輕量、也最符合直覺的一個(gè)。它的名字就說明了它的性格獨(dú)占所有權(quán)。一個(gè)資源在同一時(shí)刻只能被一個(gè)unique_ptr持有不允許拷貝只能通過移動來轉(zhuǎn)移所有權(quán)。從原理上看它內(nèi)部就是保存了一個(gè)裸指針析構(gòu)時(shí)釋放拷貝構(gòu)造和拷貝賦值都被刪除了只有移動構(gòu)造和移動賦值被保留下來。正是因?yàn)楠?dú)占所以它沒有任何額外的計(jì)數(shù)開銷幾乎和裸指針一樣快。你看它的典型用法從工廠函數(shù)返回新對象或者作為局部變量管理某個(gè)生命周期單一的資源。比如你寫了一個(gè)創(chuàng)建配置對象的函數(shù)#include memory struct Config { int timeout 30; }; std::unique_ptrConfig makeConfig() { return std::make_uniqueConfig(); } void demo() { auto cfg makeConfig(); // 局部變量退出作用域自動釋放 // 這里絕對不能 copy但可以 move auto cfg2 std::move(cfg); // cfg 變成空所有權(quán)轉(zhuǎn)移給 cfg2 if (!cfg) { // 轉(zhuǎn)移后原來的cfg為空可以用來做判空 } }很多人會困惑什么時(shí)候用unique_ptr什么時(shí)候應(yīng)該用shared_ptr我的經(jīng)驗(yàn)是如果資源的所有權(quán)從一開始就是清晰的、唯一的優(yōu)先用unique_ptr。它約束了代碼防止別人隨意拷貝等于把所有權(quán)語義寫進(jìn)了類型系統(tǒng)里。就算以后真的需要共享也可以把它移動進(jìn)shared_ptr這個(gè)升級成本很低。unique_ptr的另一個(gè)特性是刪除器可以作為模板參數(shù)的一部分。這意味著如果資源的釋放方式不是普通delete你可以在類型層面指定如何釋放比如處理文件指針FILE*時(shí)用fclose。因?yàn)閯h除器是類型的一部分每個(gè)不同刪除器的unique_ptr是不同的類型這是它和后面的shared_ptr的一個(gè)關(guān)鍵差異。2.2 shared_ptr引用計(jì)數(shù)實(shí)現(xiàn)共享std::shared_ptr解決的是一塊內(nèi)存可能有多個(gè)持有者的問題。它內(nèi)部維護(hù)一個(gè)引用計(jì)數(shù)每個(gè)持有者都讓計(jì)數(shù)加一當(dāng)最后一個(gè)持有者被銷毀或者重置時(shí)計(jì)數(shù)降到零就會真正釋放內(nèi)存。你可以把它理解成一個(gè)共享租約只要還有一個(gè)人在使用房子就不會被拆掉當(dāng)最后一個(gè)房客搬走才進(jìn)入拆除流程。引用計(jì)數(shù)在原理上不難但實(shí)現(xiàn)細(xì)節(jié)里有不少講究。每個(gè)shared_ptr對象內(nèi)部不只保存裸指針還會保存一個(gè)指向控制塊的指針控制塊里放著強(qiáng)引用計(jì)數(shù)、弱引用計(jì)數(shù)、刪除器、分配器等信息。當(dāng)你拷貝一個(gè)shared_ptr時(shí)兩個(gè)shared_ptr指向同一個(gè)控制塊計(jì)數(shù)加一。當(dāng)一個(gè)shared_ptr銷毀時(shí)計(jì)數(shù)減一減到零就釋放資源、銷毀控制塊。這個(gè)過程是自動的你不需要關(guān)心具體時(shí)機(jī)只需要保證一個(gè)資源從創(chuàng)建開始就統(tǒng)一交給shared_ptr管理。實(shí)際開發(fā)中shared_ptr最常見的坑出在初始化方式上。如果你用同一個(gè)裸指針去創(chuàng)建兩個(gè)獨(dú)立的shared_ptr等于生成了兩個(gè)互不相干的控制塊最后每個(gè)控制塊都會嘗試釋放同一塊內(nèi)存導(dǎo)致雙重釋放崩潰。正確做法是直接使用std::make_shared或者從一個(gè)已有的shared_ptr拷貝。這不僅僅是代碼風(fēng)格問題而是關(guān)系到底層控制塊是否唯一的問題后面我會專門展開。shared_ptr還有一個(gè)容易被忽略的特性它會把刪除器保存在控制塊里。所以即使兩個(gè)shared_ptr的類型不同比如刪除器不同只要它們控制著同一個(gè)對象仍然可以賦值和拷貝因?yàn)閯h除器是運(yùn)行時(shí)信息。這一點(diǎn)和unique_ptr截然不同。2.3 weak_ptr用來打破循環(huán)引用的觀察者std::weak_ptr不是獨(dú)立的資源管理工具它是shared_ptr的觀察者。它指向一個(gè)由shared_ptr管理的對象但不會增加強(qiáng)引用計(jì)數(shù)。這意味著它不擁有資源也不阻止資源被釋放。當(dāng)你需要訪問對象時(shí)要調(diào)用lock()來臨時(shí)獲得一個(gè)shared_ptr如果對象已經(jīng)被釋放lock()會返回一個(gè)空的shared_ptr。這里有一個(gè)非常重要的場景循環(huán)引用。想象兩個(gè)對象A和BA內(nèi)部持有指向B的shared_ptrB內(nèi)部持有指向A的shared_ptr。這時(shí)候A的析構(gòu)要等B釋放B的析構(gòu)要等A釋放結(jié)果誰都不會被釋放內(nèi)存就泄漏了。如果讓其中一個(gè)方向的持有變成weak_ptr比如A持有B的shared_ptrB持有A的weak_ptr那么A釋放時(shí)B還能通過weak_ptr觀察A但B本身不會反向延長A的生命周期循環(huán)就被打破了。weak_ptr另一個(gè)常用場景是實(shí)現(xiàn)緩存或者觀察者模式。比如某個(gè)管理器需要保存一份對象的弱引用方便隨時(shí)檢查對象是否還活著但又不想阻止這個(gè)對象被銷毀。直接用裸指針會面臨懸空風(fēng)險(xiǎn)用shared_ptr又可能延長生命周期weak_ptr是恰好正確的選擇。它的內(nèi)部原理也很巧妙控制塊里除了強(qiáng)引用計(jì)數(shù)還有弱引用計(jì)數(shù)。當(dāng)強(qiáng)引用計(jì)數(shù)歸零時(shí)對象先被釋放但控制塊還會保留一段時(shí)間直到弱引用計(jì)數(shù)也歸零才銷毀控制塊。這就是為什么weak_ptr可以安全地判斷對象是否存活——控制塊本身還活著只是標(biāo)記了對象已經(jīng)釋放。3. 智能指針的實(shí)操要點(diǎn)與避坑經(jīng)驗(yàn)3.1 定制刪除器不只是delete默認(rèn)情況下智能指針會用delete來釋放內(nèi)存。但C項(xiàng)目里有很多資源并不是用new分配的比如打開文件得到的FILE*、用malloc分配的內(nèi)存、第三方庫返回的句柄等。這些資源需要各自的釋放函數(shù)比如fclose、free、CloseHandle。如果直接用默認(rèn)智能指針去管它會嘗試調(diào)用delete輕則資源沒正確釋放重則直接崩潰。unique_ptr的刪除器是類型的一部分你可以在聲明模板參數(shù)時(shí)指定也可以直接用自定義刪除器類型。shared_ptr的刪除器則不是類型的一部分它是在構(gòu)造時(shí)傳入的存放在控制塊里。舉個(gè)例子#include cstdio #include memory // 用 unique_ptr 管理文件指針 auto fileCloser [](FILE* f) { if (f) { fclose(f); std::puts(文件已關(guān)閉); } }; std::unique_ptrFILE, decltype(fileCloser) filePtr(fopen(data.txt, r), fileCloser); // 用 shared_ptr 管理 malloc 分配的內(nèi)存 std::shared_ptrint memPtr( static_castint*(std::malloc(10 * sizeof(int))), std::free );從這個(gè)例子里能看到定制刪除器能讓你放心地把非new資源交給智能指針管理但要注意兩個(gè)細(xì)節(jié)第一unique_ptr使用自定義刪除器會讓類型變長如果你想在容器里存放它們最好把公共釋放邏輯提取成函數(shù)對象而不是每次寫lambda第二shared_ptr雖然刪除器不影響類型但你也要避免同一塊資源用不同刪除器管理這種自相矛盾很容易引發(fā)問題。我在實(shí)際項(xiàng)目中還踩過一個(gè)坑給shared_ptr傳入刪除器時(shí)如果刪除器里捕獲了一些引用或者需要額外清理的資源一定要確保刪除器可以安全執(zhí)行。記得有一次我在刪除器里訪問了已經(jīng)析構(gòu)的日志對象結(jié)果資源釋放的時(shí)候直接崩潰了。正確的做法是刪除器要么是純函數(shù)要么持有自己能安全獨(dú)立存活的數(shù)據(jù)。3.2 管理數(shù)組別用錯(cuò)new[]和delete[]用智能指針管理數(shù)組是一個(gè)比較容易犯錯(cuò)的點(diǎn)。C里new T[]必須對應(yīng)delete[]否則行為未定義。std::unique_ptrT默認(rèn)刪除器調(diào)用的是delete如果管理new[]出來的數(shù)組就會出錯(cuò)。正確的做法是用std::unique_ptrT[]這個(gè)特化版本內(nèi)部會用delete[]來釋放而且重載了operator[]可以直接按下標(biāo)訪問。std::shared_ptr的情況就更微妙了。在C17之前標(biāo)準(zhǔn)庫沒有提供shared_ptrT[]的偏特化當(dāng)你用shared_ptr管理數(shù)組時(shí)必須手動提供刪除器// C17 之前shared_ptr 管理數(shù)組需要自定義刪除器 std::shared_ptrint arr(new int[100], [](int* p) { delete[] p; }); // C17 之后可以直接用 shared_ptrint[] std::shared_ptrint[] arr2(new int[100]);我自己在早期代碼里就犯過直接用std::shared_ptrint arr(new int[10])然后忘寫刪除器的錯(cuò)誤。表面上程序沒立刻崩但釋放時(shí)調(diào)用的delete和分配時(shí)的delete[]不配對屬于未定義行為運(yùn)行到一定規(guī)模就開始隨機(jī)出問題。排查這類問題非常痛苦因?yàn)楸罎⑽恢猛透蛭恢秒x得很遠(yuǎn)。建議是如果你要在堆上分配連續(xù)內(nèi)存優(yōu)先考慮std::vector它本身就管理內(nèi)存還能正確析構(gòu)元素。智能指針管理數(shù)組只適用于一些特殊場景比如不想引入vector、需要和C接口交互時(shí)。必須用智能指針時(shí)記得用unique_ptrT[]或者給shared_ptr提供正確的刪除器。3.3 從裸指針遷移到智能指針的技巧從老代碼遷移到智能指針不是簡單地把delete刪掉然后把裸指針包一層就完事了。最重要的一條原則是一個(gè)資源從誕生到死亡必須自始至終交給同一種所有權(quán)模型管理。不要讓裸指針和智能指針混用更不能從裸指針憑空構(gòu)造多個(gè)shared_ptr。我看很多人寫過這樣的代碼int* raw new int(42); std::shared_ptrint sp1(raw); std::shared_ptrint sp2(raw); // 兩個(gè)控制塊釋放兩次這種寫法幾乎必然導(dǎo)致雙重釋放。即使你只是在一個(gè)局部作用域里用shared_ptr管理一塊內(nèi)存又順手把裸指針傳給了別人別人如果在某個(gè)角落又把它包裝成一個(gè)新的shared_ptr結(jié)局也是災(zāi)難。結(jié)論就是不要相信裸指針還能繼續(xù)安全地借用給第三方除非你非常確定對方在生命周期結(jié)束前不會觸達(dá)已釋放的內(nèi)存。遷移時(shí)還有個(gè)常見的困惑成員變量應(yīng)該用unique_ptr還是shared_ptr我的經(jīng)驗(yàn)是先看需求別把智能指針當(dāng)成默認(rèn)選項(xiàng)。如果這個(gè)對象是否有父對象、子對象的關(guān)系已經(jīng)明確比如二叉樹節(jié)點(diǎn)父節(jié)點(diǎn)擁有子節(jié)點(diǎn)的生命周期那用unique_ptr就夠。如果多個(gè)對象需要共享一個(gè)配置對象、連接池之類的長期資源用shared_ptr。如果只是臨時(shí)觀察一下別人的資源用weak_ptr。另一種不錯(cuò)的思路是盡量讓上層對象擁有資源下層對象通過引用或者裸指針觀察只在真正需要共享所有權(quán)時(shí)才引入shared_ptr。這么做可以減少引用計(jì)數(shù)的原子操作開銷也讓代碼更直白。4. 深入底層引用計(jì)數(shù)與線程安全4.1 控制塊與對象的內(nèi)存布局shared_ptr看起來是一個(gè)很小的對象但它的內(nèi)部結(jié)構(gòu)比你想的要豐滿。標(biāo)準(zhǔn)對象內(nèi)部通常有兩個(gè)指針一個(gè)指向被管理的對象另一個(gè)指向控制塊?？刂茐K里保存了強(qiáng)引用計(jì)數(shù)、弱引用計(jì)數(shù)、刪除器、分配器這些數(shù)據(jù)。當(dāng)你創(chuàng)建shared_ptr時(shí)這個(gè)控制塊也會被創(chuàng)建。整個(gè)布局可以用下面這張簡化的圖理解shared_ptr 對象 ┌─────────────┐ │ 裸指針 ptr │──────? 被管理對象存放實(shí)際數(shù)據(jù) │ 控制塊指針 │──────? 控制塊引用計(jì)數(shù)、刪除器等 └─────────────┘強(qiáng)引用計(jì)數(shù)表示當(dāng)前有幾個(gè)shared_ptr在管理這個(gè)對象。當(dāng)它從1變成0時(shí)就說明最后一個(gè)擁有者也已經(jīng)放棄對象可以被析構(gòu)資源可以釋放。但控制塊并不會立刻銷毀因?yàn)榭赡苓€有weak_ptr在觀察它?？刂茐K一直要等到弱引用計(jì)數(shù)也歸零才會被完全回收。這是理解weak_ptr為什么能安全判斷對象是否存活的關(guān)鍵weak_ptr并不直接知道對象的地址是否有效它只能通過控制塊里的強(qiáng)引用計(jì)數(shù)來判斷而控制塊本身還在所以這個(gè)判斷是可靠的不會訪問已經(jīng)回收的內(nèi)存。從這種設(shè)計(jì)可以看出shared_ptr相比裸指針多出來的開銷不只是引用計(jì)數(shù)本身還有控制塊的分配和管理。內(nèi)存分配的次數(shù)變多了這是性能上不可忽視的成本。這也是為什么后文要強(qiáng)調(diào)make_shared的重要性——它能減少一次內(nèi)存分配從兩個(gè)分配合并成一個(gè)。4.2 make_shared和new shared_ptr的差別很多人寫shared_ptr時(shí)喜歡直接構(gòu)造std::shared_ptrFoo sp(new Foo(42));而現(xiàn)代C推薦std::shared_ptrFoo sp std::make_sharedFoo(42);這兩種方式在表面上都能得到一個(gè)shared_ptr但底層差別很大。直接的new寫法會先分配一塊內(nèi)存給Foo對象然后shared_ptr構(gòu)造時(shí)再分配一塊控制塊內(nèi)存。也就是說這里出現(xiàn)了兩次獨(dú)立的堆分配。而make_shared會一次性分配一整塊連續(xù)內(nèi)存里面既包含F(xiàn)oo對象的數(shù)據(jù)也包含控制塊的數(shù)據(jù)。這樣做有兩個(gè)好處第一減少一次內(nèi)存分配性能更好第二由于對象和控制塊放在同一塊內(nèi)存里緩存局部性更好訪問對象時(shí)控制塊信息可能已經(jīng)在緩存中了。還有一個(gè)更隱蔽的異常安全問題?？紤]這種寫法std::shared_ptrFoo sp(new Foo(42)); doSomething(); // 假設(shè)這里拋異常如果構(gòu)造函數(shù)new Foo(42)執(zhí)行成功但在shared_ptr構(gòu)造完成之前doSomething拋出異常那么new出來的Foo對象沒人管理會泄漏。用make_shared則不會有這個(gè)問題因?yàn)閷ο髣?chuàng)建和shared_ptr管理是同一個(gè)原子步驟中間不會插入可能拋出異常的其他代碼。所以從安全性和性能兩個(gè)維度看make_shared都更合理。make_shared也不是沒有弱點(diǎn)。因?yàn)閷ο蠛涂刂茐K在同一個(gè)內(nèi)存塊里只有當(dāng)弱引用計(jì)數(shù)也歸零時(shí)這塊大內(nèi)存才會整體釋放。如果你的shared_ptr已經(jīng)銷毀了但還有一個(gè)weak_ptr殘留那么Foo對象的那部分內(nèi)存其實(shí)也還沒被釋放。這在一些極端場景下會造成資源明明沒人用了內(nèi)存卻遲遲不歸還的現(xiàn)象。比如一個(gè)大對象被shared_ptr管理同時(shí)有weak_ptr長期保存著而且對象本身占用的內(nèi)存很大那么即使強(qiáng)引用計(jì)數(shù)歸零這塊大內(nèi)存也不會被釋放直到弱引用也消失。如果你的場景很在意這個(gè)可能要考慮直接用new分配控制塊讓對象可以提前釋放但這屬于少數(shù)情況下的權(quán)衡。4.3 多線程場景下的智能指針多線程下使用shared_ptr有一個(gè)容易誤解的點(diǎn)標(biāo)準(zhǔn)庫里shared_ptr的引用計(jì)數(shù)本身是原子操作所以多個(gè)線程同時(shí)對同一個(gè)shared_ptr做拷貝和析構(gòu)不會導(dǎo)致計(jì)數(shù)錯(cuò)亂。這句話的意思是計(jì)數(shù)增減是線程安全的你不用擔(dān)心兩個(gè)線程同時(shí)減少導(dǎo)致負(fù)數(shù)。但這絕對不等于多個(gè)線程可以安全地讀取和修改被管理對象。對象本身的線程安全需要你自行通過互斥鎖、原子操作等方式保證。舉個(gè)例子兩個(gè)線程都持有一個(gè)shared_ptrint的拷貝它們指向同一個(gè)int對象。如果其中一個(gè)線程寫*sp 1另一個(gè)線程讀*sp這里沒有同步就是數(shù)據(jù)競爭行為未定義。計(jì)數(shù)安全和對象數(shù)據(jù)安全是完全兩回事。很多人誤以為用了shared_ptr就自動線程安全了結(jié)果線上出現(xiàn)奇怪的數(shù)據(jù)錯(cuò)亂排查半天才意識到是自己理解錯(cuò)了。另一個(gè)相關(guān)的點(diǎn)在于對shared_ptr對象本身的并發(fā)訪問。如果有多個(gè)線程共享同一個(gè)shared_ptr變量也就是說不是各自持有拷貝而是通過引用或指針訪問同一個(gè)shared_ptr實(shí)例那么這個(gè)實(shí)例本身的并發(fā)讀寫也是不安全的。你需要用鎖來保護(hù)它。最穩(wěn)定的模式是在多線程環(huán)境中盡量不要直接共享shared_ptr變量本身而是讓每個(gè)線程持有它自己的拷貝。因?yàn)榭截惐旧硎窃拥囊糜?jì)數(shù)增減這樣就能安全地復(fù)制所有權(quán)避免了對同一個(gè)實(shí)例的并發(fā)訪問。weak_ptr的lock()實(shí)現(xiàn)也是線程安全的。多個(gè)線程同時(shí)lock()同一個(gè)weak_ptr即使恰好對象在另一個(gè)線程中被釋放也能保證結(jié)果準(zhǔn)確——要么成功提升為有效的shared_ptr要么返回空。這是標(biāo)準(zhǔn)庫對weak_ptr::lock的原子性保證。但同樣地鎖定的也只是獲得所有權(quán)這個(gè)動作之后對被管理對象的操作仍然需要自行同步。5. 常見問題與排查技巧實(shí)錄5.1 循環(huán)引用導(dǎo)致內(nèi)存泄漏循環(huán)引用是shared_ptr最經(jīng)典的坑。我最初接觸智能指針時(shí)以為只要指針不用手動delete就萬事大吉結(jié)果用shared_ptr寫出了內(nèi)存泄漏還不自知。場景是這樣的有一個(gè)父節(jié)點(diǎn)類Node它持有子節(jié)點(diǎn)的shared_ptr子節(jié)點(diǎn)為了回調(diào)方便又持有了父節(jié)點(diǎn)的shared_ptr。這樣構(gòu)建出來的樹形結(jié)構(gòu)任何一個(gè)節(jié)點(diǎn)離開作用域后因?yàn)榛ハ喑钟幸糜?jì)數(shù)永遠(yuǎn)到不了0整棵樹的節(jié)點(diǎn)全泄漏了。struct Node { std::shared_ptrNode child; std::shared_ptrNode parent; ~Node() { std::printf(釋放節(jié)點(diǎn)\n); } }; void demo() { auto parent std::make_sharedNode(); auto child std::make_sharedNode(); parent-child child; child-parent parent; // 離開作用域時(shí)兩個(gè)節(jié)點(diǎn)的引用計(jì)數(shù)都是2降不下去 }釋放日志不會打印因?yàn)閮蓚€(gè)對象互相把對方鎖死了。解決方式很簡單打破其中一個(gè)方向的強(qiáng)引用。一般來說父子關(guān)系中父節(jié)點(diǎn)擁有子節(jié)點(diǎn)所以父節(jié)點(diǎn)用shared_ptr持有子節(jié)點(diǎn)子節(jié)點(diǎn)要訪問父節(jié)點(diǎn)用weak_ptr就可以了。weak_ptr不增加強(qiáng)引用計(jì)數(shù)所以父節(jié)點(diǎn)被釋放后子節(jié)點(diǎn)里的weak_ptr會感知到對象已經(jīng)不在了訪問前通過lock()判斷一下即可。struct Node { std::shared_ptrNode child; std::weak_ptrNode parent; ~Node() { std::printf(釋放節(jié)點(diǎn)\n); } };用weak_ptr后parent離開作用域它的引用計(jì)數(shù)從1降到0立刻釋放child還活著但它持有的只是對parent的弱引用不會延長parent的生命周期。這個(gè)改動雖然很小卻直接避免了一場內(nèi)存泄漏。在排查自己寫的代碼時(shí)如果發(fā)現(xiàn)某個(gè)資源明明不再使用但進(jìn)程內(nèi)存只增不減優(yōu)先檢查對象之間是否存在相互的shared_ptr引用。畫一個(gè)誰指向誰的圖凡是形成環(huán)狀的強(qiáng)引用都必須用weak_ptr切斷。5.2 enable_shared_from_this的正確姿勢另一個(gè)高頻問題是一個(gè)對象已經(jīng)被shared_ptr管理了在它的成員函數(shù)內(nèi)部怎么安全地獲得指向自身的shared_ptr如果你直接在函數(shù)里寫std::shared_ptrX(this)就會在已有管理關(guān)系之外創(chuàng)建一個(gè)新的控制塊等這個(gè)臨時(shí)的shared_ptr析構(gòu)它會嘗試再次釋放對象造成雙重釋放。這個(gè)坑非常隱蔽因?yàn)槟憧赡苤辉谀承┨厥夥种Ю锓祷豷elf運(yùn)行很久都不會觸發(fā)一旦觸發(fā)就是程序崩潰。標(biāo)準(zhǔn)答案是繼承std::enable_shared_from_thisT然后調(diào)用shared_from_this()class Request : public std::enable_shared_from_thisRequest { public: void start() { // 把自身作為回調(diào)參數(shù)傳給別的模塊 auto self shared_from_this(); callback_-invoke(self); } }; auto req std::make_sharedRequest(); req-start();enable_shared_from_this內(nèi)部的實(shí)現(xiàn)原理是這個(gè)類里面藏了一個(gè)weak_ptrT成員。當(dāng)?shù)谝粋€(gè)shared_ptr接管這個(gè)對象時(shí)它會把正確的控制塊信息寫入這個(gè)weak_ptr。之后你調(diào)用shared_from_this()實(shí)際上就是從這個(gè)內(nèi)部weak_ptr提升出一個(gè)新的shared_ptr所以不會創(chuàng)建重復(fù)的控制塊引用計(jì)數(shù)也能正確增加非常安全。使用enable_shared_from_this有幾個(gè)必須記住的約束。第一個(gè)你只能在對象已經(jīng)被shared_ptr管理之后調(diào)用shared_from_this()。如果在棧上創(chuàng)建了一個(gè)普通對象沒有經(jīng)過shared_ptr直接調(diào)用shared_from_this內(nèi)部weak_ptr是空的提升失敗標(biāo)準(zhǔn)庫會拋出std::bad_weak_ptr異常。第二個(gè)不要在構(gòu)造函數(shù)里調(diào)用shared_from_this()。因?yàn)榇藭r(shí)控制塊還沒綁定好調(diào)用時(shí)機(jī)太早了。第三個(gè)如果你的類是多繼承請確保enable_shared_from_this被正確繼承一次不要通過多個(gè)基類引入多份不相關(guān)的能力否則可能拿到錯(cuò)誤的this指針。這一塊是C里典型的看起來不難、實(shí)際陷阱很多的地方我建議你在自己的小項(xiàng)目里專門寫一個(gè)測試場景把棧上對象、堆對象、構(gòu)造函數(shù)調(diào)用三種情況都跑一遍印象會深刻得多。5.3 智能指針不是越多越好聊到這里估計(jì)有人會走向另一個(gè)極端所有對象全用shared_ptr能不用裸指針就不用裸指針。這個(gè)想法出發(fā)點(diǎn)沒錯(cuò)但實(shí)踐下來會引入新的問題。第一個(gè)問題是性能開銷。shared_ptr的引用計(jì)數(shù)增減是原子操作在多線程環(huán)境下頻繁拷貝和析構(gòu)shared_ptr會帶來不小的原子操作開銷。如果你在熱路徑上大量使用shared_ptr性能表現(xiàn)可能比裸指針差很多。我見過一個(gè)網(wǎng)絡(luò)模塊每條消息都通過shared_ptr傳遞結(jié)果高并發(fā)下CPU占用明顯偏高。不是shared_ptr本身設(shè)計(jì)得差而是這個(gè)場景里共享所有權(quán)并不是必需的用unique_ptr甚至直接在棧上傳遞對象更合適。第二個(gè)問題是語義混亂。當(dāng)所有成員變量都是shared_ptr時(shí)這個(gè)類其實(shí)已經(jīng)失去了清晰的生命周期邊界。誰都可以隨便持有一份長期有效的引用結(jié)果資源被意外地延長生命周期甚至出現(xiàn)一些無法理解的引用關(guān)系。寫代碼的人自己都說不清楚某個(gè)對象到底應(yīng)該由誰銷毀。相比之下unique_ptr代表我是唯一的所有者weak_ptr代表我不擁有它只觀察它。把這些類型用準(zhǔn)確代碼本身就能表達(dá)設(shè)計(jì)意圖別人維護(hù)起來也輕松很多。我個(gè)人的經(jīng)驗(yàn)是先問自己這個(gè)對象的所有權(quán)模型到底是什么再決定用哪種智能指針。如果對象只是臨時(shí)在函數(shù)里用一下直接放棧上如果確實(shí)是堆對象而且生命周期唯一用unique_ptr如果確實(shí)要共享才用shared_ptr并且配套使用weak_ptr處理不擁有但需要觀察的場景。一個(gè)項(xiàng)目里不可能所有對象都必須共享把沒有必要的shared_ptr替換成unique_ptr或者棧對象通常會讓代碼更清爽性能也更好。最后再分享一個(gè)排查內(nèi)存問題的小技巧如果你的程序里大量使用shared_ptr可以在編譯期臨時(shí)打開一些內(nèi)存檢測工具比如AddressSanitizer或者valgrind它們能幫你識別出雙重釋放、使用已釋放內(nèi)存等問題。但工具只是輔助根本解法還是得回到所有權(quán)模型上把誰擁有、誰觀察、誰釋放這三件事想明白。智能指針不是魔法它只是把內(nèi)存管理的規(guī)則固化到語言層面規(guī)則本身不會變變的是你不再需要靠肌肉記憶去遵守它們。踩過幾次循環(huán)引用的坑再看到weak_ptr你會有一種原來如此的融會貫通感。希望這篇筆記能幫你少走一段彎路。