CN108121602B - 一种确定垃圾收集触发点的方法、电子设备及存储介质 - Google Patents

Abstract

本申请公开了一种确定垃圾收集触发点的方法、电子设备及存储介质，该方法包括获取触发垃圾收集的时间；从应用程序进行内存申请的多个内存申请信息中，筛选出预先设定的目标应用程序的第一类内存申请信息；将第一类内存申请信息与触发垃圾收集的时间进行匹配，得到触发垃圾收集的内存申请信息；其中，内存申请信息至少包括内存申请的时间。通过对多个内存申请信息进行筛选，得到第一类内存申请信息，再将第一类内存申请信息与触发垃圾收集的时间进行匹配，得到触发垃圾收集的内存申请，从而找到触发垃圾收集的位置。

Description

一种确定垃圾收集触发点的方法、电子设备及存储介质

技术领域

本申请涉及计算机技术领域，具体涉及一种确定垃圾收集触发点的方法、电子设备及存储介质。

背景技术

大量使用内存的应用可能引起系统垃圾收集，但是没办法直接分析内存泄露对应的具体代码行，导致内存泄露的分析只能通过集成开发环境自带的工具逐个去寻找、分离无效或不关注的内存分配，最终筛选出可能有问题的内存申请，这种分析方法既原始又效率低。

发明内容

本申请主要解决的问题是提供一种确定垃圾收集触发点的方法、电子设备及存储介质，能够找到触发垃圾收集的具体位置，有助于分析内存泄漏问题。

为解决上述技术问题，本申请采用的技术方案是提供一种确定垃圾收集触发点的方法，该方法包括获取触发垃圾收集的时间；从应用程序进行内存申请的多个内存申请信息中，筛选出预先设定的目标应用程序的第一类内存申请信息；将第一类内存申请信息与触发垃圾收集的时间进行匹配，得到触发垃圾收集的内存申请信息；其中，内存申请信息至少包括内存申请的时间。

为解决上述技术问题，本申请采用的另一技术方案是提供一种电子设备，该电子设备包括互相连接的存储器和处理器，存储器用于存储计算机程序，计算机程序在被处理器执行时，用以实现上述的方法。

为解决上述技术问题，本申请采用的另一技术方案是提供一种存储介质，该存储介质用于存储计算机程序，计算机程序在被处理器执行时，用以实现上述的方法。

通过上述方案，本申请的有益效果是：首先对多个内存申请信息进行筛选，得到第一类内存申请信息，再将第一类内存申请信息与触发垃圾收集的时间进行匹配，从而得到触发垃圾收集的内存申请；通过筛选和匹配两个操作，无需逐一查找多个内存申请信息，快速找到触发垃圾收集的程序代码位置。

附图说明

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

图1是本申请提供的确定垃圾收集触发点的方法第一实施例的流程示意图；

图2是本申请提供的确定垃圾收集触发点的方法第二实施例的流程示意图；

图3是本申请提供的确定垃圾收集触发点的方法第三实施例的流程示意图；

图4是本申请提供的确定垃圾收集触发点的方法第四实施例的流程示意图；

图5是本申请提供的确定垃圾收集触发点的方法第五实施例的流程示意图；

图6是本申请提供的确定垃圾收集触发点的方法第六实施例的流程示意图；

图7是本申请提供的电子设备一实施例的结构示意图；

图8是本申请提供的电子设备另一实施例的结构示意图；

图9是本申请提供的存储介质一实施例的结构示意图。

具体实施方式

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

参阅图1，图1是本申请提供的确定垃圾收集触发点的方法第一实施例的流程示意图，该方法包括：

步骤11：获取触发垃圾收集的时间。

垃圾收集(Gabage Collection，GC)意味着程序不再需要的对象是“无用信息”，这些信息将被丢弃回收；垃圾收集可以有效的防止内存泄露，有效的使用空闲的内存。

内存泄漏指由于错误的设计造成程序未能释放已经不再使用的内存，造成资源浪费。垃圾收集会自动清理失去引用的对象所占用的内存，但是，由于程序设计错误而导致某些对象始终被引用，那么将会出现内存泄漏。

Java是一种面向对象的语言，Java具有简单性、面向对象、分布式、健壮性、安全性、平台独立与可移植性、多线程、动态性等特点。虽然JAVA有完善的垃圾收集机制，但是该垃圾收集机制无法避免内存泄漏。

应用程序运行时需要申请内存空间，当某个应用程序申请的内存量超过一定范围时，可能就会触发垃圾收集机制，此时系统发送消息通知触发了垃圾收集，记录该时间，在同一时刻可能收到几条触发垃圾收集的消息。其中，该时间可以是系统运行的时间。

步骤12：从应用程序进行内存申请的多个内存申请信息中，筛选出预先设定的目标应用程序的第一类内存申请信息。

其中，内存申请信息至少包括内存申请的时间；可选的，内存申请信息还可以包括触发垃圾收集的程序代码的位置信息。

可选的，预先设定的目标应用程序可以为预先接收用户指令选择的应用程序，在多个应用程序中，选择出预先设定的目标应用程序，具体地，可以是内存占用率较高、使用率较高、或者后台运行较频繁的应用程序。例如：QQ、微信等聊天应用程序、音频或视频播放应用程序、游戏类应用程序；这些程序若未在前台使用，则可以认定为是可以被垃圾收集的应用程序。

可选的，预先设定的目标应用程序还可以为申请内存量大于设定内存申请量阈值的应用程序。

例如，假设预先设定的目标应用程序为申请内存量大于设定内存申请量阈值的应用程序，这里以设定内存申请量阈值是100MB为例，当某一应用程序所申请的内存大于100MB时，该应用程序将被筛选出来，其内存信息属于第一类内存申请信息。

步骤13：将第一类内存申请信息与触发垃圾收集的时间进行匹配，得到触发垃圾收集的内存申请信息。

在步骤12中对所有内存信息进行第一次筛选，从所有内存信息中筛选出第一类内存申请信息之后，将对筛选后的第一类内存申请信息进行第二次筛选。由于在步骤11中获取了触发垃圾收集的时间，内存申请信息中又包含了内存申请的时间，因此可以将第一类内存申请信息中的时间信息与触发垃圾收集的时间进行匹配，从而得到触发垃圾收集的内存申请信息。由于内存申请信息包含触发垃圾收集的程序代码的位置信息；因此，在找到内存申请信息后，便可找到触发垃圾收集的程序代码的位置信息。

可以理解的，触发垃圾收集的程序代码的位置信息可以预先存储在内存申请信息中；也可以在查找到触发垃圾收集的内存信息之后，再查找触发垃圾收集的程序代码的位置信息。

例如，第一类内存申请信息包含3条信息A、B和C，信息A对应的时间为3s，信息B对应的时间为3.1s，信息C对应的时间为3.5s，触发垃圾收集的时间为3.1s，则信息B为触发垃圾收集的信息，信息B中包含触发垃圾收集的位置信息。

可理解的，当第一类内存申请信息中只包含一种应用程序的信息时，可以不将第一类内存信息与触发垃圾收集的时间进行匹配。例如，第一类内存申请信息只包含信息A，则信息A即为触发垃圾收集的内存申请信息，无需再进行匹配操作。

区别于现有技术，本实施例提供的确定垃圾收集触发点的方法，首先获取触发垃圾收集的时间；其次从应用程序进行内存申请的多个内存申请信息中，筛选出预先设定的目标应用程序的第一类内存申请信息；最后将第一类内存申请信息与触发垃圾收集的时间进行匹配，得到触发垃圾收集的内存申请信息；其中，内存申请信息至少包括内存申请的时间。首先对多个内存申请信息进行筛选，得到第一类内存申请信息，再将第一类内存申请信息与触发垃圾收集的时间进行匹配，从而得到触发垃圾收集的内存申请；通过筛选和匹配两个操作，无需逐一查找多个内存申请信息，快速找到触发垃圾收集的程序代码位置。

参阅图2，图2是本申请提供的确定垃圾收集触发点的方法第二实施例的流程示意图，该方法包括：

步骤21：获取触发垃圾收集的时间。

步骤22：从应用程序进行内存申请的多个内存申请信息中，筛选出预先设定的目标应用程序的第一类内存申请信息。

其中，步骤21和步骤22可以具体参考上述步骤11和步骤12，这里不再赘述。

步骤23：从第一类内存申请信息中，筛选出申请频率大于设定频率阈值的第二类内存申请信息。

可以理解的，一个应用程序可以多次进行内存申请，这种频繁进行内存申请的应用程序也极有可能引起垃圾收集触发；因此，在本步骤中，需要筛选出申请频率较高的应用程序对应的内存申请信息。

在从所有应用程序的内存信息中筛选出第一类内存申请信息之后，统计第一内存申请信息中对应的每个应用程序出现的频率，将第一内存申请信息中申请频率大于设定频率阈值的信息筛选出来，即为第二类内存申请信息。

例如，第一类内存申请信息包含3条信息A、B和C，信息A对应的时间为3s，信息B对应的时间为3.1s，信息C对应的时间为3s，触发垃圾收集的时间位3s，信息A对应的应用程序在5秒内申请了100次内存，信息B对应的应用程序在5秒内申请了84次内存，信息C对应的应用程序在5秒内申请了96次内存，设定频率阈值为20次/秒，则第二类内存申请信息为信息A。

步骤24：将第二类内存申请信息与触发垃圾收集的时间进行匹配，得到触发垃圾收集的内存申请信息。

与第一实施例类似，此步骤中将第二类内存申请信息中的时间信息与触发垃圾收集的时间进行匹配，从而得到触发垃圾收集的内存申请信息。

区别于现有技术，本实施例提供的确定垃圾收集触发点的方法，首先从应用程序的内存申请信息中筛选出第一类内存申请信息，再利用第一类内存申请信息中内存申请频率从第一类内存申请信息筛选出第二类内存申请信息，再将第二类内存申请信息与触发垃圾收集的时间进行匹配。通过两次筛选，缩小查找触发垃圾收集的内存申请的范围，快速找到符合要求的内存申请位置。

参阅图3，图3是本申请提供的确定垃圾收集触发点的方法第三实施例的流程示意图，该方法包括：

步骤31：获取触发垃圾收集的时间。

步骤32：从应用程序进行内存申请的多个内存申请信息中，筛选出预先设定的目标应用程序的第一类内存申请信息。

其中，步骤31和步骤32可以具体参考上述步骤11和步骤12，这里不再赘述。

步骤33：获取第一类内存申请信息中不同应用程序的内存申请次数。

一个应用程序运行时可能会申请多次内存，这种在设定时间中申请多次申请内存的应用程序可能会由于申请的内存的积累导致垃圾收集。例如，对于一个循环程序，需要循环的次数是1000次，每次执行循环语句时申请内存200KB，执行到500次时，就因为内存不够引起了垃圾收集。因此，在本步骤中，需要统计第一类内存申请信息中不同应用程序的内存申请次数。

步骤34：筛选出在设定时间阈值内申请次数大于设定次数阈值的第二类内存申请信息。

在获取第一类内存申请信息中不同应用程序的内存申请次数之后，计算在设定时间阈值内各信息出现的次数，将在设定时间阈值内申请次数大于设定次数阈值的内存申请信息筛选出来，被筛选出来的内存申请信息即为第二类内存申请信息。

步骤35：将第二类内存申请信息与触发垃圾收集的时间进行匹配，得到触发垃圾收集的内存申请信息。

其中，步骤35可以具体参考上述步骤24，这里不再赘述。

区别于现有技术，本实施例提供的确定垃圾收集触发点的方法，首先从应用程序的内存申请信息中筛选出第一类内存申请信息，再通过获取第一类内存申请信息中不同应用程序的内存申请次数，筛选出在设定时间阈值内申请次数大于设定次数阈值的第二类内存申请信息，找到频繁申请内存的应用程序对应的信息。通过两次筛选，将内存申请次数作为筛选指标，将触发垃圾收集的内存申请的范围缩小，从而找到触发垃圾收集的内存申请位置。

参阅图4，图4是本申请提供的确定垃圾收集触发点的方法第四实施例的流程示意图，该方法包括：

步骤41：获取触发垃圾收集的时间。

步骤42：从应用程序进行内存申请的多个内存申请信息中，筛选出内存申请量大于设定内存申请量阈值的第一类内存申请信息。

其中，步骤41和步骤42可以具体参考上述步骤11和步骤12，这里不再赘述。

步骤43：将第一类内存申请信息中的多个内存申请信息按照申请量从大到小进行排序。

例如，第一类内存申请信息包含3条信息A、B和C，信息A的内存申请量为50M，信息B的内存申请量为20M，信息C的内存申请量为60M，则排序后的第一类内存申请信息中各信息依次为信息C、信息A和信息B。

步骤44：按照申请量从大到小的顺序依次记录第一类内存申请信息中不同应用程序的内存申请次数。

步骤45：筛选出在设定时间段内申请次数大于设定次数阈值的内存申请信息。

例如，第一类内存申请信息包含3条信息A、B和C，第一类内存申请中各信息、内存申请量如下表所示：

信息类别	A	B	C
				内存申请量	40M	10M	20M

信息A申请内存的次数为2次，信息B申请内存的次数为5次，信息C申请内存的次数为3次。在执行步骤44之后，第一类内存申请信息中不同应用程序信息的排列如下表所示：

信息类别	内存申请量	申请次数
			A	40M	2
C	20M	3
			B	10M	5

假如设定次数阈值为2次，则在执行步骤45之后，第二类内存申请信息为信息B和信息C。

步骤46：将第二类内存申请信息与触发垃圾收集的时间进行匹配，得到触发垃圾收集的内存申请信息。

其中，步骤46可以具体参考上述步骤24，这里不再赘述。

区别于现有技术，本实施例通过从应用程序的内存申请中筛选出第一类内存申请信息，对第一类内存申请信息中的各信息按照申请量的大小进行由大到小的排序，统计第一类内存申请信息中的各信息对应的应用程序申请内存的次数，将申请次数超过预设值的内存申请信息筛选出来，形成第二类内存申请信息，再将第二类内存申请信息中的时间与触发垃圾收集的时间进行匹配，从而找到触发垃圾收集的内存申请信息。

参阅图5，图5是本申请提供的确定垃圾收集触发点的方法第五实施例的流程示意图，该方法包括：

步骤51：获取触发垃圾收集的时间。

其中，步骤51可以具体参考上述步骤11，这里不再赘述。

步骤52：从安卓系统的虚拟机中获取多个内存申请信息。

为了查找触发垃圾收集的内存申请，首先要从安卓系统的虚拟机中获取多个内存申请信息。

步骤53：从应用程序进行内存申请的多个内存申请信息中，筛选出预先设定的目标应用程序的第一类内存申请信息。

步骤54：将第一类内存申请信息与触发垃圾收集的时间进行匹配，得到触发垃圾收集的内存申请信息。

其中，步骤53和步骤54可以具体参考上述步骤12和步骤13，这里不再赘述。

区别于现有技术，本实施例通过从安卓系统的虚拟机中获取多个内存申请信息，对获取到的内存申请信息进行筛选，缩小可能触发垃圾收集的内存申请信息的范围，再将缩小范围后的内存申请信息的时间与触发垃圾收集的时间进行匹配，从而找到触发垃圾收集的代码所在位置。

参阅图6，图6是本申请提供的确定垃圾收集触发点的方法第六实施例的流程示意图，该方法包括：

步骤61：获取触发垃圾收集的时间。

其中，步骤61可以具体参考上述步骤11，这里不再赘述。

步骤62：加载libdvm动态库。

libdvm是系统的一个链接库，在运行程序时需要加载该动态库以使得程序正常运行。

步骤63：从libdvm动态库中获取DvmGlobals全局变量。

DvmGlobals全局变量为一个全局结构体，libdvm内导出了一个该结构体的实例，可以通过载入libdvm动态库，去获得该变量。

步骤64：从DvmGlobals全局变量中获取allocRecords变量，得到应用程序进行内存申请的多个内存申请信息。

allocRecords变量记录了所有内存分配的详细信息，可以通过遍历该变量搜索到所有的内存申请信息，从而分析触发垃圾收集的内存信息。

步骤65：从应用程序进行内存申请的多个内存申请信息中，筛选出预先设定的目标应用程序的第一类内存申请信息。

步骤66：将第一类内存申请信息与触发垃圾收集的时间进行匹配，得到触发垃圾收集的内存申请信息。

其中，步骤65和步骤66可以具体参考上述步骤12和步骤13，这里不再赘述。

区别于现有技术，本实施例通过加载系统的libdvm动态库，获取DvmGlobals全局变量，从DvmGlobals全局变量中获取allocRecords变量，得到应用程序进行内存申请的多个内存申请信息；在获取到内存申请信息之后，对内存申请信息进行筛选，再将筛选后的信息中的时间与触发垃圾收集的时间进行匹配，从而找到触发垃圾收集的程序代码的位置，无需逐个的去寻找、分离无效或不关注的内存申请信息，效率高而且便捷。

参阅图7，图7是本申请提供的电子设备一实施例的结构示意图。该电子设备70包括互相连接的存储器71和处理器72，存储器71用于存储计算机程序，计算机程序在被处理器72执行时，用以实现上述实施例的方法。可以理解的，在本实施例中的电子设备70，所用来执行的方法与上述实施例提供的方法类似，其原理和步骤相同，这里不再赘述。

参阅图8，图8是本申请提供的电子设备另一实施例的结构示意图。该电子设备包括：

获取模块81，用于获取触发垃圾收集的时间。

当某一应用程序引起了垃圾收集，获取模块81将触发垃圾收集的时间记录下来；其中，该时间可以为系统运行的时间。

筛选模块82，用于从应用程序进行内存申请的多个内存申请信息中，筛选出预先设定的目标应用程序的第一类内存申请信息。

其中，内存申请信息至少包括内存申请的时间；可选的，内存申请信息还可以包括触发垃圾收集的程序代码的位置信息。

预先设定的目标应用程序可以为预先接收用户指令选择的应用程序或申请内存量大于设定内存申请量阈值的应用程序。

匹配模块83，用于将第一类内存申请信息与触发垃圾收集的时间进行匹配，得到触发垃圾收集的内存申请信息。

筛选模块82对所有内存信息进行了第一次筛选，在从所有内存信息中筛选出第一类内存申请信息之后，将对筛选后的第一类内存申请信息进行第二次筛选，即利用匹配模块进行第二次筛选。

由于获取模块81获取了触发垃圾收集的时间，内存申请信息中又包含了内存申请的时间，因此可以将第一类内存申请信息中的时间信息与触发垃圾收集的时间进行匹配，从而得到触发垃圾收集的内存申请信息。由于内存申请信息包含触发垃圾收集的程序代码的位置信息，因此，在找到内存申请信息后，便可找到触发垃圾收集的程序代码的位置信息。

参阅图9，图9是本申请提供的存储介质一实施例的结构示意图。该存储介质90用于存储计算机程序91，该计算机程序91被处理器执行以实现上述实施例中提供的方法。可以理解的，在本实施例中的存储介质90存储的计算机程序91，所用来执行的方法与上述实施例提供的方法类似，其原理和步骤相同，这里不再赘述。

其中，该存储介质90包括：服务器、U盘、移动硬盘、只读存储器(ROM，Read－OnlyMemory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

在本申请所提供的几个实施方式中，应该理解到，所揭露的方法以及设备，可以通过其它的方式实现。例如，以上所描述的设备实施方式仅仅是示意性的，例如，模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。

作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施方式方案的目的。

另外，在本申请各个实施方式中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

以上仅为本申请的实施例，并非因此限制本申请的专利范围，凡是利用本申请说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本申请的专利保护范围内。

Claims (9)

1.一种确定垃圾收集触发点的方法，其特征在于，包括：

获取触发垃圾收集的时间；

从应用程序进行内存申请的多个内存申请信息中，筛选出预先设定的目标应用程序的第一类内存申请信息；

将所述第一类内存申请信息与所述触发垃圾收集的时间进行匹配，得到触发垃圾收集的内存申请信息；

根据所述触发垃圾收集的内存申请信息中包含的所述触发垃圾收集的程序代码的位置信息，找到所述触发垃圾收集的程序代码；

其中，所述内存申请信息至少包括内存申请的时间和所述触发垃圾收集的程序代码的位置信息。

2.根据权利要求1所述的方法，其特征在于，

所述从应用程序进行内存申请的多个内存申请信息中，筛选出预先设定的目标应用程序的第一类内存申请信息的步骤之后，还包括：

从所述第一类内存申请信息中，筛选出申请频率大于设定频率阈值的第二类内存申请信息；

所述将所述第一类内存申请信息与所述触发垃圾收集的时间进行匹配，得到触发垃圾收集的内存申请信息的步骤，具体为：

将所述第二类内存申请信息与所述触发垃圾收集的时间进行匹配，得到触发垃圾收集的内存申请信息。

3.根据权利要求2所述的方法，其特征在于，

所述从所述第一类内存申请信息中，筛选出申请频率大于设定频率阈值的第二类内存申请信息的步骤，包括：

获取第一类内存申请信息中不同应用程序的内存申请次数；

筛选出在设定时间阈值内申请次数大于设定次数阈值的第二类内存申请信息。

4.根据权利要求3所述的方法，其特征在于，

所述获取第一类内存申请信息中不同应用程序的内存申请次数的步骤，包括：

将所述第一类内存申请信息中的多个内存申请信息按照申请量从大到小进行排序；

按照申请量从大到小的顺序依次记录第一类内存申请信息中不同应用程序的内存申请次数。

5.根据权利要求1所述的方法，其特征在于，

所述目标应用程序为内存申请量大于设定内存申请量阈值的应用程序。

6.根据权利要求1所述的方法，其特征在于，

所述从应用程序进行内存申请的多个内存申请信息中，筛选出预先设定的目标应用程序的第一类内存申请信息的步骤之前，还包括：

从安卓系统的虚拟机中获取多个内存申请信息。

7.根据权利要求6所述的方法，其特征在于，

所述从安卓系统的虚拟机中获取多个内存申请信息的步骤，包括：

加载libdvm动态库；

从所述libdvm动态库中获取DvmGlobals全局变量；

从所述DvmGlobals全局变量中获取allocRecords变量，得到应用程序进行内存申请的多个内存申请信息。

8.一种电子设备，其特征在于，包括互相连接的存储器和处理器，所述存储器用于存储计算机程序，所述计算机程序在被所述处理器执行时，用以实现如权利要求1-7任一项所述的方法。

9.一种存储介质，其特征在于，所述存储介质用于存储计算机程序，所述计算机程序在被处理器执行时，用以实现如权利要求1-7任一项所述的方法。

Images