你踩过几种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 pObj = make_unique();
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 pArrayObjs = std::make_unique(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 m_pPreNode;
std::shared_ptr m_pNextNode;
int m_iVal;
};
void MemoryLeakLoopReference()
{
std::shared_ptr pFirstNode = std::make_shared(100);
std::shared_ptr pSecondNode = std::make_shared(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 m_pPreNode;
std::weak_ptr m_pNextNode;
int m_iVal;
};
void MemoryLeakLoopRefference()
{
std::shared_ptr pFirstNode = std::make_shared(100);
std::shared_ptr pSecondNode = std::make_shared(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:\test\doc.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:\test\doc.txt)",
GENERIC_READ,
FILE_SHARE_READ,
NULL,
OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL,
NULL);
std::unique_ptr< HANDLE, std::function> 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;
}
}