這些C++ 內存泄露的坑你踩過幾種?

2021年09月11日17:56:01 科技 1220

推薦視頻:

這些C++ 內存泄露的坑你踩過幾種? - 天天要聞

那麼其實調用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();
  }
}

【文章福利】需要C/C++ Linux伺服器架構師學習資料加群812855908(資料包括C/C++,Linux,golang技術,內核,Nginx,ZeroMQ,MySQL,Redis,fastdfs,MongoDB,ZK,流媒體,CDN,P2P,K8S,Docker,TCP/IP,協程,DPDK,ffmpeg等)

這些C++ 內存泄露的坑你踩過幾種? - 天天要聞

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;
  }
}

先來看看下圖,是鏈表創建完成後的示意圖。有點暈乎了,怎麼一個雙向鏈表畫的這麼複雜,黃色背景的均為智能指針或者智能指針的組成部分。其實根據雙向鏈表的簡單性和下圖的複雜性,可以想到,智能指針的引入雖然提高了安全性,但是損失的是性能。所以往往安全性和性能是需要互相權衡的。 我們繼續往下看,哪裡內存泄露了呢?

這些C++ 內存泄露的坑你踩過幾種? - 天天要聞


如果函數退出,那麼m_pFirstNode和m_pNextNode作為棧上局部變數,智能指針本身調用自己的析構函數,給引用的對象引用計數減去1(shared_ptr本質採用引用計數,當引用計數為0的時候,才會刪除對象)。此時如下圖所示,可以看到智能指針的引用計數仍然為1, 這也就導致了這兩個節點的實際內存,並沒有被釋放掉, 從而導致內存泄露。

這些C++ 內存泄露的坑你踩過幾種? - 天天要聞

你可以在函數返回前手動調用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對象也進行了釋放。

這些C++ 內存泄露的坑你踩過幾種? - 天天要聞


如果將上述代碼改為雙向循環鏈表,去除那個循環遍歷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;
  }
}

科技分類資訊推薦

蘋果8月1日凌晨發布第三財季財報 預計營收環比下滑 - 天天要聞

蘋果8月1日凌晨發布第三財季財報 預計營收環比下滑

【TechWeb】7月7日消息,據外媒報道,隨著二季度落下帷幕,各大公司新一季度的財報也就提上了日程,蘋果公司就已在官網宣布,他們將在當地時間7月31日美國股市收盤後,也就是北京時間8月1日凌晨,發布截至6月底的2025財年第三財季的財報。在財報發布之後,蘋果隨後就將舉行財報分析師電話會議。蘋果公司第三財季的財報分析...
更大更適合家用,鈦7或成方程豹下一個銷量增長極 - 天天要聞

更大更適合家用,鈦7或成方程豹下一個銷量增長極

日前,方程豹旗下全新車型——鈦7登陸工信部新車申報目錄,迅速引起了業內外的高度關注和廣泛熱議。據最新銷量數據顯示,6月方程豹汽車依舊熱銷,銷量超1.8萬台,環比大增50.1%,鈦3更是熱銷了超1.2萬台,成為A級純電SUV爆款選手。數據一出,不少網友評論:「方
大車身長軸距更適合家用,方程豹鈦7或錨定30萬 - 天天要聞

大車身長軸距更適合家用,方程豹鈦7或錨定30萬

日前,方程豹旗下全新車型——鈦7登陸工信部新車申報目錄,迅速引起了業內外的高度關注和廣泛熱議。據最新銷量數據顯示,6月方程豹汽車依舊熱銷,銷量超1.8萬台,環比大增50.1%,鈦3更是熱銷了超1.2萬台,成為A級純電SUV爆款選手。數據一出,不少網友評論:「方
金士頓 M.2 2230 短款 NV3 固態硬碟上市,標價高於 2280 版本 - 天天要聞

金士頓 M.2 2230 短款 NV3 固態硬碟上市,標價高於 2280 版本

IT之家 7 月 7 日消息,金士頓在 2024 年 9 月推出了 M.2 2280 外形規格的新一代入門級客戶端 PCIe 4.0 固態硬碟 NV3。如今這一 SSD 採用 M.2 2230 尺寸的短款也已上市,定價相較同容量的 2280 版本更高。由於外形設計不同,M.2 2230 版的 NV3 不再提供 4TB 容量點,可選 500GB、1TB、2TB
「廠二代」升級「創一代」,義烏小商品如何借新電商轉型? - 天天要聞

「廠二代」升級「創一代」,義烏小商品如何借新電商轉型?

義烏號稱「世界小商品之都」,以塑料為核心原材料製成的家庭日用品銷往全球。但歷經三四十年的產業發展,當地日用品已進入高度的同質化競爭階段,這導致商家的利潤逐漸被攤薄。如何才能跳出同質化競爭?近兩年,隨著拼多多推出新質商家計劃,不少義烏商家在平台扶持下紛紛求變,開始進行產品和技術創新,並取得了成功。近日...
小米與徠卡即將終止合作?小米官方回應了 - 天天要聞

小米與徠卡即將終止合作?小米官方回應了

【TechWeb】7月7日消息,近日有傳聞稱小米與徠卡的合作關係即將結束,對此,小米公關總經理王化在社交媒體上進行了回應。王化表示:「上次是 2023 年 6 月 1 日,番茄發了個微博說小米 14 就是最後一代了。我轉發了文案搭配的是「這就胡說了」,這次居然進階了,來了個據報道,還有作者…… 我的回復也需要進階,請大家笑納...