内存检测方法、装置及电子设备与流程

本申请涉及计算机技术领域，尤其涉及一种内存检测方法、装置及电子设备。

背景技术：

在应用程序实际的运行过程中，导致内存溢出的因素很多，例如，技术人员由于疏忽或错误造成应用程序未能释放已经不再使用的内存，可能会出现内存泄漏，而内存泄漏会导致内存溢出。对于应用程序已经发布上线的情形，线上环境出现的内存溢出问题通常由于线上环境复杂，技术人员难以通过线下复现的方式排查线上环境导致内存溢出的原因。

技术实现要素：

有鉴于此，本申请提供一种新的技术方案，可以利用电子设备有限的内存资源对应用程序出现内存泄漏的问题进行实时分析。

为实现上述目的，本申请提供技术方案如下：

根据本申请的第一方面，提出了一种内存检测方法，包括：

当监测到应用程序在运行过程中占用的内存需要检测时，确定与所述应用程序相关的第一实例集合；

基于所述第一实例集合中每一个实例占用的内存值，从所述第一实例集合中确定用于分析所述应用程序出现内存泄漏的第二实例集合；

基于所述第二实例集合中每一个实例的路径信息，生成关于所述应用程序出现内存泄漏的检测结果。

根据本申请的第二方面，提出了一种内存检测装置，包括：

第一确定单元，用于当监测到应用程序在运行过程中占用的内存需要检测时，确定与所述应用程序相关的第一实例集合；

第二确定单元，用于基于所述第一确定单元确定的所述第一实例集合中每一个实例占用的内存值，从所述第一实例集合中确定用于分析所述应用程序出现内存泄漏的第二实例集合；

检测结果生成单元，用于基于所述第二确定单元确定的所述第二实例集合中每一个实例的路径信息，生成关于所述应用程序出现内存泄漏的检测结果。

根据本申请的第三方面，提出了一种计算机可读存储介质，所述存储介质存储有计算机程序，所述计算机程序用于执行上述第一方面提出的内存检测方法。

根据本申请的第四方面，提出了一种电子设备，所述电子设备包括：存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述第一方面提供的内存检测方法。

由以上技术方案可见，由于第二实例集合中包含的实例的数量远远小于堆内存中的实例的数量，因此可以确保在复杂的线上环境中，利用电子设备有限的内存资源，通过第二实例集合中的每一个实例的路径信息对应用程序出现内存泄漏的问题进行实时分析，便于查找造成应用程序出现内存溢出的原因，使测试人员根据检测结果快速定位出现内存溢出的位置，进而可改进出现内存溢出的代码，提高应用程序的稳定性。

附图说明

图1是本申请一示例性实施例示出的内存检测方法的流程示意图；

图2是本申请另一示例性实施例示出的内存检测方法的流程示意图；

图3a是本申请再一示例性实施例示出的内存检测方法的流程示意图；

图3b是图3a所示实施例中的实例的路径示意图；

图3c是经过图3a所示实施例合并实例之后的示意图；

图4a是本申请再一示例性实施例示出的内存检测方法的流程示意图；

图4b是图4a所示实施例中的第二实例集合的示意图；

图4c是图4a所示实施例中对第二实例集合进行扩容的示意图；

图4d是图4a所示实施例中对第二实例集合进行置换的示意图；

图5a是本申请又一示例性实施例示出的内存检测方法的流程示意图；

图5b是图5a所示实施例中应用程序在运行过程中的内存值的示意图；

图5c是图5a所示实施例中的波谷点的示意图；

图6是本申请一示例性实施例示出的内存检测装置的结构示意图；

图7是本申请另一示例性实施例示出的内存检测装置的结构示意图；

图8是本申请一示例性实施例示出的电子设备的结构示意图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

本申请涉及到的基础定义：

实例：是根据类创建出来的一个个具体的“对象”。

实例属性：包括实例自身的信息以及与实例相关的信息，实例自身的信息可包括：实例的名称、实例本身大小(shallowsize)、实例被回收可释放的总内存大小(retainsize)、用于查找泄漏路径信息(mhardreferences)等，与实例相关的信息可包括：实例的直接掌控者(mimmediatedominator)的信息，也可以理解为父实例的信息，例如，父实例的名称、序列号(id)以及大小等。

内存泄露：也称作“存储渗漏”，用动态存储分配函数动态开辟的内存空间，在该内存空间使用完毕后未释放而一直被占据，直到程序结束。

内存溢出：指程序在申请内存时，没有足够的内存空间供其使用。

图1是本申请一示例性实施例示出的内存检测方法的流程示意图；本申请可以应用在电子设备上，通过开发第三方程序或者第三方库的方式实现，当应用程序接入到该第三方程序或者第三方库时，通过第三方程序或者第三方库检测应用程序在运行过程中占用的内存，如图1所示，包括如下步骤：

步骤101，当监测到应用程序在运行过程中占用的内存需要检测时，确定与应用程序相关的第一实例集合。

在一实施例中，可通过应用程序的内存的快照文件获取与应用程序相关的第一实例集合，例如，在应用程序运行过程中，通过dump命令生成hprof文件，解析hprof文件得到快照文件，从快照文件中确定与应用程序相关的堆内存(heap)。在堆内存中包括与该应用程序相关的大量实例，每个实例具有实例名称、本身大小(shallowsize)和被回收可释放的总内存大小(retainsize)等属性。

进一步地，在解析hprof文件的过程中，可存储已解析的实例以及记录已解析的实例的名称以及实例本身大小，将当前正在解析的实例的名称与已存储的实例的实例名称以及实例本身大小进行比较，若已存储的具有相同实例名称并且具有相同本身大小的实例的数量等于第一预设阈值，可以在后续解析过程中将与该实例名称相同并且具有相同本身大小的实例丢弃，从而可以将相同名称并且具有相同本身大小的实例的数量控制在第一预设阈值以内，确保本申请在检测内存泄漏时占用较少的内存。

步骤102，基于第一实例集合中每一个实例占用的内存值，从第一实例集合中确定用于分析应用程序出现内存泄漏的第二实例集合。

与上述步骤101的描述相对应，在步骤102中，可以先统计第一实例集合中的具有相同实例名称并且具有相同大小的实例，得到多个实例组，其中，多个实例组中的每一个实例组包括至少一个实例；对每一个实例组中的实例的内存值进行加和，得到多个实例组各自对应的内存和值；基于多个实例组各自对应的内存和值，对实例组按照预设顺序进行排序；基于内存和值由大到小的顺序，确定排在前设定位数的实例组，排在前设定位数的实例组形成用于分析应用程序出现内存泄漏的第二实例集合。在一实施例中，每一个实例组中可以包括多个具有相同实例名称并且大小相同的实例，例如，实例“abc1”和实例“abc2”为实例名称相同并且大小相同，则可以为被统计到一个实例组中；实例“abc3”和实例“abc4”为实例名称相同并且大小相同，实例“abc1”与实例“abc3”为实例名称相同但大小不相同，则实例“abc3”和实例“abc4”可被统计到另一个实例组中；实例“abc1”和实例“bcd2”为名称不同的实例，则可以需要被统计不同的实例组中。

在一实施例中，每一个实例组中的实例的内存值可以为实例被回收可释放的总内存大小(retainsize)。

在一实施例中，可以基于第一实例集合中每一个实例占用的内存值大小，通过堆排序法、快速排序法、冒泡排序法等，将第一实例集合中的实例按照占用的内存值以预设顺序(例如，由大到小或者由小到大)排序，例如，当由大到小排序时，从第二实例集合中确定出大小排在前设定位数的实例，该排在前设定位数的实例可视为本申请中的第二实例集合，当由小到大排序时，从第二实例集合中确定出大小排在后设定位数的实例，该排在后设定位数的实例可视为本申请中的第二实例集合。

步骤103，基于第二实例集合中每一个实例的路径信息，生成关于应用程序出现内存泄漏的检测结果。

在一实施例中，路径信息表示每一个实例到垃圾回收器中的根对象(gcroot)所经过的所有父实例的信息，父实例的信息可包括父实例的名称、父实例被回收可释放的总内存大小(retainsize)等，其中一个实例的路径信息例如：

*gcrootthreadjava.lang.thread.<javalocal>(named'threadnamenotavailable')

*referencesjava.util.arraylist.array

*referencesarrayjava.lang.object[].[0]

*leakscom.amap.api.col.aj$a。

本领域技术人员可以理解的是，同一个应用程序中可包含多个根对象(gcroot)，因此不同的实例可能对应不同的根对象。

现举例说明本实施例：例如，当监测到应用程序在运行过程中占用的内存需要检测时，若通过dump命令生成的hprof文件中包含有20万个实例，通过步骤101的描述可以从这20万个实例中，统计出具有相同名称以及相同本身大小的实例，并控制具有相同名称以及相同本身大小的实例的数量小于或者等于第一预设阈值，从而可以使第一实例集合中包含的实例的数量远远小于hprof文件中包含的实例的数量，例如，从这20万个实例中通过步骤101的描述得到5万个实例，则该5万个实例形成的集合即可视为本申请所述的第一实例集合。通过上述步骤202的描述可对这5万个实例进行分组，得到多个实例组(例如，500个实例组)。对这500个实例组中的每一个实例组的实例的内存值进行加和，得到每一个实例组对应的内存和值，例如，共有500个内存和值，通过对这500个内存和值进行由大到小的顺序排序，得到排在前100的实例组，则这100个实例组可视为本申请中的第二实例集合。基于这100个实例组中的每一个实例的路径信息，可生成关于应用程序出现内存泄漏的检测结果。

对于第二实例集合中的每一个实例的路径信息，组成检测结果。此外，检测结果可以通过文本的方式上报给服务器，还可以在电子设备本地通过文本的方式展示给用户。

本实施例通过上述步骤101-步骤103，由于第二实例集合中包含的实例的数量远远小于堆内存中的实例的数量，因此可以确保在复杂的线上环境中，利用电子设备有限的内存资源，通过第二实例集合中的每一个实例的路径信息对应用程序出现内存泄漏的问题进行实时分析，便于查找造成应用程序出现内存泄漏的原因，使测试人员根据检测结果快速定位出现内存泄漏的位置，进而可改进出现内存泄漏的代码，提高应用程序的稳定性。

图2是本申请另一示例性实施例示出的内存检测方法的流程示意图；本实施例在上述实施例的基础上，以如何确定与应用程序相关的第一实例集合为例进行示例性说明，如图2所示，包括如下步骤：

步骤201，当监测到应用程序在运行过程中占用的内存需要检测时，确定用于记录应用程序的内存信息的内存镜像文件。

在一实施例中，可以通过dump命令拷贝应用程序当前占用的内存信息，生成hprof文件，该hprof文件可视为本申请中的内存镜像文件。

步骤202，在解析内存镜像文件的过程中，确定第一实例集合中已记录的与当前正在解析的具有相同实例名称并且具有相同本身大小的实例的数量。

在一实施例中，名称相同的实例，由于序列号(id)不同，可表示不同的实例，例如，实例abc1与实例abc2，其中，“abc”可视为实例的名称，“1”和“2”可视为实例的序列号。例如，堆内存中有与应用程序相关的10万个实例，可以根据实例名称以及实例本身大小统计这10万个实例，找到具有相同名称并且具有相同本身大小的实例，控制具有相同名称并且具有相同本身大小的实例的数量在第一预设阈值以内。

步骤203，确定具有相同名称并且具有相同本身大小的实例的数量与第一预设阈值的大小关系，若实例的数量小于第一预设阈值，执行步骤204，若实例的数量等于第一预设阈值，执行步骤205。

在一实施例中，第一预设阈值的大小可以为万级以上，具体的数值可以根据具体应用程序的大小来确定，本申请对第一预设阈值的具体值不做限定。

步骤204，若实例的数量小于第一预设阈值，将当前正在解析的实例记录在第一实例集合中，以及，更新与当前正在解析的实例具有相同实例名称并且具有相同本身大小的实例的数量。

例如，第一预设阈值为1万，当前正在解析的实例为“abc10”，其中，“abc”为实例名称，“10”为实例的序列号(id)，若第一实例集合中已经记录的实例名称为“abc”并且具有相同本身大小的实例的总数量为9990，则可以将实例“abc10”记录在第一实例集合中，并将第一实例集合中的具有实例名称为“abc”的实例的数量更新为9991。

步骤205，若实例的数量等于第一预设阈值，将当前正在解析的实例记录在第三实例集合。

与上述步骤204相对应，若第一实例集合中已经记录的实例名称为“abc”并且具有相同本身大小的实例的总数量为1万个，则可以将实例“abc10”记录在第三实例集合中，从而将第一实例集合关于实例名称为“abc”并具有相同本身大小的实例的数量控制在1万个以内。

本实施例中，通过将第一实例集合中具有相同实例名称并且具有相同大小的实例的数量控制在第一预设阈值，可以控制本申请在分析应用程序的进程在内存中的占用比例，从而确保本申请能够在应用程序运行过程中分析应用程序的内存泄漏，降低由于分析内存泄漏所消耗的内存资源。

图3a是本申请再一示例性实施例示出的内存检测方法的流程示意图，图3b是图3a所示实施例中的实例的路径示意图，图3c是经过图3a所示实施例合并实例之后的示意图；本实施例在上述实施例的基础上，以如何调整第二实例集合为例进行示例性说明，如图3a所示，包括如下步骤：

步骤301，根据实例名称、该实例对应的父实例的名称，对与应用程序相关的并且未记录在第二实例集合中的实例进行路径合并。

在一实施例中，与应用程序相关的并且未记录在第二实例集合中的实例，既可以包括在上述图1所示实施例中与应用程序相关的堆内存中的大量实例中未记录在第一实例集合中的实例，也可以包括上述图2所示实施例中的第三实例集合中的实例。

步骤302，当合并后的实例的内存值符合预设条件时，将合并后的实例添加到第二实例集合中。

应用程序在运行过程中可能是由于不断进入新界面，退出该新界面，再进入该新界面，再退出该新界面等反复操作造成小对象导致内存泄露，这些小对象在堆内存中通过快照解析后成为不同的实例，并且这些小对象自身不会占用太大的内存，并分属于不同的垃圾回收器(gc)路径(也可称为链路)，其中，gcroot表示内存中不可以被回收的实例，例如，若整条路径上的根节点为垃圾回收器的根对象，则该条路径在内存使用过程中无法被回收。

如图3b所示，由于反复操作实例b1、实例b2、实例b3造成了内存泄漏，而泄漏的路径互不相同，例如，对于实例b1而言，到垃圾回收器的根对象(gcroots)的路径为b1-a1-根对象，对于实例b2而言，到垃圾回收器的根对象(gcroots)的路径为b2-a2-根对象，对于实例b3而言，到垃圾回收器的根对象(gcroots)的路径为b3-a3-根对象。实例b1、实例b2、实例b3通过不同的路径，汇聚到相同的祖辈节点(gcroots)，因此可以将这三个小实例合并，也即，将同一级的实例合并为一个实例，合并后的实例如图3c所示，在合并同一级节点的实例的过程中，需要将同一级节点的实例的内存值(可以为实例被回收可释放的总内存大小(retainsize))进行加和，由此可提高该条路径上的实例的内存值所占的比重。

在一实施例中，预设条件的具体描述可以参见下述图4a所示实施例的相关描述，在此先不详述。

本实施例中，通过将排在前设定位数的合并后的实例记录在第二实例集合中，从而可确保由小对象导致的内存泄漏被及时查找到。

图4a是本申请再一示例性实施例示出的内存检测方法的流程示意图，图4b是图4a所示实施例中的第二实例集合的示意图，图4c是图4a所示实施例中对第二实例集合进行扩容的示意图，图4d是图4a所示实施例中对第二实例集合进行置换的示意图；本实施例在上述实施例的基础上，以如何调整第二实例集合为例进行示例性说明，如图4a所示，包括如下步骤：

步骤401，将与应用程序相关的并且未记录在第二实例集合中的每一个实例的内存值与第二预设阈值进行比较，若内存值大于第二预设阈值，执行步骤402，若内存值小于第二预设阈值，执行步骤403。

步骤402，将内存值大于第二预设阈值的实例添加到第二实例集合中，执行图1所示实施例中的步骤403，流程结束。

步骤403，对与应用程序相关的并且未记录在第二实例集合中的内存值小于第二预设阈值的实例，将小于第二预设阈值的内存值与第二实例集合中实例对应的最小内存值进行比较。

步骤404，若小于第二预设阈值的内存值大于最小内存值，则在第二实例集合中，将最小内存值对应的实例置换成小于第二预设阈值的内存值对应的实例，执行图1所示实施例中的步骤103，流程结束。

在步骤403和步骤404中，为防止第二实例集合中包含的实例的数量较多导致一些可疑的实例没有添加到第二实例集合中的情形，可以将与应用程序相关的并且未记录在第二实例集合中的实例的内存值与第二预设阈值进行比较，对于内存值大于第二预设阈值的实例，则可对第二实例集合的容量加一，同时将该实例添加到第二实例集合中；对与应用程序相关的并且未记录在第二实例集合中的内存值小于第二预设阈值的实例，可继续按照排序规则(例如，堆排序)，将与应用程序相关的并且未记录在第二实例集合中的实例的内存值与第二实例中的最小内存值进行比较，若与应用程序相关的并且未记录在第二实例集合中的实例的内存值大于第二实例集合中的最小内存值，则将第二实例集合中的与最小内存值对应的实例置换成与应用程序相关的并且未记录在第二实例集合中的内存值大于第二实例集合中的最小内存值的实例。如图4b所示，第二实例集合32包括实例1-实例10。如图4c所示，可将与应用程序相关的并且未记录在第二实例集合中的实例视为一个集合31，对于集合31中的一个实例a，将实例a的内存值与第二预设阈值进行比较，若实例a的内存值大于第二预设阈值，则可以将实例a添加到第二实例集合32中。如图4d所示，若实例a的内存值小于第二预设阈值，则将实例a的内存值与第二实例集合32中的最小内存值(例如，编号为7的实例对应的内存值)进行比较，例如，第二实例集合中编号为7的实例的内存值为最小值，若实例a的内存值小于实例7的内存值，则可以将实例a丢弃，若实例a的内存值大于实例7的内存值，则可以将实例7替换成实例a。

在一实施例中，第二预设阈值可以由内存镜像文件大小以及一个预设百分比来确定，例如，内存镜像文件的大小为100m，则第二预设阈值为100m的5％，6％，等等。需要说明的是，5％以及6％为示例性说明，其不能形成对本申请的限制。

本实施例中，通过将与应用程序相关的并且未记录在第二实例集合中的实例对第二实例集合进行扩容，可以防止第二实例集合中包含的实例的数量较多导致一些可疑的实例没有添加到第二实例集合中的情形，由于本实施例是通过导致内存泄漏的直接原因得到的第二实例集合，即实例本身被回收可释放的总内存较大，或者是反复操作不断产生泄漏，相比现有技术中的预先定义需要怀疑内存泄露的对象集合会出现定义不准确的缺陷，本实施例的通用性更强。

图5a是本申请又一示例性实施例示出的内存检测方法的流程示意图，图5b是图5a所示实施例中应用程序在运行过程中的内存值的示意图，图5c是图5a所示实施例中的波谷点的示意图；本实施例在上述实施例的基础上，以如何监测应用程序在运行过程中占用的内存是否需要检测为例进行示例性说明，如图5a所示，包括如下步骤：

步骤501，当监测到应用程序在运行过程中占用的内存值高于第三预设阈值时，连续采样应用程序的内存值，得到n个采样点，其中，n为正整数。

在一实施例中，第三预设阈值可以由应用程序正常运行时达到的最大值来确定，本申请对第三预设阈值的具体大小不做限制。如图5b所示，为应用程序在运行过程中的内存值的动态示意图，其中水平方向为时间，竖直方向为内存值的大小，通过图5b可知在应用程序运行过程中，应用程序占用的内存值随着时间会动态变化，其中的箭头指向的点为本申请中所述波谷点。

步骤502，确定n个采样点中的m个波谷点，其中，m为正整数，并且m<n。

如图5c所示，波谷点可以视为内存值动态变化曲线中的凹点。

步骤503，对m个波谷点进行曲线拟合，基于曲线拟合的结果确定应用程序的内存值的变化趋势。

在一实施例中，可以通过现有技术中的拟合算法(例如，多项式函数拟合算法、最小二乘法拟合算法)等拟合出该m个波谷点对应的曲线图，通过曲线图来确定内存值的变化趋势。在一实施例中，内存值的变化趋势可以包括上升趋势和下降趋势，若为下降趋势，表明应用程序的内存消耗在降低，应用程序不会出现内存溢出的情形，若为上升趋势，表明应用程序中可能存在未释放并且已经不再使用的内存。

步骤504，当变化趋势为上升趋势时，确定应用程序占用的内存需要检测。

在一实施例中，可以提示应用程序存在内存泄漏的风险，并启动执行上述图1所示实施例的方法流程，及时检测应用程序是否存在内存泄露。

本实施例中，通过对波谷点进行曲线拟合，当拟合得到的曲线呈现上升趋势时，判断出应用程序出现内存泄漏，由于连续内存值的波谷点更能真实反映应用程序的内存实际使用情况，因此本实施例能够更准确地判断内存泄漏的风险。

与前述内存检测方法的实施例相对应，本申请还提供了内存检测装置的实施例。

图6是本申请一示例性实施例示出的内存检测装置的结构示意图，如图6，内存检测装置可包括：第一确定单元61、第二确定单元62、检测结果生成单元63；其中，

第一确定单元61，用于当监测到应用程序在运行过程中占用的内存需要检测时，确定与应用程序相关的第一实例集合；

第二确定单元62，用于基于第一确定单元61确定的第一实例集合中每一个实例占用的内存值，从第一实例集合中确定用于分析应用程序出现内存泄漏的第二实例集合；

检测结果生成单元63，用于基于第二确定单元62确定的第二实例集合中每一个实例的路径信息，生成关于应用程序出现内存泄漏的检测结果。

图7是本申请另一示例性实施例示出的内存检测装置的结构示意图，如图7所示，在上述图6所示实施例的基础上，第一确定单元61可包括：

第一确定子单元611，用于确定用于记录应用程序的内存信息的内存镜像文件；

第二确定子单元612，用于在解析第一确定子单元611确定的内存镜像文件的过程中，确定第一实例集合中已记录的与当前正在解析的具有相同实例名称并且具有相同大小的实例的数量；

第一记录子单元613，用于若第二确定子单元612确定的实例的数量小于第一预设阈值，将当前正在解析的实例记录在第一实例集合中，以及，更新与当前正在解析的实例具有相同实例名称并且具有相同大小的实例的数量；

第二记录子单元614，用于若第二确定子单元612确定的实例的数量等于第一预设阈值，将当前正在解析的实例记录在第三实例集合中。

在一实施例中，第二确定单元62可包括：

路径合并子单元621，用于在检测结果生成单元63生成关于应用程序出现内存泄漏的检测结果之前，根据实例名称、该实例对应的父实例的名称，对与所述应用程序相关的并且未记录在第二实例集合中的实例进行路径合并；

第一添加子单元622，用于当路径合并子单元621合并后的实例的内存值符合预设条件时，将合并后的实例添加到第二实例集合中。

在一实施例中，第二确定单元62还可包括：

比较子单元623，用于在检测结果生成单元63生成关于所述应用程序出现内存泄漏的检测结果之前，将与应用程序相关的并且未记录在第二实例集合中的每一个实例的内存值与第二预设阈值进行比较；

第二添加子单元624，用于将比较子单元623比较的内存值大于第二预设阈值的实例添加到第二实例集合中。

在一实施例中，内存检测装置还可包括：

比较单元64，用于在比较子单元623将与应用程序相关的并且未记录在第二实例集合中的每一个实例的内存值与第二预设阈值进行比较之后，对内存值小于第二预设阈值的第三实例集合中的实例，将小于第二预设阈值的内存值与第二实例集合对应的最小内存值进行比较；

实例置换单元65，用于若比较单元64比较的结果表示小于第二预设阈值的内存值大于最小内存值，则在第二实例集合中，将最小内存值对应的实例置换成小于预设阈值的内存值对应的实例。

在一实施例中，第二确定单元62还可包括：

统计子单元625，用于统计第一实例集合中的具有相同实例名称并且具有相同大小的实例，得到多个实例组，多个实例组中的每一个实例组包括至少一个实例；

加和子单元626，用于对统计子单元625统计出的每一个实例组中的实例的内存值进行加和，得到多个实例组各自对应的内存和值；

排序子单元627，用于基于加和子单元626得到的多个实例组各自对应的内存和值，对实例组按照预设顺序进行排序；

第三确定子单元628，用于基于排序子单元627对内存和值由大到小的顺序，确定排在前设定位数的实例组，排在前设定位数的实例组形成用于分析应用程序出现内存泄漏的第二实例集合。

在一实施例中，内存检测装置还可包括：

采样单元66，用于当监测到应用程序在运行过程中占用的内存值高于第三预设阈值时，连续采样应用程序的内存值，得到n个采样点，其中，n为正整数；

第三确定单元67，用于确定采样单元66采样得到的n个采样点中的m个波谷点，其中，m为正整数，并且m<n；

曲线拟合单元68，用于对第三确定单元67确定的m个波谷点进行曲线拟合，基于曲线拟合的结果确定应用程序的内存值的变化趋势；

第四确定单元69，用于若变化趋势为上升趋势，确定应用程序占用的内存需要检测，第一确定单元61执行确定与应用程序相关的第一实例集合的步骤。

本申请内存检测装置的实施例可以应用在电子设备上。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在电子设备的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，如图8所示，为本申请内存检测装置所在电子设备的一种硬件结构图，除了图8所示的处理器、内存、网络接口、以及非易失性存储器之外，实施例中装置所在的电子设备通常根据该电子设备的实际功能，还可以包括其他硬件，对此不再赘述。

上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由下面的权利要求指出。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。