CN112035314B - 内存泄漏的监控方法、装置及电子设备 - Google Patents
内存泄漏的监控方法、装置及电子设备 Download PDFInfo
- Publication number
- CN112035314B CN112035314B CN202010761045.6A CN202010761045A CN112035314B CN 112035314 B CN112035314 B CN 112035314B CN 202010761045 A CN202010761045 A CN 202010761045A CN 112035314 B CN112035314 B CN 112035314B
- Authority
- CN
- China
- Prior art keywords
- node
- memory
- application program
- dump file
- heap
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 146
- 238000012544 monitoring process Methods 0.000 title claims abstract description 85
- 230000008569 process Effects 0.000 claims abstract description 40
- 238000004458 analytical method Methods 0.000 claims description 45
- 230000003068 static effect Effects 0.000 claims description 22
- 238000009825 accumulation Methods 0.000 claims description 3
- 238000012795 verification Methods 0.000 claims description 3
- 238000004883 computer application Methods 0.000 abstract description 2
- 230000001960 triggered effect Effects 0.000 description 8
- 238000010586 diagram Methods 0.000 description 6
- 230000000694 effects Effects 0.000 description 5
- 230000004044 response Effects 0.000 description 5
- 238000004590 computer program Methods 0.000 description 4
- 238000003491 array Methods 0.000 description 3
- 238000012806 monitoring device Methods 0.000 description 3
- 230000003287 optical effect Effects 0.000 description 3
- 238000012545 processing Methods 0.000 description 3
- 238000012360 testing method Methods 0.000 description 3
- 208000000044 Amnesia Diseases 0.000 description 2
- 208000026139 Memory disease Diseases 0.000 description 2
- 230000006978 adaptation Effects 0.000 description 2
- 239000012634 fragment Substances 0.000 description 2
- 230000006870 function Effects 0.000 description 2
- 230000006984 memory degeneration Effects 0.000 description 2
- 208000023060 memory loss Diseases 0.000 description 2
- 230000002093 peripheral effect Effects 0.000 description 2
- 230000008439 repair process Effects 0.000 description 2
- 230000002159 abnormal effect Effects 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
- G06F11/3037—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system component is a memory, e.g. virtual memory, cache
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
- G06F11/301—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is a virtual computing platform, e.g. logically partitioned systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45583—Memory management, e.g. access or allocation
Abstract
本公开关于一种内存泄漏的监控方法、装置及电子设备，属于计算机应用技术领域。其中，该方法包括：响应于获取的应用程序启动指令，轮询应用程序对应的目标虚拟机堆内存占用状态；在目标虚拟机堆内存占用状态满足堆转储条件时，创建应用程序对应的子进程；执行子进程，以获取与目标虚拟机堆中的数据对应的堆转储文件；对堆转储文件进行分析，确定应用程序中包含的各个内存泄漏对象。由此，通过这种内存泄漏的监控方法，不仅可以有效定位应用程序中存在的内存泄露对象，有效解决内存溢出问题，而且通过独立的进程进行内存泄露监控，无需冻结虚拟机，不会影响应用程序的正常使用。
Description
技术领域
本公开涉及计算机应用技术领域，尤其涉及一种内存泄漏的监控方法、装置及电子设备。
背景技术
内存溢出(Out Of Memory，简称OOM)是指应用系统中存在无法回收的内存或使用的内存过多，最终使得程序运行要用到的内存大于能提供的最大内存。OOM是安卓应用程序开发中常见的疑难问题。
相关技术中，内存泄露是导致内存溢出的一个重要原因。但是，在应用程序投入线上使用之后，对于发生内存泄露的对象很难进行定位，从而导致OOM问题难以解决。
发明内容
本公开提供一种内存泄漏的监控方法、装置、电子设备、存储介质及计算机程序产品，以至少解决相关技术中，在应用程序投入线上使用之后，对于发生内存泄露的对象很难进行定位，从而导致OOM问题难以解决的问题。本公开的技术方案如下：
根据本公开实施例的第一方面，提供一种内存泄漏的监控方法，包括：响应于获取的应用程序启动指令，轮询所述应用程序对应的目标虚拟机堆内存占用状态；在所述目标虚拟机堆内存占用状态满足堆转储条件时，创建所述应用程序对应的子进程；执行所述子进程，以获取与所述目标虚拟机堆中的数据对应的堆转储文件；对所述堆转储文件进行分析，确定所述应用程序中包含的各个内存泄漏对象。
可选地，在本公开第一方面实施例一种可能的实现方式中，所述对所述堆转储文件进行分析，确定所述应用程序中包含的各个内存泄漏对象，包括：
创建堆转储分析进程；
执行所述堆转储分析进程，以对所述堆转储文件进行分析，确定所述应用程序中包含的各个内存泄漏对象。
可选地，在本公开第一方面实施例另一种可能的实现方式中，所述在所述目标虚拟机堆内存占用状态满足堆转储条件时，创建所述应用程序对应的子进程，包括：
在当前轮询时刻所述目标虚拟机堆的内存占用率大于第一阈值、且当前轮询时刻的内存占用率大于相邻的前一轮询时刻的内存占用率时，将堆转储触发次数加一；
在当前的所述堆转储触发次数大于第二阈值时，创建所述应用程序对应的子进程。
可选地，在本公开第一方面实施例再一种可能的实现方式中，所述对所述堆转储文件进行分析，以确定所述应用程序中包含的各个内存泄漏对象，包括：
对所述堆转储文件进行解析，以构建所述堆转储文件的索引；
依据所述堆转储文件的索引，对所述堆转储文件进行遍历分析，以确定所述应用程序中包含的各个内存泄漏对象。
可选地，在本公开第一方面实施例又一种可能的实现方式中，所述堆转储文件的索引包括各个第一类实例对象索引，所述依据所述堆转储文件的索引，对所述堆转储文件进行遍历分析，以确定所述应用程序中包含的各个内存泄漏对象，包括：
依据所述堆转储文件中各个第一类实例对象索引，对所述堆转储文件中的各个第一类实例对象进行遍历，以将目标字段值为预设值的每个第一类实例对象确定为所述应用程序中的内存泄漏对象。
可选地，在本公开第一方面实施例又一种可能的实现方式中，所述堆转储文件的索引包括各个第二类实例对象索引，所述依据所述堆转储文件的索引，对所述堆转储文件进行遍历分析，以确定所述应用程序中包含的各个内存泄漏对象，包括：
依据所述堆转储文件中各个第二类实例对象索引，对所述堆转储文件中的各个第二类实例对象进行遍历，以获取每个第二类实例对象的字段值；
将每个字段值大于第三阈值的第二类实例对象，确定为所述应用程序中的内存泄漏对象。
可选地，在本公开第一方面实施例另一种可能的实现方式中，所述堆转储文件的索引包括各个数组对象索引，所述依据所述堆转储文件的索引，对所述堆转储文件进行遍历分析，以确定所述应用程序中包含的各个内存泄漏对象，包括：
依据所述堆转储文件中各个数组对象索引，对所述堆转储文件中的各个数组对象进行遍历，以获取每个数组对象的长度；
将长度大于第四阈值的数组对象，确定为所述应用程序中的内存泄漏对象。
可选地，在本公开第一方面实施例再一种可能的实现方式中，在所述确定所述应用程序中包含的各个内存泄漏对象之后，还包括：
获取每个内存泄漏对象对应的垃圾收集路径。
可选地，在本公开第一方面实施例又一种可能的实现方式中，所述获取每个内存泄漏对象对应的垃圾收集路径，包括：
获取待遍历的节点队列；
依次从所述节点队列中取出一个节点，以校验所述取出的节点标识是否与所述应用程序的任一内存泄漏对象的标识匹配；
在所述取出的节点标识与所述应用程序的任一内存泄漏对象的标识匹配时，根据所述取出的节点及关联的各级父节点，确定所述内存泄漏对象对应的垃圾收集路径。
可选地，在本公开第一方面实施例又一种可能的实现方式中，在所述校验所述取出的节点标识是否为所述应用程序的任一内存泄漏对象的标识之后，还包括：
在所述取出的节点标识与所述应用程序的任一内存泄漏对象的标识未匹配时，将所述取出的节点的子节点加入所述节点队列，返回继续执行从所述节点队列中取出节点的操作，直至所述节点队列中的节点为空。
可选地，在本公开第一方面实施例另一种可能的实现方式中，在所述将所述取出的节点的子节点加入所述节点队列之前，还包括：
确定所述取出的节点的子节点所属的目标类；
确定已加入所述节点队列中、且属于所述目标类的节点数量小于第五阈值。
可选地，在本公开第一方面实施例再一种可能的实现方式中，在所述取出的节点为类节点时，在所述将所述取出的节点的子节点加入所述节点队列之前，还包括：
遍历所述堆转储文件的类索引，以获取所述取出的节点包含的类静态变量；
确定所述类静态变量为所述取出的节点的子节点。
可选地，在本公开第一方面实施例又一种可能的实现方式中，在所述取出的节点为实例时，在所述将所述取出的节点的子节点加入所述节点队列之前，还包括：
遍历所述堆转储文件的类索引，以获取所述堆转储文件中的各非静态变量字段中引用所述取出的节点的目标类；
遍历所述堆转储文件的实例索引，以确定所述目标类对应的各实例；
确定所述目标类对应的各实例为所述取出的节点的子节点。
可选地，在本公开第一方面实施例又一种可能的实现方式中，在所述取出的节点为数组时，在所述将所述取出的节点的子节点加入所述节点队列之前，还包括：
遍历所述堆转储文件的数组索引，以根据所述取出的节点中包含的各实例确定所述取出的节点的子节点。
可选地，在本公开第一方面实施例另一种可能的实现方式中，所述获取待遍历的节点队列，包括：
根据所述应用程序对应的各个垃圾收集根节点，生成所述待遍历的节点队列。
根据本公开实施例的第二方面，提供一种内存泄漏的监控装置，包括：轮询模块，被配置为执行响应于获取的应用程序启动指令，轮询所述应用程序对应的目标虚拟机堆内存占用状态的步骤；创建模块，被配置为执行在所述目标虚拟机堆内存占用状态满足堆转储条件时，创建所述应用程序对应的子进程的步骤；第一获取模块，被配置为执行执行所述子进程，以获取与所述目标虚拟机堆中的数据对应的堆转储文件的步骤；确定模块，被配置为执行对所述堆转储文件进行分析，确定所述应用程序中包含的各个内存泄漏对象的步骤。
可选地，在本公开第二方面实施例一种可能的实现方式中，所述确定模块，包括：
创建单元，被配置为执行创建堆转储分析进程的步骤；
第一确定单元，执行所述堆转储分析进程，以对所述堆转储文件进行分析，确定所述应用程序中包含的各个内存泄漏对象。
可选地，在本公开第二方面实施例另一种可能的实现方式中，所述创建模块，包括：
累加单元，被配置为执行在当前轮询时刻所述目标虚拟机堆的内存占用率大于第一阈值、且当前轮询时刻的内存占用率大于相邻的前一轮询时刻的内存占用率时，将堆转储触发次数加一的步骤；
创建单元，被配置为执行在当前的所述堆转储触发次数大于第二阈值时，创建所述应用程序对应的子进程的步骤。
可选地，在本公开第二方面实施例再一种可能的实现方式中，所述确定模块，包括：
解析单元，被配置为执行对所述堆转储文件进行解析，以构建所述堆转储文件的索引的步骤；
第二确定单元，被配置为执行依据所述堆转储文件的索引，对所述堆转储文件进行遍历分析，以确定所述应用程序中包含的各个内存泄漏对象的步骤。
可选地，在本公开第二方面实施例又一种可能的实现方式中，所述堆转储文件的索引包括各个第一类实例对象索引，所述第二确定单元，包括：
第一确定子单元，被配置为执行依据所述堆转储文件中各个第一类实例对象索引，对所述堆转储文件中的各个第一类实例对象进行遍历，以将目标字段值为预设值的每个第一类实例对象确定为所述应用程序中的内存泄漏对象的步骤。
可选地，在本公开第二方面实施例又一种可能的实现方式中，所述堆转储文件的索引包括各个第二类实例对象索引，所述第二确定单元，包括：
第一获取子单元，被配置为执行依据所述堆转储文件中各个第二类实例对象索引，对所述堆转储文件中的各个第二类实例对象进行遍历，以获取每个第二类实例对象的字段值的步骤；
第二确定子单元，被配置为执行将每个字段值大于第三阈值的第二类实例对象，确定为所述应用程序中的内存泄漏对象的步骤。
可选地，在本公开第二方面实施例另一种可能的实现方式中，所述堆转储文件的索引包括各个数组对象索引，所述第二确定单元，包括：
第二获取子单元，被配置为执行依据所述堆转储文件中各个数组对象索引，对所述堆转储文件中的各个数组对象进行遍历，以获取每个数组对象的长度的步骤；
第三确定子单元，被配置为执行将长度大于第四阈值的数组对象，确定为所述应用程序中的内存泄漏对象的步骤。
可选地，在本公开第二方面实施例再一种可能的实现方式中，所述装置，还包括：
第二获取模块，被配置为执行获取每个内存泄漏对象对应的垃圾收集路径的步骤。
可选地，在本公开第二方面实施例又一种可能的实现方式中，所述第二获取模块，包括：
第一获取单元，被配置为执行获取待遍历的节点队列的步骤；
校验单元，被配置为执行依次从所述节点队列中取出一个节点，以校验所述取出的节点标识是否与所述应用程序的任一内存泄漏对象的标识匹配的步骤；
第三确定单元，被配置为执行在所述取出的节点标识与所述应用程序的任一内存泄漏对象的标识匹配时，根据所述取出的节点及关联的各级父节点，确定所述内存泄漏对象对应的垃圾收集路径的步骤。
可选地，在本公开第二方面实施例又一种可能的实现方式中，所述第二获取模块，还包括：
迭代单元，被配置为执行所述取出的节点标识与所述应用程序的任一内存泄漏对象的标识未匹配时，将所述取出的节点的子节点加入所述节点队列，返回继续执行从所述节点队列中取出节点的操作，直至所述节点队列中的节点为空的步骤。
可选地，在本公开第二方面实施例另一种可能的实现方式中，所述第二获取模块，还包括：
第四确定单元，被配置为执行确定所述取出的节点的子节点所属的目标类的步骤；
第五确定单元，被配置为执行确定已加入所述节点队列中、且属于所述目标类的节点数量小于第五阈值的步骤。
可选地，在本公开第二方面实施例再一种可能的实现方式中，在所述取出的节点为类节点时，所述第二获取模块，还包括：
第二获取单元，被配置为执行遍历所述堆转储文件的类索引，以获取所述取出的节点包含的类静态变量的步骤；
第六确定单元，被配置为执行确定所述类静态变量为所述取出的节点的子节点的步骤。
可选地，在本公开第二方面实施例又一种可能的实现方式中，在所述取出的节点为实例时，所述第二获取模块，还包括：
第三获取单元，被配置为执行遍历所述堆转储文件的类索引，以获取所述堆转储文件中的各非静态变量字段中引用所述取出的节点的目标类的步骤；
第七确定单元，被配置为执行遍历所述堆转储文件的实例索引，以确定所述目标类对应的各实例的步骤；
第八确定单元，被配置为执行确定所述目标类对应的各实例为所述取出的节点的子节点的步骤。
可选地，在本公开第二方面实施例又一种可能的实现方式中，在所述取出的节点为数组时，所述第二获取模块，还包括：
第九确定单元，被配置为执行遍历所述堆转储文件的数组索引，以根据所述取出的节点中包含的各实例确定所述取出的节点的子节点的步骤。
可选地，在本公开第二方面实施例另一种可能的实现方式中，所述第一获取单元，包括：
生成子单元，被配置为执行根据所述应用程序对应的各个垃圾收集根节点，生成所述待遍历的节点队列的步骤。
根据本公开实施例的第三方面，提供一种电子设备，包括：处理器；用于存储所述处理器可执行指令的存储器；其中，所述处理器被配置为执行所述指令，以实现如前所述的内存泄漏的监控方法。
根据本公开实施例的第四方面，提供一种存储介质，当所述存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行如前所述的内存泄漏的监控方法。
根据本公开实施例的第五方面，提供一种计算机程序产品，该计算机程序由电子设备的处理器执行时，使得电子设备能够执行如前所述的内存泄漏的监控方法。
本公开的实施例提供的技术方案至少带来以下有益效果：通过在应用程序启动之后，轮询应用程序对应的目标虚拟机堆内存占用状态，并在目标虚拟机堆内存占用状态满足堆转储条件时，创建应用程序对应的子进程，之后执行子进程，以获取与目标虚拟机堆中的数据对应的堆转储文件，进而对堆转储文件进行分析，确定应用程序中包含的各个内存泄漏对象。由此，通过预设堆转储条件确定应用程序可能出现OOM的时机，并新建独立的子进程生成可对目标虚拟机对中的数据进行索引的堆转储文件并进行分析，以确定内存泄露对象，从而不仅可以有效定位应用程序中存在的内存泄露对象，有效解决OOM问题，而且通过独立的进程进行内存泄露监控，无需冻结虚拟机，不会影响应用程序的正常使用。
应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理，并不构成对本公开的不当限定。
图1是根据一示例性实施例示出的一种内存泄漏的监控方法的流程图。
图2是根据一示例性实施例示出的另一种内存泄漏的监控方法的流程图。
图3是根据一示例性实施例示出的再一种内存泄漏的监控方法的流程图。
图4为一种垃圾收集根节点及其子节点之间的引用关系示意图。
图5是根据一示例性实施例示出的又一种内存泄漏的监控方法的流程图。
图6是根据一示例性实施例示出的一种内存泄漏的监控装置框图。
图7是根据一示例性实施例示出的一种电子设备的框图。
具体实施方式
为了使本领域普通人员更好地理解本公开的技术方案，下面将结合附图，对本公开实施例中的技术方案进行清楚、完整地描述。
需要说明的是，本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本公开的实施例能够以除了在这里图示或描述的那些以外的顺序实施。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。
图1是根据一示例性实施例示出的一种内存泄漏的监控方法的流程图，如图1所示，该内存泄漏的监控方法用于电子设备中，包括以下步骤。
在步骤101中，响应于获取的应用程序启动指令，轮询应用程序对应的目标虚拟机堆内存占用状态。
需要说明的是，本公开实施例的内存泄漏的监控方法可以由本公开实施例的内存泄漏的监控装置执行，本公开实施例的内存泄漏的监控装置可以配置在任意电子设备中，以执行本公开实施例的内存泄漏的监控方法。本公开实施例的内存泄漏的监控方法可以应用在任意的应用程序以进行内存泄漏监控。
其中，应用程序，可以是新闻类、短视频类、音视频类、评论类、游戏类、社交类等类型的应用程序，本公开实施例对此不做限定。
其中，应用程序启动指令，可以是用户对应用程序对应的图标的点击操作，也可以是用户通过其他应用程序向应用程序发送的启动请求，本公开实施例对此不做限定。
其中，目标虚拟机堆，是指应用程序启动后，应用程序所在的系统映射的与应用程序对应的虚拟机。
其中，目标虚拟机堆内存占用状态，可以包括目标虚拟机堆的内存占用率，即应用程序的内存占用率。需要说明的是，目标虚拟机堆的内存占用率，可以是目标虚拟机堆实际的内存占用量与应用程序所在的电子设备可提供给应用程序的内存总量的比值；也可以是目标虚拟机堆实际的内存占用量与应用程序所在的电子设备的内存总量的比值，本公开实施例对此不做限定。
在本公开实施例中，应用程序所在的电子设备的处理器，在获取到应用程序启动指令后，可以以预设的频率轮询应用程序对应的目标虚拟机堆内存占用状态，以实时获取应用程序对应的目标虚拟机堆内存占用状态，及时了解应用程序的内存占用情况。
作为一种可能的实现方式，本公开实施例的内存泄露的监控方法可以以独立的应用程序的形式存在，从而内存泄露的监控方法对应的应用程序可以在检测到所在的电子设备中任意一个应用程序的启动指令时，轮询该应用程序对应的目标虚拟机堆内存占用状态，从而可以对电子设备中任意一个应用程序的内存泄露情况进行监控。
作为另一种可能的实现方式，本公开实施例的内存泄露的监控方法，还可以作为应用程序中的一个进程存在，从而在应用程序启动时，可以同时启动内存泄露的监控方法对应的进程，以轮询该应用程序对应的目标虚拟机堆内存占用状态，以仅对该应用程序的内存泄露情况进行监控。
在步骤102中，在目标虚拟机堆内存占用状态满足堆转储条件时，创建应用程序对应的子进程。
其中，转储条件，可以是指应用程序可能出现内存泄露情况时，目标虚拟机堆内存占用状态需要满足的条件。
在本公开实施例中，可以根据实际的应用场景或实验标定数据，预先设定转储条件，从而处理器可以在确定目标虚拟机内存占用状态满足转储条件时，触发内存泄露监控过程，即可以创建应用程序对应的子进程，以通过子进程实现虚拟机数据的转储，从而不会影响应用程序当前正在运行的进程，应用程序仍然可以正常使用。
需要说明的是，实际使用时，可以根据实际的应用场景或实验标定数据，设定转储条件，本公开实施例对此不做限定。比如，在目标虚拟机堆内存占用状态包括内存占用率时，转储条件可以为目标虚拟机堆的内存占用率大于占用率阈值，等等。
在步骤103中，执行子进程，以获取与目标虚拟机堆中的数据对应的堆转储文件。
其中，堆转储文件，可以是目标虚拟机堆中的数据对应的镜像文件；也可以是目标虚拟机对中的数据对应的索引文件。需要说明的是，为了节约对目标虚拟机堆中的数据进行转储时所使用的空间、时间、流量等，堆转储文件可以是根据目标虚拟机中的数据生成的、可对目标虚拟机中的数据进行遍历的简化文件，以降低堆转储文件的大小，提升转储效率。
在本公开实施例中，创建子进程之后，可以利用fork虚拟机堆转储技术，通过执行子进程根据目标虚拟机堆中的数据，生成目标虚拟机中的数据对应的堆转储文件，以供对目标虚拟机中的数据进行后续分析。
在步骤104中，对堆转储文件进行分析，确定应用程序中包含的各个内存泄漏对象。
其中，内存泄露对象，可以是应用程序中出现内存泄露的类、实例、数组等对象，本公开实施例对此不做限定。
在本公开实施例中，生成堆转储文件之后可以对堆转储文件进行分析，以确定目标虚拟机中的数据包括的各对象，进而根据各对象的字段值与预设字段范围，将字段值不属于预设字段范围的对象，确定为内存泄露对象。进而，在确定出内存泄露对象之后，可以根据确定出的内存泄露对象生成包含各内存泄露对象的分析报告，以供技术人员对各内存泄露对象进行处理，进而节点内存泄露导致的OOM问题。
作为一种可能的实现方式，可以通过建立独立的进程对堆转储文件进行分析，以保证应用程序的正常运行，不影响用户的正常使用。即在本公开实施例一种可能的实现形式中，上述步骤104，可以包括：
创建堆转储分析进程；
执行堆转储分析进程，以对堆转储文件进行分析，确定应用程序中包含的各个内存泄漏对象。
在本公开实施例中，可以在转储完成之后，创建堆转储分析进程，以通过与应用程序当前正在运行的主进程相互独立的堆转储分析进程对堆转储文件进行分析，从而不会影响应用程序中当前正常运行的主进程的运行效率。
本公开的实施例提供的内存泄漏的监控方法，通过在应用程序启动之后，轮询应用程序对应的目标虚拟机堆内存占用状态，并在目标虚拟机堆内存占用状态满足堆转储条件时，创建应用程序对应的子进程，之后执行子进程，以获取与目标虚拟机堆中的数据对应的堆转储文件，进而对堆转储文件进行分析，确定应用程序中包含的各个内存泄漏对象。由此，通过预设堆转储条件确定应用程序可能出现OOM的时机，并新建独立的子进程生成可对目标虚拟机对中的数据进行索引的堆转储文件并进行分析，以确定内存泄露对象，从而不仅可以有效定位应用程序中存在的内存泄露对象，有效解决OOM问题，而且通过独立的进程进行内存泄露监控，无需冻结虚拟机，不会影响应用程序的正常使用。
在本公开一种可能的实现形式中，可以在应用程序的内存占用率较大且逐渐递增时，触发内存泄露监控，并且对于不同类型的对象可以采用不同的方式确定是否为内存泄露对象，以进一步提升内存泄露监控的可靠性和稳定性。
图2是根据一示例性实施例示出的另一种内存泄漏的监控方法的流程图，如图2所示，该内存泄漏的监控方法用于电子设备中，包括以下步骤。
在步骤201中，响应于获取的应用程序启动指令，轮询应用程序对应的目标虚拟机堆内存占用状态。
上述步骤201的具体实现过程及原理，可以参照上述实施例的详细描述，此处不再赘述。
在步骤202中，在当前轮询时刻目标虚拟机堆的内存占用率大于第一阈值、且当前轮询时刻的内存占用率大于相邻的前一轮询时刻的内存占用率时，将堆转储触发次数加一。
在本公开实施例中，可以在应用程序的内存占用率的基数较大，且逐渐递增时，确定应用程序出现内存泄露的风险较高，从而可以触发内存泄露监控。
作为一种可能的实现方式，在对目标虚拟机堆的内存占用状态进行轮询时，记录目标虚拟机的内存占用率较大且持续递增的次数，以根据该次数判断应用程序是否出现内存泄露风险。具体的，可以在当前轮询时刻获取到目标虚拟机堆的内存占用率之后，判断当前轮询时刻目标虚拟机堆的内存占用率是否大于第一阈值，若大于第一阈值，则可以确定目标虚拟机堆在当前轮询时刻的内存占用率较大；之后，可以进一步判断当前轮询时刻的内存占用率是否大于相邻的前一轮询时刻的内存占用率，若是，则可以确定当前轮询时刻的内存占用率不仅较大而且处于递增状态，从而可以将堆转储触发次数加一。若当前轮询时刻的内存占用率小于或等于第一阈值，或者当前轮询时刻的内存占用率小于或等于相邻的前一轮询时刻的内存占用率，则可以确定应用程序的内存占用率未处于较大且逐渐递增的状态，则可以将堆转储触发次数清零。
需要说明的是，实际使用时，可以根据实际需要及具体的应用场景，确定第一阈值的具体取值，本公开实施例对此不做限定。比如，第一阈值可以为80％，从而可以在应用程序出现OOM问题之前，及时发现存在内存泄露的对象，以尽量避免应用程序出现OO M问题。
在步骤203中，在当前的堆转储触发次数大于第二阈值时，创建应用程序对应的子进程。
作为一种可能的实现方式，由于堆转储触发次数越大，说明应用程序正处在以较大的基数逐渐递增的状态，即应用程序出现OOM的风险越大，因此，预先设定的转储条件可以是当前的堆转储触发次数大于第二阈值，从而可以在当前的堆转储触发次数大于第二阈值时，创建应用程序对应的子进程，以触发内存泄露的监控过程。
需要说明的是，在当前的堆转储触发次数大于第二阈值时，触发内存泄露的监控过程，不仅可以及时发现应用程序的内存占用异常，而且可以避免应用程序的占用率偶然升高时，便触发内存泄露监控，从而避免了对内存泄露监控时机的误判，提升了内存泄露监控的可靠性和稳定性。
实际使用时，可以根据实际需要及具体的应用场景，确定第二阈值的具体取值，本公开实施例对此不做限定。比如，第二阈值可以为3。
在步骤204中，执行子进程，以获取与目标虚拟机堆中的数据对应的堆转储文件。
上述步骤204的具体实现过程及原理，可以参照上述实施例的详细描述，此处不再赘述。
在步骤205中，创建堆转储分析进程，并执行堆转储分析进程，以对堆转储文件进行解析，以构建堆转储文件的索引。
其中，堆转储文件的索引，是指可以包括堆转储文件中每个对象的标识与其对应的存储位置的映射的文件。堆转储文件的索引中可以包括对转储文件中的实例索引、类索引与数组索引。
作为一种可能的实现方式，堆转储文件可以是目标虚拟机堆中的数据的镜像文件，从而堆转储分析进程可以对堆转储文件进行扫描处理，以获取堆转储文件中包括的每个对象的标识，以及每个对象对应的存储位置，进而将每个对象的标识与存储位置进行映射，以构建堆转储文件的索引。
需要说明的是，构建堆转储文件的索引之后，可以直接根据对象的标识查询对象对应的存储位置，进而根据对象对应的存储位置获取对象，从而无需一次性将堆转储文件载入内存，降低了内存泄露监控的内存开销，提升了内存泄露监控的效率。
在步骤206中，依据堆转储文件的索引，对堆转储文件进行遍历分析，以确定应用程序中包含的各个内存泄漏对象。
在本公开实施例中，构建出堆转储文件的索引之后，可以根据堆转储文件的索引对堆转储文件进行遍历分析，以从堆转储文件中每个对象对应的存储位置中，获取每个对象，以对每个对象进行分析，判断每个对象是否为内存泄露对象，从而确定出堆转储文件中包含的各内存泄露对象，即应用程序中的内存泄露对象。
作为一种可能的实现方式，对于不同类型的对象，可以根据不同类型的对象的特征，选择不同的原则判断对象是否为内存泄露对象，以提升内存泄露监控的准确性和可靠性。以下以对象为第一类实例对象、第二类实例对象、数组对象为例，进行具体说明、
情况一
堆转储文件的索引包括各个第一类实例对象索引，则在本公开实施例一种可能的实现形式中，上述步骤206，可以包括：
依据堆转储文件中各个第一类实例对象索引，对堆转储文件中的各个第一类实例对象进行遍历，以将目标字段值为预设值的每个第一类实例对象确定为应用程序中的内存泄漏对象。
其中，第一类实例对象，是指可以通过字段值确定其是否为内存泄露对象的实例。目标字段，是指可以指示第一类实例对象是否为内存泄露对象的字段。
实际使用时，对于不同的第一类实例对象，目标字段与预设值均可以是不同的。比如，第一类实例对象为Activity实例时，目标字段可以为mDestroyed字段，预设值可以为tru e；第一类实例对象为Fragment实例时，目标字段可以为mFragmentManager，预设值可以为null。
在本公开实施例中，若堆转储文件中包括第一类实例对象索引，则可以根据各个第一类实例对象索引，对堆转储文件中的各个第一类实例对象进行遍历，以确定各个第一类实例对象的存储位置，进而从各个第一类实例对象的存储位置中获取各个第一类实例对象的目标字段值，进而在第一类实例对象的目标字段值为预设值时，可以确定该第一类实例对象为应用程序中的内存泄露对象；在第一类实例对象的目标字段值不是预设值时，可以确定该第一类实例对象不是应用程序中的内存泄露对象。
举例来说，堆转储文件中的一个第一类实例对象A为Activity实例，则可以确定第一类实例对象A的目标字段为mDestroyed字段，预设值可以为true，从而可以根据第一类实例对象A的索引，从第一类实例对象A的存储位置获取mDestroyed字段值。若第一类实例对象A的mDestroyed字段值为true，则可以确定第一类实例对象A已经销毁，理应释放不再占用内存资源；但是堆转储文件中仍然存在第一类实例对象A，则可以确定第一类实例对象A还没有释放、仍然占用内存，从而可以将第一类实例对象A确定为内存泄露对象，并将第一类实例对象A加入内存泄露对象列表。若第一类实例对象A的mDestr oyed字段值为false，则可以确定第一类实例对象A未被销毁，仍然需要正常占用内存，从而可以确定第一类实例对象A不是内存泄露对象。
又如，堆转储文件中的一个第一类实例对象B为Fragment实例，则可以确定第一类实例对象B的目标字段为mFragmentManager字段，预设值可以为null，从而可以根据第一类实例对象B的索引，从第一类实例对象B的存储位置获取mFragmentManager字段值。若第一类实例对象B的mFragmentManager字段值为null，则可以确定第一类实例对象B已经销毁，理应释放不再占用内存资源；但是堆转储文件中仍然存在第一类实例对象B，则可以确定第一类实例对象B还没有释放、仍然占用内存，从而可以将第一类实例对象B确定为内存泄露对象，并将第一类实例对象B加入内存泄露对象列表。
情况二
堆转储文件的索引包括各个第二类实例对象索引，在本公开实施例一种可能的实现形式中，上述步骤206，可以包括：
依据堆转储文件中各个第二类实例对象索引，对堆转储文件中的各个第二类实例对象进行遍历，以获取每个第二类实例对象的字段值；
将每个字段值大于第三阈值的第二类实例对象，确定为应用程序中的内存泄漏对象。
其中，第二类实例对象，是指可以通过字段值确定其占用内存大小的实例。比如，第二类实例对象可以包括Bitmap(位图)实例，Bitmap实例的字段值可以表示Bitmap实例的尺寸信息，从而可以根据Bitmap的字段值确定Bitmap实例的占用内存的大小。
在本公开实施例中，若堆转储文件中包括第二类实例对象索引，则可以根据各个第二类实例对象索引，对堆转储文件中的各个第二类实例对象进行遍历，以确定各个第二类实例对象的存储位置，进而从各个第二类实例对象的存储位置中获取各个第二类实例对象的字段值，进而在第二类实例对象的字段值大于第三阈值时，可以确定该第二类实例对象为应用程序中的内存泄露对象；在第二类实例对象的字段值小于或等于第三阈值时，可以确定该第二类实例对象不是应用程序中的内存泄露对象。
举例来说，堆转储文件中的一个第二类实例对象C为Bitmap实例，则可以根据第二类实例对象C的索引，从第二类实例对象C的存储位置获取字段值。若第二类实例对象C的字段包括宽字段与高字段，且宽字段值为1400，高字段值为800，第三阈值为1366×768。由于1400×800大于1366×768，从而可以将第二类实例对象C确定为内存泄露对象，并将第二类实例对象B加入内存泄露对象列表。
需要说明的是，上述举例仅为示例性的，不能视为对本公开的限制。实际使用时，可以根据实际需要及具体的应用场景，确定第三阈值的具体取值，本公开实施例对此不做限定。
情况三
堆转储文件的索引包括各个数组对象索引，在本公开实施例一种可能的实现形式中，上述步骤206，可以包括：
依据堆转储文件中各个数组对象索引，对堆转储文件中的各个数组对象进行遍历，以获取每个数组对象的长度；
将长度大于第四阈值的数组对象，确定为应用程序中的内存泄漏对象。
在本公开实施例中，若堆转储文件中包括数组对象索引，则可以根据各个数组对象索引，对堆转储文件中的各个数组对象进行遍历，以确定各个数组对象的存储位置，进而从各个数组对象的存储位置中获取各个数组对象的长度，进而在数组对象的长度大于第四阈值时，可以确定该数组对象为应用程序中的内存泄露对象；在数组对象的长度小于或等于第四阈值时，可以确定该数组对象不是应用程序中的内存泄露对象。
举例来说，堆转储文件中包含一个数组对象D，则可以根据数组对象D的索引，从数组对象D的存储位置获取数组对象D的长度。若数组对象D的长度为110，第四阈值为100。由于110大于100，从而可以将数组对象D确定为内存泄露对象，并将数组对象D加入内存泄露对象列表。
需要说明的是，上述举例仅为示例性的，不能视为对本公开的限制。实际使用时，可以根据实际需要及具体的应用场景，确定第四阈值的具体取值，本公开实施例对此不做限定。
本公开的实施例提供的内存泄漏的监控方法，通过在应用程序启动之后，轮询应用程序对应的目标虚拟机堆内存占用状态，并在确定目标虚拟机堆的内存占用率大于阈值且逐渐递增时，触发内存泄露监控进程并创建应用程序对应的子进程，之后执行子进程，以获取与目标虚拟机堆中的数据对应的堆转储文件，进而通过堆转储分析进程，构建堆转储文件的索引，进而根据堆转储文件的索引对堆转储文件进行遍历分析，以确定应用程序中包含的各个内存泄漏对象。由此，通过将目标虚拟机对的内存占用率较大且逐渐递增的时机确定为触发内存泄露监控的时机，避免了对内存泄露监控时机的误判；并且通过构建堆转储文件的索引对堆转储文件进行遍历，无需一次性将堆转储文件载入内存，降低了内存泄露监控的内存开销，从而不仅可以通过独立的进程进行内存泄露监控，有效定位应用程序中存在的内存泄露对象，有效解决OOM问题，而且进一步提升了内存泄露监控的可靠性和稳定性，并且降低了内存损耗，进一步提升了用户体验。
在本公开一种可能的实现形式中，确定出应用程序中的内存泄露对象之后，还可以确定内存泄露对象对应的垃圾收集路径，并形成分析报告，以便于分析内存泄露原因并进行修复，进一步提升了内存泄露监控的准确度和问题发现率。
图3是根据一示例性实施例示出的再一种内存泄漏的监控方法的流程图，如图3所示，该内存泄漏的监控方法用于电子设备中，包括以下步骤。
在步骤301中，响应于获取的应用程序启动指令，轮询应用程序对应的目标虚拟机堆内存占用状态。
在步骤302中，在目标虚拟机堆内存占用状态满足堆转储条件时，创建应用程序对应的子进程。
在步骤303中，执行子进程，以获取与目标虚拟机堆中的数据对应的堆转储文件。
在步骤304中，对堆转储文件进行分析，确定应用程序中包含的各个内存泄漏对象。
上述步骤301-304的具体实现过程及原理，可以参照上述实施例的详细描述，此处不再赘述。
在步骤305中，获取每个内存泄漏对象对应的垃圾收集路径。
其中，内存泄露对象对应的垃圾收集路径(Garbage Collection Path，简称GCPath)，可以是指内存泄露对象至垃圾收集根节点(Garbage Collection Root，简称GCRoot)的最短引用路径。
在本公开实施例中，确定出应用程序中的各内存泄露对象之后，还可以获取每个内存泄露对象对应的GC Path，并根据每个内存泄露对象对应的GC Path生成分析报告，以使技术人员可以根据泄露对象的GC Path定位内存泄露对象产生泄露的根本原因，并进行修复。
作为一种可能的实现方式，可以对应用程序中的所有节点进行遍历，确定内存泄露对象对应的节点，进而根据节点间的关联关系，确定各个内存泄露对象对应的GC Path。即在本公开实施例一种可能的实现形式中，上述步骤305，可以包括：
获取待遍历的节点队列；
依次从节点队列中取出一个节点，以校验取出的节点标识是否与应用程序的任一内存泄漏对象的标识匹配；
在取出的节点标识与应用程序的任一内存泄漏对象的标识匹配时，根据取出的节点及关联的各级父节点，确定内存泄漏对象对应的GC Path。
在本公开实施例中，可以以应用程序中的GC Root为查找起点，使用基于队列的广度优先搜索(Breadth First Search，简称BFS)，确定内存泄露对象对应的节点。也就是说，可以根据应用程序对应的各个GC Root，生成待遍历的节点队列。
具体的，可以首先可以将应用程序对应的各个GC Root加入节点队列，之后可以从节点队列中取出一个GC Root，并判断该GC Root的标识是否与任意一个内存泄露对象的标识匹配；若匹配，则可以确定该GC Root为已经确定出的一个内存泄露对象，从而可以根据该GC Root关联的各级父节点，确定为与其标识相同的内存泄露对象对应的G C Path。由于GC Root不存在关联的父节点，从而可以直接将该GC Root确定为与其标识相同的内存泄露对象对应的GC Path。采用上述相同的方法，可以依次判断节点队列中的其他GC Root是否为内存泄露对象。
进一步的，由于GC Root是类，通常不会是内存泄露对象，从而基于BFS原则，在确定GC Root的标识与任一内存泄露对象的标识均不匹配时，可以将GC Root的子节点加入节点队列，以根据GC Root的子节点的关联关系，搜索内存泄露对象对应的GC Pa th。即在本公开实施例一种可能的实现形式中，上述校验取出的节点标识是否为应用程序的任一内存泄漏对象的标识之后，还可以包括：
在取出的节点标识与应用程序的任一内存泄漏对象的标识未匹配时，将取出的节点的子节点加入节点队列，返回继续执行从节点队列中取出节点的操作，直至节点队列中的节点为空。
下面以图4为例进行具体说明。如图4所示，为一种垃圾收集根节点及其子节点之间的引用关系示意图。若图4中的垃圾收集根节点(GC Root)的标识与任一内存泄露对象的标识均不匹配，则可以将GC Root的子节点“节点1”加入节点队列，之后从节点队列中取出节点1，并判断节点1的标识是否与任一内存泄露对象的标识匹配；若节点1的标识也与任一内存泄露对象的标识均不匹配，则可以将节点1的子节点“节点2”与“节点3”加入节点队列；之后从节点队列中取出节点2，并判断节点2的标识是否与任一内存泄露对象的标识匹配；若节点2的标识与内存泄露对象A的标识匹配，则可以将节点2与GC Root之间的引用路径(即节点2及其关联的各级父节点)，确定为内存泄露对象A的G C Path，即内存泄露对象A的GC Path为“GC Root->节点1->节点2”；若节点2的标识与任一内存泄露对象的标识均不匹配，由于节点2不存在子节点，则可以不做任何操作，并继续从节点队列中取出节点进行判断。
之后，从节点队列中取出节点3，并判断节点3的标识是否与任一内存泄露对象的标识匹配；若节点3的标识与内存泄露对象B的标识匹配，则可以将节点3与GC Root之间的引用路径(即节点3及其关联的各级父节点)，确定为内存泄露对象B的GC Path，即内存泄露对象B的GC Path为“GC Root->节点1->节点3”。若节点3的标识与任一内存泄露对象的标识均不匹配，则可以将节点3的子节点“节点4”加入节点队列，之后从节点队列中取出节点4，并判断节点4的标识是否与任一内存泄露对象的标识匹配；若节点4的标识与内存泄露对象C的标识匹配，则可以将节点4与GC Root之间的引用路径(即节点4及其关联的各级父节点)，确定为内存泄露对象C的GC Path，即内存泄露对象C的GC Path为“GC Root->节点1->节点3->节点4”。若节点4与任一内存泄露对象的标识均不匹配，则可以完成对该GC Root的遍历，并采用上述相同的方式对其他GC Root进行遍历，直至节点队列为空，则可以确定出所有内存泄露对象对应的GC Path。
进一步的，在将节点进行入队列操作时，还可以对属于同一个类的子节点进行剪枝，以控制同类节点入队列的数量，降低内存泄露监控的运算量与对电子设备的性能要求，即在本公开实施例一种可能的实现形式中，上述将取出的节点的子节点加入节点队列之前，还可以包括：
确定取出的节点的子节点所属的目标类；
确定已加入节点队列中、且属于目标类的节点数量小于第五阈值。
在本公开实施例中，将节点加入队列时，可以记录节点所属的类，从而在确定可以将一个子节点加入节点队列中时，首先确定该子节点所属的目标类型，进而获取已加入节点队列中中且属于目标类的节点数量，并在已加入节点队列中中且属于目标类的节点数量小于第五阈值时，可以将该子节点加入节点队列；在已加入节点队列中中且属于目标类的节点数量大于或等于第五阈值时，可以不将该子节点加入节点队列，以控制加入节点队列的节点数量。
举例来说，对于class com.test.Activity类，该类包含10万个实例，第五阈值为1024，从而在节点队列中已经加入class com.test.Activity类对应的1024个实例之后，则可以不再将class com.test.Activity类对应的实例加入节点队列，以防止重复计算，影响内存泄露监控的性能和效率。
需要说明的是，上述举例仅为示例性的，不能视为对本公开的限制。实际使用时，可以根据实际需要及具体的应用场景，确定第五阈值的具体取值，本公开实施例对此不做限定。
本公开的实施例提供的内存泄漏的监控方法，通过在应用程序启动之后，轮询应用程序对应的目标虚拟机堆内存占用状态，并在确定目标虚拟机堆的内存占用率大于阈值且逐渐递增时，触发内存泄露监控进程并创建应用程序对应的子进程，之后执行子进程，以获取与目标虚拟机堆中的数据对应的堆转储文件，进而通过堆转储分析进程，构建堆转储文件的索引，进而根据堆转储文件的索引对堆转储文件进行遍历分析，以确定应用程序中包含的各个内存泄漏对象，并获取各个内存泄露对象对应的GC Path。由此，通过对应用程序中的所有节点进行遍历，以确定各个内存泄露对象对应的GC Path，并生成分析报告，从而不仅可以通过独立的进程进行内存泄露监控，有效定位应用程序中存在的内存泄露对象，有效解决OOM问题，而且便于分析内存泄露原因并进行修复，进一步提升了内存泄露监控的准确度和问题发现率。
在本公开一种可能的实现形式中，对于不同类型的节点，可以采用不同的方式计算节点对应的子节点，以提升节点遍历的准确性和全面性，进而进一步提升确定的内存泄露对象对应的GC Path的准确性。
图5是根据一示例性实施例示出的又一种内存泄漏的监控方法的流程图，如图5所示，该内存泄漏的监控方法用于电子设备中，包括以下步骤。
在步骤401中，响应于获取的应用程序启动指令，轮询应用程序对应的目标虚拟机堆内存占用状态。
在步骤402中，在目标虚拟机堆内存占用状态满足堆转储条件时，创建应用程序对应的子进程。
在步骤403中，执行子进程，以获取与目标虚拟机堆中的数据对应的堆转储文件。
在步骤404中，对堆转储文件进行分析，确定应用程序中包含的各个内存泄漏对象。
在步骤405中，获取待遍历的节点队列。
在步骤406中，依次从节点队列中取出一个节点，以校验取出的节点标识是否与应用程序的任一内存泄漏对象的标识匹配，若是，则执行步骤407；否则，执行步骤408。
在步骤407中，根据取出的节点及关联的各级父节点，确定内存泄露对象对应的GCPath。
上述步骤401-407的具体实现过程及原理，可以参照上述实施例的详细描述，此处不再赘述。
在步骤408中，将取出的节点的子节点加入所述节点队列。
在本公开实施例中，由于不同类型的节点，其数据结构、引用关系等都可能不同，从而可以采用不同的方式确定不同类型的节点的子节点，并将确定出的子节点加入节点队列中。以下以取出的节点分别为类节点、实例、数组为例，进行具体说明。
情况一
在本公开实施例一种可能的实现形式中，从节点队列中取出的节点为类节点时，上述步骤408之前，还可以包括：
遍历堆转储文件的类索引，以获取取出的节点包含的类静态变量；
确定类静态变量为取出的节点的子节点。
在本公开实施例中，若从节点队列中取出的节点为类节点，则可以根据堆转储文件的类索引，对取出的节点的类索引进行遍历，以确定取出的节点包含的类静态变量，并将取出节点包含的类静态变量(如实例和数组)，确定为取出节点的子节点，之后将确定出的子节点加入节点队列。
情况二
在本公开实施例一种可能的实现形式中，从节点队列中取出的节点为实例时，上述步骤408之前，还可以包括：
遍历堆转储文件的类索引，以获取堆转储文件中的各非静态变量字段中引用取出的节点的目标类；
遍历堆转储文件的实例索引，以确定目标类对应的各实例；
确定目标类对应的各实例为取出的节点的子节点。
在本公开实施例中，由于引用实例B的类对应的各实例都会引用实例B，从而在取出的节点为实例时，可以首先遍历堆转储文件的类索引，以获取堆转储文件中各非静态变量字段中引用取出的节点的所有目标类，之后遍历堆转储文件的实际索引，以确定目标类对应的各实例，进而将目标类对应的各实例均确定为取出节点的子节点。
举例来说，Class A{B var；}与Class C{B var；}为两个类，B为Class A与Class C引用的实例，则在取出的节点为实例B时，遍历堆转储文件的类索引，可以确定出引用非静态变量引用实例B的目标类Class A与Class C，之后可以变量堆转储文件的实例索引，以确定目标类Class A对应的各实例，以及目标类Class C对应的各实例，进而将目标类Class A对应的各实例与目标类Class C对应的各实例，确定为实例B的子节点，之后将确定出的子节点加入节点队列。
情况三
在本公开实施例一种可能的实现形式中，从节点队列中取出的节点为数组时，上述步骤408之前，还可以包括：
遍历堆转储文件的数组索引，以根据取出的节点中包含的各实例确定取出的节点的子节点。
在本公开实施例中，若从节点队列中取出的节点为数组，则可以根据堆转储文件的数组索引，对取出的节点的数组索引进行遍历，以确定取出的节点包含的各实例，并将取出节点包含的各实例，确定为取出节点的子节点，之后将确定出的子节点加入节点队列。
在步骤409中，判断节点队列是否为空，若是，则执行步骤410；否则，执行步骤406。
步骤410，结束获取内存泄漏对象对应的GC Path。
在本公开实施例中，在将取出节点的子节点加入节点队列之后，若节点队列不为空，则可以继续执行从节点队列中取出节点的操作，即返回执行步骤406，直至节点队列为空，则可以确定已经获取到所以内存泄露对象对应的GC Path，从而可以结束获取内存泄露对象对应的GC Path的过程。
本公开的实施例提供的内存泄漏的监控方法，通过堆转储分析进程，构建堆转储文件的索引，进而根据堆转储文件的索引对堆转储文件进行遍历分析，以确定应用程序中包含的各个内存泄漏对象，并依据BFS原则对应用程序中的所有节点进行遍历，以确定各个内存泄露对象对应的GC Path，以及在确定生成节点队列时，对于类节点、实例、数组分别采用不同的方式求取子节点，并加入节点队列。由此，通过对于不同类型的节点，采用不同的方式求取节点对应的子节点，以提升节点遍历的准确性和全面性，从而不仅可以通过独立的进程进行内存泄露监控，有效定位应用程序中存在的内存泄露对象，有效解决O OM问题，而且进一步提升了确定的内存泄露对象对应的GC Path的准确性，进而进一步提升了内存泄露监控的准确度。
图6是根据一示例性实施例示出的一种内存泄漏的监控装置框图。参照图6，该装置50包括轮询模块51、创建模块52、第一获取模块53及确定模块54。
该轮询模块51，被配置为执行响应于获取的应用程序启动指令，轮询应用程序对应的目标虚拟机堆内存占用状态的步骤；
该创建模块52，被配置为执行在目标虚拟机堆内存占用状态满足堆转储条件时，创建应用程序对应的子进程的步骤；
该第一获取模块53，被配置为执行执行子进程，以获取与目标虚拟机堆中的数据对应的堆转储文件的步骤；
该确定模块54，被配置为执行对堆转储文件进行分析，确定应用程序中包含的各个内存泄漏对象的步骤。
在实际使用时，本公开实施例提供的内存泄漏的监控装置，可以被配置在任意电子设备中，以执行前述内存泄漏的监控方法。
本公开的实施例提供的内存泄漏的监控装置，通过在应用程序启动之后，轮询应用程序对应的目标虚拟机堆内存占用状态，并在目标虚拟机堆内存占用状态满足堆转储条件时，创建应用程序对应的子进程，之后执行子进程，以获取与目标虚拟机堆中的数据对应的堆转储文件，进而对堆转储文件进行分析，确定应用程序中包含的各个内存泄漏对象。由此，通过预设堆转储条件确定应用程序可能出现OOM的时机，并新建独立的子进程生成可对目标虚拟机对中的数据进行索引的堆转储文件并进行分析，以确定内存泄露对象，从而不仅可以有效定位应用程序中存在的内存泄露对象，有效解决OOM问题，而且通过独立的进程进行内存泄露监控，无需冻结虚拟机，不会影响应用程序的正常使用。
在本公开一种可能的实现形式中，上述确定模块54，包括：
创建单元，被配置为执行创建堆转储分析进程的步骤；
第一确定单元，执行堆转储分析进程，以对堆转储文件进行分析，确定应用程序中包含的各个内存泄漏对象。
进一步的，在本公开另一种可能的实现形式中，上述创建模块52，包括：
累加单元，被配置为执行在当前轮询时刻目标虚拟机堆的内存占用率大于第一阈值、且当前轮询时刻的内存占用率大于相邻的前一轮询时刻的内存占用率时，将堆转储触发次数加一的步骤；
创建单元，被配置为执行在当前的堆转储触发次数大于第二阈值时，创建应用程序对应的子进程的步骤。
进一步的，在本公开再一种可能的实现形式中，上述确定模块54，包括：
解析单元，被配置为执行对堆转储文件进行解析，以构建堆转储文件的索引的步骤；
第二确定单元，被配置为执行依据堆转储文件的索引，对堆转储文件进行遍历分析，以确定应用程序中包含的各个内存泄漏对象的步骤。
进一步的，在本公开又一种可能的实现形式中，上述堆转储文件的索引包括各个第一类实例对象索引，相应的，上述第二确定单元，包括：
第一确定子单元，被配置为执行依据堆转储文件中各个第一类实例对象索引，对堆转储文件中的各个第一类实例对象进行遍历，以将目标字段值为预设值的每个第一类实例对象确定为应用程序中的内存泄漏对象的步骤。
进一步的，在本公开又一种可能的实现形式中，上述堆转储文件的索引包括各个第二类实例对象索引，相应的，上述第二确定单元，包括：
第一获取子单元，被配置为执行依据堆转储文件中各个第二类实例对象索引，对堆转储文件中的各个第二类实例对象进行遍历，以获取每个第二类实例对象的字段值的步骤；
第二确定子单元，被配置为执行将每个字段值大于第三阈值的第二类实例对象，确定为应用程序中的内存泄漏对象的步骤。
进一步的，在本公开另一种可能的实现形式中，上述堆转储文件的索引包括各个数组对象索引，相应的，上述第二确定单元，包括：
第二获取子单元，被配置为执行依据堆转储文件中各个数组对象索引，对堆转储文件中的各个数组对象进行遍历，以获取每个数组对象的长度的步骤；
第三确定子单元，被配置为执行将长度大于第四阈值的数组对象，确定为应用程序中的内存泄漏对象的步骤。
进一步的，在本公开再一种可能的实现形式中，上述内存泄漏的监控装置50，还包括：
第二获取模块，被配置为执行获取每个内存泄漏对象对应的垃圾收集路径的步骤。
进一步的，在本公开又一种可能的实现形式中，上述第二获取模块，包括：
第一获取单元，被配置为执行获取待遍历的节点队列的步骤；
校验单元，被配置为执行依次从节点队列中取出一个节点，以校验取出的节点标识是否与应用程序的任一内存泄漏对象的标识匹配的步骤；
第三确定单元，被配置为执行在取出的节点标识与应用程序的任一内存泄漏对象的标识匹配时，根据取出的节点及关联的各级父节点，确定内存泄漏对象对应的垃圾收集路径的步骤。
进一步的，在本公开又一种可能的实现形式中，上述第二获取模块，还包括：
迭代单元，被配置为执行取出的节点标识与应用程序的任一内存泄漏对象的标识未匹配时，将取出的节点的子节点加入节点队列，返回继续执行从节点队列中取出节点的操作，直至节点队列中的节点为空的步骤。
进一步的，在本公开另一种可能的实现形式中，上述第二获取模块，还包括：
第四确定单元，被配置为执行确定取出的节点的子节点所属的目标类的步骤；
第五确定单元，被配置为执行确定已加入节点队列中、且属于目标类的节点数量小于第五阈值的步骤。
进一步的，在本公开再一种可能的实现形式中，上述在取出的节点为类节点时，相应的，上述第二获取模块，还包括：
第二获取单元，被配置为执行遍历堆转储文件的类索引，以获取取出的节点包含的类静态变量的步骤；
第六确定单元，被配置为执行确定类静态变量为取出的节点的子节点的步骤。
进一步的，在本公开又一种可能的实现形式中，上述在取出的节点为实例时，相应的，上述第二获取模块，还包括：
第三获取单元，被配置为执行遍历堆转储文件的类索引，以获取堆转储文件中的各非静态变量字段中引用取出的节点的目标类的步骤；
第七确定单元，被配置为执行遍历堆转储文件的实例索引，以确定目标类对应的各实例的步骤；
第八确定单元，被配置为执行确定目标类对应的各实例为取出的节点的子节点的步骤。
进一步的，在本公开又一种可能的实现形式中，上述在取出的节点为数组时，相应的，上述第二获取模块，还包括：
第九确定单元，被配置为执行遍历堆转储文件的数组索引，以根据取出的节点中包含的各实例确定取出的节点的子节点的步骤。
进一步的，在本公开另一种可能的实现形式中，上述第一获取单元，包括：
生成子单元，被配置为执行根据应用程序对应的各个垃圾收集根节点，生成待遍历的节点队列的步骤。
关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。
本公开的实施例提供的内存泄漏的监控装置，本公开的实施例提供的内存泄漏的监控方法，通过在应用程序启动之后，轮询应用程序对应的目标虚拟机堆内存占用状态，并在确定目标虚拟机堆的内存占用率大于阈值且逐渐递增时，触发内存泄露监控进程并创建应用程序对应的子进程，之后执行子进程，以获取与目标虚拟机堆中的数据对应的堆转储文件，进而通过堆转储分析进程，构建堆转储文件的索引，进而根据堆转储文件的索引对堆转储文件进行遍历分析，以确定应用程序中包含的各个内存泄漏对象。由此，通过将目标虚拟机对的内存占用率较大且逐渐递增的时机确定为触发内存泄露监控的时机，避免了对内存泄露监控时机的误判；并且通过构建堆转储文件的索引对堆转储文件进行遍历，无需一次性将堆转储文件载入内存，降低了内存泄露监控的内存开销，从而不仅可以通过独立的进程进行内存泄露监控，有效定位应用程序中存在的内存泄露对象，有效解决OOM问题，而且进一步提升了内存泄露监控的可靠性和稳定性，并且降低了内存损耗，进一步提升了用户体验。
图7是根据一示例性实施例示出的一种用于内存泄漏监控的电子设备200的框图。
如图7所示，上述电子设备200包括：
存储器210及处理器220，连接不同组件(包括存储器210和处理器220)的总线230，存储器210存储有计算机程序，当处理器220执行所述程序时实现本公开实施例所述的内存泄漏的监控方法。
总线230表示几类总线结构中的一种或多种，包括存储器总线或者存储器控制器，外围总线，图形加速端口，处理器或者使用多种总线结构中的任意总线结构的局域总线。举例来说，这些体系结构包括但不限于工业标准体系结构(ISA)总线，微通道体系结构(M AC)总线，增强型ISA总线、视频电子标准协会(VESA)局域总线以及外围组件互连(PCI)总线。
电子设备200典型地包括多种电子设备可读介质。这些介质可以是任何能够被电子设备200访问的可用介质，包括易失性和非易失性介质，可移动的和不可移动的介质。
存储器210还可以包括易失性存储器形式的计算机系统可读介质，例如随机存取存储器(RAM)240和/或高速缓存存储器250。电子设备200可以进一步包括其它可移动/不可移动的、易失性/非易失性计算机系统存储介质。仅作为举例，存储系统260可以用于读写不可移动的、非易失性磁介质(图7未显示，通常称为“硬盘驱动器”)。尽管图7中未示出，可以提供用于对可移动非易失性磁盘(例如“软盘”)读写的磁盘驱动器，以及对可移动非易失性光盘(例如CD-ROM,DVD-ROM或者其它光介质)读写的光盘驱动器。在这些情况下，每个驱动器可以通过一个或者多个数据介质接口与总线230相连。存储器210可以包括至少一个程序产品，该程序产品具有一组(例如至少一个)程序模块，这些程序模块被配置以执行本公开各实施例的功能。
具有一组(至少一个)程序模块270的程序/实用工具280，可以存储在例如存储器210中，这样的程序模块270包括——但不限于——操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。程序模块270通常执行本公开所描述的实施例中的功能和/或方法。
电子设备200也可以与一个或多个外部设备290(例如键盘、指向设备、显示器291等)通信，还可与一个或者多个使得用户能与该电子设备200交互的设备通信，和/或与使得该电子设备200能与一个或多个其它计算设备进行通信的任何设备(例如网卡，调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口292进行。并且，电子设备200还可以通过网络适配器293与一个或者多个网络(例如局域网(LAN)，广域网(W AN)和/或公共网络，例如因特网)通信。如图所示，网络适配器293通过总线230与电子设备200的其它模块通信。应当明白，尽管图中未示出，可以结合电子设备200使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储系统等。
处理器220通过运行存储在存储器210中的程序，从而执行各种功能应用以及数据处理。
需要说明的是，本实施例的电子设备的实施过程和技术原理参见前述对本公开实施例的内存泄漏的监控方法的解释说明，此处不再赘述。
本公开实施例提供的电子设备，可以执行如前所述的内存泄漏的监控方法，通过在应用程序启动之后，轮询应用程序对应的目标虚拟机堆内存占用状态，并在目标虚拟机堆内存占用状态满足堆转储条件时，创建应用程序对应的子进程，之后执行子进程，以获取与目标虚拟机堆中的数据对应的堆转储文件，进而对堆转储文件进行分析，确定应用程序中包含的各个内存泄漏对象。由此，通过预设堆转储条件确定应用程序可能出现OOM的时机，并新建独立的子进程生成可对目标虚拟机对中的数据进行索引的堆转储文件并进行分析，以确定内存泄露对象，从而不仅可以有效定位应用程序中存在的内存泄露对象，有效解决OOM问题，而且通过独立的进程进行内存泄露监控，无需冻结虚拟机，不会影响应用程序的正常使用。
为了实现上述实施例，本公开还提出一种存储介质。
其中，该存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行如前所述的内存泄漏的监控方法。
为了实现上述实施例，本公开还提供一种计算机程序产品，该计算机程序由电子设备的处理器执行时，使得电子设备能够执行如前所述的内存泄漏的监控方法。
本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本公开旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求指出。
应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。
Claims (28)
1.一种内存泄漏的监控方法，其特征在于，包括：
响应于获取的应用程序启动指令，轮询所述应用程序对应的目标虚拟机堆内存占用状态；
在所述目标虚拟机堆内存占用状态满足堆转储条件时，创建所述应用程序对应的子进程；
执行所述子进程，以获取与所述目标虚拟机堆中的数据对应的堆转储文件；
对所述堆转储文件进行分析，确定所述应用程序中包含的各个内存泄漏对象；
其中，在所述确定所述应用程序中包含的各个内存泄漏对象之后，还包括：
获取每个内存泄漏对象对应的垃圾收集路径；
所述获取每个内存泄漏对象对应的垃圾收集路径，包括：
获取待遍历的节点队列，其中，所述节点队列由应用程序对应的各个GC Root为查找起点，使用基于队列的广度优先搜索生成；
依次从所述节点队列中取出一个节点，以校验所述取出的节点标识是否与所述应用程序的任一内存泄漏对象的标识匹配；
在所述取出的节点标识与所述应用程序的任一内存泄漏对象的标识匹配时，根据所述取出的节点及关联的各级父节点，确定所述内存泄漏对象对应的垃圾收集路径。
2.如权利要求1所述的方法，其特征在于，所述对所述堆转储文件进行分析，确定所述应用程序中包含的各个内存泄漏对象，包括：
创建堆转储分析进程；
执行所述堆转储分析进程，以对所述堆转储文件进行分析，确定所述应用程序中包含的各个内存泄漏对象。
3.如权利要求1所述的方法，其特征在于，所述在所述目标虚拟机堆内存占用状态满足堆转储条件时，创建所述应用程序对应的子进程，包括：
在当前轮询时刻所述目标虚拟机堆的内存占用率大于第一阈值、且当前轮询时刻的内存占用率大于相邻的前一轮询时刻的内存占用率时，将堆转储触发次数加一；
在当前的所述堆转储触发次数大于第二阈值时，创建所述应用程序对应的子进程。
4.如权利要求2所述的方法，其特征在于，所述对所述堆转储文件进行分析，以确定所述应用程序中包含的各个内存泄漏对象，包括：
对所述堆转储文件进行解析，以构建所述堆转储文件的索引；
依据所述堆转储文件的索引，对所述堆转储文件进行遍历分析，以确定所述应用程序中包含的各个内存泄漏对象。
5.如权利要求4所述的方法，其特征在于，所述堆转储文件的索引包括各个第一类实例对象索引，所述依据所述堆转储文件的索引，对所述堆转储文件进行遍历分析，以确定所述应用程序中包含的各个内存泄漏对象，包括：
依据所述堆转储文件中各个第一类实例对象索引，对所述堆转储文件中的各个第一类实例对象进行遍历，以将目标字段值为预设值的每个第一类实例对象确定为所述应用程序中的内存泄漏对象。
6.如权利要求4所述的方法，其特征在于，所述堆转储文件的索引包括各个第二类实例对象索引，所述依据所述堆转储文件的索引，对所述堆转储文件进行遍历分析，以确定所述应用程序中包含的各个内存泄漏对象，包括：
依据所述堆转储文件中各个第二类实例对象索引，对所述堆转储文件中的各个第二类实例对象进行遍历，以获取每个第二类实例对象的字段值；
将每个字段值大于第三阈值的第二类实例对象，确定为所述应用程序中的内存泄漏对象。
7.如权利要求4所述的方法，其特征在于，所述堆转储文件的索引包括各个数组对象索引，所述依据所述堆转储文件的索引，对所述堆转储文件进行遍历分析，以确定所述应用程序中包含的各个内存泄漏对象，包括：
依据所述堆转储文件中各个数组对象索引，对所述堆转储文件中的各个数组对象进行遍历，以获取每个数组对象的长度；
将长度大于第四阈值的数组对象，确定为所述应用程序中的内存泄漏对象。
8.如权利要求1所述的方法，其特征在于，在所述校验所述取出的节点标识是否为所述应用程序的任一内存泄漏对象的标识之后，还包括：
在所述取出的节点标识与所述应用程序的任一内存泄漏对象的标识未匹配时，将所述取出的节点的子节点加入所述节点队列，返回继续执行从所述节点队列中取出节点的操作，直至所述节点队列中的节点为空。
9.如权利要求8所述的方法，其特征在于，在所述将所述取出的节点的子节点加入所述节点队列之前，还包括：
确定所述取出的节点的子节点所属的目标类；
确定已加入所述节点队列中、且属于所述目标类的节点数量小于第五阈值。
10.如权利要求8所述的方法，其特征在于，在所述取出的节点为类节点时，在所述将所述取出的节点的子节点加入所述节点队列之前，还包括：
遍历所述堆转储文件的类索引，以获取所述取出的节点包含的类静态变量；
确定所述类静态变量为所述取出的节点的子节点。
11.如权利要求8所述的方法，其特征在于，在所述取出的节点为实例时，在所述将所述取出的节点的子节点加入所述节点队列之前，还包括：
遍历所述堆转储文件的类索引，以获取所述堆转储文件中的各非静态变量字段中引用所述取出的节点的目标类；
遍历所述堆转储文件的实例索引，以确定所述目标类对应的各实例；
确定所述目标类对应的各实例为所述取出的节点的子节点。
12.如权利要求8所述的方法，其特征在于，在所述取出的节点为数组时，在所述将所述取出的节点的子节点加入所述节点队列之前，还包括：
遍历所述堆转储文件的数组索引，以根据所述取出的节点中包含的各实例确定所述取出的节点的子节点。
13.如权利要求1所述的方法，其特征在于，所述获取待遍历的节点队列，包括：
根据所述应用程序对应的各个垃圾收集根节点，生成所述待遍历的节点队列。
14.一种内存泄漏的监控装置，其特征在于，包括：
轮询模块，被配置为执行响应于获取的应用程序启动指令，轮询所述应用程序对应的目标虚拟机堆内存占用状态的步骤；
创建模块，被配置为执行在所述目标虚拟机堆内存占用状态满足堆转储条件时，创建所述应用程序对应的子进程的步骤；
第一获取模块，被配置为执行执行所述子进程，以获取与所述目标虚拟机堆中的数据对应的堆转储文件的步骤；
确定模块，被配置为执行对所述堆转储文件进行分析，确定所述应用程序中包含的各个内存泄漏对象的步骤；
所述装置还包括：
第二获取模块，被配置为执行获取每个内存泄漏对象对应的垃圾收集路径的步骤；
所述第二获取模块，包括：
第一获取单元，被配置为执行获取待遍历的节点队列的步骤，其中，所述节点队列由应用程序对应的各个GC Root为查找起点，使用基于队列的广度优先搜索生成；
校验单元，被配置为执行依次从所述节点队列中取出一个节点，以校验所述取出的节点标识是否与所述应用程序的任一内存泄漏对象的标识匹配的步骤；
第三确定单元，被配置为执行在所述取出的节点标识与所述应用程序的任一内存泄漏对象的标识匹配时，根据所述取出的节点及关联的各级父节点，确定所述内存泄漏对象对应的垃圾收集路径的步骤。
15.如权利要求14所述的装置，其特征在于，所述确定模块，包括：
创建单元，被配置为执行创建堆转储分析进程的步骤；
第一确定单元，执行所述堆转储分析进程，以对所述堆转储文件进行分析，确定所述应用程序中包含的各个内存泄漏对象。
16.如权利要求14所述的装置，其特征在于，所述创建模块，包括：
累加单元，被配置为执行在当前轮询时刻所述目标虚拟机堆的内存占用率大于第一阈值、且当前轮询时刻的内存占用率大于相邻的前一轮询时刻的内存占用率时，将堆转储触发次数加一的步骤；
创建单元，被配置为执行在当前的所述堆转储触发次数大于第二阈值时，创建所述应用程序对应的子进程的步骤。
17.如权利要求15所述的装置，其特征在于，所述确定模块，包括：
解析单元，被配置为执行对所述堆转储文件进行解析，以构建所述堆转储文件的索引的步骤；
第二确定单元，被配置为执行依据所述堆转储文件的索引，对所述堆转储文件进行遍历分析，以确定所述应用程序中包含的各个内存泄漏对象的步骤。
18.如权利要求17所述的装置，其特征在于，所述堆转储文件的索引包括各个第一类实例对象索引，所述第二确定单元，包括：
第一确定子单元，被配置为执行依据所述堆转储文件中各个第一类实例对象索引，对所述堆转储文件中的各个第一类实例对象进行遍历，以将目标字段值为预设值的每个第一类实例对象确定为所述应用程序中的内存泄漏对象的步骤。
19.如权利要求17所述的装置，其特征在于，所述堆转储文件的索引包括各个第二类实例对象索引，所述第二确定单元，包括：
第一获取子单元，被配置为执行依据所述堆转储文件中各个第二类实例对象索引，对所述堆转储文件中的各个第二类实例对象进行遍历，以获取每个第二类实例对象的字段值的步骤；
第二确定子单元，被配置为执行将每个字段值大于第三阈值的第二类实例对象，确定为所述应用程序中的内存泄漏对象的步骤。
20.如权利要求17所述的装置，其特征在于，所述堆转储文件的索引包括各个数组对象索引，所述第二确定单元，包括：
第二获取子单元，被配置为执行依据所述堆转储文件中各个数组对象索引，对所述堆转储文件中的各个数组对象进行遍历，以获取每个数组对象的长度的步骤；
第三确定子单元，被配置为执行将长度大于第四阈值的数组对象，确定为所述应用程序中的内存泄漏对象的步骤。
21.如权利要求14所述的装置，其特征在于，所述第二获取模块，还包括：
迭代单元，被配置为执行所述取出的节点标识与所述应用程序的任一内存泄漏对象的标识未匹配时，将所述取出的节点的子节点加入所述节点队列，返回继续执行从所述节点队列中取出节点的操作，直至所述节点队列中的节点为空的步骤。
22.如权利要求21所述的装置，其特征在于，所述第二获取模块，还包括：
第四确定单元，被配置为执行确定所述取出的节点的子节点所属的目标类的步骤；
第五确定单元，被配置为执行确定已加入所述节点队列中、且属于所述目标类的节点数量小于第五阈值的步骤。
23.如权利要求21所述的装置，其特征在于，在所述取出的节点为类节点时，所述第二获取模块，还包括：
第二获取单元，被配置为执行遍历所述堆转储文件的类索引，以获取所述取出的节点包含的类静态变量的步骤；
第六确定单元，被配置为执行确定所述类静态变量为所述取出的节点的子节点的步骤。
24.如权利要求21所述的装置，其特征在于，在所述取出的节点为实例时，所述第二获取模块，还包括：
第三获取单元，被配置为执行遍历所述堆转储文件的类索引，以获取所述堆转储文件中的各非静态变量字段中引用所述取出的节点的目标类的步骤；
第七确定单元，被配置为执行遍历所述堆转储文件的实例索引，以确定所述目标类对应的各实例的步骤；
第八确定单元，被配置为执行确定所述目标类对应的各实例为所述取出的节点的子节点的步骤。
25.如权利要求21所述的装置，其特征在于，在所述取出的节点为数组时，所述第二获取模块，还包括：
第九确定单元，被配置为执行遍历所述堆转储文件的数组索引，以根据所述取出的节点中包含的各实例确定所述取出的节点的子节点的步骤。
26.如权利要求14所述的装置，其特征在于，所述第一获取单元，包括：
生成子单元，被配置为执行根据所述应用程序对应的各个垃圾收集根节点，生成所述待遍历的节点队列的步骤。
27.一种电子设备，其特征在于，包括：
处理器；
用于存储所述处理器可执行指令的存储器；
其中，所述处理器被配置为执行所述指令，以实现如权利要求1-13中任一项所述的内存泄漏的监控方法。
28.一种存储介质，当所述存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行如权利要求1-13中任一项所述的内存泄漏的监控方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010761045.6A CN112035314B (zh) | 2020-07-31 | 2020-07-31 | 内存泄漏的监控方法、装置及电子设备 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010761045.6A CN112035314B (zh) | 2020-07-31 | 2020-07-31 | 内存泄漏的监控方法、装置及电子设备 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN112035314A CN112035314A (zh) | 2020-12-04 |
| CN112035314B true CN112035314B (zh) | 2024-04-30 |
Family
ID=73583762
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010761045.6A Active CN112035314B (zh) | 2020-07-31 | 2020-07-31 | 内存泄漏的监控方法、装置及电子设备 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112035314B (zh) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113157477B (zh) * | 2021-04-14 | 2024-02-06 | 北京字节跳动网络技术有限公司 | 内存泄漏的归因方法、装置、电子设备和存储介质 |
| CN113360454B (zh) * | 2021-06-30 | 2024-03-01 | 广州虎牙科技有限公司 | 一种内存快照文件的压缩、解压缩方法及相关装置 |
| CN115952006B (zh) * | 2023-03-13 | 2023-06-02 | 浪潮电子信息产业股份有限公司 | 资源泄漏的检测方法、系统、装置、服务器及存储介质 |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107102922A (zh) * | 2017-04-01 | 2017-08-29 | 北京三快在线科技有限公司 | 内存检测方法、装置及电子设备 |
| CN107632929A (zh) * | 2017-08-21 | 2018-01-26 | 北京京东尚科信息技术有限公司 | 一种检测内存泄漏的方法和装置 |
| CN109558308A (zh) * | 2018-09-29 | 2019-04-02 | 中国平安人寿保险股份有限公司 | 应用程序内存泄露检测方法、装置、电子设备及存储介质 |
| CN110457150A (zh) * | 2019-07-10 | 2019-11-15 | 锐捷网络股份有限公司 | 一种内存故障检测方法及装置 |
| CN111090536A (zh) * | 2019-11-19 | 2020-05-01 | 北京字节跳动网络技术有限公司 | 一种获取内存泄露信息的方法、装置、介质和电子设备 |
-
2020
- 2020-07-31 CN CN202010761045.6A patent/CN112035314B/zh active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107102922A (zh) * | 2017-04-01 | 2017-08-29 | 北京三快在线科技有限公司 | 内存检测方法、装置及电子设备 |
| CN107632929A (zh) * | 2017-08-21 | 2018-01-26 | 北京京东尚科信息技术有限公司 | 一种检测内存泄漏的方法和装置 |
| CN109558308A (zh) * | 2018-09-29 | 2019-04-02 | 中国平安人寿保险股份有限公司 | 应用程序内存泄露检测方法、装置、电子设备及存储介质 |
| CN110457150A (zh) * | 2019-07-10 | 2019-11-15 | 锐捷网络股份有限公司 | 一种内存故障检测方法及装置 |
| CN111090536A (zh) * | 2019-11-19 | 2020-05-01 | 北京字节跳动网络技术有限公司 | 一种获取内存泄露信息的方法、装置、介质和电子设备 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN112035314A (zh) | 2020-12-04 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN112035314B (zh) | 内存泄漏的监控方法、装置及电子设备 | |
| CN106874187B (zh) | 代码覆盖率收集方法和装置 | |
| CN107066390B (zh) | 一种动态内存泄漏检测方法及系统 | |
| CN108694320B (zh) | 一种多安全环境下敏感应用动态度量的方法及系统 | |
| CN110059068B (zh) | 一种分布式存储系统中的数据校验方法及数据校验系统 | |
| CN110245085B (zh) | 利用在线模型检验的嵌入式实时操作系统验证方法及系统 | |
| CN111324441A (zh) | 运行环境的切换方法、装置、计算机设备和存储介质 | |
| CN111240876A (zh) | 微服务的故障定位方法、装置、存储介质及终端 | |
| CN111181800A (zh) | 测试数据处理方法、装置、电子设备及存储介质 | |
| CN115686961A (zh) | 处理器测试方法、装置及电子设备 | |
| CN116097226A (zh) | 用于将故障注入分布式系统的装置和方法 | |
| CN113127331A (zh) | 一种基于故障注入的测试方法、装置及计算机设备 | |
| CN115022201B (zh) | 一种数据处理功能测试方法、装置、设备及存储介质 | |
| CN108021478B (zh) | 一种图形处理器鲁棒性测试方法 | |
| CN111858307B (zh) | 模糊测试方法和设备 | |
| US20130006568A1 (en) | Test Operation | |
| CN113590495A (zh) | 一种测试覆盖率的确定方法、装置、设备及存储介质 | |
| CN107102938B (zh) | 测试脚本的更新方法及装置 | |
| CN111966599A (zh) | 一种虚拟化平台可靠性测试方法、系统、终端及存储介质 | |
| CN113760696A (zh) | 一种程序问题定位方法、装置、电子设备和存储介质 | |
| CN113010409B (zh) | 智能合约测试方法及装置、电子设备、存储介质 | |
| CN111274143B (zh) | 埋点测试方法、装置、设备及存储介质 | |
| CN116414722B (zh) | 模糊测试处理方法、装置、模糊测试系统及存储介质 | |
| CN112613254B (zh) | 一种处理器内部镜像控制模块注错验证系统及方法 | |
| US9262251B1 (en) | Detecting memory failures in computing systems |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant |