你踩过几种C++内存泄露的坑？

素颜马尾好姑娘i 2022-08-28 05:50 280阅读 0赞

![2b2b6daaea3f9507e1027f89e11071b1.png][]

在`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`), 就以这个语句为例做了两个操作:

1.  调用了`operator new`从堆上申请所需的空间
2.  调用`XXX_Class`的构造函数

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

1.  调用了`XXX_Class`的析构函数
2.  通过`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`的行为：  
![aaeacc01ca048b28c61503f9fed93373.png][]

那么其实调用`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假设提供了下面三个接口:

1.  `InitObj`创建一个对象，并且返回一个`PROGRAMER_HANDLE`(即`void *`)，对应用程序屏蔽其实际类型
2.  `DoSomething` 提供了一个功能去做一些事情，输入的参数，即为通过`InitObj`申请的对象
3.  应用程序使用完毕后，一般需要释放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;
      }
    }

先来看看下图，是链表创建完成后的示意图。有点晕乎了，怎么一个双向链表画的这么复杂，黄色背景的均为智能指针或者智能指针的组成部分。其实根据双向链表的简单性和下图的复杂性，可以想到，智能指针的引入虽然提高了安全性，但是损失的是性能。所以往往安全性和性能是需要互相权衡的。 我们继续往下看，哪里内存泄露了呢？  
![548ba7e8993c67cbecae48a8f8cd1d5a.png][]  
如果函数退出，那么`m_pFirstNode`和`m_pNextNode`作为栈上局部变量，智能指针本身调用自己的析构函数，给引用的对象引用计数减去1(`shared_ptr`本质采用引用计数，当引用计数为0的时候，才会删除对象)。此时如下图所示，可以看到智能指针的引用计数仍然为1， 这也就导致了这两个节点的实际内存，并没有被释放掉， 从而导致内存泄露。  
![7382d013cd0f5780b52faf3bad3cb4c3.png][]  
你可以在函数返回前手动调用`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对象也进行了释放。  
![5418f155ea44b94db279e16544f457f9.png][]  
如果将上述代码改为双向循环链表，去除那个循环遍历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<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;
      }
    }

[2b2b6daaea3f9507e1027f89e11071b1.png]: /images/20220828/d4973c3468894d6cbc93941c64eb3303.png
[aaeacc01ca048b28c61503f9fed93373.png]: /images/20220828/92455ea31de54484a79bb92f059faf58.png
[548ba7e8993c67cbecae48a8f8cd1d5a.png]: /images/20220828/801c448217df4b16a79abbcffef81c46.png
[7382d013cd0f5780b52faf3bad3cb4c3.png]: /images/20220828/40036e5e5f854a53bcf9796f9fbc4408.png
[5418f155ea44b94db279e16544f457f9.png]: /images/20220828/ac07c6dfc540480eadc39c47feba1b82.png