CN112346894A - 内存泄露检测方法、装置、***及计算机设备 - Google Patents

Abstract

本申请提供了一种内存泄露检测方法、装置、***及计算机设备，通过对被测应用的内存分配信息进行抽样统计，即记录抽取的有限数量的待统计内存分配信息进行分类统计，即可检测出被测应用是否发生内存泄露，相对于现有技术对被测应用的所有内存分配信息进行统计的方法，极大减小了对测试终端的性能消耗，解决了现有技术因统计所有的内存分配信息，导致测试终端性能消耗严重，无法为用户提供服务，进而导致无法全面且准确检测被测应用是否发生内存泄露的问题。

Description

内存泄露检测方法、装置、***及计算机设备

技术领域

本申请涉及计算机应用领域，更具体的说，是涉及一种内存泄露检测方法、装置、***及计算机设备。

背景技术

随着计算机应用需求的日益增加，应用程序的设计与开发也相应的日趋复杂，开发人员在程序实现的过程中处理的变量大量增加，如何有效进行内存分配和释放，防止内存泄露(Memory Leak)的问题变得越来越突出。

其中，内存泄漏是指应用程序中己动态分配的堆内存，由于某种原因应用程序分配的内容未释放或无法释放，造成了***内存的浪费，且因***可用的内存越来越少，导致后续应用程序运行速度减慢，甚至***崩溃等严重后果。

现有的内存泄露检测方法，通常需要重启电子设备，运行内存检测工具，记录被测应用程序的所有内存分配信息，通过对这些内存分配信息进行分析，判定是否发生内存泄露。可见，这种内存检测方法重启会中断应用程序的服务，影响应用程序的服务质量，且对性能消耗非常严重，尤其是在分布式***中，一旦开启内存检测工具，电子设备将无法再提供服务，而内存泄露很多时候是在正常服务时候出现，降低了内存泄露检测的准确性。

发明内容

有鉴于此，本申请提供了一种内存泄露检测方法、装置、***及计算机设备，通过对被测应用的内存分配信息进行随机抽样统计，极大减小了性能消耗，无需重启测试终端，不会中断服务，提高了内存泄露检测的效率及准确性。

为实现上述目的，本申请实施例提出了一种内存泄露检测方法，所述方法包括：

在被测应用多次运行过程中，对所述被测应用的内存分配信息进行随机抽样，得到待统计内存分配信息；

按照所述被测应用的函数调用路径及抽样时间点，对所述待统计内存分类信息进行分类统计；

利用得到的分类统计结果，检测所述被测应用是否发生内存泄露。

本申请实施例还提出了一种内存泄露检测装置，所述装置包括：

随机抽样模块，用于在被测应用多次运行过程中，对所述被测应用的内存分配信息进行随机抽样，得到待统计内存分配信息；

分类统计模块，用于按照所述被测应用的函数调用路径及抽样时间点，对所述待统计内存分类信息进行分类统计；

检测模块，用于利用得到的分类统计结果，检测所述被测应用是否发生内存泄露。

本申请实施例还提出了一种计算机设备，所述计算机设备包括：

通信接口；

存储器，用于存储实现如上所述的内存泄露检测方法的程序；

处理器，用于调用并执行所述存储器的程序，以实现如上所述的内存泄露检测方法的各个步骤。

本申请实施例还提出了一种内存泄露检测***，所述***包括：测试服务器和测试终端，其中：

所述测试服务器为如上所述的计算机设备；

所述测试终端用于运行被测应用，并输出所述测试服务器反馈的所述被测应用是否发生内存泄露的检测结果。

经由上述的技术方案可知，与现有技术相比，本申请提供了一种内存泄露检测方法、装置、***及计算机设备，通过对被测应用的内存分配信息进行抽样统计，即记录抽取的有限数量的待统计内存分配信息进行分类统计，即可检测出被测应用是否发生内存泄露，相对于现有技术对被测应用的所有内存分配信息进行统计的方法，极大减小了对测试终端的性能消耗，解决了现有技术因统计所有的内存分配信息，导致测试终端性能消耗严重，无法为用户提供服务，进而导致无法全面且准确检测被测应用是否发生内存泄露的问题。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图1示出了实现本申请提出的内存泄露检测方法的一种可选实施场景的***架构图；

图2示出了本申请提出的内存泄露检测方法的一种可选示例的流程图；

图3示出了本申请提出的内存泄露检测方法的另一种可选示例的流程图；

图4示出了本申请提出的内存泄露检测方法中，输出第一检测结果的可选示意图；

图5示出了本申请提出的内存泄露检测方法中，输出第二检测结果的可选示意图；

图6示出了本申请提出的内存泄露检测方法的一种实施场景流程示意图；

图7示出了本申请提出的内存泄露检测方法的一种可选示例的信令流程图；

图8示出了本申请提出的内存泄露检测装置的一种可选示例的结构图；

图9示出了本申请提出的内存泄露检测装置的一种可选示例的结构图；

图10示出了本申请提出的一种计算机设备的硬件结构示意图；

图11示出了本申请提出的一种测试终端的硬件结构示意图。

具体实施方式

结合上文背景技术部分的描述，在适用于电子设备使用的应用程序的开发中，可能会出现由于编码不规范导致的应用内存泄露，现有的内存泄露检测工具使用过程中，由于其是对被测应用的所有内存分配信息进行记录，导致对电子设备的性能消耗非常严重，影响被测应用的正常运行，且因必须重启才能够进行内存泄露检测，而该重启操作必然会中断被测应用运行，严重影响用户体验。

对此，本申请的发明人希望内存泄露检测降低电子设备的性能效率，且在内存检测过程中不会影响被测应用的正常工作，即不需要重启电子设备，被测应用不会中断服务。基于此，本申请提出对被测应用的内存分配信息的记录方式进行调整，不再对所有内存分配信息进行记录，而是采用随机抽样的方式，抽样记录有限数量的内存分配信息，且为了尽量保证所抽样到的内存分配量变化情况的完整性，本申请提出对同一被测应用进行多次内存泄露检测，即使被测应用运行多次，每次均可以采用随机抽样方式进行抽样，再对抽样得到的内存分配信息进行分类统计分析，判定被测应用是否发生内存泄露，还可以进一步定位引起该内存泄露的调用函数。

应该理解，本申请提出的对内存分配信息进行抽样统计的方式，对电子设备的性能消耗极小，开启内存泄露检测之后，电子设备仍可以提供正常服务，且整个检测过程中，无需重启电子设备，服务不中断，不影响用户对被测应用及电子设备的其他应用的正常使用。可见，本申请提出的内存泄露检测方法，既提高了内存泄露检测的效率，又保证了用户使用应用的服务体验。

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

参照图1，为实现本申请提出的内存泄露检测方法的一种可选实施场景的***架构图，该***可以包括测试终端11和测试服务器12，其中：

测试终端可以是提供被测应用的运行环境的终端设备，用来检测被测应用运行过程中所产生各种运行信息，并发送至测试服务器12进行处理，以使测试服务器按照本申请提出的内存泄露检测方法，确定被测应用哪个对象(如调用函数)发生了内存泄露。

在实际应用中，测试终端可以是笔记本电脑、台式电脑、平板电脑、手机、工控机等终端设备，被测应用可以是终端设备安装的应用程序，也可以是能够在终端设备的浏览器上运行的网页应用程序，本申请对终端设备的产品类型及结构，被测应用的类型及功能不做限定，

本申请中，测试服务器12可以是一个服务器或多个服务器构成的服务器集群，本申请对测试服务器12的组成结构不做限定，关于其实现内存泄露检测的过程，可以参照下文方法实施例相应部分的描述。

通常情况下，测试终端中可以安装于测试服务器相匹配的测试客户端，测试人员可以启动测试客户端，进入内存泄露测试平台，实现对当前运行的被测应用的内存泄露的检测。其中，测试服务器完成一被测应用的内存泄露检测后，可以将检测结果或表征该检测结果的数据反馈至测试客户端进行展示，以使测试人员能够直观得知被测应用是否发生内存泄露，还可以进一步定位内存泄露问题。

应该理解，对于本申请提供的***架构，并不局限于本实施例描述的测试终端和测试服务器，可以根据具体实施场景的需求确定，本申请不再一一详述。

基于上图1示出的***架构，参照图2，为本申请提出的内存泄露检测方法的一种可选示例流程图，该方法可以适用于计算机设备，该计算机设备可以是测试服务器，如图2所示，该方法可以包括但并不局限于以下步骤：

步骤S11，在被测应用多次运行过程中，对被测应用的内存分配信息进行抽样，得到待统计内存分配信息；

结合上文对本申请技术构思的描述，本申请在内存泄露检测过程中，采用抽样方式，获取被测应用的内存分配信息，所以，为了能够尽可能多的抽取被测应用的对象的内存分配信息，本申请采用大数据统计的方式，即对被测应用进行多次内存泄露检测，每次内存泄露检测均可以采用随机抽样的方式，来获取所需的待统计内存分配信息，具体获取方法不做限定，且被测应用每次运行进行内存泄露检测，对其内存分配信息进行抽样的方法相同，本申请不再一一详述。

其中，对于运行的被测应用，其可以是测试终端中的任一应用程序，本申请对被测应用的应用类型不做限定，在实际应用中，测试终端运行被测应用，通常会启动一个进程(本实施例可以将其记为被测进程)，对于不同的被测应用，所启动的被测进程可以不同，所以，本申请对被测应用进行内存泄露检测，实际也是对相应被测进程进行内存泄露检测，步骤S11可以是对被测进程的内存分配信息进行抽样，得到待统计内存分配信息。

可选的，关于对被测进程的内存分配信息的抽样，具体可以是在被测进程执行过程中，对所调用的工作线程对内存的使用情况进行抽样记录，本申请对被测进程执行过程中，为其各工作线程分配内存的实现过程不做详述。

本实施例实际应用中，上述被测进程(或被测应用)可以是一个或多个，如各种社交应用(即被测应用)的进程、浏览器应用的进程等等。通常情况下，在被测应用正常运行时，即相应的被测进行在正常运行时，用户可以通过被测应用执行各种操作，如对于社交应用类的被测应用，用户可以通过社交应用的进程进行语音、文字、视频聊天、还可以发朋友圈、添加好友等操作。

对于不同用户操作，社交应用响应该用户操作，通常是调用相应的功能函数，实现相应的功能，对于测试终端的操作***来说，在社交应用调用函数，实现用户操作的功能时，需要为其分配内存，待完成操作后，通常会释放之前占用的内存。本申请可以对***为各种调用函数进行内存分配操作，所产生的相应的内存分配信息进行抽样，实现内存泄露检测。

其中，抽样又称取样，可以是从欲研究的全部样品中抽取一部分的样品单位，需要保证所抽取的样品单位对全部样品具有充分的代表性，以便能够通过对抽取样品的分析、研究结果，估计和推断全部样品特性。基于此，本申请则是利用抽取到的待统计内存分配信息的变化情况，代表被测应用运行产生的所有内存分配信息的变化情况。

可选的，本申请可以采用随机抽样方式，实现对内存分配信息的抽样，随机抽样法也可以称为抽样调查法，按照随机原则，利用随机数，从总体中抽取样本的方法，本申请对内存分配信息的随机抽样的具体实现过程不做详述。其中，执行随机抽样依据的抽样率可以是动态可调的，所以，对同一被测应用的内存分配信息进行抽样，所依据的抽样率可以是不同的，以使最终得到的待统计内存分配信息更具有代表性。

步骤S12，按照被测应用的函数调用路径及抽样时间点，对待统计内存分类信息进行分类统计；

继上文描述，被测应用运行过程中，通常需要调用各种函数，来实现被测应用的各种服务功能，且各函数之间通常存在一定关联关系，可以形成如图3所示的一种函数调用关系拓扑图，func1～func6可以分别表示被测应用运行过程中所调用的函数，但并不局限于图3示出的几个函数及其调用关系。

基于如图3示出的函数调用关系，被测应用运行过程中，内存分配器可以按照开发人员预先编写的内存分配关系，为被测应用当前调用函数配置可使用的内存，即由内存分配器负责内存分配工作，与此同时，本实施例中的内存分配器还可以负责抽样内存分配信息的工作，具体抽样过程可以参照上述步骤S11的相关描述。由于本申请是抽取各调用函数的内存分配信息，因此，本申请得到的待统计内存分配信息通常可以包括：被测应用的多个调用函数各自的函数调用路径、内存分配量及抽样时间点(即被测应用的运行时间点)等数据。

其中，由于本申请是要对被测应用进行多次内存泄露抽样检测，每一次抽样检测过程中，所抽取到的是不同抽样时间点对应的各种调用函数的内存分配量，该调用函数可以由函数调用路径表示，这样，经过对同一被测应用进行多次抽样检测后，可能会抽取到同一函数调用路径对应的不同抽样时间点的相同或不同内存分配量，以及同一抽样时间点对应的不同函数调用路径的相同或不同内存分配量等各种待统计内存分配信息。

之后，由于本申请需要依据内存分配量的变化情况，实现内存泄露的检测，所以，本实施例可以按照各待统计内存分配信息中的函数调用路径及抽样时间点，对得到的各待统计内存分配信息进行分类统计，如将函数调用路径相同且抽样时间点相同的内存分配量进行累加，可以得到如下数据结构的分类统计结果：

(函数调用路径1：(抽取时间1，内存分配量1)，(抽取时间2，内存分配量2)，(抽取时间3，内存分配量3)……)

(函数调用路径2：(抽取时间1，内存分配量1)，(抽取时间2，内存分配量2)，(抽取时间3，内存分配量3)……)

(函数调用路径3：(抽取时间1，内存分配量1)，(抽取时间2，内存分配量2)，(抽取时间3，内存分配量3)……)

……

需要说明，对于步骤S12得到的分类统计结果的数据结构，并不局限于上文列举的这种数据结构，可以根据实际需求灵活选择，本申请在此仅以该数据结构为例进行分类统计说明。

应该理解的是，对于如上所示的数据结构，在获取待统计内存分配信息时，也可以按照该数据结构进行记录，即(调用函数路径，抽样时间点，内存分配量)，但并不局限于这种记录方式。

步骤S13，利用得到的分类统计结果，检测被测应用是否发生内存泄露。

如上文对内存分配信息的分类统计的描述，所得到的分类统计结果包括了同一函数调用路径在不同抽样时间点的内存分配量，而在实际应用中，正常情况下，一调用函数不同运行时间点的内存分配量基本是不变的，若发生内存泄露，因存在未被释放的内存，将会导致相应调用函数在不同运行时间点的内存分配量突不断增加。

因此，本申请可以通过分析被测应用的每个调用函数的内存分配量的变化情况，即分析每一个函数调用路径在不同抽样时间点的内存分配量的变化情况，实现对被测应用内存泄露的检测，本申请对该内存分配量的变化情况的具体分析方法不做限定。

可见，本申请通过对分类统计结果中各类内存分配量随时间的变化情况的分析，不仅可以检测出被测应用是否发生了内存泄露，还可以由此确定出是什么原因导致被测应用内存泄露，即快速定位引起内存泄露的代码位置，方便测试人员及时进行修正，保证被测应用运行可靠性，并改善测试终端的性能。

作为本申请另一可选示例，本申请也可以将得到的分类统计结果，和/或被测应用是否发生内存泄露的检测结果发送至测试终端，由该测试终端响应于查看操作，输出分类统计结果和/或检测结果，以使测试人员能够直观得知被测应用是否发生内存泄露，以及具体是调用哪个函数引发了内存泄露等，本申请对测试服务器通知测试终端被测应用的内存泄露检测结果的方式不做限定。

综上，本申请是对被测应用的内存分配信息进行抽样统计，即记录抽取的有限数量的待统计内存分配信息进行分类统计，即可检测出被测应用是否发生内存泄露，相对于现有技术对被测应用的所有内存分配信息进行统计的方法，极大减小了对测试终端的性能消耗，解决了现有技术因统计所有的内存分配信息，导致测试终端性能消耗严重，无法为用户提供服务，进而导致无法全面且准确检测被测应用是否发生内存泄露的问题。

参照图3，为本申请提供的内存泄露检测方法的另一种可选示例的流程示意图，该方法仍可以适用于计算机设备，本实施例可以是对上述实施例描述的内存泄露检测的一种细化示例，但并不局限于本实施例这种细化实现方法，如图3所示，该方法可以包括：

步骤S21，获取被测应用本次运行期间的内存分配信息的抽样率；

需要说明，在被测应用每次运行期间的内存泄露检测的抽样方法类似，本申请仅以被测应用一次运行期间的抽样过程为例进行说明，但并不局限于本实施例描述的这种抽放方法。

抽样率可以指在单位时间内的信号样值数目，本实施例可以是指单位时间内的内存分配量的数目，且该抽样率可以是动态可调的，对被测应用的每次内存泄露检测的抽样过程所获取的抽样率可以不同，对被测应用的同一次内存泄露抽样过程中，该抽样率可以保持不变，也可以动态改变，也就是说，相邻两次抽样的时间差并不固定，本申请对获取的抽样率的数值及其变化规则不做限定。

步骤S22，按照该抽样率，对本次运行的被测应用的多次内存分配操作进行抽样，记录抽取到的内存分配操作所产生的内存分配信息；

结合上文实施例的描述，在被测应用运行过程中，调用函数实现某功能时，***通常会为其分配内存空间(即虚拟地址空间)，而对于所分配的内存空间，可以是在被测应用开发期间配置生成的，由内存分配器完成内存分配工作以及抽样工作。

其中，被测应用(即任一应用程序)对内存的使用通常包括栈区(stack)、堆区、全局区、常量区和代码区五部分，栈区由操作***自动分配和释放内存，通常可以存放调用函数的参数值，局部变量的值等。操作方式类似于数据结构中的栈，用于维护函数调用的上下文。堆区的内存通常由开发人员分配和释放，若开发人员不释放，被测应用结束运行时可以由操作***回收，其分配方式类似于链表，可以用来容纳被测应用动态分配的内存区域，当被测应用使用malloc或new分配内存时，得到的内存来自堆里。

由此可见，被测应用所调用的各函数的调用关系通常记录在堆栈中，在每次进行抽样时，可以获取当前函数调用关系的堆栈，并将该函数调用关系堆栈翻译成调用链路，之后，将该调用链路转成字符串格式的函数调用路径，同时，在该函数调用路径的结尾处，添加当前函数的内存分配量及当前抽样时间点，得到该当前函数的内存分配信息，此时，可以将该内存分配信息记录在内存中，当记录的内存分配信息的数量达到一定阈值，可以将记录的这些内存分配信息写入磁盘。

需要说明的是，本申请对各被测应用的函数调用关系的记录方式，及其调用函数实现被测应用各服务功能的实现过程均不作详述。每次内存分配命中动态抽样的时候，即每次进行抽样时，均可以按照但并不局限于上段描述的方式，获取包含相应调用函数的函数调用路径、内存分配量及抽样时间点的内存分配信息，其中，内存分配量可以是正数，也可以是负数，通常正数可以表示为相应调用函数分配内存；若该内存分配量为负数，可以表示正在释放相应调用函数分配到的内存。

应该理解，由于同一时间点，被测应用可能有多个调用函数的内存处于分配或释放状态，所以说，一次抽样，可能得到包含不同函数调用路径的多个内存分配信息；当然，也可能得到一条内存分配信息，可以依据抽样时间点被测应用的具体运行情况确定，本申请对每次抽样得到的内存分配信息的内容及其数量不做限定。

另外，在本实施例中，对于写入内存及磁盘中的内存分配信息，可以按照一定的数据结构进行记录，关于数据结构的内容可以参照上述实施例相应部分的描述，但并不局限于上述实施例描述的这一种数据结构。

步骤S23，将被测应用多次运行所记录下的内存分配信息确定为待统计内存分配信息；

由于本实施例对内存分配信息采用抽样统计方式，为了使抽样得到的待统计内存分配信息能够代表所有的内存分配信息，本实施例将对该被测应用进行多次内存泄露检测，每次进行多次抽样操作，以获得被测应用更多更全面的内存分配信息，并将每次抽样得到的内存分配信息记为待统计内存分配信息，以实现后续内存泄露的判定。

步骤S24，对待统计内存分配信息中，同一函数调用路径在同一抽样时间点对应的内存分配量求和，得到同一函数调用路径在不同抽样时间点的内存分配量；

继上文描述，本实施例得到的待统计内存分配信息，是由对被测应用进行多次内存泄露检测，即由被测应用运行多次后抽取到的内存分配信息组成，应该理解，得到的这些待统计内存分配信息往往包含同一函数调用路径在相同或不同抽样时间点的相同或不同内存分配量，但每一条待统计内存分配信息中的函数调用路径、抽样时间点和内存分配量是固定的。

基于此，本申请可以先按照函数调用路径和抽样时间点，对得到的多条待统计内存分配信息进行分类，将函数调用路径和抽样时间点均相同的待统计内存分配信息作为一类，之后，再将同一类中待统计内存分配信息中的内存分配量进行求和，从而得到同一函数调用路径在不同抽样时间点的内存分配量，如函数调用路径1在各抽取时间点的内存分配量可以为：

函数调用路径1：(抽取时间1，内存分配量1)，(抽取时间2，内存分配量2)，(抽取时间3，内存分配量3)……。

应该理解，关于对多条待统计内存分配信息的分类统计方法，并不局限于上文描述的方式，只要能够得到同一函数调用路径在不同抽样时间点的内存分配量即可，本申请不再一一详述。

步骤S25，获取同一函数调用路径在不同抽样时间点的内存分配量的变化趋势；

按照上文描述的分类统计方式，针对被测应用的每一个调用函数，通常可以得到对应不同抽样时间点的多个内存分配量，之后，可以通过计算相邻两个抽样时间点的内存分配量差值，来确定这多个内存分配量的变化趋势，但并不局限于这种获取方式。

可选的，可以将得到的同一函数调用路径对应的不同抽样时间点的内存分配量，在XY坐标系中表示出来，如图4所示，X轴可以表示抽样时间点(即被测应用的运行时间点)，Y轴可以表示内存分配量，之后，对XY坐标系中的各点连线，得到被测应用调用相应函数时的内存分配量变化曲线，由其表示该调用函数的内存分配量变化趋势。当然，本申请也可以采用柱状图的方式来表示被测应用调用相应函数的内存分配量的变化趋势，本申请对被测应用调用各函数的内存分配量的变化趋势的表示方式不做限定，并不局限于本文描述的曲线图或柱形图表示方式。

步骤S26，检测是否存在呈递增趋势的变化趋势，如果存在，进入步骤S27；如果不存在，执行步骤S29；

步骤S27，利用存在递增趋势的变化趋势对应的函数调用路径，得到被测应用中发生内存泄露的函数；

通常情况下，被测应用发生内存泄露时，该被测应用的内存分配量将会变大，即该被测应用使用完某个分配的内存后，没有及时释放，再需要内存时，***还会为其分配新的内存，从而导致该被测应用的内存分配量变大。所以，本申请可以检测被测应用的内存分配量的变化趋势，来判定被测应用是否发生内存泄露。

其中，为了进一步定位引起内存泄露的被测应用的对象，即被测应用调用哪个函数运行期间发生了内存泄露，本实施例将获取被测应用运行期间，具体是被测应用在调用每一个函数过程中，被测应用的内存分配量的变化趋势，若存在被测应用调用某一函数期间的内存分配量的变化趋势呈递增趋势，即可确定该被测应用发生了内存泄露，具体是在调用该函数期间发生了内存泄露，测试人员可以针对调用该函数的相关代码进行调整。

需要说明的是，上述内存分配量的变化趋势为递增趋势可以指：内存分配量随着时间增大一直增加，或者在内存分配量存在短时间增大、一段时间减小的情况下，内存分配量随着时间增大而增加的幅度远远大于降低的幅度，这两种情况的内存分配量变化趋势，本申请均可以认为呈递增趋势，但并不局限于本申请列举的这两种递增变化趋势。

步骤S28，利用得到的发生内存泄露的函数，生成被测应用的第一检测结果；

步骤S29，生成被测应用未发生内存泄露的第二检测结果；

步骤S210，将生成的第一检测结果或第二检测结果反馈至测试终端。

本实施例按照上述方式确定引发内存系列的被测应用所调用的函数后，可以生成包含该函数的第一检测结果，当然，根据实际需求，该第一检测结果还可以包括上文得到的被测应用所调用的各函数对应的内存分配量的变化趋势，以及该被测应用所调用的各函数之间的函数调用关系数据等等，其中，对于确定发生内存泄露的函数，可以调整其显示属性(如图4所示的函数调用关系中，将发生内存泄露的函数func7的显示背景设置为具有灰度，还可以将其字体加粗等，但并不局限于这种显示属性的调整内容及方式)，以使测试服务器将第一检测结果反馈至测试终端后，测试终端输出被测应用的函数调用关系时，能够使引发内存泄露的函数与未引发内存泄露的函数之间的显示状态不同，使得测试人员能够直观得知被测应用的内存泄露检测结果，及引起内存泄露的对象等。

可选的，参照图4，本申请可以将得到被测应用所调用的各函数对应的内存分配量的变化趋势，作为函数调用关系中相应函数的内存泄露检测的详情，以使用户从展示的函数调用关系中，选定某一函数后，可以直接输出该函数对应的内存分配量的变化趋势，进而确定是否由该函数引发内存泄露，如图4所示，测试人员从测试终端输出的被测应用的函数调用关系拓扑图中，可以直接看出函数func7使用期间发生了内存泄露，为了解内存泄露详情，可以点击“func7”，测试终端将展示func7的内存分配量的变化趋势，如图4中下方图所示的折线，结合上述分析，显然，被测应用调用func7这个函数期间发生了内存泄露。

同理，若用户点击“func4”，测试中输出如图5所示的第二测试结果示意图，其内存分配量的变化趋势基本是一条直线，此时，可以认为被测应用使用func4期间未发生内存泄露。依次类推，测试终端可以依据测试人员的查看操作，输出相应的函数的内存分配量的变化趋势，但并不局限于图4和图5对内存分配量变化趋势的展示方式。

可选的，在内存泄露检测过程中，测试人员通过测试客户端登录测试服务器的测试平台后，可以输出内存泄露检测控制界面可以包含如下表1所示内容：

表1

模块名称	内存泄露开关	剩余时间	详细情况
				模块1	关	0
模块2	关	0
				模块3	关	0
模块4	开	8分钟	详情页
				模块5	关	0
模块6	关	0
				模块7	关	0

由上述表1可以得知，在对被测应用开始进行内存泄露检测之前，可以选定进行内存泄露检测的模块，如选定模块4，可以将其内存泄露检测开关的状态调整为开，在检测过程中，可以在该模块对应的剩余时间单元格中，动态显示对被测应用进行内存泄露检测的剩余时间，以使测试人员了解内存泄露检测的进度，在完成内存泄露检测后，可以显示“详情页”内容，测试人员点击该详情页，可以输出如上述图4和图5示出的函数调用关系拓扑图，以及引起内存系列的函数的内存分配量的变化趋势，以使测试人员了解被测应用的内存泄露检测的详细情况

需要说明，关于上述第一检测结果和第二检测结果的内容，及其在测试终端上的展示方式，并不局限于本申请上文描述的方式。

综上，本实施例对被测应用调用各函数的内存分配信息进行随机抽样统计，得到各函数对应的内存分配量的变化趋势，若其中存在递增趋势的变化趋势，可以直接确定被测应用发生了内存泄露，还可以准确且快速定位引起内存泄露的被测应用所调用的函数；而且，本申请根据需要，还可以将内存泄露检测结果以及各函数的内存分配量的变化趋势反馈至测试终端，以使得测试人员能够直观看到各函数的内存分配量的变化趋势，了解被测应用的内存泄露情况。

基于上文各实施例对本申请提出的内存泄露检测方法的描述，参照图6示出的一种实施场景示意图，该测试人员可以在测试终端上启动测试客户端，登录测试服务器的内存泄露检测平台，来实现对被测应用的内存泄露的检测。具体的，测试人员可以在测试终端上正常使用被测应用，即启动被测应用的进程正常运行，在该过程中，测试服务器可以对***为被测应用分配的内存分配信息进行随机抽样，以得到被测应用运行过程中所调用的各函数的内存分配信息，该内存分配信息可以包括相应函数的函数调用路径、抽取该内存分配信息的抽样时间点以及该函数占用的内存分配量等数据。

因此，测试服务器可以对抽取到的内存分配信息进行分类统计，得到被测应用所调用的各函数在不同抽样时间点的内存分配量的变化趋势，之后，可以直接将该变化趋势作为相应函数的检测详情反馈至测试终端，同时还可以生成被测应用的函数调用关系树并反馈至测试终端，以使得测试终端的测试界面能够直接输出被测应用的函数调用关系树，其中，可以调整该函数调用关系树中，测试服务器已确定的发生了内存泄露的函数的显示属性，以区别未发生内存泄露的函数。

其中，当测试人员希望了解某函数的内存泄露检测详情时，可以直接点击函数调用关系树中的相应函数，以输出如上图4和图5所示的内存分配量变化趋势，以使测试人员更加直观看到被测应用的哪个函数发生了内存泄露，还可以依据内存分配量变化趋势的变化量大小，初步估计该函数发生的内存泄露严重情况等，以便据此指定合适的维护策略，本申请对发生内存泄露的被测应用的代码调整方法不做详述。

综合上述分析，本申请实现被测应用的内存泄露检测的***组成，按照功能可以分为内存分配器、数据统计工具、数据分析工具及数据显示工具四部分，应该理解，这几部分可以根据实际实施场景确定所部署的位置，可以是测试终端和/或测试服务器上，本申请对这几部分的部署位置不做限定。下面将基于这种***功能架构划分方式，对本申请提出的内存泄露检测方法进行描述，参照图7示出的信令流程图，该内存泄露检测方法可以包括：

步骤S31，内存分配器为被测应用运行期间调用的函数分配内存，并对内存分配信息进行随机抽样，获取所调用函数的函数调用链路；

步骤S32，内存分配器将获取的函数调用链路转换成字符串格式的函数调用路径；

步骤S33，内存分配器在转换得到的函数调用路径结尾处，添加本次调用函数的内存分配量及抽样时间点，记录得到待统计内存分配信息；

步骤S34，内存分配器在记录的待统计内存分配信息的数量达到阈值的情况下，将记录的待统计内存分配信息按照预设数据格式写入磁盘；

步骤S35，数据统计工具从磁盘读取被测应用关联的多条待统计内存分配信息；

步骤S36，数据统计工具按照函数调用路径及抽样时间点，对读取的多条待统计内存分配信息进行分类统计，得到分类统计结果；

步骤S37，数据统计工具将分类统计结果发送至数据分析工具；

步骤S38，数据分析工具利用分类统计结果中，同一函数调用路径在各抽样时间点的内存分配量，得到被测应用所调用的相应函数的内存分配量变化趋势；

步骤S39，数据分析工具利用得到的内存分配量变化趋势，确定被测应用是否发生了内存泄露；

步骤S310，数据显示工具利用被测应用的函数调用路径，得到并输出被测应用的函数调用关系树；

步骤S311，数据显示工具调整数据分析工具得到的引发内存系泄露的函数，在该函数调用关系树中的显示状态；

步骤S312，数据显示工具响应于针对函数调用关系树中的任意函数的选择操作，输出相应函数的内存分配量变化趋势。

本实施例中，上述内存分配器、数据统计工具、数据分析工具、数据显示工具可以根据实际需要部署在测试终端或测试服务器上，本申请对这几部分具体部署位置不做限定，通常情况下，数据显示工具部署在测试终端，数据分析工具、数据统计工具及内存分配器可以部署在测试服务器上，当然，内存分配器也可以部署在测试终端上等，且对于内存分配器、数据统计工具、数据分析工具、数据显示工具可以是应用程序功能模块，关于各部分实现相应功能的具体过程，可以参照上述实施例相应部分的描述，本实施例不再赘述。

在实际应用中，对于本申请上述各实施例提出的内存泄露检测方法，可以在被测应用开发阶段，由测试人员利用测试终端及测试服务器实现对被测应用的内存泄露的检测；也可以是在被测应用实际应用中，根据应用的定期维护要求，对测试终端上的应用进行内存泄露检测，或者是被测应用的测试人员接收到一定量用户的问题反馈后，对该被测应用进行内存泄露检测等场景，但并不局限于本申请列举的这几种实施场景。

参照图8，为本申请提供的内存泄露检测装置的一种可选示例的结构图，该装置可以适用于计算机设备，该计算机设备可以是测试服务器，如图7所示，该装置可以包括：

随机抽样模块21，用于在被测应用多次运行过程中，对所述被测应用的内存分配信息进行随机抽样，得到待统计内存分配信息；

可选的，随机抽样模块21可以包括：

抽样率获取单元，用于获取所述被测应用本次运行期间的内存分配信息的抽样率，所述抽样率是动态可调的；

抽样记录单元，用于按照所述抽样率，对本次运行的所述被测应用的多次内存分配操作进行抽样，记录抽取到的内存分配操作所产生的内存分配信息；

确定单元，用于将所述被测应用多次运行所记录下的内存分配信息确定为待统计内存分配信息。

作为本申请另一可选示例，上述随机抽样模块21可以包括：

函数调用链路获取单元，用于获取所述被测应用在抽样时间点所调用函数的函数调用链路；

待统计内存分配信息获取单元，用于将所述函数调用链路转换成字符串格式的函数调用路径，并在所述函数调用路径结尾添加本次调用函数的内存分配量及抽样时间点，得到待统计内存分配信息；

数据写入单元，用于在得到的待统计内存分配信息的数量达到阈值的情况下，将所述待统计内存分配信息写入磁盘。

需要说明，本申请对该阈值的具体数值不做限定，可以依据内存空间大小确定。

分类统计模块22，用于按照所述被测应用的函数调用路径及抽样时间点，对所述待统计内存分类信息进行分类统计；

检测模块23，用于利用得到的分类统计结果，检测所述被测应用是否发生内存泄露。

本申请实际应用中，如图9所示，该分类统计模块22可以包括：

分类单元221，用于从所述待统计内存分配信息中，提取同一函数调用路径同一抽样时间点对应的内存分配量；

统计单元222，用于对同一函数调用路径同一抽样时间点对应的内存分配量求和，得到同一函数调用路径在不同抽样时间点的内存分配量。

相应地，检测模块23可以包括：

变化趋势获取单元231，用于获取同一函数调用路径在不同抽样时间点的内存分配量的变化趋势；

内存泄露检测单元232，用于在至少一个函数调用路径对应的所述变化趋势存在递增趋势的情况下，确定被测应用发生了内存泄露；

函数确定单元233，用于利用存在递增趋势的所述变化趋势对应的函数调用路径，得到所述被测应用中发生内存泄露的函数。

在上述各实施例的基础上，该装置还可以包括：

数据发送模块，用于将得到的分类统计结果，和/或所述被测应用是否发生内存泄露的检测结果发送至检测客户端，由所述检测客户端响应于查看操作，输出所述分类统计结果和/或所述检测结果。

进一步地，该装置还可以包括：

函数调用关系树生成模块，用于利用所述被测应用所调用函数的函数调用路径，生成函数调用关系树；

数据关联模块，用于将得到的分类统计结果与所述函数调用关系树中的相应函数进行关联，以使测试终端响应于对所述函数调用关系树中的任一函数的查看操作，输出所述函数对应的内存分配量变化趋势。

应该理解，上述各模块或单元均是应用程序模块，其实现相应功能的过程，可以参照上述方法实施例相应部分的描述。

本申请还提供了一种存储介质，其上存储有程序，该程序被处理器调用并执行，以实现上述内存泄露检测方法的各步骤。

参照图10，为本申请提供的一种计算机设备的硬件结构图，该计算机设备可以是上述测试服务器，具体可以包括：至少一个通信接口31、至少一个存储器32及至少一个处理器33，其中：

至少一个通信接口31、至少一个存储器32及至少一个处理器33可以通过通信总线，实现相互之间的数据交互。

通信接口31可以包括无线通信模块的接口，如WIFI模块、GPRS模块、GSM模块等通信模块的接口，以实现与其他设备的数据交互，如与测试终端进行通信连接，获取测试终端运行的被测应用的内存分配信息等，还可以与其他服务器，数据库等连接，可以依据具体场景需求确定；另外，通信接口还可以包括有线通信模块的接口，如串/并口等，以实现计算机设备内部数据交互，本申请对通信接口的类型不做限定。

存储器32可能包含高速RAM存储器，也可能还包括非易失性存储器(non-volatilememory)，例如至少一个磁盘存储器。

在本实施例中，该存储器32可以存储实现内存泄露检测方法的程序，还可以用于内存泄露检测过程中产生的各种中间数据，本申请不作详述。

处理器32可能是一个中央处理器CPU，或者是特定集成电路ASIC(ApplicationSpecific Integrated Circuit)，或者是被配置成实施本申请实施例的一个或多个集成电路。

本实施例中，处理器32可以调用存储器31所存储的程序，以实现上述内存泄露检测方法的各步骤，具体实现过程可以参照上述方法实施例相应部分的描述，本实施例不再赘述。

参照上图1，本申请实施例还提供了一种内存泄露检测***，该***可以包括测试终端11和测试服务器12，其中：

测试服务器12的组成结构及其功能，可以参照上述计算机设备实施例的描述，不再赘述。

测试终端11可以用于运行被测应用，并输出测试服务器反馈的被测应用是否发生内存泄露的检测结果，分类统计结果等数据。

结合上述方法实施例的描述，该测试终端11还可以用于输出所述被测应用的函数调用关系树，响应于针对所述函数调用关系树中的任一函数的查看操作，输出所述函数对应的内存分配量变化趋势等等，关于测试终端11在内存泄露检测场景中所实现的功能，可以参照上述方法实施例相应部分的描述，本实施例不作详述。

可选的，参照图11，为本申请提出的一种测试终端的硬件结构示意图，该测试终端可以包括：显示器41、输入设备42、存储器43、处理器44、电源装置45、声音采集/播放装置46及多个传感器47等，本申请对测试终端的组成结构不做限定，可以依据其产品类型确定，且关于图11中测试终端各组成部分的具体功能，可以依据实际场景需求确定，本申请在此不做详述。

其中，声音采集/播放装置46可以包括麦克风、喇叭等设备、多个传感器47可以包括压力传感器、温度传感器、重力传感器、位移传感器等等，可以依据测试终端的应用需求确定，本申请不做一一列举。

最后，需要说明的是，本说明书中各个实施例采用递进或并列的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置、计算机设备、***而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (10)

1.一种内存泄露检测方法，其特征在于，所述方法包括：

在被测应用多次运行过程中，对所述被测应用的内存分配信息进行随机抽样，得到待统计内存分配信息；

按照所述被测应用的函数调用路径及抽样时间点，对所述待统计内存分类信息进行分类统计；

利用得到的分类统计结果，检测所述被测应用是否发生内存泄露。

2.根据权利要求1所述的方法，其特征在于，所述对所述被测应用的内存分配信息进行随机抽样，得到待统计内存分配信息，包括：

获取所述被测应用本次运行期间的内存分配信息的抽样率，所述抽样率是动态可调的；

按照所述抽样率，对本次运行的所述被测应用的多次内存分配操作进行抽样，记录抽取到的内存分配操作所产生的内存分配信息；

将所述被测应用多次运行所记录下的内存分配信息确定为待统计内存分配信息。

3.根据权利要求1所述的方法，其特征在于，所述按照所述被测应用的函数调用路径及抽样时间点，对所述待统计内存分类信息进行分类统计，包括：

对所述待统计内存分配信息中，同一函数调用路径同一抽样时间点对应的内存分配量求和，得到同一函数调用路径在不同抽样时间点的内存分配量；

所述利用得到的分类统计结果，检测所述被测应用是否发生内存泄露，包括：

获取同一函数调用路径在不同抽样时间点的内存分配量的变化趋势；

若至少一个函数调用路径对应的所述变化趋势存在递增趋势，确定被测应用发生了内存泄露，并利用存在递增趋势的所述变化趋势对应的函数调用路径，得到所述被测应用中发生内存泄露的函数。

4.根据权利要求1所述的方法，其特征在于，所述对所述被测应用的内存分配信息进行随机抽样，得到待统计内存分配信息，包括：

获取所述被测应用在抽样时间点所调用函数的函数调用链路；

将所述函数调用链路转换成字符串格式的函数调用路径，并在所述函数调用路径结尾添加本次调用函数的内存分配量及抽样时间点，得到待统计内存分配信息；

在得到的待统计内存分配信息的数量达到阈值，将所述待统计内存分配信息写入磁盘。

5.根据权利要求1～4任一项所述的方法，其特征在于，所述方法还包括：

将得到的分类统计结果，和/或所述被测应用是否发生内存泄露的检测结果发送至检测客户端，由所述检测客户端响应于查看操作，输出所述分类统计结果和/或所述检测结果。

6.根据权利要求5所述的方法，其特征在于，所述方法还包括：

利用所述被测应用所调用函数的函数调用路径，生成函数调用关系树；

将得到的分类统计结果与所述函数调用关系树中的相应函数进行关联，以使测试终端响应于对所述函数调用关系树中的任一函数的查看操作，输出所述函数对应的内存分配量变化趋势。

7.一种内存泄露检测装置，其特征在于，所述装置包括：

随机抽样模块，用于在被测应用多次运行过程中，对所述被测应用的内存分配信息进行随机抽样，得到待统计内存分配信息；

分类统计模块，用于按照所述被测应用的函数调用路径及抽样时间点，对所述待统计内存分类信息进行分类统计；

检测模块，用于利用得到的分类统计结果，检测所述被测应用是否发生内存泄露。

8.一种计算机设备，其特征在于，所述计算机设备包括：

通信接口；

存储器，用于存储实现如权利要求1～6任一项所述的内存泄露检测方法的程序；

处理器，用于调用并执行所述存储器的程序，以实现如权利要求1～6任一项所述的内存泄露检测方法的各个步骤。

9.一种内存泄露检测***，其特征在于，所述***包括：测试服务器和测试终端，其中：

所述测试服务器为如权利要求8所述的计算机设备；

所述测试终端用于运行被测应用，并输出所述测试服务器反馈的所述被测应用是否发生内存泄露的检测结果。

10.根据权利要求9所述的***，其特征在于，所述测试终端还用于：

输出所述被测应用的函数调用关系树，响应于针对所述函数调用关系树中的任一函数的查看操作，输出所述函数对应的内存分配量变化趋势。

Images