解决了一个隐蔽的内存泄漏——pthread_create后没有detach导致内存持续增长

本是古典何须时尚 2022-06-09 09:19 467阅读 0赞

昨天解决了一个隐蔽的内存泄漏问题，原因是pthread\_create后的僵死线程没有释放导致的内存持续增长。  
现象是这样的：短时间内程序运行正常，但跑了12小时左右，用top查看其内存占用居然高达2G，于是马上意识到有内存泄漏。

最先想到的是malloc/free、new/delete没有配对，申请的内存没有释放。于是写了个跟踪malloc/free调用的模块，不过检查中并没有找到未释放的内存。之后怀疑是不是 free then malloc 导致的内存管理错误（事实证明虽然free后不是立即回收内存，但是接连调用free & malloc并不会影响操作系统的内存管理），不过写了个小程序发现并不是这么回事。

陷入窘境了，只好用最小系统法把功能部分和内存分配都给屏蔽掉，这时发现内存泄漏依然存在！仔细看top的输出，几乎是每次创建线程时内存就往上涨一点，只是增长速度不是很快，看来是线程的问题了。仔细分析发现，之前图简单 **pthread\_create (&thread, NULL, &thread\_function, NULL);** 就这么写了，参数2没有设置线程结束后自动detach，并且没有使用pthread\_join或pthread\_detach释放执行结束后线程的空间！

**Linux man page** 里有已经说明了这个问题：  
When a joinable thread terminates, its memory resources (thread descriptor and stack) are not deallocated until another thread performs pthread\_join on it. Therefore, pthread\_join must be called once for each joinable thread created to avoid **memory leaks**.

也就说线程执行完后如果不join的话，线程的资源会一直得不到释放而导致内存泄漏！一时的图快后患无穷啊。

**解决办法**：

代码 
    
    
    
    Code highlighting produced by Actipro CodeHighlighter (freeware)
    http://www.CodeHighlighter.com/
    
    --> 1 // 最简单的办法，在线程执行结束后调用pthread_detach让他自己释放
     pthread_detach(pthread_self());
     
     
     // 或者创建线程前设置 PTHREAD_CREATE_DETACHED 属性
     pthread_attr_t attr;
     pthread_t thread;
     pthread_attr_init (&attr);
     pthread_attr_setdetachstate (&attr, PTHREAD_CREATE_DETACHED);
     pthread_create (&thread, &attr, &thread_function, NULL);
     pthread_attr_destroy (&attr);

第2行的那种方法最简单，在线程函数尾部加上这句话就可以将线程所占用的资源给释放掉；或者像 5-11 所示的方法设置detach属性，这样也会在线程return/pthread\_exit后释放内存。

其实仔细想想，valgrind检查时已经提示了pthread\_create没有释放的问题，只是之前没引起注意。其实这样的问题也只有在长时间运行时，慢慢积累这一点点的内存才会暴露出来，看来valgrind的提示也不能置之不理啊。

from：

[http://www.cnblogs.com/bits/archive/2009/12/04/no\_join\_or\_detach\_memory\_leak.html][http_www.cnblogs.com_bits_archive_2009_12_04_no_join_or_detach_memory_leak.html]

[http_www.cnblogs.com_bits_archive_2009_12_04_no_join_or_detach_memory_leak.html]: http://www.cnblogs.com/bits/archive/2009/12/04/no_join_or_detach_memory_leak.html