专栏首页一个程序员的修炼之路你踩过几种C++内存泄露的坑?

你踩过几种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), 就以这个语句为例做了两个操作:

  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的行为:

那么其实调用delete pArrayObjs;的时候,释放了整个pArrayObjs的内存,但是只调用了pArrayObjs[0]析构函数并释放中的m_pStr指向的内存。pArrayObjs 1~4并没有调用析构函数,从而导致其中的m_pStr指向的内存没有释放。所以我们要注意newdelete要匹配使用,当使用的new []申请的内存最好要用delete[]

那么留一个问题给读者, 上面代码delete m_pStr;会导致同样的问题吗?

如果总是要让我们自己去保证,newdelete的配对,显然还是难以避免错误的发生的。这个时候也可以使用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;
  }
}

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

如果函数退出,那么m_pFirstNodem_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_ptrweak计数。注意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<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;
  }
}

7. 相关阅读

  1. <<从lock_guard来说一说C++中常用的RAII>>
  2. <<C++ RAII实现golang的defer>>

本文分享自微信公众号 - 一个程序员的修炼之路(CoderStudyShare),作者:河边一枝柳

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2021-08-16

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

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

    在Modern C++之前,C++无疑是个更容易写出坑的语言,无论从开发效率,和易坑性,让很多新手望而却步。比如内存泄露问题,就是经常会被写出来的坑,本文就让我...

    C语言与CPP编程
  • 常见内存错误

    C语言强大的原因之一在于几乎能掌控所有的细节,包括对内存的处理,什么时候使用内存,使用了多少内存,什么时候该释放内存,这都在程序员的掌控之中。而不像Java中,...

    编程珠玑
  • 某行小程序投标测试的思路和坑

    先发下牢骚吧,最近看FB里面的文章,大体上往底层概念越来越多,各种挖矿木马的,还有各种难理解的概念,都没有勇气点开看看了。

    FB客服
  • 【Rust日报】2020-08-04 — 内存泄漏:预防优于治疗

    内存泄漏并不是 Rust 语言要解决的问题,但是 Rust 语言也不大容易发生内存泄漏。

    MikeLoveRust
  • 颠覆认知——Redis会遇到的15个「坑」,你踩过几个?

    如果你在使用 Redis 时,也遇到过以下这些「诡异」的场景,那很大概率是踩到「坑」了:

    JAVA日知录
  • 小记最近踩得两个C++坑

    记一下最近踩得两个C++独有的暗坑,其中一个和ABI相关。第二个坑其实之前研究过,但是没有实例,这次算是碰到了个典型的实例。

    owent
  • Java架构师中的内存溢出和内存泄露是什么?实际操作案例!

    申请了内存用完了不释放,比如一共有 1024M 的内存,分配了 521M 的内存一直不回收,那么可以用的内存只有 521M 了,仿佛泄露掉了一部分;

    Java架构师进阶技术
  • 你需要认真对待warning,不然......

    作者介绍:olivialu,架构平台部质量组员工,测试妹子两年来摸爬滚打、踩坑无数,努力从细微处发现问题、提升测试思路和方法,通过构建测试工具,让每个BUG无所...

    腾讯技术工程官方号
  • 学好 C/C++,走遍天下都不怕

    与 Java、Python 等语言相比,C/C++ 语言是离操作系统更近的一种高级语言,因此其执行效率也更高。可以说,就像武侠小说中的“九阳神功”一样,C/C+...

    CSDN技术头条
  • Golang 需要避免踩的 50 个坑(三)

    Go 是一门简单有趣的编程语言,与其他语言一样,在使用时不免会遇到很多坑,不过它们大多不是 Go 本身的设计缺陷。如果你刚从其他语言转到 Go,那这篇文章里的坑...

    aoho求索
  • C#学习系列之人脸识别控制台接口调用

    要想使用C#的人脸识别控制台,对于没有使用过的朋友,可能会遇到比较多的坑,所以我这里就先去踩了坑,趁着这段时间,把能直接运行的步骤告诉大家。

    算法发
  • 北理工研究生被爆公然抄袭?旷视研究员列出「实锤」,相似度近100%

    原作者发文「在arxiv上看到自己的投稿署了别人的名字是什么体验?」,在文中对比并指出高度一致的内容。

    新智元
  • 【团队分享】苍翼之刃:论File Descriptor泄漏如何导致Crash?

    这一期的团队分享,我们特邀苍翼之刃的开发负责人Jay,为大家分享在Android项目中遇到的一些Crash。 苍翼之刃 外文:BlazBlue Revolut...

    腾讯Bugly
  • 注意!JWT不是万能的,入坑需谨慎!

    越来越多的开发者开始学习 JWT 技术并在实际项目中运用 JWT 来保护应用安全。一时间,JWT 技术风光无限,很多公司的应用程序也开始使用 JWT(Json...

    用户1516716
  • 注意!JWT不是万能的,入坑需谨慎!

    任何技术框架都有自身的局限性,不可能一劳永逸,JWT 也不例外。接下来,将从 JWT 的概念,基本原理和适用范围来剖析为什么说 JWT 不是银弹,需要谨慎处理。

    Bug开发工程师
  • 案例分享 | dubbo 2.7.12 bug导致线上故障

    最近某天的深夜,刚洗完澡就接到业务方打来电话,说他们的 dubbo 服务出故障了,要我协助排查一下。

    龟仙老人
  • 【JVM进阶之路】四:直面内存溢出和内存泄漏

    在JVM的几个内存区域中,除了程序计数器外,其他几个运行时区域都有发生内存溢出(OOM)异常的可能。

    三分恶
  • 【前端监控】自动抓取接口请求数据

    今天要写的是前端监控SDK的自动抓取接口请求数据。内容不复杂,但是其中会涉及很多细节,不然会踩坑。废话不多说

    神仙朱
  • 买知识,也别冲动消费

    其实知识本来就值钱。咨询专家给普通人的印象就是西装革履、坐头等舱、住五星酒店。他们卖的是什么?知识。

    王树义

扫码关注云+社区

领取腾讯云代金券