C++中的资源泄露问题

描述

在Modern C++之前,C++无疑是个更容易写出坑的语言,无论从开发效率,和易坑性,让很多新手望而却步。比如内存泄露问题,就是经常会被写出来的坑,本文就让我们一起来看看,这些让现在或者曾经的C++程序员泪流满面的内存泄露场景吧。你是否有踩过?

1. 函数内或者类成员内存未释放

这类问题可以称之为out of scope的时候,并没有释放相应对象的堆上内存。有时候最简单的场景,反而是最容易犯错的。这个我想主要是因为经常写,哪有不出错。下面场景一看就知道了,当你在写XXX_Class * pObj = new XXX_Class();这一行的时候,脑子里面还在默念记得要释放pObj ,记得要释放pObj, 可能因为重要的事情要说三遍,而你只喊了两遍,最终还是忘记了写delete pObj; 这样去释放对象。

void MemoryLeakFunction()

{

XXX_Class * pObj = new XXX_Class();

pObj-》DoSomething();

return;

}

下面这个场景,就是析构函数中并没有释放成员所指向的内存。这个我们就要注意了,一般当你构建一个类的时候,写析构函数一定要切记释放类成员关联的资源。

class MemoryLeakClass

{

public:

MemoryLeakClass()

{

m_pObj = new XXX_ResourceClass;

}

void DoSomething()

{

m_pObj-》DoSomething();

}

~MemoryLeakClass()

{

;

}

private:

XXX_ResourceClass* m_pObj;

};

上述这两种代码例子,是不是让一个C++工程师如履薄冰,完全看自己的大脑在不在状态。在boost或者C++ 11后,通过智能指针去进行包裹这个原始指针,这是一种RAII的思想(可以参阅本文末尾的关联阅读), 在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++关键字 (keyword), 就以这个语句为例做了两个操作:

调用了operator new从堆上申请所需的空间

调用XXX_Class的构造函数

那么当你调用delete pObj;的时候,道理同new,刚好相反:

调用了XXX_Class的析构函数

通过operator delete 释放了内存

一切似乎都没有什么问题,然后又一个坑来了。但如果申请的是一个数组呢,入下述例子:

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数组,那么调用不匹配的delete pArrayObjs;, 会产生内存泄露。先看看下图, 然后结合刚讲的delete的行为:

 

那么其实调用delete pArrayObjs;的时候,释放了整个pArrayObjs的内存,但是只调用了pArrayObjs[0]析构函数并释放中的m_pStr指向的内存。pArrayObjs 1~4并没有调用析构函数,从而导致其中的m_pStr指向的内存没有释放。所以我们要注意new和delete要匹配使用,当使用的new []申请的内存最好要用delete[]。那么留一个问题给读者, 上面代码delete m_pStr;会导致同样的问题吗?如果总是要让我们自己去保证,new和delete的配对,显然还是难以避免错误的发生的。这个时候也可以使用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*)

如果上一个章节已经有理解,那么对于这个例子,就很容易明白了。正因为C++的灵活性,有时候会将一个对象指针转换为void *,隐藏其类型。这种情况SDK比较常用,实际上返回的并不是SDK用的实际类型,而是一个没有类型的地址,当然有时候我们会为其亲切的取一个名字,比如叫做XXX_HANDLE。那么继续用上述为例MemoryLeakClass, SDK假设提供了下面三个接口:

InitObj创建一个对象,并且返回一个PROGRAMER_HANDLE(即void *),对应用程序屏蔽其实际类型

DoSomething 提供了一个功能去做一些事情,输入的参数,即为通过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;

}

看到这里,也许有读者已经发现问题所在了。上述代码在调用FreeObj的时候,delete看到的是一个void *, 只会释放对象所占用的内存,但是并不会调用对象的析构函数,那么对象内部的m_pStr所指向的内存并没有被释放,从而会导致内存泄露。修改也是自然比较简单的:

void FreeObj(void *pObj)

{

delete ((MemoryLeakClass*)pObj);

}

那么一般来说,最好由相对资深的程序员去进行SDK的开发,无论从设计和实现上面,都尽量避免了各种让人泪流满满的坑。

4. Virtual destructor

现在大家来看看这个很容易犯错的场景, 一个很常用的多态场景。那么在调用delete pObj;会出现内存泄露吗?

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没有设置Virtual 析构函数,那么在调用delete pObj;的时候会直接调用Father的析构函数,而不会调用Child的析构函数,这就导致了Child中的m_pStr所指向的内存,并没有被释放,从而导致了内存泄露。并不是绝对,当有这种使用场景的时候,最好是设置基类的析构函数为虚析构函数。修改如下:

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. 对象循环引用

看下面例子,既然为了防止内存泄露,于是使用了智能指针shared_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::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;

}

}

先来看看下图,是链表创建完成后的示意图。有点晕乎了,怎么一个双向链表画的这么复杂,黄色背景的均为智能指针或者智能指针的组成部分。其实根据双向链表的简单性和下图的复杂性,可以想到,智能指针的引入虽然提高了安全性,但是损失的是性能。所以往往安全性和性能是需要互相权衡的。 我们继续往下看,哪里内存泄露了呢?

 

如果函数退出,那么m_pFirstNode和m_pNextNode作为栈上局部变量,智能指针本身调用自己的析构函数,给引用的对象引用计数减去1(shared_ptr本质采用引用计数,当引用计数为0的时候,才会删除对象)。此时如下图所示,可以看到智能指针的引用计数仍然为1, 这也就导致了这两个节点的实际内存,并没有被释放掉, 从而导致内存泄露。

 

你可以在函数返回前手动调用pFirstNode-》m_pNextNode.reset();强制让引用计数减去1, 打破这个循环引用。

还是之前那句话,如果通过手动去控制难免会出现遗漏的情况, 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之后的链表结构如下图所示,weak_ptr只是对管理的对象做了一个弱引用,其并不会实际支配对象的释放与否,对象在引用计数为0的时候就进行了释放,而无需关心weak_ptr的weak计数。注意shared_ptr本身也会对weak计数加1.

那么在函数退出后,当pSecondNode调用析构函数的时候,对象的引用计数减一,引用计数为0,释放第二个Node,在释放第二个Node的过程中又调用了m_pPreNode的析构函数,第一个Node对象的引用计数减1,再加上pFirstNode析构函数对第一个Node对象的引用计数也减去1,那么第一个Node对象的引用计数也为0,第一个Node对象也进行了释放。

 

如果将上述代码改为双向循环链表,去除那个循环遍历Node的代码,那么最后Node的内存会被释放吗?这个问题留给读者。

6. 资源泄露

如果说些作文的话,这一章节,可能有点偏题了。本章要讲的是广义上的资源泄露,比如句柄或者fd泄露。这些也算是内存泄露的一点点扩展,写作文的一点点延伸吧。

看看下述例子, 其在操作完文件后,忘记调用CloseHandle(hFile);了,从而导致内存泄露。

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从而让其在函数退出后,直接调用CloseHandle(hFile);。C++智能指针提供了自定义deleter的功能,这就可以让我们使用这个deleter的功能,改写代码如下。不过本人更倾向于使用类似于golang defer的实现方式,读者可以参阅本文相关阅读部分。

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

打开APP阅读更多精彩内容
声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表电子发烧友网立场。文章及其配图仅供工程师学习之用,如有内容侵权或者其他违规问题,请联系本站处理。 举报投诉

全部0条评论

快来发表一下你的评论吧 !

×
20
完善资料,
赚取积分