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