支持原创，转载请附上原文链接
0 引言
前面介绍了valgrind的基础，参见 Valgrind 基础，今天这结合Valgrind，来讲讲内存泄漏，以及基于Valgrind定位、分析内存泄漏的罪魁祸首
索引：
1、valgrind 实战
2、”still reachable“ 是否关注
3、内存泄漏的思考
1 内存泄漏与 valgrind
1.1 什么是内存泄漏？
内存泄漏（Memory Leak）是指程序中已动态分配的堆内存由于某种原因程序未释放或无法释放，造成系统内存的浪费，导致程序运行速度减慢甚至系统崩溃等严重后果
内存泄漏-百科
用程序员的话讲：就是malloc 或者 new 了分配了内存空间，由于某种原因没有执行free 或者delete释放内存空间，导致系统内存逐渐变少以至于无内存可用
1.2 理论 && 实际
关于一些比较明确的内存泄漏案例，我这里就简单带过，比如下面代码
#include <iostream>
void leak(){
char* p = new char[1024];
}
int main() {
leak();
return 0;
}
通过valgrind工具运行检查，结果如下
==11562== HEAP SUMMARY:
==11562== in use at exit: 73,728 bytes in 2 blocks
==11562== total heap usage: 2 allocs, 0 frees, 73,728 bytes allocated
==11562==
==11562== 1,024 bytes in 1 blocks are definitely lost in loss record 1 of 2
==11562== at 0x4C2E80F: operator new[](unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11562== by 0x400717: leak() (in /home/a.out)
==11562== by 0x400727: main (in /home/a.out)
==11562==
==11562== 72,704 bytes in 1 blocks are still reachable in loss record 2 of 2
==11562== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11562== by 0x4EC3EFF: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==11562== by 0x40106F9: call_init.part.0 (dl-init.c:72)
==11562== by 0x401080A: call_init (dl-init.c:30)
==11562== by 0x401080A: _dl_init (dl-init.c:120)
==11562== by 0x4000C69: ??? (in /lib/x86_64-linux-gnu/ld-2.23.so)
==11562==
==11562== LEAK SUMMARY:
==11562== definitely lost: 1,024 bytes in 1 blocks
==11562== indirectly lost: 0 bytes in 0 blocks
==11562== possibly lost: 0 bytes in 0 blocks
==11562== still reachable: 72,704 bytes in 1 blocks
==11562== suppressed: 0 bytes in 0 blocks
很明显，leak()函数内存泄露了，valgrind的检测结果也明确指出：definitely lost: 1,024 bytes in 1 blocks
1.2.1 似而不是的内存泄漏
? 那么我首先提一个问题：是否所有的malloc/new没有对应的free/delete，都是内存泄漏，需要我们修复呢?
其实，这个问题并不难，仔细看内存泄漏的定义也可以得出答案，但是这里，我通过一段代码，来给大家看看，加深理解
#include <iostream>
struct GlobalConf{
int conf1;
int conf2;
int conf3;
};
GlobalConf* conf2;
int main() {
conf2 = new GlobalConf();
conf2->conf1 = 1;
conf2->conf2 = 2;
conf2->conf3 = 3;
/*
* 整个生命周期conf2都需要使用
*/
while(1);
return 0;
}
上面我们有一个全局配置，conf2指针，程序初始化的时候，通过分配空间的方式分配内存，该程序一直运行不会结束，conf2虽然分配了内存，但是其实只是在初始化的时候分配一次，且整个程序声明周期一直在使用，所以虽然看起来分配了内存未释放，但是其实并不属于内存泄漏
1.2.2 引发血案的内存泄漏
内存泄漏之所以比较难查，一个原因就是不同于数组越界等其他的内存非法访问，存在很大的隐蔽性，而且有时候，valgrind提供的信息，还需要结合我们的代码，才能真正定位问题，下面，我分析一个案例，讲述still reachable在我们分析问题时候的重要性，不可忽视，特别是blocks比较多，一定需要关注
#include <unistd.h>
#include <iostream>
#include <thread>
#include <vector>
class Buffer {
public:
Buffer(int size) : size_(size) { buf_ = new char[size]; }
~Buffer() {
size_ = 0;
delete[] buf_;
}
private:
char* buf_;
int size_;
};
std::vector<std::shared_ptr<Buffer>> vectors_;
std::vector<std::shared_ptr<Buffer>> vectors2_;
void t1_handler() {
while (1) {
auto item = std::make_shared<Buffer>(1024);
vectors_.emplace_back(item);
auto item2 = std::make_shared<Buffer>(1024);
vectors2_.emplace_back(item2);
std::cout << "insert" << std::endl;
sleep(2);
}
}
void t2_handler() {
while (1) {
if (!vectors_.empty()) {
std::cout << "before --> size:" << vectors_.size() << std::endl;
vectors_.clear();
std::cout << "after --> size:" << vectors_.size() << std::endl;
std::cout << "vector2 --> size:" << vectors2_.size() << std::endl;
sleep(1);
}
}
}
int main() {
std::thread t1(t1_handler);
std::thread t2(t2_handler);
t1.detach();
t2.detach();
while (1)
;
return 0;
}
通过valgrind执行程序的日志如下：
==18654== HEAP SUMMARY:
==18654== in use at exit: 87,376 bytes in 33 blocks
==18654== total heap usage: 60 allocs, 27 frees, 100,256 bytes allocated
==18654==
省略...
==18654== 12,288 bytes in 12 blocks are still reachable in loss record 10 of 11
==18654== at 0x4C2E80F: operator new[](unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==18654== by 0x40170F: Buffer::Buffer(int) (in /home/a.out)
==18654== by 0x4037F7: _ZN9__gnu_cxx13new_allocatorI6BufferE9constructIS1_IiEEEvPT_DpOT0_ (in /home/a.out)
==18654== by 0x4034CD: _ZNSt16allocator_traitsISaI6BufferEE9constructIS0_IiEEEvRS1_PT_DpOT0_ (in /home/a.out)
==18654== by 0x403123: std::_Sp_counted_ptr_inplace<Buffer, std::allocator<Buffer>, (__gnu_cxx::_Lock_policy)2>::_Sp_counted_ptr_inplace<int>(std::allocator<Buffer>, int&&) (in /home/a.out)
==18654== by 0x402C86: std::__shared_count<(__gnu_cxx::_Lock_policy)2>::__shared_count<Buffer, std::allocator<Buffer>, int>(std::_Sp_make_shared_tag, Buffer*, std::allocator<Buffer> const&, int&&) (in /home/a.out)
==18654== by 0x402915: std::__shared_ptr<Buffer, (__gnu_cxx::_Lock_policy)2>::__shared_ptr<std::allocator<Buffer>, int>(std::_Sp_make_shared_tag, std::allocator<Buffer> const&, int&&) (in /home/a.out)
==18654== by 0x402397: std::shared_ptr<Buffer>::shared_ptr<std::allocator<Buffer>, int>(std::_Sp_make_shared_tag, std::allocator<Buffer> const&, int&&) (in /home/a.out)
==18654== by 0x401CB3: std::shared_ptr<Buffer> std::allocate_shared<Buffer, std::allocator<Buffer>, int>(std::allocator<Buffer> const&, int&&) (in /home/a.out)
==18654== by 0x401833: _ZSt11make_sharedI6BufferIiEESt10shared_ptrIT_EDpOT0_ (in /home/a.out)
==18654== by 0x4012AF: t1_handler() (in /home/a.out)
==18654== by 0x404358: void std::_Bind_simple<void (*())()>::_M_invoke<>(std::_Index_tuple<>) (in /home/a.out)
==18654==
==18654== 72,704 bytes in 1 blocks are still reachable in loss record 11 of 11
==18654== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==18654== by 0x50E0EFF: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==18654== by 0x40106F9: call_init.part.0 (dl-init.c:72)
==18654== by 0x401080A: call_init (dl-init.c:30)
==18654== by 0x401080A: _dl_init (dl-init.c:120)
==18654== by 0x4000C69: ??? (in /lib/x86_64-linux-gnu/ld-2.23.so)
==18654==
==18654== LEAK SUMMARY:
==18654== definitely lost: 0 bytes in 0 blocks
==18654== indirectly lost: 0 bytes in 0 blocks
==18654== possibly lost: 576 bytes in 2 blocks
==18654== still reachable: 86,800 bytes in 31 blocks
==18654== suppressed: 0 bytes in 0 blocks
==18654==
valgrind 是在程序结束的时候检测，上面程序while运行不能结束，因此需要ctrl+c结束程序
上面still reachable显示有12blocks泄漏了12M的数据，位置是在t1_handler中分配的。
上面看起来可能一眼能看出来，vectors2_没被清理，那是因为这是一个简单的测试demo，显示中这种隐蔽的case可能就比较难查了
关于valgrind的经验总结：
- definitely lost 需要全部清理掉
- still reachable 需要关注，但是需要case by case的分析，特别是有多个blocks泄漏时，表明内存泄漏位置被重复调用了，这种一般会在长时间运行后由于无内存可用导致系统崩溃
