针对JAVA进程垃圾回收的监控方法及监控系统

技术领域

本发明涉及应用程序的资源回收技术领域，更具体地，涉及一种针对JAVA进程垃圾回收的监控方法。

背景技术

在Java程序运行过程中，对不需要的对象进行回收，以释放资源和空间。堆空间分为三个分代空间：年轻代、年老代和持久代。年轻代空间大多是小对象并且会被频繁回收，年轻代堆空间的垃圾回收较为频繁。年轻代堆空间的长期存活对象会转移到（也许是永久性转移）年老代堆空间；这个堆空间通常比年轻代的堆空间大，并且其空间增长速度较缓。持久代堆空间存放VM和Java类的元数据（metadata），以及interned字符串和类的静态变量。

Java程序使用垃圾回收器（GC）来实现资源的回收，在创建对象的时候会自动分配内存，并在该对象不再使用时自动释放对象所使用的内存。在程序执行过程中，垃圾回收器会执行多次垃圾收集动作。举例而言，当年轻代堆空间紧张时会触发次收集动作（MinorGC），其相对于全收集动作（Full GC）而言，回收间隔较短。而当老年代或持久代堆空间满了，会触发全收集动作，其通常是显式地启动。

频繁的垃圾回收会导致程序卡顿，而垃圾回收不彻底又会导致内存溢出等问题。开发大型 Java 应用程序的过程中难免遇到内存泄露、性能瓶颈等问题，比如文件、网络、数据库的连接未释放，未优化的算法就会引起这些问题。随着应用程序的持续运行，可能会造成整个系统运行效率下降，甚至造成系统崩溃。

针对垃圾回收的监控，通常有两类方法。一是在服务器上手动输入命令查看。通过控制命令以及相应的参数设置，可以从控制台输出JAVA虚拟机（JVM）在当前时刻的相关信息，垃圾回收数据也可以通过命令在终端持续展示。二是使用JConsole、VisualVM等类似GUI工具。通过在目标监控系统安装或者配置客户端，或通过JMX协议建立远程连接，这些工具可以连接到目标Java进程，将垃圾回收相关数据在固定的面板上以累积的方式进行展示。上述工具在监控JVM时都依赖于JMX协议或者特定Java守护进程。这需要在Java应用启动前通过配置来支持JMX协议与对应端口，而不同的应用中间件配置JMX协议的方式均有差异。使用守护进程也需要在目标监控机器上配置Java权限控制等操作来启动。这些操作都需要具有专业技能的技术人员来进行，这降低了监控的易用性。此外，开放JMX协议与相应端口也增加了目标系统被入侵的风险。

发明内容

本发明的一个方面在于提供一种能够至少部分地克服现有技术不足的针对JAVA进程垃圾回收的监控方法。

一种针对JAVA进程垃圾回收的监控方法包括：获取待监控进程的JVM标识信息；配置监控参数；其中，监控参数至少包括一年轻代垃圾回收指标和一年老代垃圾回收指标；启动监控，收集并保存待监控进程的JVM数据；统计JVM数据所包含的垃圾收集动作，以确定年轻代垃圾回收指标和年老代垃圾回收指标；基于统计结果来确定年轻代垃圾回收指标和/或年老代垃圾回收指标是否满足相应的告警标准。

可选地，该方法还包括：基于第二待监控进程的一个JVM标识信息与第一待监控进程的相应JVM标识信息相同，确定第二待监控进程为第一待监控进程的延续进程。

可选地，年轻代垃圾回收指标包括在一时间段内年轻代垃圾回收所占用的第一平均时长，年老代垃圾回收指标包括年老代垃圾回收所产生的资源释放量，其中告警标准包括：第一平均时长大于第一监控阈值；以及资源释放量小于第二监控阈值。

可选地，年老代垃圾回收指标还包括资源释放量小于一释放量阈值连续出现的次数，其中告警标准进一步包括：次数不小于第三监控阈值。

本发明的另一方面在于提供一种能够至少部分地克服现有技术不足的针对JAVA进程垃圾回收的监控系统。

该针对JAVA进程垃圾回收的监控系统包括：延续进程确定单元，配置成获取待监控进程的JVM标识信息；监控参数配置单元，配置成接受用户对监控参数的设置；其中，监控参数至少包括一年轻代垃圾回收指标和一年老代垃圾回收指标；监控单元，配置成收集和保存待监控进程的JVM数据、并统计JVM数据所包含的垃圾收集动作以确定年轻代垃圾回收指标和年老代垃圾回收指标；告警单元，配置成基于统计结果来确定年轻代垃圾回收指标和/或年老代垃圾回收指标是否满足相应的告警标准。

可选地，延续进程确定单元还配置成基于第二待监控进程的一个JVM标识信息与第一待监控进程的相应JVM标识信息相同，将第二待监控进程确定为第一待监控进程的延续进程。

可选地，监控单元还配置成确定在一时间段内年轻代垃圾回收所占用的第一平均时长；以及确定年老代垃圾回收所产生的资源释放量；其中，告警单元配置成基于第一平均时长大于第一监控阈值发出告警信息；以及基于资源释放量小于第二监控阈值发出告警信息。

可选地，监控单元进一步配置成确定资源释放量小于一释放量阈值连续出现的次数；其中，告警单元配置成基于次数不小于第三监控阈值发出告警信息。

本发明提供的针对JAVA进程垃圾回收的监控方法及系统，从JVM数据中统计各次垃圾收集动作，进而确定垃圾回收指标是否符合设定的告警标准，这种方式实现了以非侵入式方式来监控JVM数据，不依赖外部工具，无需根据不同中间件做适配，具有广泛的适用性。对于进程启停，这种监控方式也可根据获取的JVM标识而延续之前的监控过程。此外，这种监控方式也有利于保护数据安全。

附图说明

图1示出根据第一实施例的针对JAVA进程垃圾回收的监控方法的流程示意图。

图2示出根据第一实施例的针对JAVA进程垃圾回收的监控系统的模块结构图。

具体实施方式

在以下描述中提出具体细节，以便提供对本发明的透彻理解。然而，本领域的技术人员将清楚地知道，即使没有这些具体细节也可实施本发明的实施例。在本发明中，可进行具体的数字引用，例如“第一元件”、“第二装置”等。但是，具体数字引用不应当被理解为必须服从于其字面顺序，而是应被理解为“第一元件”与“第二元件”不同。

本发明所提出的具体细节只是示范性的，具体细节可以变化，但仍然落入本发明的精神和范围之内。术语“耦合”定义为表示直接连接到组件或者经由另一个组件而间接连接到组件。此外，本文所使用的、用于任何数值或范围的术语“大约”、“大体上”指示适当地容许偏差、而不会影响本发明的实施效果。

以下通过参照附图来描述适于实现本发明的方法、系统和装置的优选实施例。虽然各实施例是针对元件的单个组合来描述，但是应理解，本发明包括所公开元件的所有可能组合。因此，如果一个实施例包括元件A、B和C，而第二实施例包括元件B和D，则本发明也应被认为包括A、B、C或D的其他剩余组合，即使没有明确公开。

如图1所示，本发明第一实施例提供一种针对JAVA进程垃圾回收的监控方法，其包括以下步骤S10-S12-S14-S16-S18。虽然图1示出的各步骤的顺序是固定的，但是，本领域的技术人员可以理解，这些步骤可以相互组合、或分拆为多个不同的子步骤来执行，均不影响本发明的技术效果。本发明的一些实施例中，步骤S10可以在其他步骤之前、之后多次执行。在本发明的另一些实施例中，步骤S10、S12在监控程序首次启动时执行，步骤S14、S16、S18则随着每个待监控进程的确定而执行，即，在增加新的待监控进程之后，再次执行步骤S14、S16、S18，但无需重复执行步骤S10、S12。

步骤S10：获取待监控进程的JVM标识信息。

首先，在确定监控目标时，可根据监控目标的数量分别添加相应应用所在资源的IP地址、可用于登录并执行监控相关命令的用户名和密码。也可以直接获取一个或多个待监控进程的JAVA虚拟机标识信息。由用户提供、或系统自动筛选的待监控Java进程的标识信息可以是Java进程的名称或者ID、对应的用户标识符或其他的JAVA虚拟机标识信息、或它们的某种组合。如果是进程名称，则系统可通过jps命令获取其对应的进程ID，但若一个在监控目标上存在多个重复的进程名称，则可提供明确的待监控进程ID。

在监控运行期间，该监控方法对待监控进程的连接异常做了一定的容错。具体来说，如果待监控Java进程中途重启，该监控方法可在发现连接异常后会通过先前保存的Java进程名称在进程重启后自动获取新的进程ID，并继续先前的监控过程，从而保证了监控的延续性。例如，在监控方法发现第二待监控进程的一个JVM标识信息与第一待监控进程的相应JVM标识信息相同的情况下，可以确定第二待监控进程为第一待监控进程的延续进程，进而，可以延续对第一待监控进程的监控，而不是开始新的监控。为此，在监控方法的执行期间，在步骤S12-S14-S16-S18之前或之后，可以多次获取各待监控进程的JVM标识信息，判定有无监控进程重启或新的监控进程实际上是前一监控进程的延续进程。

步骤S12：配置监控参数。

在步骤S12，由用户配置监控参数，监控参数可包括命令参数和环境参数、监控时长、监控阈值等。监控参数应至少包括一个年轻代垃圾回收指标和一个年老代垃圾回收指标。在以下步骤S18中所需的监控阈值或告警标准也可以在此设置。其他监控参数作为可选项，由用户根据具体的应用场合来确定是否予以配置。

在本发明的一些实施例中，年轻代垃圾回收指标包括在一时间段内年轻代垃圾回收所占用的平均时长，年老代垃圾回收指标包括年老代垃圾回收所产生的资源释放量。与此相应地，在后续步骤S18中，对告警标准作相应的设定，如以下步骤S18详述。

步骤S14：启动监控，收集并保存待监控进程的JVM数据。

在步骤S14中，作为示例，通过监控目标系统的IP，利用SSH与监控目标系统建立链接并完成登录，确定监控目标的一个或多个待监控进程，再以根据所配置的监控参数组成jstat命令发送至监控目标，根据获得JVM数据与否可判断是否已启动监控。

在监控目标不变的情况下，根据内存或其他资源的使用率，可从监控目标自动地筛选出一个或多个待监控进程，利用步骤S12中配置的监控参数或沿用之前的监控参数来启动监控过程，在监控期间收集并保存各待监控进程的JAVA虚拟机（JVM）数据。

在本发明的一些实施例中，进一步判断已收集的JVM数据是否合法，如果合法则对数据进行格式化，然后将格式化的数据存入时序数据库。如果JVM数据不合法（通常是由于在进程停止或重启期间收集的），则根据进程名称循环获取新的进程ID并建立监控程序与新进程之间的连接，继续收集相应的合法JVM数据。

以下步骤中，将待监控进程称为当前监控进程。

步骤S16：统计JVM数据所包含的垃圾收集动作，以确定所配置的监控参数。

步骤S16中，对JVM数据进行统计分析，由于JVM数据包含关于多次垃圾收集动作的记录，所以能够从中提取出这些垃圾收集动作（包括次收集动作、全收集动作、年轻代垃圾收集动作、年老代垃圾收集动作等）并分别对它们进行统计，例如，统计各类垃圾收集动作的次数和各次垃圾收集动作的时长，这样可以将年轻代垃圾回收指标和年老代垃圾回收指标等赋以确定的数值，该数值与当前监控的JAVA进程直接关联。就不同的JAVA进程而言，第一进程的年轻代垃圾回收指标和年老代垃圾回收指标可能显著不同于第二进程的相应指标。视情况而定，还可确定（即量化）所配置的其他监控参数，例如命令参数和环境参数等，它们均与当前监控的进程相关联。

举例来说，为了确定所配置的两个指标，可计算在某个时间段内次收集动作的次数累计值YGC和所占用的时间累计值YGCT，进而计算出该时间段内年轻代垃圾回收所占用的平均时长。其中，YGCT是通过将每个次收集动作（MGC）所占用的时间累加在一起而获得。平均时长可以按如下方式计算，在滑动的时间窗口X分钟内，年轻代平均GC时长 =（YGCT1 –YGCT0）/ (YGC1 – YGC0)。其中，YGCT1表示当前时间各个次收集动作所占用的时间累计值，YGC1表示相应的次数累积值；而YGCT0表示在X分钟前各个次收集动作所占用的时间累计值，YGC0表示相应的次数累积值。

在某个确定的时间窗口，年轻代平均GC很可能不会体现出异常，然而，随着时间窗口的滑动，那些垃圾回收存在问题的JAVA进程在持续的监控过程中将在年轻代垃圾回收指标(或年老代垃圾回收指标)上反映出异于常规的趋势，这可引起预警信号，在预警信号符合相应的告警标准时，进一步发出告警信号。

量化所配置的监控参数也包括确定年老代垃圾回收所产生的资源释放量。年老代GC产生的资源释放量可计算为：年老代资源容量OC - 年老代资源使用量OU。在每次触发全收集动作时，执行一次对上述资源释放量的计算。该资源释放量关联于年老代垃圾回收，并随时间而变化。

经步骤S16，可以获得已确定的监控参数，其中至少包括量化后的年轻代垃圾回收指标和年老代垃圾回收指标，这些指标会随着时间变化，从而反映出当前监控进程在垃圾回收方面是否存在不良趋势。

步骤S18：基于统计结果来确定年轻代垃圾回收指标和/或年老代垃圾回收指标是否满足相应的告警标准。

在步骤S18，告警标准可设置成与之前配置的监控参数相匹配。具体来说，监控参数至少包括年轻代垃圾回收指标和年老代垃圾回收指标，这两个指标在步骤S16得到量化。相应地，针对年轻代垃圾回收指标，设置第一监控阈值，而针对年老代垃圾回收指标，设置第二监控阈值。在各指标与相应的监控阈值符合特定关系（大于或小于等）时，判定为符合告警标准，进而可发出告警信号。

以年轻代垃圾回收指标包括在一时间段内年轻代垃圾回收所占用的平均时长（以下称为第一平均时长）、年老代垃圾回收指标包括年老代垃圾回收所产生的资源释放量为例，可设定告警标准包括第一子标准：第一平均时长大于第一监控阈值（例如0.2秒），第二子标准：资源释放量小于第二监控阈值（以M字节为单位，例如50M）。可以在第一子标准或第二子标准被满足时，系统即可发出告警信号。或者，系统管理员可以设定为在第一、第二子标准均被满足时才发出告警信号。在一些实施例中，年老代垃圾回收指标还可包括资源释放量小于释放量阈值这种情况连续出现的次数。相应地，告警标准包括第三子标准：这种情况连续出现的次数不小于第三监控阈值。

在另一些实施例中，针对JAVA进程垃圾回收的监控方法还包括基于步骤S16获得的统计结果来确定全收集动作所占用的平均时长（以下称为第二平均时长）是否大于第四监控阈值。可理解，该第二平均时长也会随着监控时间窗口的移动而动态变化。全收集动作包含对年轻代、年老代以及持久代堆空间做一次完整的垃圾回收，根据堆大小的不同，全收集动作耗时也不相同，但若是其平均时长超过3-5秒，则可能说明对持久代堆空间的垃圾回收出现问题。对此，系统可以设定成在第二平均时长大于第四监控阈值的情况下发出预警信号或告警信息。

如上所述，在本发明的一些实施例中，同时存在预警信号和告警信号，告警信号是在预警信号满足告警标准时（例如，预警信号持续存在且呈强度上升趋势、或连续的预警信号指示相反信息且强度高于阈值）发出。预警信号可以通知技术人员提前关注或介入，防止JAVA进程异常。告警信号则会引起进一步的异常处理规程。根据一种异常处理规程，系统会执行相应的dump命令，收集来自JVM更详细的进程数据并存入数据库；在预设的时间间隔之后，启动下一次的监控。

根据本发明的一些实施例，监控方法还包括以图形化方式向用户或管理员展示当前监控进程的JVM数据和符合告警标准的年轻代垃圾回收指标及年老代垃圾回收指标的具体数值，并可进一步展示它们与相应的监控阈值之前的对比。作为示例，还可结合第三方监控系统（如Grafana），监控方法可以提供保存在时序数据库中的JVM数据，多用户可以随时以图形化的方式浏览已存放的JVM的格式化数据，包含JVM各部分的可使用空间大小与当前已使用大小随时间的变化、YGC与FGC的次数与耗时随时间的变化情况，并根据实际需求进行不同格式的展现。

以上提供针对JAVA进程垃圾回收的监控方法的各种实施例，其从JVM数据中自动提取并统计各次垃圾收集动作，基于统计结果来确定垃圾回收指标是否符合告警标准。其至少具有以下技术效果：1)、以非侵入式方式来监控JVM数据，不依赖JMX工具；2)、无需根据不同中间件做额外适配，可适用于任意Java进程；3)、对于进程启停，监控方法自动根据获取的JVM标识进行进程切换，无需人为干涉；4)、将监控数据持久化保存，基于此实现灵活且多模式的展示；5)、支持多用户实时多入口协作监控并分析监控目标系统；6)、实现自动化性能测试。

本发明第二实施例提供一种针对JAVA进程垃圾回收的监控系统20，该系统包括监控参数配置单元201、监控单元203、和延续进程确定单元205、告警单元207以及可选的图形展示单元209，各单元之间的耦合（连接）关系如图2所示。

其中，监控参数配置单元201向用户开放一个参数配置接口，并可接受用户对监控参数的设置。监控单元203一方面与监控参数配置单元201耦合，获取用户设置的监控参数。监控参数至少包括年轻代垃圾回收指标和年老代垃圾回收指标。另一方面，监控单元203还从待监控进程收集并保存JVM数据，统计其中包含的各次垃圾收集动作。延续进程确定单元205耦合到监控单元203，其配置成获取待监控进程的JVM标识信息，并将其传送到监控单元203。告警单元207与监控单元203耦合，其配置成基于监控单元203的统计结果来确定年轻代垃圾回收指标和/或年老代垃圾回收指标是否满足相应的告警标准。图形展示单元209配置成以图形化方式展示待监控进程的JVM数据和符合告警标准的年轻代垃圾回收指标及年老代垃圾回收指标。

具体来说，延续进程确定单元205可基于第二待监控进程的一个JVM标识信息与第一待监控进程的相应JVM标识信息相同，将第二待监控进程确定为第一待监控进程的延续进程。按这种方式，即使待监控进程中途重启，延续进程确定单元205也可在发现连接异常后将先前保存的JVM标识信息与在进程重启后自动获取的JVM标识信息相匹配，从而继续先前的监控过程。

在一些实施例中，监控单元203可确定在一时间段内年轻代垃圾回收所占用的第一平均时长和年老代垃圾回收所产生的资源释放量；相应地，告警单元207基于第一平均时长大于第一监控阈值发出告警信息，也可基于资源释放量小于第二监控阈值而发出告警信息。按照进一步改进的实施例，监控单元203还可确定资源释放量小于释放量阈值连续出现的次数；相应地，告警单元207基于该次数不小于第三监控阈值而发出告警信息。在需要关注持久堆空间的垃圾回收的情况下，监控单元303可确定全收集动作所占用的第二平均时长是否大于第四监控阈值，并可进一步发出预警信号或告警信号。

在本发明的一些实施例中，告警单元207在判断是否发出告警信息时，其所依赖的各监控阈值是来自于用户对监控参数配置单元201的参数设定过程。备选地，告警单元207所依赖的监控阈值是来自于告警单元207的机器学习过程。在此情况下，告警单元207接收用户对监控结果和告警信息的反馈，通过多层神经网络和遗传算法经训练和测试来确定各监控阈值。

在本发明的一些实施例中，监控系统20所包含的监控单元203和告警单元207可合并为一个单元，该合并单元从待监控进程收集并保存JVM数据，统计其中包含的各次垃圾收集动作，计算出年轻代垃圾回收指标和年老代垃圾回收指标，并且进一步确定这些指标是否满足相应的监控阈值。

在本发明的一些实施例中，上述监控系统的至少一部分可采用通信网络所连接的一组分布式计算装置来实现，或，基于“云”来实现。在这种系统中，多个计算装置共同操作，以通过使用其共享资源来提供服务。基于“云”的实现可提供一个或多个优点，包括：开放性、灵活性和可扩展性、可中心管理、可靠性、聚合和分析跨多个用户的信息的能力。

本领域的技术人员将会理解，结合本文中所公开的方面所描述的各种说明性逻辑块、模块、电路和算法步骤可以被实现为电子硬件、计算机软件或两者的组合。为了表明硬件和软件间的可互换性，各种说明性部件、块、模块、电路和步骤在上文根据其功能性总体地进行了描述。这样的功能性是实现为硬件还是软件将取决于特定应用以及对总体系统所施加的设计限制。技术人员可以针对具体的特定应用、按照变化的方式来实现所描述的功能性，但是，这样的实现方式决策不应当被理解为引起与本发明范围的背离。

上述说明仅针对于本发明的优选实施例，并不在于限制本发明的保护范围。本领域技术人员可能作出各种变形设计，而不脱离本发明的思想及附随的权利要求。