CN108073439A - 一种jvm内存泄露自动检测方法以及系统 - Google Patents

一种jvm内存泄露自动检测方法以及系统 Download PDF

Info

Publication number
CN108073439A
CN108073439A CN201611018556.9A CN201611018556A CN108073439A CN 108073439 A CN108073439 A CN 108073439A CN 201611018556 A CN201611018556 A CN 201611018556A CN 108073439 A CN108073439 A CN 108073439A
Authority
CN
China
Prior art keywords
memory
usage amount
monitor
jvm
areas
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.)
Pending
Application number
CN201611018556.9A
Other languages
English (en)
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.)
SHENZHEN YETUOXUN COMMUNICATION TECHNOLOGY Co Ltd
Original Assignee
SHENZHEN YETUOXUN COMMUNICATION 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 SHENZHEN YETUOXUN COMMUNICATION TECHNOLOGY Co Ltd filed Critical SHENZHEN YETUOXUN COMMUNICATION TECHNOLOGY Co Ltd
Priority to CN201611018556.9A priority Critical patent/CN108073439A/zh
Publication of CN108073439A publication Critical patent/CN108073439A/zh
Pending legal-status Critical Current

Links

Classifications

    • 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/45504—Abstract machines for programme code execution, e.g. Java virtual machine [JVM], interpreters, emulators
    • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

一种JVM内存泄露自动检测方法以及系统，方法包括：S1、基于获取的内存池管理对象设置内存的回收使用量阈值，基于获取的内存系统管理对象注册监听器；S2、若JVM进行完垃圾回收后内存超过回收使用量阈值，则内存系统管理对象将当前内存信息通知给监听器；S3、监听器基于最大内存使用量上升次数和上一次内存使用量，对当前内存信息进行分析以判断是否存在内存泄露。本发明能够自动的获取到JVM内存使用信息，而且能够更加及时的在GC完成之后获取JVM的内存使用信息，得到准确的内存信息，不用进行外部连接或者指令调用，不影响程序正常运行；进一步地，在判定存在内存泄露时触发告警，从而提前通知系统维护人员系统可能存在内存问题，利于问题的尽早定位。

Description

一种JVM内存泄露自动检测方法以及系统
技术领域
本发明涉及计算机领域，尤其涉及一种JVM内存泄露自动检测方法以及系统。
背景技术
JVM(Java Virtual Machine，Java虚拟机)作为Java程序的执行环境，它有自己的一套内存管理机制，能够完成分配、回收内存。对于Java程序员来说，不需要过多的关心对象是如何在内存中保存和使用的，因为有垃圾收集(Garbage Collection，简称GC)机制的存在，保证了Java程序能够正常的运行。不过，即使经过测试的程序，也可能因为代码编写或者对象使用不当，导致JVM内存泄露或者内存溢出。还有可能因为JVM的内存配置不合理，无法满足程序运行的需要(例如大量并发的请求)导致内存不足，这种情况虽然不属于内存泄露，但是出现的问题是相同的，最后都会导致内存溢出。
实际的生产环境当中，都会给JVM分配较大的内存，同时也会对GC进行一定的配置优化，从而使得出现内存问题的时间被拉长和延后，通常需要一段时间(一到几个小时甚至几天、几个星期)才能发现明显的内存问题，对于这种不可预期的内存问题，如果不能够及时准确的判断出JVM是否出现内存泄露不能帮助维护人员尽早仅进行问题的定位，则会严重影响系统的正常运行。
现有监控JVM内存的途径主要有：使用JConsole监视和管理控制台，通过远程接口进行可视化的监视，或者通过jmap、jstat等JAVA自带的指令查询当前的JVM内存状况，根据多次内存的变化情况，判断是否出现了内存泄露。现有技术方案的主要缺点是：
1)、需要人工去操作，并且需要人工进行不间断的监控，观察JVM GC后的结果，自动化程度低。
2)、所获取到的JVM内存信息，都不是刚进行完GC(垃圾收集)后的JVM内存状况，对于内存的变化，可能存在误判的情况。
3)、需要建立连接或通过指令调用正在运行的JVM，不够安全便捷，同时对于一些实时性要求高、请求并发量大的系统，实时进行对象数量的统计，会严重影响系统的正常运行。
发明内容
本发明要解决的技术问题在于，针对现有技术的上述缺陷，提供一种JVM内存泄露自动检测方法以及系统。
本发明解决其技术问题所采用的技术方案是：构造一种JVM内存泄露自动检测方法，包括以下步骤：
S1、基于获取的内存池管理对象设置内存的回收使用量阈值，基于获取的内存系统管理对象注册监听器以监听内存使用量变化；
S2、若JVM进行完垃圾回收后内存超过设置的所述回收使用量阈值，则内存系统管理对象将当前内存信息通知给注册的监听器；
S3、监听器基于最大内存使用量上升次数和上一次内存使用量，对当前内存信息进行分析以判断是否存在内存泄露。
在本发明所述的JVM内存泄露自动检测方法中，所述步骤S3中，监听器在被通知触发时，如果计算得到当前内存信息超过上一次内存使用量的连续次数达到最大内存使用量上升次数，则判定存在内存泄露。
在本发明所述的JVM内存泄露自动检测方法中，所述步骤S3具体包括：
S31、监听器每一次在被通知触发时启动步骤S32；
S32、判断当前内存使用量的数值是否大于上一次内存使用量的数值，如果是，则进入步骤S33；否则，将上一次内存使用量的数值更新为当前内存使用量的数值，并将计数器清零后结束；
S33、将上一次内存使用量的数值更新为当前内存使用量的数值，并将计数器计数加一，判断计数器的数值是否到达所述最大内存使用量上升次数，如果是，则判定存在内存泄露并触发告警；否则，结束。
在本发明所述的JVM内存泄露自动检测方法中，所述步骤S1中所述的设置内存的回收使用量阈值包括：
S11、获取内存池管理对象列表；
S12、遍历内存池管理对象列表，根据内存池管理对象的名称获取Old区和Perm区的内存池管理对象；
S13、调用Old区和Perm区的内存池管理对象的阈值设置接口，设定Old区和Perm区的所述回收使用量阈值。
在本发明所述的JVM内存泄露自动检测方法中，所述步骤S1中所述的注册监听器包括：获取内存系统管理对象，并基于系统管理对象的相关接口注册监听器以监听内存使用量变化。
本发明还公开了一种JVM内存泄露自动检测系统，包阈值设置装置，用于基于获取的内存池管理对象设置内存的回收使用量阈值；
监听器注册装置，用于基于获取的内存系统管理对象注册监听器以监听内存使用量变化的装置，若JVM进行完垃圾回收后内存超过设置的所述回收使用量阈值，则内存系统管理对象将当前内存信息通知给注册的监听器；
监听器，基于最大内存使用量上升次数和上一次内存使用量，对当前内存信息进行分析以判断是否存在内存泄露。
在本发明所述的JVM内存泄露自动检测系统中，监听器在被通知触发时，如果计算得到当前内存信息超过上一次内存使用量的连续次数达到最大内存使用量上升次数，则判定存在内存泄露。
在本发明所述的JVM内存泄露自动检测系统中，所述监听器包括内存信息分析装置，用于在监听器每一次被通知触发时判断当前内存使用量的数值是否大于上一次内存使用量的数值，如果是，则将上一次内存使用量的数值更新为当前内存使用量的数值，并将计数器计数加一，且在计数器的数值到达所述最大内存使用量上升次数时判定存在内存泄露并触发告警；否则，将上一次内存使用量的数值更新为当前内存使用量的数值，并将计数器清零。
在本发明所述的JVM内存泄露自动检测系统中，所述监听器包括检漏判定装置，用于获取内存池管理对象列表，遍历内存池管理对象列表，根据内存池管理对象的名称获取Old区和Perm区的内存池管理对象，调用Old区和Perm区的内存池管理对象的阈值设置接口，设定Old区和Perm区的所述回收使用量阈值。
在本发明所述的JVM内存泄露自动检测系统中，，所述监听器注册装置包括：用于获取内存系统管理对象的装置，以及基于系统管理对象的相关接口注册监听器以监听内存使用量变化的装置。
实施本发明的JVM内存泄露自动检测方法以及系统，具有以下有益效果：本发明通过向JVM注册监听器，通过接收通知的方式来获取JVM的内存信息，然后对于内存信息进行分析以判断是否存在内存泄露，整个过程不需要人工操作，能够自动的获取到JVM内存使用信息，减少工作量；而且能够更加及时的在GC完成之后获取JVM的内存使用信息，得到准确的内存信息；由于监听器集成在Java应用程序的内部，不用进行外部连接或者指令调用，使用简单方便，不影响程序或应用的正常运行，避免自身引出新的问题；进一步地，本发明还在判定存在内存泄露时并触发告警，从而提前通知系统维护人员系统可能存在内存问题，利于问题的尽早定位。
附图说明
下面将结合附图及实施例对本发明作进一步说明，附图中：
图1是JVM的内存分区示意图；
图2是本发明JVM内存泄露自动检测方法的流程图；
图3是图2中的步骤S3的流程图。
具体实施方式
为了对本发明的技术特征、目的和效果有更加清楚的理解，现对照附图详细说明本发明的具体实施方式。
在阐述本发明之前，首先简单介绍一下JVM的内存管理模式和GC((垃圾收集))，参考图1，JVM的内存(堆)被分为三个部分：
新生代(Young Generation)，存储区域包括Eden区和Survivor区，其中，Survivor区分为有对象的Survivor区(记为S0区)和空的Survivor区(记为S1区)；
老年代(Old Generation)，该存储区域简称Old区
持久代(Permanent Generation)，该存储区域简称Perm区，包含class信息、常量池、静态字段、方法等。
绝大部分新生成的对象都放在Eden区，当Eden区占用满时，JVM会因申请不到内存，而触发Young GC,进行Eden区和S0区的垃圾回收，把存活的对象用复制算法拷贝到一个空的S1区中，此时Eden区、Survivor S0被清空。下次触发Young GC回收Eden区和S0区，将存活对象拷贝到S1区中。
若发现Survivor区满了，则将这些对象拷贝到Old区；或者Survivor没满但某些对象足够Old(每次Young GC都会使Survivor区存活对象值+1，直到阈值则判断对象足够Old),也拷贝到Old区。Old区也会进行垃圾收集(Major GC),发生一次Major GC至少伴随一次Young GC。
当JVM在Old区或者Perm区申请不到内存时，会触发Full GC。如果Java程序存在内存泄露的情况，一般都会导致Old区或者Perm区持续增长(这里指的进行完GC之后净增长)，直至JVM内存溢出。本发明就针对Old区或者Perm区的增长进行检查。
基于上面描述的JVM内存管理模式，当进行完GC之后，没有被引用的对象都将被清理，因此，只有当GC完成之后这一时间点的JVM内存占用数值，才是最准确的内存占用数值。所以本发明需要获取GC之后的内存占用数值用于内存泄露的判断。
参考图2是本发明JVM内存泄露自动检测方法的较佳实施例的程序流程图。
本发明中的JVM内存泄露自动检测方法包括以下步骤：
S1、基于获取的内存池管理对象设置内存的回收使用量阈值，基于获取的内存系统管理对象注册监听器以监听内存使用量变化；
S2、若JVM进行完垃圾回收后内存超过设置的所述回收使用量阈值，则内存系统管理对象将当前内存信息通知给注册的监听器；
S3、监听器基于最大内存使用量上升次数和上一次内存使用量，对当前内存信息进行分析以判断是否存在内存泄露。
下面就各个步骤进行详细说明。
步骤S1：
JAVA提供了Java Management Extensions(JMXTM)API，其是一个用于管理和监视的标准API管理接口，典型用途包括：查询并更改应用程序配置、累积有关应用程序行为的统计并使其可用、通知状态更改及错误状况。其中就包含有关JVM内存管理方面的API，基于此，其系统的内存使用量可以通过轮询或阈值通知机制进行监视。本发明正是根据其阈值通知机制进行监视的原理获取内存检测的准确时机以及内存信息。
基于阈值通知机制，为了让JVM在内存回收后达到一定的回收使用量阈值后才通知程序，需要对相关的内存池管理对象设定回收使用量阈值，具体包括：
S11、获取内存池管理对象列表；
根据JDK1.6API定义，调用ManagementFactory.getMemoryPoolMXBeans()方法，可以获取内存池管理对象列表List<MemoryPoolMXBean>，列表当中存在很多内存池管理对象，但是本发明只需要关注Old区和Perm区的内存池管理对象，所以需要对于列表进行过滤，获取Old区和Perm区的内存池管理对象，此通过下述步骤S12实现。
S12、遍历内存池管理对象列表，根据内存池管理对象的名称获取Old区和Perm区的内存池管理对象；
因为在不同的操作系统中以及不同版本的JVM中，内存池的名称有区别，根据实际测试，内存池的名称有以下几种：
Old区："CMS Old Gen","PS Old Gen","Tenured Gen"
Perm区："CMS Perm Gen","PS Perm Gen","Perm Gen"
所有为了从列表中过滤得到Old区和Perm区的内存池管理对象，可以根据内存池管理对象(MemoryPoolMXBean)的名称判断是否是Old区或者是Perm区的内存池管理对象。其中，内存池的名称可通过调用MemoryPoolMXBean对象的getName()方法获取。
S13、调用Old区和Perm区的内存池管理对象的阈值设置接口，设定Old区和Perm区的所述回收使用量阈值。
获取到对应的内存池管理对象后，分别调用内存池管理对象阈值设置接口MemoryPoolMXBean.setCollectionUsageThreshold(long threhsold)设定Old区和Perm区的回收使用量阈值。
回收使用量阈值是通过增加百分比配置的方式来计算，内存池的最大容量通过MemoryPoolMXBean.getUsage().getMax()获取，然后乘以百分比得到回收使用量阈值，建议Old区的阈值大于70％，因为CMS垃圾回收策略的JVM参数CMSInitiatingOccupancyFraction默认为68，即Old区占用达到68％时就会触发CMS GC。当然如果有修改CMSInitiatingOccupancyFraction配置的值，则回收使用量阈值的百分比也应当随之修改。
为了接收内存状态的通知，需要向JVM的相关接口注册监听器来接收相关通知，注册监听器包括：
S14、获取内存系统管理对象，即MemoryMXBean；
通过ManagementFactory.getMemoryMXBean()可以获取MemoryMXBean，此MemoryMXBean是一个NotificationEmitter，如果任何一个内存池支持使用量阈值或集合使用量阈值，它将发出以下两种类型的通知：
使用量阈值超过通知-用于通知内存池的内存使用量增加，已达到或超过其使用量阈值。
集合使用量阈值超过通知-用于通知在Java虚拟机对内存池中不使用的对象进行了回收工作之后，该内存池的内存使用量已大于或等于其集合使用量阈值。
S15、将MemoryMXBean强制转型为NotificationEmitter；
由上可知，NotificationEmitter就是发起通知的起点，当JVM的垃圾收集线程在做完垃圾收集工作之后，就会根据发起通知的场景和条件，触发NotificationEmitter发出通知到各个注册的监听器，传递的参数就包含了MemoryNotificationInfo对象，其属性就包含内存池名称、内存池的使用量、超过阈值的次数等数据，这些数据将用于进行内存泄露的判断。而MemoryMXBean的实现类是NotificationEmitter的子类，因此，在本步骤中需要将MemoryMXBean强制转型为NotificationEmitter。
S16、通过NotificationEmitter的addNotificationListener接口注册监听器以监听内存使用量变化。
步骤S2：
程序启动后，程序自动执行步骤S1后，如果JVM进行完垃圾回收后内存超过设置的所述回收使用量阈值，则内存系统管理对象MemoryMXBean会将当前内存信息通知给注册的监听器，监听器接收到通知后则会执行步骤S3进行检漏判断。
步骤S3：
所述步骤S3中判断内存泄露的原理是：当前内存信息超过上一次内存使用量的连续次数达到最大内存使用量上升次数，则判定存在内存泄露。参考图3，步骤S3的包括：
S31、监听器每一次在被通知触发时启动步骤S32；
S32、判断当前内存使用量的数值是否大于上一次内存使用量的数值，如果是，则进入步骤S33；否则，将上一次内存使用量的数值更新为当前内存使用量的数值，并将计数器清零后结束；
对于首次被通知触发执行该步骤时，是不存在上一次内存使用量的，所以在程序中将为上一次内存使用量设定一个默认初始值，一般为0。
S33、将上一次内存使用量的数值更新为当前内存使用量的数值，并将计数器计数加一，判断计数器的数值是否到达所述最大内存使用量上升次数，如果是，则判定存在内存泄露并触发告警；否则，结束。
下面以一个具体的程序实现为例，说明步骤S3。
步骤S31：
该步骤中实际上需要进行一系列的准备工作。由于本发明的监听器程序实现如下：
其中的，notification参数即是用来接收的来自MemoryMXBean通知。由于通知不仅仅限于内存通知还有其他类型的通知，所以在进行检漏判断之前，需要先执行步骤31a。
S31a、判断Notification的type是否等于MemoryNotificationInfo.MEMORY_COLLECTION_THRESHOLD_EXCEEDED，如果是，执行步骤S31b，否则，处理结束。
S31b、将Notification强制转型为MemoryNotificationInfo对象(简称MNI对象)
S31c、从MNI对象当中获取MemoryUsage对象(简称MU对象)；
S31d、调用MU对象的getUsed()接口获取JVM的CMU(CurrencyMemoryUsage，当前内存使用量，单位为字节)。
步骤S32：
S32a、判断CMU是否大于LMU(LastMemoryUsage，上一次内存使用量)的数值，如果是，则进入步骤S33；否则，进入步骤S32b；
S32b、LMU＝CMU，重置MURC(MemoryUsageRaisedCounter，内存使用上升次数计数器)，结束。
由于CMU没有大于LMU的情况，说明JVM中的部分内存被回收，不符合内存泄露的场景。所以该步骤将重置MURC＝0。
步骤S33：
S33a、LMU＝CMU，累加MURC；
S33b、判断MURC是否等于MMURC(MaxMemoryUsageRaisedCount，最大内存使用量上升次数)，如果是，则进入步骤S33c，否则，结束。
MMURC的配置值越大判断越准确，不过过大的配置值可能会因为还没有达到配置值JVM就出现了内存溢出的情况，所以不建议配置超过10，默认值一般设置为5。
S33c、判定存在内存泄露并触发告警。例如，记录日志、SNMP Trap、告警短信、告警邮件。
相应于上述方法，本发明还设计一种JVM内存泄露自动检测系统，主要包括：
阈值设置装置，用于基于获取的内存池管理对象设置内存的回收使用量阈值；
监听器注册装置，用于基于获取的内存系统管理对象注册监听器以监听内存使用量变化的装置，若JVM进行完垃圾回收后内存超过设置的所述回收使用量阈值，则内存系统管理对象将当前内存信息通知给注册的监听器；
监听器，基于最大内存使用量上升次数和上一次内存使用量，对当前内存信息进行分析以判断是否存在内存泄露。
其中，监听器在被通知触发时，如果计算得到当前内存信息超过上一次内存使用量的连续次数达到最大内存使用量上升次数，则判定存在内存泄露。
具体的，所述监听器包括内存信息分析装置，用于在监听器每一次被通知触发时判断当前内存使用量的数值是否大于上一次内存使用量的数值，如果是，则将上一次内存使用量的数值更新为当前内存使用量的数值，并将计数器计数加一，且在计数器的数值到达所述最大内存使用量上升次数时判定存在内存泄露并触发告警；否则，将上一次内存使用量的数值更新为当前内存使用量的数值，并将计数器清零。
具体的，所述监听器还包括检漏判定装置，用于获取内存池管理对象列表，遍历内存池管理对象列表，根据内存池管理对象的名称获取Old区和Perm区的内存池管理对象，调用Old区和Perm区的内存池管理对象的阈值设置接口，设定Old区和Perm区的所述回收使用量阈值。
具体的，所述监听器注册装置包括：用于获取内存系统管理对象的装置，以及基于系统管理对象的相关接口注册监听器以监听内存使用量变化的装置。
综上所述，本发明通过向JVM注册监听器，通过接收通知的方式来获取JVM的内存信息，然后对于内存信息进行分析以判断是否存在内存泄露，整个过程不需要人工操作，能够自动的获取到JVM内存使用信息，减少工作量；而且能够更加及时的在GC完成之后获取JVM的内存使用信息，得到准确的内存信息；由于监听器集成在Java应用程序的内部，不用进行外部连接或者指令调用，使用简单方便，不影响程序或应用的正常运行，避免自身引出新的问题；进一步地，本发明还在判定存在内存泄露时并触发告警，从而提前通知系统维护人员系统可能存在内存问题，利于问题的尽早定位。
上面结合附图对本发明的实施例进行了描述，但是本发明并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本发明的启示下，在不脱离本发明宗旨和权利要求所保护的范围情况下，还可做出很多形式，这些均属于本发明的保护之内。

Claims (10)

1.一种JVM内存泄露自动检测方法，其特征在于，包括以下步骤：
S1、基于获取的内存池管理对象设置内存的回收使用量阈值，基于获取的内存系统管理对象注册监听器以监听内存使用量变化；
S2、若JVM进行完垃圾回收后内存超过设置的所述回收使用量阈值，则内存系统管理对象将当前内存信息通知给注册的监听器；
S3、监听器基于最大内存使用量上升次数和上一次内存使用量，对当前内存信息进行分析以判断是否存在内存泄露。
2.根据权利要求1所述的JVM内存泄露自动检测方法，其特征在于，所述步骤S3中，监听器在被通知触发时，如果计算得到当前内存信息超过上一次内存使用量的连续次数达到最大内存使用量上升次数，则判定存在内存泄露。
3.根据权利要求1或2所述的JVM内存泄露自动检测方法，其特征在于，所述步骤S3具体包括：
S31、监听器每一次在被通知触发时启动步骤S32；
S32、判断当前内存使用量的数值是否大于上一次内存使用量的数值，如果是，则进入步骤S33；否则，将上一次内存使用量的数值更新为当前内存使用量的数值，并将计数器清零后结束；
S33、将上一次内存使用量的数值更新为当前内存使用量的数值，并将计数器计数加一，判断计数器的数值是否到达所述最大内存使用量上升次数，如果是，则判定存在内存泄露并触发告警；否则，结束。
4.根据权利要求1所述的JVM内存泄露自动检测方法，其特征在于，所述步骤S1中所述的设置内存的回收使用量阈值包括：
S11、获取内存池管理对象列表；
S12、遍历内存池管理对象列表，根据内存池管理对象的名称获取Old区和Perm区的内存池管理对象；
S13、调用Old区和Perm区的内存池管理对象的阈值设置接口，设定Old区和Perm区的所述回收使用量阈值。
5.根据权利要求4所述的JVM内存泄露自动检测方法，其特征在于，所述步骤S1中所述的注册监听器包括：获取内存系统管理对象，并基于系统管理对象的相关接口注册监听器以监听内存使用量变化。
6.一种JVM内存泄露自动检测系统，其特征在于，
阈值设置装置，用于基于获取的内存池管理对象设置内存的回收使用量阈值；
监听器注册装置，用于基于获取的内存系统管理对象注册监听器以监听内存使用量变化的装置，若JVM进行完垃圾回收后内存超过设置的所述回收使用量阈值，则内存系统管理对象将当前内存信息通知给注册的监听器；
监听器，基于最大内存使用量上升次数和上一次内存使用量，对当前内存信息进行分析以判断是否存在内存泄露。
7.根据权利要求6所述的JVM内存泄露自动检测系统，其特征在于，监听器在被通知触发时，如果计算得到当前内存信息超过上一次内存使用量的连续次数达到最大内存使用量上升次数，则判定存在内存泄露。
8.根据权利要求6或7所述的JVM内存泄露自动检测系统，其特征在于，所述监听器包括内存信息分析装置，用于在监听器每一次被通知触发时判断当前内存使用量的数值是否大于上一次内存使用量的数值，如果是，则将上一次内存使用量的数值更新为当前内存使用量的数值，并将计数器计数加一，且在计数器的数值到达所述最大内存使用量上升次数时判定存在内存泄露并触发告警；否则，将上一次内存使用量的数值更新为当前内存使用量的数值，并将计数器清零。
9.根据权利要求6所述的JVM内存泄露自动检测系统，其特征在于，所述监听器包括检漏判定装置，用于获取内存池管理对象列表，遍历内存池管理对象列表，根据内存池管理对象的名称获取Old区和Perm区的内存池管理对象，调用Old区和Perm区的内存池管理对象的阈值设置接口，设定Old区和Perm区的所述回收使用量阈值。
10.根据权利要求9所述的JVM内存泄露自动检测系统，其特征在于，所述监听器注册装置包括：用于获取内存系统管理对象的装置，以及基于系统管理对象的相关接口注册监听器以监听内存使用量变化的装置。
CN201611018556.9A 2016-11-11 2016-11-11 一种jvm内存泄露自动检测方法以及系统 Pending CN108073439A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201611018556.9A CN108073439A (zh) 2016-11-11 2016-11-11 一种jvm内存泄露自动检测方法以及系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201611018556.9A CN108073439A (zh) 2016-11-11 2016-11-11 一种jvm内存泄露自动检测方法以及系统

Publications (1)

Publication Number Publication Date
CN108073439A true CN108073439A (zh) 2018-05-25

Family

ID=62160293

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201611018556.9A Pending CN108073439A (zh) 2016-11-11 2016-11-11 一种jvm内存泄露自动检测方法以及系统

Country Status (1)

Country Link
CN (1) CN108073439A (zh)

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108984295A (zh) * 2018-06-19 2018-12-11 珠海全志科技股份有限公司 内存回收方法、计算机装置及计算机可读存储介质
CN110704313A (zh) * 2019-09-25 2020-01-17 北京宝兰德软件股份有限公司 Java虚拟机内存泄漏检测方法及装置
CN110990173A (zh) * 2019-12-18 2020-04-10 北京三快在线科技有限公司 调用服务的方法、装置、设备及存储介质
CN111552616A (zh) * 2020-04-30 2020-08-18 汉海信息技术(上海)有限公司 一种内存监听方法及装置
CN111831467A (zh) * 2020-07-21 2020-10-27 北京思特奇信息技术股份有限公司 java进程内存溢出自熔断的方法、系统和电子设备
CN112783711A (zh) * 2019-11-01 2021-05-11 福建省天奕网络科技有限公司 NodeJS上程序内存分析的方法、存储介质
CN113434364A (zh) * 2021-06-25 2021-09-24 青岛海尔科技有限公司 屏端设备内存检测方法、装置、存储介质及电子装置
CN113791950A (zh) * 2021-09-15 2021-12-14 北京金山云网络技术有限公司 一种服务程序的信息处理方法、装置、服务器及存储介质
CN117971626A (zh) * 2024-03-28 2024-05-03 天津南大通用数据技术股份有限公司 基于多进程协程模型的共享内存泄漏检测方法
CN111831467B (zh) * 2020-07-21 2024-09-03 北京思特奇信息技术股份有限公司 java进程内存溢出自熔断的方法、系统和电子设备

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007004413A (ja) * 2005-06-23 2007-01-11 Hitachi Ltd メモリリークの検出方法
CN101615143A (zh) * 2008-06-27 2009-12-30 国际商业机器公司 用于内存泄漏诊断的方法和装置
US7827538B2 (en) * 2005-07-27 2010-11-02 International Business Machines Corporation Memory leak detection
CN103106134A (zh) * 2011-11-10 2013-05-15 阿里巴巴集团控股有限公司 一种性能缺陷检测方法、装置和系统
CN103577335A (zh) * 2013-10-23 2014-02-12 中国科学院计算技术研究所 一种内存垃圾回收系统及方法
CN103714004A (zh) * 2014-01-02 2014-04-09 金蝶软件（中国）有限公司 Jvm在线内存泄露分析方法及系统
CN104969222A (zh) * 2013-01-23 2015-10-07 脸谱公司 使用层次数据结构节点上递归式事件监听器的方法和系统
CN106095689A (zh) * 2016-06-24 2016-11-09 北京奇虎科技有限公司 一种应用内存泄露的检测方法和装置

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007004413A (ja) * 2005-06-23 2007-01-11 Hitachi Ltd メモリリークの検出方法
US7827538B2 (en) * 2005-07-27 2010-11-02 International Business Machines Corporation Memory leak detection
CN101615143A (zh) * 2008-06-27 2009-12-30 国际商业机器公司 用于内存泄漏诊断的方法和装置
CN103106134A (zh) * 2011-11-10 2013-05-15 阿里巴巴集团控股有限公司 一种性能缺陷检测方法、装置和系统
CN104969222A (zh) * 2013-01-23 2015-10-07 脸谱公司 使用层次数据结构节点上递归式事件监听器的方法和系统
CN103577335A (zh) * 2013-10-23 2014-02-12 中国科学院计算技术研究所 一种内存垃圾回收系统及方法
CN103714004A (zh) * 2014-01-02 2014-04-09 金蝶软件（中国）有限公司 Jvm在线内存泄露分析方法及系统
CN106095689A (zh) * 2016-06-24 2016-11-09 北京奇虎科技有限公司 一种应用内存泄露的检测方法和装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
贾晓霞等: "Java程序内存泄漏综述", 《计算机应用研究》 *

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108984295A (zh) * 2018-06-19 2018-12-11 珠海全志科技股份有限公司 内存回收方法、计算机装置及计算机可读存储介质
CN108984295B (zh) * 2018-06-19 2020-08-07 珠海全志科技股份有限公司 内存回收方法、计算机装置及计算机可读存储介质
CN110704313A (zh) * 2019-09-25 2020-01-17 北京宝兰德软件股份有限公司 Java虚拟机内存泄漏检测方法及装置
CN112783711A (zh) * 2019-11-01 2021-05-11 福建省天奕网络科技有限公司 NodeJS上程序内存分析的方法、存储介质
CN110990173A (zh) * 2019-12-18 2020-04-10 北京三快在线科技有限公司 调用服务的方法、装置、设备及存储介质
CN111552616A (zh) * 2020-04-30 2020-08-18 汉海信息技术(上海)有限公司 一种内存监听方法及装置
CN111831467A (zh) * 2020-07-21 2020-10-27 北京思特奇信息技术股份有限公司 java进程内存溢出自熔断的方法、系统和电子设备
CN111831467B (zh) * 2020-07-21 2024-09-03 北京思特奇信息技术股份有限公司 java进程内存溢出自熔断的方法、系统和电子设备
CN113434364A (zh) * 2021-06-25 2021-09-24 青岛海尔科技有限公司 屏端设备内存检测方法、装置、存储介质及电子装置
CN113434364B (zh) * 2021-06-25 2024-03-22 青岛海尔科技有限公司 屏端设备内存检测方法、装置、存储介质及电子装置
CN113791950A (zh) * 2021-09-15 2021-12-14 北京金山云网络技术有限公司 一种服务程序的信息处理方法、装置、服务器及存储介质
CN117971626A (zh) * 2024-03-28 2024-05-03 天津南大通用数据技术股份有限公司 基于多进程协程模型的共享内存泄漏检测方法

Similar Documents

Publication Publication Date Title
CN108073439A (zh) 一种jvm内存泄露自动检测方法以及系统
Zhou et al. Open source software reliability model: an empirical approach
US20040225923A1 (en) Object-based software management
WO2017167022A1 (zh) 基于大数据推算开发对象关系的方法及装置
WO2016008398A1 (zh) 程序性能测试方法和装置
EP2239664A2 (en) Context switch sampling
WO1997002528A1 (en) Method and system for an architecture based analysis of software quality
US8055926B2 (en) Aggregate power display for multiple data processing systems
CN113342939B (zh) 数据质量监控方法、装置及相关设备
JP7442900B1 (ja) 出力方法、出力装置及びプログラム
JP2008269354A (ja) インシデント・アクシデントレポート分析装置、方法、およびプログラム
CN106468560B (zh) 基于计步器消息的数据输出方法及装置
CN109697247A (zh) 一种数据准确性的检测方法及装置
CN112463807A (zh) 一种数据处理方法、装置、服务器及存储介质
US20050235284A1 (en) Systems and methods for tracking processing unit usage
JP2009282754A (ja) バッチ処理監視装置、方法及びプログラム
CN117608903A (zh) 自动生成测试报告的方法、装置、设备和存储介质
CN112328335A (zh) 一种并发请求超时的诊断方法及装置、设备、存储介质
CN107480070A (zh) 一种测试结果统计分析方法及装置
CN112036280A (zh) 水鸟种群动态监测方法、装置和设备
CN108427628A (zh) 基于持续集成工具的项目运行状态的评估方法和装置
CN113127459B (zh) 一种数据治理的实现方法、装置、可读介质及电子设备
CN116932361A (zh) 微服务变更评估方法、电子设备和存储介质
CN112181744A (zh) 一种转换器接口的故障检测方法、系统、终端以及存储介质
Tian et al. Test workload measurement and reliability analysis for large commercial software 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
RJ01 Rejection of invention patent application after publication
RJ01 Rejection of invention patent application after publication

Application publication date: 20180525