作為 C++ 程序員，內(nèi)存泄露始終是懸在頭上的一顆炸彈。在過去幾年的 C++ 開發(fā)過程中，由于我們采用了一些技術(shù)，我們的程序發(fā)生內(nèi)存泄露的情況屈指可數(shù)。今天就在這里向大家做一個(gè)簡(jiǎn)單的介紹。

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

在 C++ 程序中，主要涉及到的內(nèi)存就是『棧』和『堆』（其他部分不在本文中介紹了）。

通常來說，一個(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è)請(qǐng)求，我們通常會(huì)為這個(gè)請(qǐng)求構(gòu)造一個(gè) Context 對(duì)象，用于描述和這個(gè)請(qǐng)求有關(guān)的一些上下文。例如下面一段代碼：

void Foo(Reuqest* req) {
    RequestContext ctx(req);
    HandleRequest(&ctx);
}

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

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

void HandleRequest(RequestContext* ctx, Callback cb);

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

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)檢查工具對(duì)代碼進(jìn)行檢查，但往往異步程序的邏輯是極其復(fù)雜的，一個(gè)請(qǐng)求的生命周期中，也需要進(jìn)行大量的內(nèi)存分配操作，靜態(tài)檢查工具往往無(wú)法發(fā)現(xiàn)所有的內(nèi)存泄露情況。

那么怎么才能避免這種情況的產(chǎn)生呢？引入智能指針顯然是一種可行的方法，但引入 shared_ptr 往往引入了額外的性能開銷，并不十分理想。

在 SmartX，我們通常采用兩種方法來應(yīng)對(duì)這種情況。

經(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 對(duì)象申請(qǐng)的內(nèi)存。所以，只需要確保 Arena 對(duì)象一定被銷毀就可以了，而不用再關(guān)心其他對(duì)象是否有漏掉的 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)存一次性的申請(qǐng)完成，從而減少了在處理一個(gè)請(qǐng)求的過程中，分配和回收內(nèi)存的次數(shù)，從而優(yōu)化了性能。

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

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

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

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

還是以剛才的代碼為示例:

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 對(duì)象是安全的，并沒有被釋放。

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

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

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

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

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

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

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

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

unique_ptr 就是一種很典型的例子。然而 unique_ptr 管理的對(duì)象類型只能是指針，對(duì)于其他的資源，例如 fd，我們可以通過將 fd 封裝成另外一個(gè) FileHandle 對(duì)象的方式管理，也可以采用一些更通用的方式。例如，在我們內(nèi)部的 C++ 基礎(chǔ)庫(kù)中實(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)然不是簡(jiǎn)單的『重啟大法好』，畢竟重啟后還是可能會(huì)產(chǎn)生泄露，而且最寶貴的現(xiàn)場(chǎng)也被破壞了。最佳的方式，還是利用現(xiàn)場(chǎng)進(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ì)更直觀一些。

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

寫在最后

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