在Modern C++之前,C++無疑是個更容易寫出坑的語言,無論從開發(fā)效率,和易坑性,讓很多新手望而卻步。比如內(nèi)存泄露問題,就是經(jīng)常會被寫出來的坑,本文就讓我們一起來看看,這些讓現(xiàn)在或者曾經(jīng)的C++程序員淚流滿面的內(nèi)存泄露場景吧。你是否有踩過?
1. 函數(shù)內(nèi)或者類成員內(nèi)存未釋放
這類問題可以稱之為out of scope的時候,并沒有釋放相應對象的堆上內(nèi)存。有時候最簡單的場景,反而是最容易犯錯的。這個我想主要是因為經(jīng)常寫,哪有不出錯。下面場景一看就知道了,當你在寫XXX_Class * pObj = new XXX_Class();這一行的時候,腦子里面還在默念記得要釋放pObj ,記得要釋放pObj, 可能因為重要的事情要說三遍,而你只喊了兩遍,最終還是忘記了寫delete pObj; 這樣去釋放對象。
{
XXX_Class * pObj = new XXX_Class();
pObj-》DoSomething();
return;
}
下面這個場景,就是析構(gòu)函數(shù)中并沒有釋放成員所指向的內(nèi)存。這個我們就要注意了,一般當你構(gòu)建一個類的時候,寫析構(gòu)函數(shù)一定要切記釋放類成員關(guān)聯(lián)的資源。
class MemoryLeakClass
{
public:
MemoryLeakClass()
{
m_pObj = new XXX_ResourceClass;
}
void DoSomething()
{
m_pObj-》DoSomething();
}
~MemoryLeakClass()
{
;
}
private:
XXX_ResourceClass* m_pObj;
};
上述這兩種代碼例子,是不是讓一個C++工程師如履薄冰,完全看自己的大腦在不在狀態(tài)。在boost或者C++ 11后,通過智能指針去進行包裹這個原始指針,這是一種RAII的思想(可以參閱本文末尾的關(guān)聯(lián)閱讀), 在out of scope的時候,釋放自己所包裹的原始指針指向的資源。將上述例子用unique_ptr改寫一下。
void MemoryLeakFunction()
{
std::unique_ptr《XXX_Class》 pObj = make_unique《XXX_Class》();
pObj-》DoSomething();
return;
}
2. delete []
大家知道C++中這樣一個語句XXX_Class * pObj = new XXX_Class(); 中的new我們一般稱其為C++關(guān)鍵字 (keyword), 就以這個語句為例做了兩個操作:
調(diào)用了operator new從堆上申請所需的空間
調(diào)用XXX_Class的構(gòu)造函數(shù)
那么當你調(diào)用delete pObj;的時候,道理同new,剛好相反:
調(diào)用了XXX_Class的析構(gòu)函數(shù)
通過operator delete 釋放了內(nèi)存
一切似乎都沒有什么問題,然后又一個坑來了。但如果申請的是一個數(shù)組呢,入下述例子:
class MemoryLeakClass
{public:
MemoryLeakClass()
{
m_pStr = new char[100];
}
void DoSomething()
{
strcpy_s(m_pStr, 100, “Hello Memory Leak!”);
std::cout 《《 m_pStr 《《 std::endl;
}
~MemoryLeakClass()
{
delete m_pStr;
}
private:
char *m_pStr;
};
void MemoryLeakFunction()
{
const int iSize = 5;
MemoryLeakClass* pArrayObjs = new MemoryLeakClass [iSize];
for (int i = 0; i 《 iSize; i++)
{
(pArrayObjs+i)-》DoSomething();
}
delete pArrayObjs;
}
上述例子通過MemoryLeakClass* pArrayObjs = new MemoryLeakClass [iSize];申請了一個MemoryLeakClass數(shù)組,那么調(diào)用不匹配的delete pArrayObjs;, 會產(chǎn)生內(nèi)存泄露。先看看下圖, 然后結(jié)合剛講的delete的行為:
那么其實調(diào)用delete pArrayObjs;的時候,釋放了整個pArrayObjs的內(nèi)存,但是只調(diào)用了pArrayObjs[0]析構(gòu)函數(shù)并釋放中的m_pStr指向的內(nèi)存。pArrayObjs 1~4并沒有調(diào)用析構(gòu)函數(shù),從而導致其中的m_pStr指向的內(nèi)存沒有釋放。所以我們要注意new和delete要匹配使用,當使用的new []申請的內(nèi)存最好要用delete[]。那么留一個問題給讀者, 上面代碼delete m_pStr;會導致同樣的問題嗎?如果總是要讓我們自己去保證,new和delete的配對,顯然還是難以避免錯誤的發(fā)生的。這個時候也可以使用unique_ptr, 修改如下:
void MemoryLeakFunction()
{
const int iSize = 5;
std::unique_ptr《MemoryLeakClass[]》 pArrayObjs = std::make_unique《MemoryLeakClass[]》(iSize);
for (int i = 0; i 《 iSize; i++)
{
(pArrayObjs.get()+i)-》DoSomething();
}
}
3. delete (void*)
如果上一個章節(jié)已經(jīng)有理解,那么對于這個例子,就很容易明白了。正因為C++的靈活性,有時候會將一個對象指針轉(zhuǎn)換為void *,隱藏其類型。這種情況SDK比較常用,實際上返回的并不是SDK用的實際類型,而是一個沒有類型的地址,當然有時候我們會為其親切的取一個名字,比如叫做XXX_HANDLE。那么繼續(xù)用上述為例MemoryLeakClass, SDK假設(shè)提供了下面三個接口:
InitObj創(chuàng)建一個對象,并且返回一個PROGRAMER_HANDLE(即void *),對應用程序屏蔽其實際類型
DoSomething 提供了一個功能去做一些事情,輸入的參數(shù),即為通過InitObj申請的對象
應用程序使用完畢后,一般需要釋放SDK申請的對象,提供了FreeObj
typedef void * PROGRAMER_HANDLE;
PROGRAMER_HANDLE InitObj()
{
MemoryLeakClass* pObj = new MemoryLeakClass();
return (PROGRAMER_HANDLE)pObj;
}
void DoSomething(PROGRAMER_HANDLE pHandle)
{
((MemoryLeakClass*)pHandle)-》DoSomething();
}
void FreeObj(void *pObj)
{
delete pObj;
}
看到這里,也許有讀者已經(jīng)發(fā)現(xiàn)問題所在了。上述代碼在調(diào)用FreeObj的時候,delete看到的是一個void *, 只會釋放對象所占用的內(nèi)存,但是并不會調(diào)用對象的析構(gòu)函數(shù),那么對象內(nèi)部的m_pStr所指向的內(nèi)存并沒有被釋放,從而會導致內(nèi)存泄露。修改也是自然比較簡單的:
void FreeObj(void *pObj)
{
delete ((MemoryLeakClass*)pObj);
}
那么一般來說,最好由相對資深的程序員去進行SDK的開發(fā),無論從設(shè)計和實現(xiàn)上面,都盡量避免了各種讓人淚流滿滿的坑。
4. Virtual destructor
現(xiàn)在大家來看看這個很容易犯錯的場景, 一個很常用的多態(tài)場景。那么在調(diào)用delete pObj;會出現(xiàn)內(nèi)存泄露嗎?
class Father
{public:
virtual void DoSomething()
{
std::cout 《《 “Father DoSomething()” 《《 std::endl;
}
};
class Child : public Father
{
public:
Child()
{
std::cout 《《 “Child()” 《《 std::endl;
m_pStr = new char[100];
}
~Child()
{
std::cout 《《 “~Child()” 《《 std::endl;
delete[] m_pStr;
}
void DoSomething()
{
std::cout 《《 “Child DoSomething()” 《《 std::endl;
}
protected:
char* m_pStr;
};
void MemoryLeakVirualDestructor()
{
Father * pObj = new Child;
pObj-》DoSomething();
delete pObj;
}
會的,因為Father沒有設(shè)置Virtual 析構(gòu)函數(shù),那么在調(diào)用delete pObj;的時候會直接調(diào)用Father的析構(gòu)函數(shù),而不會調(diào)用Child的析構(gòu)函數(shù),這就導致了Child中的m_pStr所指向的內(nèi)存,并沒有被釋放,從而導致了內(nèi)存泄露。并不是絕對,當有這種使用場景的時候,最好是設(shè)置基類的析構(gòu)函數(shù)為虛析構(gòu)函數(shù)。修改如下:
class Father
{public:
virtual void DoSomething()
{
std::cout 《《 “Father DoSomething()” 《《 std::endl;
}
virtual ~Father() { ; }
};
class Child : public Father
{
public:
Child()
{
std::cout 《《 “Child()” 《《 std::endl;
m_pStr = new char[100];
}
virtual ~Child()
{
std::cout 《《 “~Child()” 《《 std::endl;
delete[] m_pStr;
}
void DoSomething()
{
std::cout 《《 “Child DoSomething()” 《《 std::endl;
}
protected:
char* m_pStr;
};
5. 對象循環(huán)引用
看下面例子,既然為了防止內(nèi)存泄露,于是使用了智能指針shared_ptr;并且這個例子就是創(chuàng)建了一個雙向鏈表,為了簡單演示,只有兩個節(jié)點作為演示,創(chuàng)建了鏈表后,對鏈表進行遍歷。
那么這個例子會導致內(nèi)存泄露嗎?
struct Node
{
Node(int iVal)
{
m_iVal = iVal;
}
~Node()
{
std::cout 《《 “~Node(): ” 《《 “Node Value: ” 《《 m_iVal 《《 std::endl;
}
void PrintNode()
{
std::cout 《《 “Node Value: ” 《《 m_iVal 《《 std::endl;
}
std::shared_ptr《Node》 m_pPreNode;
std::shared_ptr《Node》 m_pNextNode;
int m_iVal;
};
void MemoryLeakLoopReference()
{
std::shared_ptr《Node》 pFirstNode = std::make_shared《Node》(100);
std::shared_ptr《Node》 pSecondNode = std::make_shared《Node》(200);
pFirstNode-》m_pNextNode = pSecondNode;
pSecondNode-》m_pPreNode = pFirstNode;
//Iterate nodes
auto pNode = pFirstNode;
while (pNode)
{
pNode-》PrintNode();
pNode = pNode-》m_pNextNode;
}
}
先來看看下圖,是鏈表創(chuàng)建完成后的示意圖。有點暈乎了,怎么一個雙向鏈表畫的這么復雜,黃色背景的均為智能指針或者智能指針的組成部分。其實根據(jù)雙向鏈表的簡單性和下圖的復雜性,可以想到,智能指針的引入雖然提高了安全性,但是損失的是性能。所以往往安全性和性能是需要互相權(quán)衡的。 我們繼續(xù)往下看,哪里內(nèi)存泄露了呢?
如果函數(shù)退出,那么m_pFirstNode和m_pNextNode作為棧上局部變量,智能指針本身調(diào)用自己的析構(gòu)函數(shù),給引用的對象引用計數(shù)減去1(shared_ptr本質(zhì)采用引用計數(shù),當引用計數(shù)為0的時候,才會刪除對象)。此時如下圖所示,可以看到智能指針的引用計數(shù)仍然為1, 這也就導致了這兩個節(jié)點的實際內(nèi)存,并沒有被釋放掉, 從而導致內(nèi)存泄露。
你可以在函數(shù)返回前手動調(diào)用pFirstNode-》m_pNextNode.reset();強制讓引用計數(shù)減去1, 打破這個循環(huán)引用。
還是之前那句話,如果通過手動去控制難免會出現(xiàn)遺漏的情況, C++提供了weak_ptr。
struct Node
{
Node(int iVal)
{
m_iVal = iVal;
}
~Node()
{
std::cout 《《 “~Node(): ” 《《 “Node Value: ” 《《 m_iVal 《《 std::endl;
}
void PrintNode()
{
std::cout 《《 “Node Value: ” 《《 m_iVal 《《 std::endl;
}
std::shared_ptr《Node》 m_pPreNode;
std::weak_ptr《Node》 m_pNextNode;
int m_iVal;
};
void MemoryLeakLoopRefference()
{
std::shared_ptr《Node》 pFirstNode = std::make_shared《Node》(100);
std::shared_ptr《Node》 pSecondNode = std::make_shared《Node》(200);
pFirstNode-》m_pNextNode = pSecondNode;
pSecondNode-》m_pPreNode = pFirstNode;
//Iterate nodes
auto pNode = pFirstNode;
while (pNode)
{
pNode-》PrintNode();
pNode = pNode-》m_pNextNode.lock();
}
}
看看使用了weak_ptr之后的鏈表結(jié)構(gòu)如下圖所示,weak_ptr只是對管理的對象做了一個弱引用,其并不會實際支配對象的釋放與否,對象在引用計數(shù)為0的時候就進行了釋放,而無需關(guān)心weak_ptr的weak計數(shù)。注意shared_ptr本身也會對weak計數(shù)加1.
那么在函數(shù)退出后,當pSecondNode調(diào)用析構(gòu)函數(shù)的時候,對象的引用計數(shù)減一,引用計數(shù)為0,釋放第二個Node,在釋放第二個Node的過程中又調(diào)用了m_pPreNode的析構(gòu)函數(shù),第一個Node對象的引用計數(shù)減1,再加上pFirstNode析構(gòu)函數(shù)對第一個Node對象的引用計數(shù)也減去1,那么第一個Node對象的引用計數(shù)也為0,第一個Node對象也進行了釋放。
如果將上述代碼改為雙向循環(huán)鏈表,去除那個循環(huán)遍歷Node的代碼,那么最后Node的內(nèi)存會被釋放嗎?這個問題留給讀者。
6. 資源泄露
如果說些作文的話,這一章節(jié),可能有點偏題了。本章要講的是廣義上的資源泄露,比如句柄或者fd泄露。這些也算是內(nèi)存泄露的一點點擴展,寫作文的一點點延伸吧。
看看下述例子, 其在操作完文件后,忘記調(diào)用CloseHandle(hFile);了,從而導致內(nèi)存泄露。
void MemroyLeakFileHandle()
{
HANDLE hFile = CreateFile(LR“(C: estdoc.txt)”,
GENERIC_READ,
FILE_SHARE_READ,
NULL,
OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL,
NULL);
if (INVALID_HANDLE_VALUE == hFile)
{
std::cerr 《《 “Open File error!” 《《 std::endl;
return;
}
const int BUFFER_SIZE = 100;
char pDataBuffer[BUFFER_SIZE];
DWORD dwBufferSize;
if (ReadFile(hFile,
pDataBuffer,
BUFFER_SIZE,
&dwBufferSize,
NULL))
{
std::cout 《《 dwBufferSize 《《 std::endl;
}
}
上述你可以用RAII機制去封裝hFile從而讓其在函數(shù)退出后,直接調(diào)用CloseHandle(hFile);。C++智能指針提供了自定義deleter的功能,這就可以讓我們使用這個deleter的功能,改寫代碼如下。不過本人更傾向于使用類似于golang defer的實現(xiàn)方式,讀者可以參閱本文相關(guān)閱讀部分。
void MemroyLeakFileHandle()
{
HANDLE hFile = CreateFile(LR“(C: estdoc.txt)”,
GENERIC_READ,
FILE_SHARE_READ,
NULL,
OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL,
NULL);
std::unique_ptr《 HANDLE, std::function《void(HANDLE*)》》 phFile(
&hFile,
[](HANDLE* pHandle) {
if (nullptr != pHandle)
{
std::cout 《《 “Close Handle” 《《 std::endl;
CloseHandle(*pHandle);
}
});
if (INVALID_HANDLE_VALUE == *phFile)
{
std::cerr 《《 “Open File error!” 《《 std::endl;
return;
}
const int BUFFER_SIZE = 100;
char pDataBuffer[BUFFER_SIZE];
DWORD dwBufferSize;
if (ReadFile(*phFile,
pDataBuffer,
BUFFER_SIZE,
&dwBufferSize,
NULL))
{
std::cout 《《 dwBufferSize 《《 std::endl;
}
}
責任編輯:haq
-
內(nèi)存
+關(guān)注
關(guān)注
8文章
3048瀏覽量
74209 -
函數(shù)
+關(guān)注
關(guān)注
3文章
4345瀏覽量
62864 -
C++
+關(guān)注
關(guān)注
22文章
2114瀏覽量
73784
原文標題:6. 資源泄露
文章出處:【微信號:LinuxHub,微信公眾號:Linux愛好者】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。
發(fā)布評論請先 登錄
相關(guān)推薦
評論