[go: up one dir, main page]

CN111274060A - 一种确定内存异常的方法、装置、设备和存储介质 - Google Patents

一种确定内存异常的方法、装置、设备和存储介质 Download PDF

Info

Publication number
CN111274060A
CN111274060A CN202010084704.7A CN202010084704A CN111274060A CN 111274060 A CN111274060 A CN 111274060A CN 202010084704 A CN202010084704 A CN 202010084704A CN 111274060 A CN111274060 A CN 111274060A
Authority
CN
China
Prior art keywords
memory
information
memory information
determining
application program
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.)
Granted
Application number
CN202010084704.7A
Other languages
English (en)
Other versions
CN111274060B (zh
Inventor
陈文俊
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Guangzhou Huya Technology Co Ltd
Original Assignee
Guangzhou Huya Technology Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Guangzhou Huya Technology Co Ltd filed Critical Guangzhou Huya Technology Co Ltd
Priority to CN202010084704.7A priority Critical patent/CN111274060B/zh
Publication of CN111274060A publication Critical patent/CN111274060A/zh
Application granted granted Critical
Publication of CN111274060B publication Critical patent/CN111274060B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING OR CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/073Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a memory management context, e.g. virtual memory or cache management
    • GPHYSICS
    • G06COMPUTING OR CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0766Error or fault reporting or storing
    • GPHYSICS
    • G06COMPUTING OR CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/079Root cause analysis, i.e. error or fault diagnosis
    • GPHYSICS
    • G06COMPUTING OR CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Prevention of errors by analysis, debugging or testing of software
    • G06F11/362Debugging of software
    • G06F11/366Debugging of software using diagnostics
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02DCLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Health & Medical Sciences (AREA)
  • Biomedical Technology (AREA)
  • Computer Hardware Design (AREA)
  • Debugging And Monitoring (AREA)

Abstract

本发明公开了一种确定内存异常的方法、装置、设备和存储介质。该方法包括:接收应用程序上传的日志信息,日志信息包括应用程序发生崩溃时的页面,以及,应用程序发生崩溃前的、两种或两种以上的内存信息;根据两种或两种以上的内存信息,识别应用程序发生崩溃前存在内存异常;确定应用程序在跳转页面申请内存时,因内存异常引发崩溃。通过该方法实现了采集每个可能发生系统崩溃的内存异常时的较为全面的信息,通过该方法可以较为全面的信息可以判定出导致系统崩溃的内存异常。

Description

一种确定内存异常的方法、装置、设备和存储介质
技术领域
本发明实施例涉及内存异常采集技术,尤其涉及一种确定内存异常的方法、装置、设备和存储介质。
背景技术
内存泄漏(Memory Leak)是指程序中己动态分配的堆内存由于某种原因程序未释放或无法释放,造成系统内存的浪费,导致程序运行速度减慢甚至系统崩溃等严重后果。
内存泄漏缺陷具有隐蔽性、积累性的特征,比其他内存非法访问错误更难检测。因为内存泄漏的产生原因是内存块未被释放,属于遗漏型缺陷而不是过错型缺陷。此外,内存泄漏通常不会直接产生可观察的错误症状,而是逐渐积累,降低系统整体性能,极端的情况下可能使系统崩溃。
一般的,以移动通信设备(如手机)为例,一般会在移动通信设备发生系统崩溃时,采集系统崩溃时的各种信息。同时,移动通信设备的进程运行期间也会记录一些必要数据。在系统崩溃发生时候,会将崩溃时采集的各种信息以及常规采集的必要数据一并上报。
由于应用程序进程内存耗尽后,进程的任意正常需要申请内存的操作会发生异常,进而发生进程崩溃。因此可能耗费/泄露内存的是在第一时间点,但是崩溃却发生在需要申请内存的第二时间点。采用常规的处理方式,我们能够获得系统崩溃的第二时间点比较全面的各种信息,但是对于实际发生耗费/泄露内存的第一时间点,只能获得常规信息。这对我们确定内存异常带来了极大的不便。
发明内容
本发明提供一种确定内存异常的方法、装置、设备和存储介质,以解决收集系统崩溃时较为全面的信息和应用程序运行时的常规信息、不能确定内存异常的问题。
第一方面,本发明实施例提供了一种确定内存异常的方法,包括:
接收应用程序上传的日志信息,所述日志信息包括所述应用程序发生崩溃时的页面,以及,所述应用程序发生崩溃前的、两种或两种以上的内存信息;
根据所述两种或两种以上的内存信息,识别所述应用程序发生崩溃前存在内存异常;
确定所述应用程序在跳转所述页面申请内存时,因所述内存异常引发崩溃。
在此基础上,所述根据所述两种或两种以上的内存信息,识别所述应用程序发生崩溃前存在内存异常,包括:
确定所述两种或两种以上的内存信息之间的约束关系,每个所述内存信息用于识别一种内存异常,所述约束关系用于约束在出现某一内存信息的异常时,是否出现其他内存信息的异常;
按照所述约束关系确定所述两种或两种以上的内存信息的顺序;
按照所述顺序依次根据所述内存信息识别所述应用程序发生崩溃前存在内存异常。
在此基础上,所述内存信息包括:堆内存信息、常驻内存信息和虚拟内存信息,所述堆内存信息用于识别java内存泄露、所述常驻内存信息用于识别native内存泄露、所述虚拟内存信息用于识别虚拟内存地址空间耗尽;
所述确定所述两种或两种以上的内存信息之间的约束关系,包括:
确定所述堆内存信息与所述常驻内存信息、所述虚拟内存信息约束关系为:出现堆内存信息异常时,出现常驻内存信息异常与虚拟内存信息异常;出现常驻内存信息异常时,出现虚拟内存信息异常。
在此基础上,所述按照所述顺序依次根据所述内存信息识别所述应用程序发生崩溃前存在内存异常,包括:
判断所述堆内存信息是否异常;
当所述堆内存信息为异常时,确定所述应用程序发生崩溃前存在的内存异常为java内存泄露;
当所述堆内存信息为正常时,判断所述常驻内存信息是否异常;
当所述常驻内存信息为异常时,确定所述应用程序发生崩溃前存在的内存异常为native内存泄露;
当所述常驻内存信息为正常时,判断所述虚拟内存信息是否异常;
当所述虚拟内存信息为异常时,确定所述应用程序发生崩溃前存在的内存异常为虚拟内存地址空间耗尽。
在此基础上,所述堆内存信息包括进程最大可用堆内存、已经申请的堆内存、已用内存和剩余堆内存;
所述判断所述堆内存信息是否异常,包括:
判断所述堆内存信息是否满足第一条件;
若是,则确定所述堆内存信息异常;
若否,则确定所述堆内存信息正常;
其中,所述第一条件包括如下至少一种:
所述已经申请的堆内存在所述进程最大可用堆内存中占比超过第一阈值;
所述已用内存在所述进程最大可用堆内存中占比超过第一阈值;
或者,
判断所述堆内存信息是否满足第二条件;
若是,则确定所述堆内存信息异常;
若否,则确定所述堆内存信息正常;
其中,所述第二条件包括如下至少一种:
在相邻两条日志信息中,后一条日志信息中的已经申请的堆内存与前一条日志信息中的已经申请的堆内存相比,超过第二阈值;
在相邻两条日志信息中,后一条日志信息中的已用内存与前一条日志信息中的已用内存相比,超过第二阈值。
在此基础上,所述判断所述常驻内存信息是否异常,包括:
判断相邻两条日志信息中,后一条日志信息中的常驻内存信息与前一条日志信息中的常驻内存信息相比,是否超过第三阈值;
若是,则确定所述常驻内存信息异常;
若否,则确定所述常驻内存信息正常。
在此基础上,所述判断所述虚拟内存信息是否异常,包括:
判断所述虚拟内存信息是否超过第四阈值;
若是,则确定所述虚拟内存信息异常;
若否,则确定所述虚拟内存信息正常;
或者,
判断相邻两条日志信息中,后一条日志信息中的虚拟内存信息与前一条日志信息中的虚拟内存信息相比,是否超过第五阈值;
若是,则确定所述虚拟内存信息异常;
若否,则确定所述虚拟内存信息正常。
在此基础上,所述内存信息包括:常驻内存信息和虚拟内存信息;
所述内存信息在满足如下条件时记录:
分别采集所述虚拟内存信息中第一内存数值的大小与所述常驻内存信息中第二内存数值的大小;
计算相邻两个内存信息中的所述第一内存数值、第二内存数值之间的差异值;
基于所述差异值记录所述应用程序的、两种或两种以上的内存信息。
在此基础上,还包括:
确定一个或一个以上的内存异常对应的时间;
确定排序在前的所述时间对应的所述内存异常引发崩溃。
第二方面,本发明实施例还提供了一种确定内存异常的方法,包括:
记录应用程序运行时的、两种或两种以上的内存信息;
若检测到所述应用程序发生崩溃,则记录所述应用程序发生崩溃时跳转的页面;
将所述页面与所述两种或两种以上的内存信息写入日志信息;
将所述日志信息发送至服务器,所述服务器用于根据所述两种或两种以上的内存信息,识别所述应用程序发生崩溃前存在内存异常;确定所述应用程序在跳转所述页面时申请内存,因所述内存异常引发崩溃。
第三方面,本发明实施例还提供了一种确定内存异常的装置,包括:
日志信息接收模块,用于接收应用程序上传的日志信息,所述日志信息包括所述应用程序发生崩溃时的页面,以及,所述应用程序发生崩溃前的、两种或两种以上的内存信息;
内存异常识别模块,用于根据所述两种或两种以上的内存信息,识别所述应用程序发生崩溃前存在内存异常;
页面跳转关联模块,用于确定所述应用程序在跳转所述页面申请内存时,因所述内存异常引发崩溃。
第四方面,本发明实施例还提供了一种确定内存异常的装置,包括:
内存信息接收模块,用于记录应用程序运行时的、两种或两种以上的内存信息;
程序崩溃检测模块,用于若检测到所述应用程序发生崩溃,则记录所述应用程序发生崩溃时跳转的页面;
日志信息写入模块,用于将所述页面与所述两种或两种以上的内存信息写入日志信息;
日志信息发送模块,用于将所述日志信息发送至服务器,所述服务器用于根据所述两种或两种以上的内存信息,识别所述应用程序发生崩溃前存在内存异常;确定所述应用程序在跳转所述页面时申请内存,因所述内存异常引发崩溃。
第五方面,本发明实施例还提供了一种电子设备,包括:
一个或多个处理器;
存储器,用于存储一个或多个程序;
当所述一个或多个程序被所述一个或多个处理器执行,使得所述一个或多个处理器实现如第一、第二方面所述的一种确定内存异常的方法。
第六方面,本发明实施例还提供了一种计算机可读存储介质,其上存储有计算机程序,该程序被处理器执行时实现如第一、第二方面所述的一种确定内存异常的方法。
本发明实施例通过接收应用程序上传的日志信息;根据两种或两种以上的内存信息,识别应用程序发生崩溃前存在内存异常;确定应用程序在跳转页面申请内存时,因内存异常引发崩溃,从而实现了采集每个可能发生系统崩溃的内存异常时的较为全面的信息,通过该方法可以较为全面的信息可以判定出导致系统崩溃的内存异常。
附图说明
图1为本发明实施例一提供的一种确定内存异常的方法的流程图;
图2为本发明实施例二提供的一种确定内存异常的方法的流程图;
图3为本发明实施例三提供的一种确定内存异常的方法的流程图;
图4为本发明实施例四提供的一种确定内存异常的方法的流程图;
图5为本发明实施例五提供的一种确定内存异常的装置的结构图;
图6为本发明实施例六提供的一种确定内存异常的装置的结构图;
图7为本发明实施例七提供的一种电子设备的结构示意图。
具体实施方式
下面结合附图和实施例对本发明作进一步的详细说明。可以理解的是,此处所描述的具体实施例仅仅用于解释本发明,而非对本发明的限定。另外还需要说明的是,为了便于描述,附图中仅示出了与本发明相关的部分而非全部结构。
实施例一
图1为本发明实施例一提供的一种确定内存异常的方法的流程图。本实施例适用于接收应用程序上传的日志信息,根据该日志信息识别应用程序发生崩溃前存在内存异常。该方法可以由一种确定内存异常的装置来执行,该装置可以由软件和/或硬件的方式实现。可配置在计算机设备中,例如,服务器、工作站、个人电脑,等等,该方法具体包括如下步骤:
S101、接收应用程序上传的日志信息。
在计算机中,日志信息是记录在操作系统或其他软件运行中发生的事件或在通信软件的不同用户之间的消息的文件。日志信息记录了在系统的执行中发生的事件,以便提供可用于理解系统的活动和诊断问题的跟踪。日志信息对理解复杂系统的活动至关重要,特别是在用户交互较少的应用程序中。日志信息还可以用于组合来自多个源的日志信息的条目。这种方法与统计分析相结合,可以产生不同服务器上看起来不相关的事件之间的相关性。
一般的,每个日志记录的内容主要包括:事务标识,用于标明是哪个事务;操作的类型,如:插入操作、删除操作或修改操作;操作对象,如:记录内部标识;更新前数据的旧值,对插入操作而言,此项为空值;更新后数据的新值,如:对删除操作而言,此项为空值。
当然,可以根据使用者的需要对日志信息采集的内容进行定义。如在本方案中,日志信息包括应用程序发生崩溃时的页面,可以是采集该页面的统一资源定位系统(uniformresource locator,URL)或者页面编号等。在该应用程序发生崩溃前,该日志信息还包括两种或两种以上的内存信息。
内存信息根据获取和表现内容的不同,包括:堆内存信息、常驻内存信息和虚拟内存信息。
其中,堆内存信息与java内存泄露存在关联关系,常驻内存信息与native内存泄露存在关联关系,虚拟内存信息与虚拟内存地址空间耗尽存在关联关系。
在本实施例中,常驻内存信息可以为常驻内存集(Resident Set Size,RSS)。表示该进程分配的内存大小。包括共享库占用的内存、所有分配的栈内存和堆内存,但不包括进入交换分区的内存。
一般的,虚拟内存是内存管理的一种方式,它在磁盘上划分出一块空间由操作系统管理。本实施例中,虚拟内存信息可以通过VSZ(Virtual Memory Size,虚拟内存)进行表示。VSZ为进程分配的虚拟内存。VSZ包括进程可以访问的所有内存,包括进入交换分区的内容,以及共享库占用的内存。
具体的,服务器接收客户端中、应用程序上传的日志信息。该日志信息还包括两种或两种以上的内存信息,内存信息根据获取和表现内容的不同,包括:堆内存信息、常驻内存信息和虚拟内存信息。
S102、根据所述两种或两种以上的内存信息,识别所述应用程序发生崩溃前存在内存异常。
内存溢出(Out Of Memory,OOM)是指应用系统中存在无法回收的内存或使用的内存过多,最终使得程序运行要用到的内存大于能提供的最大内存。应用程序直接申请内存过多会导致内存泄漏,应用程序进程内存耗尽后,进程的任意正常需要申请内存的操作会发生异常,进而发生进程崩溃。
内存泄漏可以包括如下的三种情况:
第一、对于安卓(Android)平台的应用进程,由于都是虚拟机进程(VirtualMachin,VM)。在该平台上,限制java堆内存默认192M了(最大到512M)。在VM中申请内存超过该限制,会发生内存溢出。
第二、对于32位进程而言,只有4G的理论虚拟地址空间。若理论虚拟地址空间耗尽,再申请内存会发生内存溢出。
第三、对于64位进程而言,理论虚拟地址空间非常大(有2^64),因此几乎不会发生虚拟地址空间耗尽的情况。但是,对于64位进程而言可能发生物理地址耗尽的情况。
当然,另无论是32位进程还是64位进程,都可能发生物理内存耗尽导致的内存溢出。
采集java堆内存作为内存信息中的堆内存信息;采集对常驻内存的消耗作为内存信息中的常驻内存信息;采集对虚拟内存的消耗作为内存信息中的虚拟内存信息。
在一可行的实现方式中,可以逐个对堆内存信息、常驻内存信息与虚拟内存信息是否异常进行判断,根据判断的结果确定内存异常。
在一可行的实现方式中,确定内存信息之间的约束关系,根据约束关系按照一定的先后顺序对堆内存信息、常驻内存信息与虚拟内存信息是否异常进行判断,根据判断的结果确定内存异常。
S103、确定所述应用程序在跳转所述页面申请内存时,因所述内存异常引发崩溃。
接收用户作用于应用程序的操作,根据该操作跳转至一页面。在应用程序跳转到页面时需要申请内存,当应用程序申请内存导致内存溢出时,确定应用程序在跳转页面前存在内存异常,由于该内存异常引发了系统崩溃。
本发明实施例通过接收应用程序上传的日志信息;根据两种或两种以上的内存信息,识别应用程序发生崩溃前存在内存异常;确定应用程序在跳转页面申请内存时,因内存异常引发崩溃,从而实现了采集每个可能发生系统崩溃的内存异常时的较为全面的信息,通过该方法可以较为全面的信息可以判定出导致系统崩溃的内存异常。
实施例二
图2为本发明实施例二提供的一种确定内存异常的方法的流程图。本实施例是在实施例一的基础上进行了细化,描述了根据两种或两种以上的内存信息,识别应用程序发生崩溃前存在内存异常的具体步骤。该方法具体包括如下步骤:
S201、接收应用程序上传的日志信息。
一般的,日志信息包括应用程序发生崩溃时的页面,以及,应用程序发生崩溃前的、两种或两种以上的内存信息。
S202、确定所述两种或两种以上的内存信息之间的约束关系。
一般的,每个内存信息用于识别一种内存异常。内存信息包括:堆内存信息、常驻内存信息和虚拟内存信息。内存异常包括:java内存泄露、native内存泄露和虚拟内存地址空间耗尽。其中,堆内存信息用于识别java内存泄露、常驻内存信息用于识别native内存泄露、虚拟内存信息用于识别虚拟内存地址空间耗尽。
内存信息之间的约束关系,以及内存信息的异常与内存异常之间的对照关系如表一所示:
表一
java内存泄露 native内存泄露 虚拟内存地址空间耗尽
堆内存信息 异常 异常 异常
常驻内存信息 正常 异常 异常
虚拟内存信息 正常 正常 异常
约束关系用于约束在出现某一内存信息的异常时,是否出现其他内存信息的异常。
具体的,堆内存信息与所述常驻内存信息、所述虚拟内存信息约束关系为:出现堆内存信息异常时,出现常驻内存信息异常与虚拟内存信息异常;出现常驻内存信息异常时,出现虚拟内存信息异常。
S203、按照所述约束关系确定所述两种或两种以上的内存信息的顺序。
由于出现堆内存信息异常时,出现常驻内存信息异常与虚拟内存信息异常;出现常驻内存信息异常时,出现虚拟内存信息异常。因此可以设定判断内存信息的顺序为:首先判断堆内存信息是否异常、再判断常驻内存信息是否异常最后判断虚拟内存信息是否异常。
S204、按照所述顺序依次根据所述内存信息识别所述应用程序发生崩溃前存在内存异常。
按照首先判断堆内存信息是否异常、再判断常驻内存信息是否异常最后判断虚拟内存信息是否异常的顺序对内存信息进行逐一的判断。当判断结果为任何一种内存信息为异常时,停止判断并输出内存异常。该内存异常为应用程序发生崩溃前存在的内存异常。
S205、确定所述应用程序在跳转所述页面申请内存时,因所述内存异常引发崩溃。
在上述实施例的基础上,所述内存信息包括:常驻内存信息和虚拟内存信息。如果在应用程序运行时实时记录这些内存信息,会消耗大量的存储空间。由于应用程序正常时,这些内存信息的变化并不大。因此,为了节约存储空间,为内存信息的记录设定如下的条件。即内存信息在满足如下条件时才对其进行记录:
分别采集虚拟内存信息中第一内存数值的大小与常驻内存信息中第二内存数值的大小。计算相邻两个内存信息中的所述第一内存数值、第二内存数值之间的差异值。基于所述差异值记录所述应用程序的、两种或两种以上的内存信息。可以理解为需要两次内存信息有一定的变化时,才会对内存信息进行记录。
在上述实施例的基础上,当某一内存异常是由于某一内存信息超过阈值产生的,那么该内存信息可能在超过阈值到触发系统崩溃之间的很长一段时间都存在,此时可以确定一个或一个以上的内存异常对应的时间;确定排序在前的时间对应的内存异常引发崩溃。
本发明实施例通过接收应用程序上传的日志信息;根据两种或两种以上的内存信息,识别应用程序发生崩溃前存在内存异常;确定应用程序在跳转页面申请内存时,因内存异常引发崩溃,从而实现了采集每个可能发生系统崩溃的内存异常时的较为全面的信息,通过该方法可以较为全面的信息可以判定出导致系统崩溃的内存异常。在此基础上,根据内存异常与内存信息的包含关系,确定了判断内存异常的顺序,在提高内存异常判断的准确性的同时,还节约了判断内存异常所需的数据量和时间。在此基础上,由于设置了内存信息的记录条件,因此可以减少内存信息的数据量。减少了客户端对不必要的内存信息的采集和上传,也减少了服务器端对不必要的内存信息的处理。即节约了算力,也提高了处理效率。
实施例三
图3为本发明实施例三提供的一种确定内存异常的方法的流程图。本实施例是在实施例一、实施例二的基础上进行了细化,描述了按照约束关系确定所述两种或两种以上的内存信息的顺序,以及根据该顺序判断内存异常的具体步骤。该方法具体包括如下步骤:
S301、接收应用程序上传的日志信息。
日志信息包括应用程序发生崩溃时的页面,以及,应用程序发生崩溃前的、两种或两种以上的内存信息。
S302、确定所述两种或两种以上的内存信息之间的约束关系。
所述内存信息包括:堆内存信息、常驻内存信息和虚拟内存信息,所述堆内存信息用于识别java内存泄露、所述常驻内存信息用于识别native内存泄露、所述虚拟内存信息用于识别虚拟内存地址空间耗尽;
所述确定所述两种或两种以上的内存信息之间的约束关系,包括:
确定所述堆内存信息与所述常驻内存信息、所述虚拟内存信息约束关系为:出现堆内存信息异常时,出现常驻内存信息异常与虚拟内存信息异常;出现常驻内存信息异常时,出现虚拟内存信息异常。
S303、按照所述约束关系确定所述两种或两种以上的内存信息的顺序。
S304、判断所述堆内存信息是否异常。当所述堆内存信息为异常时,执行步骤S305;当所述堆内存信息为正常时,执行步骤S306。
其中,判断堆内存信息是否异常可以通过单条内存信息或多条内存信息来确定:
进行数据采集,具体包括采集进程最大可用堆内存(long maxMemory)、已经申请的堆内存(long totalMemory)和剩余堆内存(long freeMemory)。根据已经申请的堆内存与剩余堆内存的差值确定已用内存(long usedMemory)。
对于一个安卓程序来说,可以通过如下的代码指令获得上述的数据:
long maxMemory=java.lang.Runtime.getRuntime().maxMemory();
long totalMemory=java.lang.Runtime.getRuntime().totalMemory();
long freeMemory=java.lang.Runtime.getRuntime().freeMemory();
long usedMemory=totalMemory–freeMemory;
当采用单条内存信息确定时,可以是当已经申请的堆内存在进程最大可用堆内存占比超过第一阈值(通常设置为80%)时,确定堆内存信息异常。或者,可以是当已用内存在进程最大可用堆内存中占比超过第一阈值(通常设置为80%)时,确定堆内存信息异常。
当采用多条内存信息确定时,可以是在相邻两条日志信息中,后一条日志信息中的已经申请的堆内存与前一条日志信息中的已经申请的堆内存相比,超过第二阈值(一般设定为进程最大可用堆内存的20%)时,确定堆内存信息异常。或者,可以是当在相邻两条日志信息中,后一条日志信息中的已用内存与前一条日志信息中的已用内存相比,超过第二阈值(一般设定为进程最大可用堆内存的20%)时,确定堆内存信息异常。
具体的,当堆内存信息为异常时,确定所述应用程序发生崩溃前存在的内存异常为java内存泄露;当所述堆内存信息为正常时,判断所述常驻内存信息是否异常。
S305、确定所述应用程序发生崩溃前存在的内存异常为java内存泄露。
S306、判断所述常驻内存信息是否异常。当所述常驻内存信息为异常时,执行步骤S307;当所述常驻内存信息为正常时,执行步骤S308。
其中,判断常驻内存信息是否异常可以通过多条内存信息来确定:
进行数据采集,具体包括采集常驻内存信息。该常驻内存信息可以通过PS命令获取RSS字段的方式来获得。
可以是在相邻两条日志信息中,后一条日志信息中的常驻内存信息与前一条日志信息中的常驻内存信息相比,超过第三阈值(一般设定为100M)时,确定常驻内存信息异常。应当知道的是,第三阈值是根据不同业务的设定指,在不同应用程序中,可以对第三阈值进行重新设定。
具体的,当常驻内存信息为异常时,确定应用程序发生崩溃前存在的内存异常为native内存泄露;当常驻内存信息为正常时,判断所述虚拟内存信息是否异常。
S307、确定所述应用程序发生崩溃前存在的内存异常为native内存泄露。
S308、判断所述虚拟内存信息是否异常。当所述虚拟内存信息为异常时,执行步骤S309;当所述常驻内存信息为正常时,执行步骤S310。
其中,判断虚拟内存信息是否异常可以通过单条内存信息或多条内存信息来确定:
进行数据采集,具体包括采集虚拟内存信息,尤其是虚拟地址空间。该虚拟内存信息可以通过PS命令获取VSZ字段的方式来获得。
当采用单条内存信息确定时,可以是当虚拟内存信息超过第四阈值(通常设置为接近4G的数值)时,确定堆内存信息异常。
当采用多条内存信息确定时,可以是在相邻两条日志信息中,后一条日志信息中的虚拟内存信息与前一条日志信息中的虚拟内存信息相比,超过第五阈值(一般设定为200M)时,确定虚拟内存信息异常。应当知道的是,第五阈值是根据不同业务的设定指,在不同应用程序中,可以对第五阈值进行重新设定。
具体的,当虚拟内存信息为异常时,确定应用程序发生崩溃前存在的内存异常为虚拟内存地址空间耗尽;当虚拟内存信息为正常时,确定内存无异常。
S309、确定所述应用程序发生崩溃前存在的内存异常为虚拟内存地址空间耗尽。
S310、确定内存无异常。
S311、确定所述应用程序在跳转所述页面申请内存时,因所述内存异常引发崩溃。
本发明实施例通过接收应用程序上传的日志信息;根据两种或两种以上的内存信息,识别应用程序发生崩溃前存在内存异常;确定应用程序在跳转页面申请内存时,因内存异常引发崩溃,从而实现了采集每个可能发生系统崩溃的内存异常时的较为全面的信息,通过该方法可以较为全面的信息可以判定出导致系统崩溃的内存异常。在此基础上,根据内存异常与内存信息的包含关系,确定了判断内存异常的顺序,在提高内存异常判断的准确性的同时,还节约了判断内存异常所需的数据量和时间。进一步的,以内存信息包括:堆内存信息、常驻内存信息和虚拟内存信息为例,描述了内存信息之间的顺序与判断java内存泄露、native内存泄露与虚拟内存地址空间耗尽之间的关系。
实施例四
图4为本发明实施例四提供的一种确定内存异常的方法的流程图。本实施例适用于记录应用程序运行时的、两种或两种以上的内存信息,当应用程序发生崩溃时,将所述页面与所述两种或两种以上的内存信息写入日志信息,将所述日志信息发送至服务器的场景。该方法可以由一种确定内存异常的装置来执行,该装置可以由软件和/或硬件的方式实现。可配置在计算机设备中,例如,服务器、工作站、个人电脑,等等。该方法具体包括如下步骤:
S401、记录应用程序运行时的、两种或两种以上的内存信息。
应用程序在运行时,会不断的申请内存,可以通过观察应用程序的内存信息来确定应用程序的状态。内存信息根据获取和表现内容的不同,包括:堆内存信息、常驻内存信息和虚拟内存信息。
其中,堆内存信息与java内存泄露存在关联关系,常驻内存信息与native内存泄露存在关联关系,虚拟内存信息与虚拟内存地址空间耗尽存在关联关系。
S402、若检测到所述应用程序发生崩溃,则记录所述应用程序发生崩溃时跳转的页面。
接收用户作用于应用程序的操作,根据该操作跳转至一页面。在应用程序跳转到页面时需要申请内存,当应用程序申请内存导致内存溢出时,确定应用程序在跳转页面前存在内存异常,由于该内存异常引发了系统崩溃。
S403、将所述页面与所述两种或两种以上的内存信息写入日志信息。
在计算机中,日志信息是记录在操作系统或其他软件运行中发生的事件或在通信软件的不同用户之间的消息的文件。日志信息记录了在系统的执行中发生的事件,以便提供可用于理解系统的活动和诊断问题的跟踪。日志信息对理解复杂系统的活动至关重要,特别是在用户交互较少的应用程序中。日志信息还可以用于组合来自多个源的日志信息的条目。这种方法与统计分析相结合,可以产生不同服务器上看起来不相关的事件之间的相关性。
当然,可以根据使用者的需要对日志信息采集的内容进行定义。如在本方案中,日志信息包括应用程序发生崩溃时的页面,可以是采集该页面的统一资源定位系统(uniformresource locator,URL)或者页面编号等。在该应用程序发生崩溃前,该日志信息还包括两种或两种以上的内存信息。
S404、将所述日志信息发送至服务器。
服务器用于根据所述两种或两种以上的内存信息,识别所述应用程序发生崩溃前存在内存异常;确定应用程序在跳转所述页面时申请内存,因内存异常引发崩溃。
在上述实施例的基础上,两种或两种以上的内存信息之间存在约束关系。每个内存信息用于识别一种内存异常。约束关系用于约束在出现某一内存信息的异常时,是否出现其他内存信息的异常。约束关系还用于确定两种或两种以上的内存信息的顺序。按照顺序可以依次根据内存信息识别应用程序发生崩溃前存在内存异常。
在上述实施例的基础上,内存信息包括:堆内存信息、常驻内存信息和虚拟内存信息,堆内存信息用于识别java内存泄露、常驻内存信息用于识别native内存泄露、虚拟内存信息用于识别虚拟内存地址空间耗尽。堆内存信息与常驻内存信息、虚拟内存信息约束关系为:出现堆内存信息异常时,出现常驻内存信息异常与虚拟内存信息异常;出现常驻内存信息异常时,出现虚拟内存信息异常。
在上述实施例的基础上,按照顺序依次根据内存信息识别应用程序发生崩溃前存在内存异常,包括:
判断堆内存信息是否异常;
当堆内存信息为异常时,确定应用程序发生崩溃前存在的内存异常为java内存泄露;
当堆内存信息为正常时,判断常驻内存信息是否异常;
当常驻内存信息为异常时,确定应用程序发生崩溃前存在的内存异常为native内存泄露;
当常驻内存信息为正常时,判断虚拟内存信息是否异常;
当虚拟内存信息为异常时,确定应用程序发生崩溃前存在的内存异常为虚拟内存地址空间耗尽。
在上述实施例的基础上,堆内存信息包括进程最大可用堆内存、已经申请的堆内存、已用内存和剩余堆内存;
判断堆内存信息是否异常,包括:
判断堆内存信息是否满足第一条件;
若是,则确定堆内存信息异常;
若否,则确定堆内存信息正常;
其中,第一条件包括如下至少一种:
已经申请的堆内存在进程最大可用堆内存中占比超过第一阈值;
已用内存在进程最大可用堆内存中占比超过第一阈值;
或者,
判断堆内存信息是否满足第二条件;
若是,则确定堆内存信息异常;
若否,则确定堆内存信息正常;
其中,第二条件包括如下至少一种:
在相邻两条日志信息中,后一条日志信息中的已经申请的堆内存与前一条日志信息中的已经申请的堆内存相比,超过第二阈值;
在相邻两条日志信息中,后一条日志信息中的已用内存与前一条日志信息中的已用内存相比,超过第二阈值。
在上述实施例的基础上,判断常驻内存信息是否异常,包括:
判断相邻两条日志信息中,后一条日志信息中的常驻内存信息与前一条日志信息中的常驻内存信息相比,是否超过第三阈值;
若是,则确定常驻内存信息异常;
若否,则确定常驻内存信息正常。
在上述实施例的基础上,判断虚拟内存信息是否异常,包括:
判断虚拟内存信息是否超过第四阈值;
若是,则确定虚拟内存信息异常;
若否,则确定虚拟内存信息正常;
或者,
判断相邻两条日志信息中,后一条日志信息中的虚拟内存信息与前一条日志信息中的虚拟内存信息相比,是否超过第五阈值;
若是,则确定虚拟内存信息异常;
若否,则确定虚拟内存信息正常。
在上述实施例的基础上,内存信息包括:常驻内存信息和虚拟内存信息;
内存信息在满足如下条件时记录:
分别采集虚拟内存信息中第一内存数值的大小与常驻内存信息中第二内存数值的大小;
计算相邻两个内存信息中的第一内存数值、第二内存数值之间的差异值;
基于差异值记录应用程序的、两种或两种以上的内存信息。
在上述实施例的基础上,还包括:
确定一个或一个以上的内存异常对应的时间;
确定排序在前的时间对应的内存异常引发崩溃。
本发明实施例通过记录应用程序运行时的、两种或两种以上的内存信息;若检测到应用程序发生崩溃,则记录应用程序发生崩溃时跳转的页面;将页面与两种或两种以上的内存信息写入日志信息;将日志信息发送至服务器,服务器用于根据两种或两种以上的内存信息,识别应用程序发生崩溃前存在内存异常;确定应用程序在跳转页面时申请内存,因内存异常引发崩溃。以实现在客户端采集每个可能发生系统崩溃的内存异常时的较为全面的信息,并将该信息上传到服务器,通过该方法可以较为全面的信息可以判定出导致系统崩溃的内存异常。
实施例五
图5为本发明实施例五提供的一种确定内存异常的装置的结构图。该装置具体可以包括如下模块:日志信息接收模块51、内存异常识别模块52和页面跳转关联模块53。其中:
日志信息接收模块51,用于接收应用程序上传的日志信息,所述日志信息包括所述应用程序发生崩溃时的页面,以及,所述应用程序发生崩溃前的、两种或两种以上的内存信息;
内存异常识别模块52,用于根据所述两种或两种以上的内存信息,识别所述应用程序发生崩溃前存在内存异常;
页面跳转关联模块53,用于确定所述应用程序在跳转所述页面申请内存时,因所述内存异常引发崩溃。
本发明实施例通过接收应用程序上传的日志信息;根据两种或两种以上的内存信息,识别应用程序发生崩溃前存在内存异常;确定应用程序在跳转页面申请内存时,因内存异常引发崩溃,从而实现了采集每个可能发生系统崩溃的内存异常时的较为全面的信息,通过该方法可以较为全面的信息可以判定出导致系统崩溃的内存异常。
在上述实施例的基础上,内存异常识别模块52包括:
约束关系确定子模块,用于确定所述两种或两种以上的内存信息之间的约束关系,每个所述内存信息用于识别一种内存异常,所述约束关系用于约束在出现某一内存信息的异常时,是否出现其他内存信息的异常;
信息顺序确定子模块,用于按照所述约束关系确定所述两种或两种以上的内存信息的顺序;
顺序识别子模块,用于按照所述顺序依次根据所述内存信息识别所述应用程序发生崩溃前存在内存异常。
在上述实施例的基础上,所述内存信息包括:堆内存信息、常驻内存信息和虚拟内存信息,所述堆内存信息用于识别java内存泄露、所述常驻内存信息用于识别native内存泄露、所述虚拟内存信息用于识别虚拟内存地址空间耗尽。约束关系确定子模块包括:
第一约束关系确定单元,用于确定出现堆内存信息异常时,出现常驻内存信息异常与虚拟内存信息异常;
第二约束关系确定单元,用于确定出现常驻内存信息异常时,出现虚拟内存信息异常。
在上述实施例的基础上,顺序识别子模块包括:
第一判断单元,用于判断所述堆内存信息是否异常;
第一结果执行单元,用于当所述堆内存信息为异常时,确定所述应用程序发生崩溃前存在的内存异常为java内存泄露;
第二判断单元,用于当所述堆内存信息为正常时,判断所述常驻内存信息是否异常;
第二结果执行单元,用于当所述常驻内存信息为异常时,确定所述应用程序发生崩溃前存在的内存异常为native内存泄露;
第三判断单元,用于当所述常驻内存信息为正常时,判断所述虚拟内存信息是否异常;
第三结果执行单元,用于当所述虚拟内存信息为异常时,确定所述应用程序发生崩溃前存在的内存异常为虚拟内存地址空间耗尽。
在上述实施例的基础上,第一判断单元包括:
第一判断子单元,用于判断所述堆内存信息是否满足第一条件;
若是,则确定所述堆内存信息异常;
若否,则确定所述堆内存信息正常;
其中,所述第一条件包括如下至少一种:
所述已经申请的堆内存在所述进程最大可用堆内存中占比超过第一阈值;
所述已用内存在所述进程最大可用堆内存中占比超过第一阈值。
在上述实施例的基础上,第一判断单元包括:
第二判断子单元,用于判断所述堆内存信息是否满足第二条件;
若是,则确定所述堆内存信息异常;
若否,则确定所述堆内存信息正常;
其中,所述第二条件包括如下至少一种:
在相邻两条日志信息中,后一条日志信息中的已经申请的堆内存与前一条日志信息中的已经申请的堆内存相比,超过第二阈值;
在相邻两条日志信息中,后一条日志信息中的已用内存与前一条日志信息中的已用内存相比,超过第二阈值。
在上述实施例的基础上,第二判断单元包括:
第三判断子单元,用于判断相邻两条日志信息中,后一条日志信息中的常驻内存信息与前一条日志信息中的常驻内存信息相比,是否超过第三阈值;
若是,则确定所述常驻内存信息异常;
若否,则确定所述常驻内存信息正常。
在上述实施例的基础上,第三判断单元包括:
第四判断子单元,用于判断所述虚拟内存信息是否超过第四阈值;
若是,则确定所述虚拟内存信息异常;
若否,则确定所述虚拟内存信息正常;
在上述实施例的基础上,第三判断单元包括:
第五判断子单元,用于判断相邻两条日志信息中,后一条日志信息中的虚拟内存信息与前一条日志信息中的虚拟内存信息相比,是否超过第五阈值;
若是,则确定所述虚拟内存信息异常;
若否,则确定所述虚拟内存信息正常。
在上述实施例的基础上,所述内存信息包括:常驻内存信息和虚拟内存信息,还包括内存信息记录模块,用于:
分别采集所述虚拟内存信息中第一内存数值的大小与所述常驻内存信息中第二内存数值的大小;
计算相邻两个内存信息中的所述第一内存数值、第二内存数值之间的差异值;
基于所述差异值记录所述应用程序的、两种或两种以上的内存信息。
在上述实施例的基础上,还包括:
时间确定模块,用于确定一个或一个以上的内存异常对应的时间;
时间排序模块,用于确定排序在前的所述时间对应的所述内存异常引发崩溃。
本发明实施例所提供的确定内存异常的装置可执行本发明实施例一至三,所提供的确定内存异常的方法,具备执行方法相应的功能模块和有益效果。
实施例六
图6为本发明实施例六提供的一种确定内存异常的装置的结构图。该装置具体可以包括如下模块:内存信息接收模块61、程序崩溃检测模块62、日志信息写入模块63和日志信息发送模块64。其中:
内存信息接收模块61,用于记录应用程序运行时的、两种或两种以上的内存信息;
程序崩溃检测模块62,用于若检测到所述应用程序发生崩溃,则记录所述应用程序发生崩溃时跳转的页面;
日志信息写入模块63,用于将所述页面与所述两种或两种以上的内存信息写入日志信息;
日志信息发送模块64,用于将所述日志信息发送至服务器,所述服务器用于根据所述两种或两种以上的内存信息,识别所述应用程序发生崩溃前存在内存异常;确定所述应用程序在跳转所述页面时申请内存,因所述内存异常引发崩溃。
本发明实施例通过记录应用程序运行时的、两种或两种以上的内存信息;若检测到应用程序发生崩溃,则记录应用程序发生崩溃时跳转的页面;将页面与两种或两种以上的内存信息写入日志信息;将日志信息发送至服务器,服务器用于根据两种或两种以上的内存信息,识别应用程序发生崩溃前存在内存异常;确定应用程序在跳转页面时申请内存,因内存异常引发崩溃。以实现在客户端采集每个可能发生系统崩溃的内存异常时的较为全面的信息,并将该信息上传到服务器,通过该方法可以较为全面的信息可以判定出导致系统崩溃的内存异常。
本发明实施例所提供的确定内存异常的装置可执行本发明实施例四,所提供的确定内存异常的方法,具备执行方法相应的功能模块和有益效果。
实施例七
图7为本发明实施例七提供的一种电子设备的结构示意图。如图7所示,该电子设备包括处理器70、存储器71、通信模块72、输入装置73和输出装置74;电子设备中处理器70的数量可以是一个或多个,图7中以一个处理器70为例;电子设备中的处理器70、存储器71、通信模块72、输入装置73和输出装置74可以通过总线或其他方式连接,图7中以通过总线连接为例。
存储器71作为一种计算机可读存储介质,可用于存储软件程序、计算机可执行程序以及模块。如本实施例中的一种确定内存异常的方法对应的模块(例如,一种确定内存异常的装置中的日志信息接收模块51、内存异常识别模块52和页面跳转关联模块53)。又如本实施例中的一种确定内存异常的方法对应的模块(例如,一种确定内存异常的装置中的内存信息接收模块61、程序崩溃检测模块62、日志信息写入模块63和日志信息发送模块64)。
处理器70通过运行存储在存储器71中的软件程序、指令以及模块,从而执行电子设备的各种功能应用以及数据处理,即实现上述的一种确定内存异常的方法。
存储器71可主要包括存储程序区和存储数据区,其中,存储程序区可存储操作系统、至少一个功能所需的应用程序;存储数据区可存储根据电子设备的使用所创建的数据等。此外,存储器71可以包括高速随机存取存储器,还可以包括非易失性存储器,例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实例中,存储器71可进一步包括相对于处理器70远程设置的存储器,这些远程存储器可以通过网络连接至电子设备。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
通信模块72,用于与显示屏建立连接,并实现与显示屏的数据交互。输入装置73可用于接收输入的数字或字符信息,以及产生与电子设备的用户设置以及功能控制有关的键信号输入。输出装置74还可包括音箱等电子设备,也可包括其他可用于输出的装置。
本实施例提供的一种电子设备,可执行本发明任一实施例提供的确定内存异常的方法,具体相应的功能和有益效果。
实施例八
本发明实施例八还提供一种包含计算机可执行指令的存储介质,所述计算机可执行指令在由计算机处理器执行时用于执行一种确定内存异常的方法,该方法包括:
接收应用程序上传的日志信息,所述日志信息包括所述应用程序发生崩溃时的页面,以及,所述应用程序发生崩溃前的、两种或两种以上的内存信息;
根据所述两种或两种以上的内存信息,识别所述应用程序发生崩溃前存在内存异常;
确定所述应用程序在跳转所述页面申请内存时,因所述内存异常引发崩溃。
或者,
记录应用程序运行时的、两种或两种以上的内存信息;
若检测到所述应用程序发生崩溃,则记录所述应用程序发生崩溃时跳转的页面;
将所述页面与所述两种或两种以上的内存信息写入日志信息;
将所述日志信息发送至服务器,所述服务器用于根据所述两种或两种以上的内存信息,识别所述应用程序发生崩溃前存在内存异常;确定所述应用程序在跳转所述页面时申请内存,因所述内存异常引发崩溃。
当然,本发明实施例所提供的一种包含计算机可执行指令的存储介质,其计算机可执行指令不限于如上所述的方法操作,还可以执行本发明任一实施例所提供的确定内存异常的方法中的相关操作。
通过以上关于实施方式的描述,所属领域的技术人员可以清楚地了解到,本发明可借助软件及必需的通用硬件来实现,当然也可以通过硬件实现,但很多情况下前者是更佳的实施方式。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品可以存储在计算机可读存储介质中,如计算机的软盘、只读存储器(Read-Only Memory,ROM)、随机存取存储器(RandomAccess Memory,RAM)、闪存(FLASH)、硬盘或光盘等,包括若干指令用以使得一台计算机电子设备(可以是个人计算机,服务器,或者网络电子设备等)执行本发明各个实施例所述的方法。
值得注意的是,上述确定内存异常的装置的实施例中,所包括的各个单元和模块只是按照功能逻辑进行划分的,但并不局限于上述的划分,只要能够实现相应的功能即可;另外,各功能单元的具体名称也只是为了便于相互区分,并不用于限制本发明的保护范围。
注意,上述仅为本发明的较佳实施例及所运用技术原理。本领域技术人员会理解,本发明不限于这里所述的特定实施例,对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本发明的保护范围。因此,虽然通过以上实施例对本发明进行了较为详细的说明,但是本发明不仅仅限于以上实施例,在不脱离本发明构思的情况下,还可以包括更多其他等效实施例,而本发明的范围由所附的权利要求范围决定。

Claims (14)

1.一种确定内存异常的方法,其特征在于,包括:
接收应用程序上传的日志信息,所述日志信息包括所述应用程序发生崩溃时的页面,以及,所述应用程序发生崩溃前的、两种或两种以上的内存信息;
根据所述两种或两种以上的内存信息,识别所述应用程序发生崩溃前存在内存异常;
确定所述应用程序在跳转所述页面申请内存时,因所述内存异常引发崩溃。
2.根据权利要求1所述的方法,其特征在于,所述根据所述两种或两种以上的内存信息,识别所述应用程序发生崩溃前存在内存异常,包括:
确定所述两种或两种以上的内存信息之间的约束关系,每个所述内存信息用于识别一种内存异常,所述约束关系用于约束在出现某一内存信息的异常时,是否出现其他内存信息的异常;
按照所述约束关系确定所述两种或两种以上的内存信息的顺序;
按照所述顺序依次根据所述内存信息识别所述应用程序发生崩溃前存在内存异常。
3.根据权利要求2所述的方法,其特征在于,所述内存信息包括:堆内存信息、常驻内存信息和虚拟内存信息,所述堆内存信息用于识别java内存泄露、所述常驻内存信息用于识别native内存泄露、所述虚拟内存信息用于识别虚拟内存地址空间耗尽;
所述确定所述两种或两种以上的内存信息之间的约束关系,包括:
确定所述堆内存信息与所述常驻内存信息、所述虚拟内存信息约束关系为:出现堆内存信息异常时,出现常驻内存信息异常与虚拟内存信息异常;出现常驻内存信息异常时,出现虚拟内存信息异常。
4.根据权利要求3所述的方法,其特征在于,所述按照所述顺序依次根据所述内存信息识别所述应用程序发生崩溃前存在内存异常,包括:
判断所述堆内存信息是否异常;
当所述堆内存信息为异常时,确定所述应用程序发生崩溃前存在的内存异常为java内存泄露;
当所述堆内存信息为正常时,判断所述常驻内存信息是否异常;
当所述常驻内存信息为异常时,确定所述应用程序发生崩溃前存在的内存异常为native内存泄露;
当所述常驻内存信息为正常时,判断所述虚拟内存信息是否异常;
当所述虚拟内存信息为异常时,确定所述应用程序发生崩溃前存在的内存异常为虚拟内存地址空间耗尽。
5.根据权利要求4所述的方法,其特征在于,所述堆内存信息包括进程最大可用堆内存、已经申请的堆内存、已用内存和剩余堆内存;
所述判断所述堆内存信息是否异常,包括:
判断所述堆内存信息是否满足第一条件;
若是,则确定所述堆内存信息异常;
若否,则确定所述堆内存信息正常;
其中,所述第一条件包括如下至少一种:
所述已经申请的堆内存在所述进程最大可用堆内存中占比超过第一阈值;
所述已用内存在所述进程最大可用堆内存中占比超过第一阈值;
或者,
判断所述堆内存信息是否满足第二条件;
若是,则确定所述堆内存信息异常;
若否,则确定所述堆内存信息正常;
其中,所述第二条件包括如下至少一种:
在相邻两条日志信息中,后一条日志信息中的已经申请的堆内存与前一条日志信息中的已经申请的堆内存相比,超过第二阈值;
在相邻两条日志信息中,后一条日志信息中的已用内存与前一条日志信息中的已用内存相比,超过第二阈值。
6.根据权利要求4所述的方法,其特征在于,所述判断所述常驻内存信息是否异常,包括:
判断相邻两条日志信息中,后一条日志信息中的常驻内存信息与前一条日志信息中的常驻内存信息相比,是否超过第三阈值;
若是,则确定所述常驻内存信息异常;
若否,则确定所述常驻内存信息正常。
7.根据权利要求4所述的方法,其特征在于,所述判断所述虚拟内存信息是否异常,包括:
判断所述虚拟内存信息是否超过第四阈值;
若是,则确定所述虚拟内存信息异常;
若否,则确定所述虚拟内存信息正常;
或者,
判断相邻两条日志信息中,后一条日志信息中的虚拟内存信息与前一条日志信息中的虚拟内存信息相比,是否超过第五阈值;
若是,则确定所述虚拟内存信息异常;
若否,则确定所述虚拟内存信息正常。
8.根据权利要求1-7任一所述的方法,其特征在于,所述内存信息包括:常驻内存信息和虚拟内存信息;
所述内存信息在满足如下条件时记录:
分别采集所述虚拟内存信息中第一内存数值的大小与所述常驻内存信息中第二内存数值的大小;
计算相邻两个内存信息中的所述第一内存数值、第二内存数值之间的差异值;
基于所述差异值记录所述应用程序的、两种或两种以上的内存信息。
9.根据权利要求1-7任一所述的方法,其特征在于,还包括:
确定一个或一个以上的内存异常对应的时间;
确定排序在前的所述时间对应的所述内存异常引发崩溃。
10.一种确定内存异常的方法,其特征在于,包括:
记录应用程序运行时的、两种或两种以上的内存信息;
若检测到所述应用程序发生崩溃,则记录所述应用程序发生崩溃时跳转的页面;
将所述页面与所述两种或两种以上的内存信息写入日志信息;
将所述日志信息发送至服务器,所述服务器用于根据所述两种或两种以上的内存信息,识别所述应用程序发生崩溃前存在内存异常;确定所述应用程序在跳转所述页面时申请内存,因所述内存异常引发崩溃。
11.一种确定内存异常的装置,其特征在于,包括:
日志信息接收模块,用于接收应用程序上传的日志信息,所述日志信息包括所述应用程序发生崩溃时的页面,以及,所述应用程序发生崩溃前的、两种或两种以上的内存信息;
内存异常识别模块,用于根据所述两种或两种以上的内存信息,识别所述应用程序发生崩溃前存在内存异常;
页面跳转关联模块,用于确定所述应用程序在跳转所述页面申请内存时,因所述内存异常引发崩溃。
12.一种确定内存异常的装置,其特征在于,包括:
内存信息接收模块,用于记录应用程序运行时的、两种或两种以上的内存信息;
程序崩溃检测模块,用于若检测到所述应用程序发生崩溃,则记录所述应用程序发生崩溃时跳转的页面;
日志信息写入模块,用于将所述页面与所述两种或两种以上的内存信息写入日志信息;
日志信息发送模块,用于将所述日志信息发送至服务器,所述服务器用于根据所述两种或两种以上的内存信息,识别所述应用程序发生崩溃前存在内存异常;确定所述应用程序在跳转所述页面时申请内存,因所述内存异常引发崩溃。
13.一种电子设备,其特征在于,包括:
一个或多个处理器;
存储器,用于存储一个或多个程序;
当所述一个或多个程序被所述一个或多个处理器执行,使得所述一个或多个处理器实现如权利要求1-10任一所述的一种确定内存异常的方法。
14.一种计算机可读存储介质,其上存储有计算机程序,其特征在于,该程序被处理器执行时实现如权利要求1-10任一所述的一种确定内存异常的方法。
CN202010084704.7A 2020-02-10 2020-02-10 一种确定内存异常的方法、装置、设备和存储介质 Active CN111274060B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010084704.7A CN111274060B (zh) 2020-02-10 2020-02-10 一种确定内存异常的方法、装置、设备和存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010084704.7A CN111274060B (zh) 2020-02-10 2020-02-10 一种确定内存异常的方法、装置、设备和存储介质

Publications (2)

Publication Number Publication Date
CN111274060A true CN111274060A (zh) 2020-06-12
CN111274060B CN111274060B (zh) 2023-07-28

Family

ID=70997017

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010084704.7A Active CN111274060B (zh) 2020-02-10 2020-02-10 一种确定内存异常的方法、装置、设备和存储介质

Country Status (1)

Country Link
CN (1) CN111274060B (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113434364A (zh) * 2021-06-25 2021-09-24 青岛海尔科技有限公司 屏端设备内存检测方法、装置、存储介质及电子装置
CN113835912A (zh) * 2020-06-24 2021-12-24 北京新氧科技有限公司 应用程序的崩溃信息处理方法及设备
CN114020652A (zh) * 2021-09-30 2022-02-08 荣耀终端有限公司 一种应用程序的管理方法及电子设备

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101339533A (zh) * 2007-07-04 2009-01-07 国际商业机器公司 基于分区的诊断Java系统的内存泄漏的方法及装置
CN104182320A (zh) * 2013-05-23 2014-12-03 联想(北京)有限公司 一种监控内存泄漏的方法及装置
CN105808412A (zh) * 2014-12-30 2016-07-27 展讯通信(天津)有限公司 一种进程资源实时监测方法
CN108255687A (zh) * 2017-12-29 2018-07-06 五八同城信息技术有限公司 终端的应用程序内存监控测试方法、装置及电子设备
CN110347560A (zh) * 2019-07-19 2019-10-18 深圳前海微众银行股份有限公司 大数据产品的异常提示方法、装置、系统、设备及介质
KR20190135337A (ko) * 2018-05-28 2019-12-06 삼성전자주식회사 메모리 오류를 검출하는 방법 및 시스템
CN110647451A (zh) * 2019-08-30 2020-01-03 深圳壹账通智能科技有限公司 应用程序异常分析方法及生成方法

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101339533A (zh) * 2007-07-04 2009-01-07 国际商业机器公司 基于分区的诊断Java系统的内存泄漏的方法及装置
CN104182320A (zh) * 2013-05-23 2014-12-03 联想(北京)有限公司 一种监控内存泄漏的方法及装置
CN105808412A (zh) * 2014-12-30 2016-07-27 展讯通信(天津)有限公司 一种进程资源实时监测方法
CN108255687A (zh) * 2017-12-29 2018-07-06 五八同城信息技术有限公司 终端的应用程序内存监控测试方法、装置及电子设备
KR20190135337A (ko) * 2018-05-28 2019-12-06 삼성전자주식회사 메모리 오류를 검출하는 방법 및 시스템
CN110347560A (zh) * 2019-07-19 2019-10-18 深圳前海微众银行股份有限公司 大数据产品的异常提示方法、装置、系统、设备及介质
CN110647451A (zh) * 2019-08-30 2020-01-03 深圳壹账通智能科技有限公司 应用程序异常分析方法及生成方法

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113835912A (zh) * 2020-06-24 2021-12-24 北京新氧科技有限公司 应用程序的崩溃信息处理方法及设备
CN113835912B (zh) * 2020-06-24 2024-02-09 北京新氧科技有限公司 应用程序的崩溃信息处理方法及设备
CN113434364A (zh) * 2021-06-25 2021-09-24 青岛海尔科技有限公司 屏端设备内存检测方法、装置、存储介质及电子装置
CN113434364B (zh) * 2021-06-25 2024-03-22 青岛海尔科技有限公司 屏端设备内存检测方法、装置、存储介质及电子装置
CN114020652A (zh) * 2021-09-30 2022-02-08 荣耀终端有限公司 一种应用程序的管理方法及电子设备
CN114020652B (zh) * 2021-09-30 2022-12-30 荣耀终端有限公司 一种应用程序的管理方法及电子设备

Also Published As

Publication number Publication date
CN111274060B (zh) 2023-07-28

Similar Documents

Publication Publication Date Title
US6643802B1 (en) Coordinated multinode dump collection in response to a fault
US8839271B2 (en) Call stack sampling to obtain information for analyzing idle states in a data processing system
JP5719930B2 (ja) システムテスト装置
CN112084024B (zh) 一种内存监控方法、装置、介质和电子设备
US8769504B2 (en) Method and apparatus for dynamically instrumenting a program
CN102831068B (zh) 一种内存操作记录的处理方法及装置
US6523141B1 (en) Method and apparatus for post-mortem kernel memory leak detection
CN103109276B (zh) 系统测试方法
US7870358B2 (en) Zero-penalty RAID controller memory leak detection and isolation method and system utilizing sequence numbers
CN111966603B (zh) 内存泄露的检测方法及装置、可读存储介质及电子设备
CN111274060B (zh) 一种确定内存异常的方法、装置、设备和存储介质
US7474991B2 (en) Method and apparatus for analyzing idle states in a data processing system
CN112306833A (zh) 应用程序的崩溃统计方法、装置、计算机设备及存储介质
CN111813666A (zh) 一种内存泄露定位的方法、装置、介质和电子设备
US20070089094A1 (en) Temporal sample-based profiling
CN116414722B (zh) 模糊测试处理方法、装置、模糊测试系统及存储介质
CN117785440A (zh) 异常进程处理方法和相关装置、设备、存储介质
EP2645249A1 (en) Information processing apparatus, and method of controlling information processing apparatus
CN113687942B (zh) 检测方法、装置及电子设备
CN118051427A (zh) 内存安全检测方法及电子设备
US20060150023A1 (en) Debugging apparatus
CN104572482B (zh) 一种过程变量的存储方法及装置
CN112631941A (zh) 定位linux内核slub内存泄漏的方法和系统
US10140476B2 (en) Tracing processing activity
CN117149644A (zh) 内存溢出检测方法、装置、操作系统、设备及存储介质

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
GR01 Patent grant