怎么解决内存泄漏问题

本文介绍了“如何解决内存泄漏问题”的知识。很多人在实际案例的操作中会遇到这样的困难。让边肖带领你学习如何处理这些情况。希望大家认真阅读，学点东西！

问题排查

首先，确定内存泄漏发生的时间，发现此时线上有两个代码提交，其中一个是我的。于是我立刻检查了这两个代码的变化，确定了另一个同事的代码不可能有内存问题(因为另一个同事的上线只是修改了配置)，我知道我自己的代码肯定有问题。

确定问题后，快速回滚自己的代码，就可以放心调试了。

Debug

什么是内存泄漏？

简单来说，程序员应用的内存在使用后并没有返回操作系统。由于作者使用C语言，内存泄漏一般是这样的：

obj * o=new obj()；//使用obj后未删除。一定有一些地方申请了内存，没有调用delete来释放内存。

这里简单介绍一下作者的代码修改。我的任务实际上是重构一段代码并将其并行化。也就是旧的逻辑是在一个线程中串行执行的，现在我想把这个逻辑放到两个线程中并行执行，这是最麻烦的任务之一，并行化转换容易引起bug。

接下来，我梳理了上节课所有记忆的应用和释放，包括：

使用new/delete分配释放的内存。

使用内存池来分配释放的内存。

仔细梳理了一下，没有发现问题，所有应该释放的内存都释放了。这时，作者已经开始怀疑自己的人生(:)。很明显，某个版块有他没有注意到的问题，这是不可避免的。虽然我知道问题必然会出现在这些修改后的代码中，但我不确定它会出现在哪里。

没有办法，基本上我在这里不得不放弃自己的人工调试，我想用一些内存检测工具来帮助我识别问题。

常见的内存泄漏检测工具包括valgrind、gperftools等。valgrind的优点是不需要重新编译代码就能检测内存，缺点是会让程序运行非常慢，官方文件说会比正常程序慢20-30倍。Gperftools需要重新编译可执行程序。这些工具需要下载、安装、测试，还涉及申请机器权限等问题，我觉得还是比较麻烦的。况且这个问题不像大海捞针，问题肯定出在并行化的代码上。

在这里，我决定寻找另一种解决问题的方法。由于代码在重构后开始并行执行，问题的高概率是由于多线程。遇到多线程时，首先要关注的是线程间的共享数据。

多线程问题的关键mdash;mdash;共享数据

我们知道，如果线程之间没有共享数据，就不会出现线安全问题。我们使用的锁、信号量和条件变量实际上是用来保护共享数据的。例如，锁通常用于包含关键区域，关键区域中的代码在共享数据的线程上运行。信号量使用的一个经典场景是生产者-消费者问题。生产者线程和消费者线程都操作同一个队列，其中队列是共享数据。

沿着这个思路，我开始寻找两个线程中使用的共享数据。果然，我在一个角落里发现了这段代码：

auto * pb=全局可变_ obj()；这是一段分配protobuf对象的代码。protobuf由Google开发，是一种类似于JSON和XML的技术，因此经常用于网络通信和数据交换场景，比如RPC。

不了解protobuf也没关系。事实上，上面的代码应该是这样的：

if(global-obj==NULL){ global-obj=new obj()；} return global-obj；值得注意的是，这段代码现在将在两个线程中执行，这就是明显的问题所在。

那么问题是如何产生的呢？

让我们假设有两个线程，线程A和线程b，当这样一段代码在线程AB中同时执行时，可能会出现以下情况：

线程A获取global-obj，并检测到此时global-obj为空，因此决定为其分配内存。不幸的是，此时会发生线程切换，线程A在为global-obj分配内存之前被挂起，如下所示。

If(global-obj==NULL){ -

      global->obj = new obj();  }  return global->obj;

•  线程A被暂停运行后线程B开始执行，这段代码同样会在线程B中执行一遍，因此线程B会首先检查global->obj发现为空，因此为global->obj分配内存，分配完内存后发生线程切换，线程B被暂停运行，如下所示： 

if (global->obj == NULL) {      global->obj = new obj();      <------- 线程切换，线程B被暂停执行   }  return global->obj;

• 线程B被暂停运行后调度器决定重新运行线程A，此时线程A开始从被中断的地方继续运行，还记得线程A是从哪里被中断的吗，没错，就是在为global->obj分配内存前被中断的，此时线程A继续运行，也就是说global->obj = new obj()这段代码又被执行了一次，虽然线程B已经为global->obj分配了内存。

Oops，典型的内存泄漏，线程B分配的内存再也无法被正常释放掉了。

至此，我们已经找到了问题的原因，罪魁祸首就是共享数据，关键的一点是要意识到你的线程会随时被中断执行，CPU会随时切换到其它线程。

代码修复也非常简单，再新增一个变量，两个线程不在使用共享数据，到这里问题就解决了，从发现问题到完成修复耗时大概4小时。

经验教训

代码的并行化重构是一件非常棘手的任务，很容易出现线程安全问题，解决线程安全问题首先要考虑的不是要不要加锁，而是多个线程是否真的有必要使用共享数据，没有必要的话多个线程操作私有数据根本就不会出现线程安全问题。

当出现线程安全问题时，第一时间重点排查线程使用的共享数据。

内存泄漏检测工具

虽然这些没有使用检测工具全靠人肉debug其实还是因为问题排查范围比较小，如果我们根本就不知道问题出现在了那次代码改动那么检测工具就非常重要了，在这里简单介绍一下valgrind的使用，详细的介绍请参考官方文档。

假设有这样一段问题代码：

#include <stdlib.h>  void f(void)    {     int* x = malloc(10 * sizeof(int));     x[10] = 0;        // 问题1: 越界  }                    // 问题2: 内存泄漏，x没有被释放掉   int main()   {     f();     return 0;  }

这段代码中有两个问题：一个是数据的越界访问；另一个是内存泄漏。将该程序编译为myprog。

接下来使用valgrind来检查该程序，使用以下命令：

valgrind --leak-check=yes myprog

运行完成后valgrind会给出检测报告，关于程序越界访问会给出这样的输出：

==19182== Invalid write of size 4  ==19182==    at 0x804838F: f (example.c:6)  ==19182==    by 0x80483AB: main (example.c:11)  ==19182==  Address 0x1BA45050 is 0 bytes after a block of size 40 alloc'd  ==19182==    at 0x1B8FF5CD: malloc (vg_replace_malloc.c:130) ==19182==    by 0x8048385: f (example.c:5)  ==19182==    by 0x80483AB: main (example.c:11)

第一行告诉你代码中存在Invalid write，也就是无效的写，并给出了问题出现的位置。

关于内存泄漏问题会给出这样的输出：

==19182== 40 bytes in 1 blocks are definitely lost in loss record 1 of 1  ==19182==    at 0x1B8FF5CD: malloc (vg_replace_malloc.c:130)  ==19182==    by 0x8048385: f (example.c:5)  ==19182==    by 0x80483AB: main (example.c:11)

这里第一行报告了内存"definitely lost"，也就是说一定会存在内存泄漏，并给出了问题出现的位置。

实际上除了"definitely lost"，valgrind还会给出"probably lost"的报告，这两种报告的含义是这样的：

•  "definitely lost"：你的程序一定存在内存泄漏问题，修复。

•  "probably lost"：你的程序看起来像是有内存泄漏，有可能你在使用指针完成一些特定操作，因此不一定100%存在问题。

“怎么解决内存泄漏问题”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注网站，小编将为大家输出更多高质量的实用文章！