這篇文章給大家介紹C語言中出現(xiàn)內(nèi)存泄露如何解決，內(nèi)容非常詳細(xì)，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。
創(chuàng)新互聯(lián)公司長期為上千客戶提供的網(wǎng)站建設(shè)服務(wù)，團(tuán)隊(duì)從業(yè)經(jīng)驗(yàn)10年，關(guān)注不同地域、不同群體，并針對不同對象提供差異化的產(chǎn)品和服務(wù)；打造開放共贏平臺，與合作伙伴共同營造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為寧安企業(yè)提供專業(yè)的網(wǎng)站建設(shè)、網(wǎng)站設(shè)計(jì)，寧安網(wǎng)站改版等技術(shù)服務(wù)。擁有十余年豐富建站經(jīng)驗(yàn)和眾多成功案例,為您定制開發(fā)。
最近部門不同產(chǎn)品接連出現(xiàn)內(nèi)存泄漏導(dǎo)致的網(wǎng)上問題，具體表現(xiàn)為單板在現(xiàn)網(wǎng)運(yùn)行數(shù)月以后，因?yàn)閮?nèi)存耗盡而導(dǎo)致單板復(fù)位現(xiàn)象。一方面，內(nèi)存泄漏問題屬于低級錯誤，此類問題遺漏到現(xiàn)網(wǎng)，影響很壞；另一方面，由于內(nèi)存泄漏問題很可能導(dǎo)致單板運(yùn)行固定時(shí)間以后就復(fù)位，只能通過批量升級才能解決，實(shí)際影響也很惡劣。同時(shí)，接連出現(xiàn)此類問題，尤其是其中一例問題還是我們老員工修改引入，說明我們不少員工對內(nèi)存泄漏問題認(rèn)識還是不夠深刻的。本文通過介紹內(nèi)存泄漏問題原理及檢視方法，希望后續(xù)能夠從編碼檢視環(huán)節(jié)就杜絕此類問題發(fā)生。
說明：預(yù)防內(nèi)存泄漏問題有多種方法，如加強(qiáng)代碼檢視、工具檢測和內(nèi)存測試等，本文聚集于開發(fā)人員能力提升方面。
內(nèi)存泄漏問題只有在使用堆內(nèi)存的時(shí)候才會出現(xiàn)，棧內(nèi)存不存在內(nèi)存泄漏問題，因?yàn)闂?nèi)存會自動分配和釋放。C代碼中堆內(nèi)存的申請函數(shù)是malloc，常見的內(nèi)存申請代碼如下：
重慶分公司
重慶分公司
char *info = NULL; /**轉(zhuǎn)換后的字符串**/
info = (char*)malloc(NB_MEM_SPD_INFO_MAX_SIZE);
if( NULL == info)
{
(void)tdm_error("malloc error!\n");
return NB_SA_ERR_HPI_OUT_OF_MEMORY;
}由于malloc函數(shù)返回的實(shí)際上是一個(gè)內(nèi)存地址，所以保存堆內(nèi)存的變量一定是一個(gè)指針（除非代碼編寫極其不規(guī)范）。再重復(fù)一遍，保存堆內(nèi)存的變量一定是一個(gè)指針，這對本文主旨的理解很重要。當(dāng)然，這個(gè)指針可以是單指針，也可以是多重指針。
malloc函數(shù)有很多變種或封裝，如g_malloc、g_malloc0、VOS_Malloc等，這些函數(shù)最終都會調(diào)用malloc函數(shù)。
看到本小節(jié)標(biāo)題，可能有些同學(xué)有疑惑，上一小節(jié)中的malloc函數(shù)，不就是堆內(nèi)存的獲取方法嗎？的確是，通過malloc函數(shù)申請是最直接的獲取方法，如果只知道這種堆內(nèi)存獲取方法，就容易掉到坑里了。一般的來講，堆內(nèi)存有如下兩種獲取方法：
方法一：將函數(shù)返回值直接賦給指針，一般表現(xiàn)形式如下：
char *local_pointer_xx = NULL; local_pointer_xx = (char*)function_xx(para_xx, …);
該類涉及到內(nèi)存申請的函數(shù)，返回值一般都指針類型，例如：
GSList* g_slist_append (GSList *list, gpointer data)
方法二：將指針地址作為函數(shù)返回參數(shù)，通過返回參數(shù)保存堆內(nèi)存地址，一般表現(xiàn)形式如下：
int ret; char *local_pointer_xx = NULL; /**轉(zhuǎn)換后的字符串**/ ret = (char*)function_xx(..., &local_pointer_xx, ...);
該類涉及到內(nèi)存申請的函數(shù)，一般都有一個(gè)入?yún)⑹请p重指針，例如：
__STDIO_INLINE _IO_ssize_t getline (char **__lineptr, size_t *__n, FILE *__stream)
前面說通過malloc申請內(nèi)存，就屬于方法一的一個(gè)具體表現(xiàn)形式。其實(shí)這兩類方法的本質(zhì)是一樣的，都是函數(shù)內(nèi)部間接申請了內(nèi)存，只是傳遞內(nèi)存的方法不一樣，方法一通過返回值傳遞內(nèi)存指針，方法二通過參數(shù)傳遞內(nèi)存指針。
最常見的內(nèi)存泄漏問題，包含以下三個(gè)要素：
要素一：函數(shù)內(nèi)有局部指針變量定義；
要素二：對該局部指針有通過上一小節(jié)中“兩種堆內(nèi)存獲取方法”之一獲取內(nèi)存；
要素三：在函數(shù)返回前（含正常分支和異常分支）未釋放該內(nèi)存，也未保存到其它全局變量或返回給上一級函數(shù)。
稍微使用過C語言編寫代碼的人，都應(yīng)該知道堆內(nèi)存申請之后是需要釋放的。但為何還這么容易出現(xiàn)內(nèi)存泄漏問題呢？一方面，是開發(fā)人員經(jīng)驗(yàn)不足、意識不到位或一時(shí)疏忽導(dǎo)致；另一方面，是內(nèi)存釋放誤區(qū)導(dǎo)致。很多開發(fā)人員，認(rèn)為要釋放的內(nèi)存應(yīng)該局限于以下兩種：
1）直接使用內(nèi)存申請函數(shù)申請出來的內(nèi)存，如malloc、g_malloc等；
2）該開發(fā)人員熟悉的接口中，存在內(nèi)存申請的情況，如iBMC的兄弟，都應(yīng)該知道調(diào)用如下接口需要釋放list指向的內(nèi)存：
dfl_get_object_list(const char* class_name, GSList **list)
按照以上思維編寫代碼，一旦遇到不熟悉的接口中需要釋放內(nèi)存的問題，就完全沒有釋放內(nèi)存的意識，內(nèi)存泄漏問題就自然產(chǎn)生了。
檢視內(nèi)存泄漏問題，關(guān)鍵還是要養(yǎng)成良好的編碼檢視習(xí)慣。與內(nèi)存泄漏三要素對應(yīng)，需
要做到如下三點(diǎn)：
（1）在函數(shù)中看到有局部指針，就要警惕內(nèi)存泄漏問題，養(yǎng)成進(jìn)一步排查的習(xí)慣
（2）分析對局部指針的賦值操作，是否屬于前面所說的“兩種堆內(nèi)存獲取方法”之一，如果是，就要分析函數(shù)返回的指針到底指向啥？是全局?jǐn)?shù)據(jù)、靜態(tài)數(shù)據(jù)還是堆內(nèi)存？對于不熟悉的接口，要找到對應(yīng)的接口文檔或源代碼分析；又或者看看代碼中其它地方對該接口的引用，是否進(jìn)行了內(nèi)存釋放；
（3）如果確認(rèn)對局部指針存在內(nèi)存申請操作，就需要分析該內(nèi)存的去向，是會被保存在全局變量嗎？又或者會被作為函數(shù)返回值嗎？如果都不是，就需要排查函數(shù)所有有”return“的地方，保證內(nèi)存被正確釋放。
關(guān)于C語言中出現(xiàn)內(nèi)存泄露如何解決就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學(xué)到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。
