日本黄色一级经典视频|伊人久久精品视频|亚洲黄色色周成人视频九九九|av免费网址黄色小短片|黄色Av无码亚洲成年人|亚洲1区2区3区无码|真人黄片免费观看|无码一级小说欧美日免费三级|日韩中文字幕91在线看|精品久久久无码中文字幕边打电话

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

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

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

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


前言


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


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


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

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


內存是如何泄露的


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



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

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

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


經驗 #1:盡量避免在堆上分配內存


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

然而,只在棧上分配內存,在有 IO 的情況下是存在一定局限性的。
舉個例子,為了完成一個請求,我們通常會為這個請求構造一個 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 對象的生命周期也就結束了。而 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 中調用 delete ctx,則就會觸發(fā)內存泄露。盡管我們可以借助一些靜態(tài)檢查工具對代碼進行檢查,但往往異步程序的邏輯是極其復雜的,一個請求的生命周期中,也需要進行大量的內存分配操作,靜態(tài)檢查工具往往無法發(fā)現(xiàn)所有的內存泄露情況。

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


經驗 #2:使用 Arena


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

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

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


經驗 #3:使用 Coroutine


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

有了多個棧,意味著當我們要做一個異步處理時,不需要釋放當前棧上的內存,而只需要切換到另一個棧上,就可以繼續(xù)做其他的事情了,當異步處理完成時,可以再切換回到這個棧上,將這個請求處理完成。
還是以剛才的代碼為示例:
   
void Foo(Reuqest* req) { RequestContext ctx(req); HandleRequest(&ctx);}
void HandleRequest(RequestCtx* ctx) { SubmitAsync(ctx); Coroutine::Self()->Yield(); CompleteRequest(ctx);}

這里的精髓在于,盡管 Coroutine::Self()->Yield() 被調用時,程序可以跳出 HandleRequest 函數(shù)去執(zhí)行其他代碼邏輯,但當前的棧卻被保存了下來,所以 ctx 對象是安全的,并沒有被釋放。

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

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

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

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

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


經驗 #4:善用 RAII


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

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

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

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

經驗 #5:便于 Debug


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

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

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


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

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

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


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

寫在最后

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

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

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

LED驅動電源的輸入包括高壓工頻交流(即市電)、低壓直流、高壓直流、低壓高頻交流(如電子變壓器的輸出)等。

關鍵字: 驅動電源

在工業(yè)自動化蓬勃發(fā)展的當下,工業(yè)電機作為核心動力設備,其驅動電源的性能直接關系到整個系統(tǒng)的穩(wěn)定性和可靠性。其中,反電動勢抑制與過流保護是驅動電源設計中至關重要的兩個環(huán)節(jié),集成化方案的設計成為提升電機驅動性能的關鍵。

關鍵字: 工業(yè)電機 驅動電源

LED 驅動電源作為 LED 照明系統(tǒng)的 “心臟”,其穩(wěn)定性直接決定了整個照明設備的使用壽命。然而,在實際應用中,LED 驅動電源易損壞的問題卻十分常見,不僅增加了維護成本,還影響了用戶體驗。要解決這一問題,需從設計、生...

關鍵字: 驅動電源 照明系統(tǒng) 散熱

根據LED驅動電源的公式,電感內電流波動大小和電感值成反比,輸出紋波和輸出電容值成反比。所以加大電感值和輸出電容值可以減小紋波。

關鍵字: LED 設計 驅動電源

電動汽車(EV)作為新能源汽車的重要代表,正逐漸成為全球汽車產業(yè)的重要發(fā)展方向。電動汽車的核心技術之一是電機驅動控制系統(tǒng),而絕緣柵雙極型晶體管(IGBT)作為電機驅動系統(tǒng)中的關鍵元件,其性能直接影響到電動汽車的動力性能和...

關鍵字: 電動汽車 新能源 驅動電源

在現(xiàn)代城市建設中,街道及停車場照明作為基礎設施的重要組成部分,其質量和效率直接關系到城市的公共安全、居民生活質量和能源利用效率。隨著科技的進步,高亮度白光發(fā)光二極管(LED)因其獨特的優(yōu)勢逐漸取代傳統(tǒng)光源,成為大功率區(qū)域...

關鍵字: 發(fā)光二極管 驅動電源 LED

LED通用照明設計工程師會遇到許多挑戰(zhàn),如功率密度、功率因數(shù)校正(PFC)、空間受限和可靠性等。

關鍵字: LED 驅動電源 功率因數(shù)校正

在LED照明技術日益普及的今天,LED驅動電源的電磁干擾(EMI)問題成為了一個不可忽視的挑戰(zhàn)。電磁干擾不僅會影響LED燈具的正常工作,還可能對周圍電子設備造成不利影響,甚至引發(fā)系統(tǒng)故障。因此,采取有效的硬件措施來解決L...

關鍵字: LED照明技術 電磁干擾 驅動電源

開關電源具有效率高的特性,而且開關電源的變壓器體積比串聯(lián)穩(wěn)壓型電源的要小得多,電源電路比較整潔,整機重量也有所下降,所以,現(xiàn)在的LED驅動電源

關鍵字: LED 驅動電源 開關電源

LED驅動電源是把電源供應轉換為特定的電壓電流以驅動LED發(fā)光的電壓轉換器,通常情況下:LED驅動電源的輸入包括高壓工頻交流(即市電)、低壓直流、高壓直流、低壓高頻交流(如電子變壓器的輸出)等。

關鍵字: LED 隧道燈 驅動電源
關閉