最近部门不同产品接连出现内存泄漏导致的网上问题,具体表现为单板在现网运行数月以后,因为内存耗尽而导致单板复位现象。
一方面,内存泄漏问题属于低级错误,此类问题遗漏到现网,影响很坏;另一方面,由于内存泄漏问题很可能导致单板运行固定时间以后就复位,只能通过批量升级才能解决,实际影响也很恶劣。
同时,接连出现此类问题,尤其是其中一例问题还是我们老员工修改引入,说明我们不少员工对内存泄漏问题认识还是不够深刻的。
本文通过介绍内存泄漏问题原理及检视方法,希望后续能够从编码检视环节就杜绝此类问题发生。
说明:预防内存泄漏问题有多种方法,比如加强代码检视、工具检测和内存测试等,本文聚集于开发人员能力提升方面。
内存泄漏问题只有在使用堆内存的时候才会出现,栈内存不存在内存泄漏问题,因为栈内存会自动分配和释放。
C代码中堆内存的申请函数是malloc,常见的内存申请代码如下:
char *info = NULL; /**转换后的字符串**/ info = (char*)malloc(NB_MEM_SPD_INFO_MAX_SIZE); if( NULL == info) { (void)tdm_error("malloc error!\n"); return NB_SA_ERR_HPI_OUT_OF_MEMORY; }
由于malloc函数返回的实际上是一个内存地址,所以保存堆内存的变量一定是一个指针(除非代码编写极其不规范)。
再重复一遍,保存堆内存的变量一定是一个指针,这对本文主旨的理解很重要。当然,这个指针可以是单指针,也可以是多重指针。
malloc函数有很多变种或封装,如g_malloc、g_malloc0、VOS_Malloc等,这些函数最终都会调用malloc函数。
看到本小节标题,可能有些同学有疑惑,上一小节中的malloc函数,不就是堆内存的获取方法吗?
的确是,通过malloc函数申请是最直接的获取方法,如果只知道这种堆内存获取方法,就容易掉到坑里了。
一般的来讲,堆内存有如下两种获取方法:
方法一:将函数返回值直接赋给指针,一般表现形式如下:
char *local_pointer_xx = NULL; local_pointer_xx = (char*)function_xx(para_xx, …);
该类涉及到内存申请的函数,返回值一般都指针类型,例如:
GSList* g_slist_append (GSList *list, gpointer data);
方法二:将指针地址作为函数返回参数,通过返回参数保存堆内存地址,一般表现形式如下:
int ret; char *local_pointer_xx = NULL; /**转换后的字符串**/ ret = (char*)function_xx(..., &local_pointer_xx, ...);
该类涉及到内存申请的函数,一般都有一个入参是双重指针,例如:
__STDIO_INLINE _IO_ssize_t; getline (char **__lineptr, size_t *__n, FILE *__stream);
前面说通过malloc申请内存,就属于方法一的一个具体表现形式。其实这两类方法的本质是一样的,都是函数内部间接申请了内存,只是传递内存的方法不一样,方法一通过返回值传递内存指针,方法二通过参数传递内存指针。
最常见的内存泄漏问题,包含以下三个要素:
稍微使用过C语言编写代码的人,都应该知道堆内存申请之后是需要释放的。但为何还这么容易出现内存泄漏问题呢?
一方面,是开发人员经验不足、意识不到位或一时疏忽导致;另一方面,是内存释放误区导致。
很多开发人员,认为要释放的内存应该局限于以下两种:
dfl_get_object_list(const char* class_name, GSList **list);
按照以上思维编写代码,一旦遇到不熟悉的接口中需要释放内存的问题,就完全没有释放内存的意识,内存泄漏问题就自然产生了。
检视内存泄漏问题,关键还是要养成良好的编码检视习惯。与内存泄漏三要素对应,需
要做到如下三点: