本文向讀者介紹了如何避免內(nèi)存泄漏的方法和原則，在細(xì)節(jié)和大體方向上均給出一些可行性方案。讀者可以嘗試文中提出的方法，改進(jìn)自己的代碼，大大減少內(nèi)存泄漏的可能性。

前言

近年來，討論 C++ 的人越來越少了，一方面是由于像 Python，Go 等優(yōu)秀的語言的流行，另一方面，大家也越來越明白一個(gè)道理，并不是所有的場景都必須使用 C++ 進(jìn)行開發(fā)。Python 可以應(yīng)付大部分對性能要求不高的場景，Go 可以應(yīng)付大部分對并發(fā)要求較高的場景，而由于 C++ 的復(fù)雜性，只有在對性能極其苛刻的場景下，才會(huì)考慮使用。

那么到底多苛刻算是苛刻呢？Go 自帶內(nèi)存管理，也就是 GC 功能，經(jīng)過多年的優(yōu)化，在 Go 中每次 GC 可能會(huì)引入 500us 的 STW 延遲。

也就是說，如果你的應(yīng)用場景可以容忍不定期的 500us 的延遲，那么用 Go 都是沒有問題的。如果你無法容忍 500us 的延遲，那么帶 GC 功能的語言就基本無法使用了，只能選擇自己管理內(nèi)存的語言，例如 C++。那么由手動(dòng)管理內(nèi)存而帶來的編程復(fù)雜度也就隨之而來了。
作為 C++ 程序員，內(nèi)存泄露始終是懸在頭上的一顆炸彈。在過去幾年的 C++ 開發(fā)過程中，由于我們采用了一些技術(shù)，我們的程序發(fā)生內(nèi)存泄露的情況屈指可數(shù)。今天就在這里向大家做一個(gè)簡單的介紹。

內(nèi)存是如何泄露的

在 C++ 程序中，主要涉及到的內(nèi)存就是『?！缓汀憾选唬ㄆ渌糠植辉诒疚闹薪榻B了）。

通常來說，一個(gè)線程的棧內(nèi)存是有限的，通常來說是 8M 左右（取決于運(yùn)行的環(huán)境）。棧上的內(nèi)存通常是由編譯器來自動(dòng)管理的。當(dāng)在棧上分配一個(gè)新的變量時(shí)，或進(jìn)入一個(gè)函數(shù)時(shí)，棧的指針會(huì)下移，相當(dāng)于在棧上分配了一塊內(nèi)存。我們把一個(gè)變量分配在棧上，也就是利用了棧上的內(nèi)存空間。當(dāng)這個(gè)變量的生命周期結(jié)束時(shí)，棧的指針會(huì)上移，相同于回收了內(nèi)存。

由于棧上的內(nèi)存的分配和回收都是由編譯器控制的，所以在棧上是不會(huì)發(fā)生內(nèi)存泄露的，只會(huì)發(fā)生棧溢出（Stack Overflow），也就是分配的空間超過了規(guī)定的棧大小。

而堆上的內(nèi)存是由程序直接控制的，程序可以通過 malloc/free 或 new/delete 來分配和回收內(nèi)存，如果程序中通過 malloc/new 分配了一塊內(nèi)存，但忘記使用 free/delete 來回收內(nèi)存，就發(fā)生了內(nèi)存泄露。

經(jīng)驗(yàn) #1：盡量避免在堆上分配內(nèi)存

既然只有堆上會(huì)發(fā)生內(nèi)存泄露，那第一原則肯定是避免在堆上面進(jìn)行內(nèi)存分配，盡可能的使用棧上的內(nèi)存，由編譯器進(jìn)行分配和回收，這樣當(dāng)然就不會(huì)有內(nèi)存泄露了。

然而，只在棧上分配內(nèi)存，在有 IO 的情況下是存在一定局限性的。 舉個(gè)例子，為了完成一個(gè)請求，我們通常會(huì)為這個(gè)請求構(gòu)造一個(gè) Context 對象，用于描述和這個(gè)請求有關(guān)的一些上下文。例如下面一段代碼：

void Foo（Reuqest* req） { RequestContext ctx（req）; HandleRequest（&ctx）;}

如果 HandleRequest 是一個(gè)同步函數(shù)，當(dāng)這個(gè)函數(shù)返回時(shí)，請求就可以被處理完成，那么顯然 ctx 是可以被分配在棧上的。

但如果 HandleRequest 是一個(gè)異步函數(shù)，例如：

void HandleRequest（RequestContext* ctx， Callback cb）;

那么顯然，ctx 是不能被分配在棧上的，因?yàn)槿绻?ctx 被分配在棧上，那么當(dāng) Foo 函數(shù)推出后，ctx 對象的生命周期也就結(jié)束了。而 FooCB 中顯然會(huì)使用到 ctx 對象。

void HandleRequest（RequestContext* ctx， Callback cb）; void Foo（Reuqest* req） { auto ctx = new RequestContext（req）; HandleRequest（ctx， FooCB）;} void FooCB（RequestContext* ctx） { FinishRequest（ctx）; delete ctx;} 在這種情況下，如果忘記在 FooCB 中調(diào)用 delete ctx，則就會(huì)觸發(fā)內(nèi)存泄露。盡管我們可以借助一些靜態(tài)檢查工具對代碼進(jìn)行檢查，但往往異步程序的邏輯是極其復(fù)雜的，一個(gè)請求的生命周期中，也需要進(jìn)行大量的內(nèi)存分配操作，靜態(tài)檢查工具往往無法發(fā)現(xiàn)所有的內(nèi)存泄露情況。

那么怎么才能避免這種情況的產(chǎn)生呢？引入智能指針顯然是一種可行的方法，但引入 shared_ptr 往往引入了額外的性能開銷，并不十分理想。 在 SmartX，我們通常采用兩種方法來應(yīng)對這種情況。

經(jīng)驗(yàn) #2：使用 Arena

Arena 是一種統(tǒng)一化管理內(nèi)存生命周期的方法。所有需要在堆上分配的內(nèi)存，不通過 malloc/new，而是通過 Arena 的 CreateObject 接口。同時(shí)，不需要手動(dòng)的執(zhí)行 free/delete，而是在 Arena 被銷毀的時(shí)候，統(tǒng)一釋放所有通過 Arena 對象申請的內(nèi)存。所以，只需要確保 Arena 對象一定被銷毀就可以了，而不用再關(guān)心其他對象是否有漏掉的 free/delete。這樣顯然降低了內(nèi)存管理的復(fù)雜度。

此外，我們還可以將 Arena 的生命周期與 Request 的生命周期綁定，一個(gè) Request 生命周期內(nèi)的所有內(nèi)存分配都通過 Arena 完成。這樣的好處是，我們可以在構(gòu)造 Arena 的時(shí)候，大概預(yù)估出處理完成這個(gè) Request 會(huì)消耗多少內(nèi)存，并提前將會(huì)使用到的內(nèi)存一次性的申請完成，從而減少了在處理一個(gè)請求的過程中，分配和回收內(nèi)存的次數(shù)，從而優(yōu)化了性能。

我們最早看到 Arena 的思想，是在 LevelDB 的代碼中。這段代碼相當(dāng)簡單，建議大家直接閱讀。

經(jīng)驗(yàn) #3：使用 Coroutine

Coroutine 相信大家并不陌生，那 Coroutine 的本質(zhì)是什么？我認(rèn)為 Coroutine 的本質(zhì)，是使得一個(gè)線程中可以存在多個(gè)上下文，并可以由用戶控制在多個(gè)上下文之間進(jìn)行切換。而在上下文中，一個(gè)重要的組成部分，就是棧指針。使用 Coroutine，意味著我們在一個(gè)線程中，可以創(chuàng)造（或模擬）多個(gè)棧。

有了多個(gè)棧，意味著當(dāng)我們要做一個(gè)異步處理時(shí)，不需要釋放當(dāng)前棧上的內(nèi)存，而只需要切換到另一個(gè)棧上，就可以繼續(xù)做其他的事情了，當(dāng)異步處理完成時(shí)，可以再切換回到這個(gè)棧上，將這個(gè)請求處理完成。 還是以剛才的代碼為示例：

void Foo（Reuqest* req） { RequestContext ctx（req）; HandleRequest（&ctx）;} void HandleRequest（RequestCtx* ctx） { SubmitAsync（ctx）; Coroutine：：Self（）-》Yield（）; CompleteRequest（ctx）;} 這里的精髓在于，盡管 Coroutine：：Self（）-》Yield（） 被調(diào)用時(shí)，程序可以跳出 HandleRequest 函數(shù)去執(zhí)行其他代碼邏輯，但當(dāng)前的棧卻被保存了下來，所以 ctx 對象是安全的，并沒有被釋放。

這樣一來，我們就可以完全拋棄在堆上申請內(nèi)存，只是用棧上的內(nèi)存，就可以完成請求的處理，完全不用考慮內(nèi)存泄露的問題。然而這種假設(shè)過于理想，由于在棧上申請內(nèi)存存在一定的限制，例如棧大小的限制，以及需要在編譯是知道分配內(nèi)存的大小，所以在實(shí)際場景中，我們通常會(huì)結(jié)合使用 Arena 和 Coroutine 兩種技術(shù)一起使用。

有人可能會(huì)提到，想要多個(gè)棧用多個(gè)線程不就可以了？然而用多線程實(shí)現(xiàn)多個(gè)棧的問題在于，線程的創(chuàng)建和銷毀的開銷極大，且線程間切塊，也就是在棧之間進(jìn)行切換的代銷需要經(jīng)過操作系統(tǒng)，這個(gè)開銷也是極大的。所以想用線程模擬多個(gè)棧的想法在實(shí)際場景中是走不通的。

關(guān)于 Coroutine 有很多開源的實(shí)現(xiàn)方式，大家可以在 github 上找到很多，C++20 標(biāo)準(zhǔn)也會(huì)包含 Coroutine 的支持。在 SmartX 內(nèi)部，我們很早就實(shí)現(xiàn)了 Coroutine，并對所有異步 IO 操作進(jìn)行了封裝，示例可參考我們之前的一篇文章 smartx：基于 Coroutine 的異步 RPC 框架示例（C++）

這里需要強(qiáng)調(diào)一下，Coroutine 確實(shí)會(huì)帶來一定的性能開銷，通常 Coroutine 切換的開銷在 20ns 以內(nèi)，然而我們依然在對性能要求很苛刻的場景使用 Coroutine，一方面是因?yàn)?20ns 的性能開銷是相對很小的，另一方面是因?yàn)?Coroutine 極大的降低了異步編程的復(fù)雜度，降低了內(nèi)存泄露的可能性，使得編寫異步程序像編寫同步程序一樣簡單，降低了程序員心智的開銷。

boost 實(shí)現(xiàn)的 coroutine 的性能測試結(jié)果

經(jīng)驗(yàn) #4：善用 RAII

盡管在有些場景使用了 Coroutine，但還是可能會(huì)有在堆上申請內(nèi)存的需要，而此時(shí)有可能 Arena 也并不適用。在這種情況下，善用 RAII（Resource Acquisition Is Initialization）思想會(huì)幫助我們解決很多問題。

簡單來說，RAII 可以幫助我們將管理堆上的內(nèi)存，簡化為管理?xiàng)Ｉ系膬?nèi)存，從而達(dá)到利用編譯器自動(dòng)解決內(nèi)存回收問題的效果。此外，RAII 可以簡化的還不僅僅是內(nèi)存管理，還可以簡化對資源的管理，例如 fd，鎖，引用計(jì)數(shù)等等。

當(dāng)我們需要在堆上分配內(nèi)存時(shí)，我們可以同時(shí)在棧上面分配一個(gè)對象，讓棧上面的對象對堆上面的對象進(jìn)行封裝，用時(shí)通過在棧對象的析構(gòu)函數(shù)中釋放堆內(nèi)存的方式，將棧對象的生命周期和堆內(nèi)存進(jìn)行綁定。

unique_ptr 就是一種很典型的例子。然而 unique_ptr 管理的對象類型只能是指針，對于其他的資源，例如 fd，我們可以通過將 fd 封裝成另外一個(gè) FileHandle 對象的方式管理，也可以采用一些更通用的方式。例如，在我們內(nèi)部的 C++ 基礎(chǔ)庫中實(shí)現(xiàn)了 Defer 類，想法類似于 Go 中 defer。

void Foo（） { int fd = open（）; Defer d = ［=］（） { close（fd）; } // do something with fd}

經(jīng)驗(yàn) #5：便于 Debug

在特定的情況下，我們難免還是要手動(dòng)管理堆上的內(nèi)存。然而當(dāng)我們面臨一個(gè)正在發(fā)生內(nèi)存泄露線上程序時(shí)，我們應(yīng)該怎么處理呢？

當(dāng)然不是簡單的『重啟大法好』，畢竟重啟后還是可能會(huì)產(chǎn)生泄露，而且最寶貴的現(xiàn)場也被破壞了。最佳的方式，還是利用現(xiàn)場進(jìn)行 Debug，這就要求程序具有便于 Debug 的能力。

這里不得不提到一個(gè)經(jīng)典而強(qiáng)大的工具 gperftools。gperftools 是 google 開源的一個(gè)工具集，包含了 tcmalloc，heap profiler，heap checker，cpu profiler 等等。gperftools 的作者之一，就是大名鼎鼎的 Sanjay Ghemawat，沒錯(cuò)，就是與 Jeff Dean 齊名，并和他一起寫 MapReduce 的那個(gè) Sanjay。

gperftools 的一些經(jīng)典用法，我們就不在這里進(jìn)行介紹了，大家可以自行查看文檔。而使用 gperftools 可以在不重啟程序的情況下，進(jìn)行內(nèi)存泄露檢查，這個(gè)恐怕是很少有人了解。

實(shí)際上我們 Release 版本的 C++ 程序可執(zhí)行文件在編譯時(shí)全部都鏈接了 gperftools。在 gperftools 的 heap profiler 中，提供了 HeapProfilerStart 和 HeapProfilerStop 的接口，使得我們可以在運(yùn)行時(shí)啟動(dòng)和停止 heap profiler。同時(shí)，我們每個(gè)程序都暴露了 RPC 接口，用于接收控制命令和調(diào)試命令。在調(diào)試命令中，我們就增加了調(diào)用 HeapProfilerStart 和 HeapProfilerStop 的命令。由于鏈接了 tcmalloc，所以 tcmalloc 可以獲取所有內(nèi)存分配和回收的信息。當(dāng) heap profiler 啟動(dòng)后，就會(huì)定期的將程序內(nèi)存分配和回收的行為 dump 到一個(gè)臨時(shí)文件中。

當(dāng)程序運(yùn)行一段時(shí)間后，你將得到一組 heap profile 文件

profile.0001.heap profile.0002.heap 。。. profile.0100.heap每個(gè) profile 文件中都包含了一段時(shí)間內(nèi)，程序中內(nèi)存分配和回收的記錄。如果想要找到內(nèi)存泄露的線索，可以通過使用pprof --base=profile.0001.heap /usr/bin/xxx profile.0100.heap --text 來進(jìn)行查看，也可以生成 pdf 文件，會(huì)更直觀一些。

這樣一來，我們就可以很方便的對線上程序的內(nèi)存泄露進(jìn)行 Debug 了。

寫在最后

C++ 可謂是最復(fù)雜、最靈活的語言，也最容易給大家?guī)砝_。如果想要用好 C++，團(tuán)隊(duì)必須保持比較成熟的心態(tài)，團(tuán)隊(duì)成員必須愿意按照一定的規(guī)則來使用 C++，而不是任性的隨意發(fā)揮。這樣大家才能把更多精力放在業(yè)務(wù)本身，而不是編程語言的特性上。
責(zé)任編輯人：CC