當前位置:首頁 > 公眾號精選 > C語言與CPP編程
[導讀]內(nèi)存泄漏是C/C++的一個老生常談的問題,無論是新手,還是有經(jīng)驗的開發(fā)者,都會在這個問題上栽跟頭。

來源: 知乎-張凱(Kyle Zhang)

【CPP開發(fā)者導讀】:內(nèi)存泄漏是C/C++的一個老生常談的問題,無論是新手還是有經(jīng)驗的開發(fā)者都會在這個問題上栽跟頭。

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


前言


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


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


也就是說,如果你的應用場景可以容忍不定期的 500us 的延遲,那么用 Go 都是沒有問題的。如果你無法容忍 500us 的延遲,那么帶 GC 功能的語言就基本無法使用了,只能選擇自己管理內(nèi)存的語言,例如 C++。那么由手動管理內(nèi)存而帶來的編程復雜度也就隨之而來了。

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


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


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



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

由于棧上的內(nèi)存的分配和回收都是由編譯器控制的,所以在棧上是不會發(fā)生內(nèi)存泄露的,只會發(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)驗 #1:盡量避免在堆上分配內(nèi)存


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

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

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


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

但如果 HandleRequest 是一個異步函數(shù),例如:

void?HandleRequest(RequestContext*?ctx,?Callback?cb);


那么顯然,ctx 是不能被分配在棧上的,因為如果 ctx 被分配在棧上,那么當 Foo 函數(shù)推出后,ctx 對象的生命周期也就結(jié)束了。而 FooCB 中顯然會使用到 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,則就會觸發(fā)內(nèi)存泄露。盡管我們可以借助一些靜態(tài)檢查工具對代碼進行檢查,但往往異步程序的邏輯是極其復雜的,一個請求的生命周期中,也需要進行大量的內(nèi)存分配操作,靜態(tài)檢查工具往往無法發(fā)現(xiàn)所有的內(nèi)存泄露情況。

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


經(jīng)驗 #2:使用 Arena


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

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

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


經(jīng)驗 #3:使用 Coroutine


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

有了多個棧,意味著當我們要做一個異步處理時,不需要釋放當前棧上的內(nèi)存,而只需要切換到另一個棧上,就可以繼續(xù)做其他的事情了,當異步處理完成時,可以再切換回到這個棧上,將這個請求處理完成。
還是以剛才的代碼為示例:
   
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)用時,程序可以跳出 HandleRequest 函數(shù)去執(zhí)行其他代碼邏輯,但當前的棧卻被保存了下來,所以 ctx 對象是安全的,并沒有被釋放。

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

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

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

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

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


經(jīng)驗 #4:善用 RAII


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

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

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

unique_ptr 就是一種很典型的例子。然而 unique_ptr 管理的對象類型只能是指針,對于其他的資源,例如 fd,我們可以通過將 fd 封裝成另外一個 FileHandle 對象的方式管理,也可以采用一些更通用的方式。例如,在我們內(nèi)部的 C++ 基礎庫中實現(xiàn)了 Defer 類,想法類似于 Go 中 defer。
   
void Foo() { int fd = open(); Defer d = [=]() { close(fd); } // do something with fd}

經(jīng)驗 #5:便于 Debug


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

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

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


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

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

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


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

寫在最后

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

免責聲明:本文內(nèi)容由21ic獲得授權后發(fā)布,版權歸原作者所有,本平臺僅提供信息存儲服務。文章僅代表作者個人觀點,不代表本平臺立場,如有問題,請聯(lián)系我們,謝謝!

本站聲明: 本文章由作者或相關機構(gòu)授權發(fā)布,目的在于傳遞更多信息,并不代表本站贊同其觀點,本站亦不保證或承諾內(nèi)容真實性等。需要轉(zhuǎn)載請聯(lián)系該專欄作者,如若文章內(nèi)容侵犯您的權益,請及時聯(lián)系本站刪除。
換一批
延伸閱讀

9月2日消息,不造車的華為或?qū)⒋呱龈蟮莫毥谦F公司,隨著阿維塔和賽力斯的入局,華為引望愈發(fā)顯得引人矚目。

關鍵字: 阿維塔 塞力斯 華為

加利福尼亞州圣克拉拉縣2024年8月30日 /美通社/ -- 數(shù)字化轉(zhuǎn)型技術解決方案公司Trianz今天宣布,該公司與Amazon Web Services (AWS)簽訂了...

關鍵字: AWS AN BSP 數(shù)字化

倫敦2024年8月29日 /美通社/ -- 英國汽車技術公司SODA.Auto推出其旗艦產(chǎn)品SODA V,這是全球首款涵蓋汽車工程師從創(chuàng)意到認證的所有需求的工具,可用于創(chuàng)建軟件定義汽車。 SODA V工具的開發(fā)耗時1.5...

關鍵字: 汽車 人工智能 智能驅(qū)動 BSP

北京2024年8月28日 /美通社/ -- 越來越多用戶希望企業(yè)業(yè)務能7×24不間斷運行,同時企業(yè)卻面臨越來越多業(yè)務中斷的風險,如企業(yè)系統(tǒng)復雜性的增加,頻繁的功能更新和發(fā)布等。如何確保業(yè)務連續(xù)性,提升韌性,成...

關鍵字: 亞馬遜 解密 控制平面 BSP

8月30日消息,據(jù)媒體報道,騰訊和網(wǎng)易近期正在縮減他們對日本游戲市場的投資。

關鍵字: 騰訊 編碼器 CPU

8月28日消息,今天上午,2024中國國際大數(shù)據(jù)產(chǎn)業(yè)博覽會開幕式在貴陽舉行,華為董事、質(zhì)量流程IT總裁陶景文發(fā)表了演講。

關鍵字: 華為 12nm EDA 半導體

8月28日消息,在2024中國國際大數(shù)據(jù)產(chǎn)業(yè)博覽會上,華為常務董事、華為云CEO張平安發(fā)表演講稱,數(shù)字世界的話語權最終是由生態(tài)的繁榮決定的。

關鍵字: 華為 12nm 手機 衛(wèi)星通信

要點: 有效應對環(huán)境變化,經(jīng)營業(yè)績穩(wěn)中有升 落實提質(zhì)增效舉措,毛利潤率延續(xù)升勢 戰(zhàn)略布局成效顯著,戰(zhàn)新業(yè)務引領增長 以科技創(chuàng)新為引領,提升企業(yè)核心競爭力 堅持高質(zhì)量發(fā)展策略,塑強核心競爭優(yōu)勢...

關鍵字: 通信 BSP 電信運營商 數(shù)字經(jīng)濟

北京2024年8月27日 /美通社/ -- 8月21日,由中央廣播電視總臺與中國電影電視技術學會聯(lián)合牽頭組建的NVI技術創(chuàng)新聯(lián)盟在BIRTV2024超高清全產(chǎn)業(yè)鏈發(fā)展研討會上宣布正式成立。 活動現(xiàn)場 NVI技術創(chuàng)新聯(lián)...

關鍵字: VI 傳輸協(xié)議 音頻 BSP

北京2024年8月27日 /美通社/ -- 在8月23日舉辦的2024年長三角生態(tài)綠色一體化發(fā)展示范區(qū)聯(lián)合招商會上,軟通動力信息技術(集團)股份有限公司(以下簡稱"軟通動力")與長三角投資(上海)有限...

關鍵字: BSP 信息技術
關閉
關閉