CN101281458B

CN101281458B - 一种垃圾回收的装置、系统及方法

Info

Publication number: CN101281458B
Application number: CN2008101066462A
Authority: CN
Inventors: 苗彩霞
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2008-05-14
Filing date: 2008-05-14
Publication date: 2011-06-01
Anticipated expiration: 2028-05-14
Also published as: CN101281458A

Abstract

一种垃圾回收的装置、系统及方法，该方法包括：收集系统的运行信息，以及应用程序的运行信息，并根据所述接收到的数据以及预先设置的裁决策略确定是否需要触发垃圾回收；若需要触发，则输出触发消息；执行装置根据接收到的触发消息，触发执行垃圾回收。本发明实施例使得系统根据可预测的垃圾回收时间点进行自我保护，以保证系统在执行垃圾回收时减少系统的冲击，保证数据的完整性；使得系统可以控制垃圾回收在系统空闲时段或吞吐量小时执行，以降低垃圾回收导致的系统阻塞情况；使得系统可以有规律的垃圾回收，对于垃圾回收执行时长是可预测的，这样可以基于不同的系统调整垃圾回收的执行时间点、频率和时长，以降低系统的损失。

Description

一种垃圾回收的装置、系统及方法

技术领域

本发明涉及计算机技术领域，尤其涉及一种垃圾回收的装置、系统及方法。

背景技术

目前，JAVA(一种程序设计语言)语言以其强大的软件开发、网络编程能力、手机编程能力等得到了广泛的应用。在JAVA语言中，由JVM(JAVA虚拟机)进行内存管理，并且，JVM采取垃圾自动回收机制进行内存释放，具体包括：JVM自动判断内存的使用情况并启动垃圾回收机制；这样，在进行编程的过程中，只需要关注对象的申请，而不必关心在抛弃对象时的空间回收问题，极大地方便了用户的编程。

JVM进程在将抛弃对象后，需要进行空间回收。但是，JVM进程在进行空间回收时会导致较大的系统开销，因此，在JVM中，并不是每个对象被抛弃就立即进行内存回收的，这样，JVM中设置了垃圾回收机制。JVM的垃圾回收机制要在进行垃圾回收的时间和空间之间进行平衡。为了提高系统效率，垃圾回收器通常只在满足两个条件时才运行：有对象要回收且系统需要回收。这需要根据系统抛弃的对象大小和设置的JVM垃圾回收算法进行判断，因此系统无法知道也无法具体预测垃圾回收发生的精确时间。

JVM的垃圾回收包括如下步骤：

步骤1：JVM通过对象遍历的方法，对不可达的对象进行标记，以便后续步骤中删除这些不可到达的对象，这称为标记对象。

步骤2：GC(垃圾回收)删除不可到达的对象。删除时，GC简单的扫描堆栈，删除标记的对象，并释放它们的内存以生成新的对象，这称为sweeping(清除)。

步骤3：GC不断地进行对象清除操作后，释放的内存会分成很多小段，这些各个小段不足以用于新的对象，但是组合起来却很大。因此，GC重新组织内存中的对象，将可用的空间连在一起，形成可利用的空间，这称为compacting(压缩)。

在JVM的垃圾回收过程中，当系统内存比较小的时候，进行对象标记、清除是比较快速的，一般毫秒级就可以完成，但是如果系统内存达到几十G之后，进行一次系统的垃圾回收，时间就会达到几十秒，引起系统长时间的处理中断；另外，GC的压缩处理十分耗时的，尤其对于大内存，每次的压缩处理时间会达到数分钟，这对于实时系统来说是无法接收。

JVM垃圾回收一般通过多代回收的方式进行垃圾回收，提供newgeneration(新生代)和old generation(老生代)两个内存区。一般来说，设置的新生代区的空间比较小，用以快速回收短时间存在的临时对象，执行新生代垃圾回收时间比较短，对系统的影响很小，一般不会造成系统的阻塞；设置的老生代区的空间比较大，当新生代区在执行垃圾回收后，仍然存在的在用对象超过设定的比例，或者长时间不释放的对象，都会转移到老生代，因此老生代存放了大量的长时间运行的对象。执行一次老生代的垃圾回收称作一次full GC，每次的full GC系统会占用较长的时间，并且full GC执行时可能同时需要执行压缩，会占用更长的时间，在进行对象删除和空间压缩期间，JVM阻塞了其它的线程，整个系统处于阻塞状态，不能进行任何处理。

本发明人在实现本发明的过程中发现，在现有技术中，系统无法知道也无法具体预测垃圾回收发生的精确时间，以及在进行垃圾回收的过程时，会消耗大量系统内存，从而导致系统处于阻塞状态。但是，对于要求运行速度快的实时系统，一般都希望在系统的繁忙或重要时段最好不要进行垃圾回收，以保证系统的稳定运行和实时处理能力。因为当垃圾回收启动时，在垃圾回收的过程中，系统处于阻塞状态，对于大吞吐量，大内存的系统来说，阻塞的时间比较长例如一分钟，在这段时间内，应用无法进行处理，导致整个系统处于停滞状态，对于电信应用实时系统来说，大量的呼损和系统过负荷带来很大的损失，呼叫量越大，带来的损失越多。因此，现有技术中，无法处理进行垃圾回收过程中导致的在系统繁忙或重要时段出现的阻塞问题。

发明内容

本发明实施例提供一种垃圾回收的装置、系统及方法，控制系统进行垃圾回收的时间，以避免在系统繁忙或重要时段进行垃圾回收处理。

本发明实施例是通过以下技术方案实现的：

本发明实施例提供一种控制垃圾回收的装置，所述装置包括：

信息收集单元，用于收集系统的运行信息，以及应用程序的运行信息；

触发裁决单元，用于根据信息收集单元收集的数据确定系统以及应用程序是否处于空闲状态，并当系统以及应用程序处于空闲状态时，根据预先设置的裁决策略确定是否需要触发垃圾回收；若需要触发，则输出触发消息。

本发明实施例提供一种垃圾回收的系统，所述系统包括：控制垃圾回收的装置，以及执行装置，其中，

所述控制垃圾回收的装置，用于根据收集的数据确定系统以及应用程序是否处于空闲状态，并当系统以及应用程序处于空闲状态时，根据预先设置的裁决策略确定是否需要触发垃圾回收；若需要触发，则输出触发消息；

所述执行装置用于根据接收到的触发消息，触发执行垃圾回收。

本发明实施例提供一种控制垃圾回收的方法，所述方法包括：

收集系统的运行信息，以及应用程序的运行信息；

根据所述接收到的数据确定系统以及应用程序是否处于空闲状态，并当系统以及应用程序处于空闲状态时，根据预先设置的裁决策略确定是否需要触发垃圾回收；若需要触发，则输出触发消息。

由上述本发明实施例提供的技术方案可以看出，本发明实施例采用控制垃圾回收的装置控制垃圾回收，使得系统根据可预测的垃圾回收时间点进行自我保护，以保证系统在执行垃圾回收时减少系统的冲击，保证数据的完整性；使得系统可以控制垃圾回收在系统空闲时段或吞吐量小时执行，以降低垃圾回收导致的系统阻塞情况；使得系统可以有规律的垃圾回收，对于垃圾回收执行时长是可预测的，这样可以基于不同的系统调整垃圾回收的执行时间点、频率和时长，以降低系统的损失。

附图说明

图1为本发明实施例垃圾回收系统的结构图；

图2为本发明实施例垃圾回收的方法的流程图；

图3为本发明实施例垃圾回收的方法的内部处理的流程图。

具体实施方式

本发明实施例提供了一种垃圾回收的系统，结构图如图1所示，包括：

独立设置于系统之外或者设置于系统中的控制垃圾回收的装置，以及设置于系统中的执行装置。其中，控制垃圾回收的装置具体可以包括：信息收集单元、触发裁决单元。其中，

信息收集单元，用于收集系统的运行信息，以及应用程序的运行信息。

系统的运行信息用于指示系统的繁忙程度，包括：系统的中央处理器CPU占用率、系统的一种程序设计语言JAVA虚拟机JVM的内存占用率、系统的内存占用率和系统的当前时间等信息中的至少一个。

应用程序的运行信息用于指示应用程序的繁忙程度以及上次垃圾回收的状况，所述应用程序的繁忙程度包括：当前应用程序的吞吐量、预先设置的应用程序的话务模型和当前应用程序占用的内存等信息中的至少一个；所述上次垃圾回收的状况包括：上次垃圾回收的时间和上次垃圾回收的内存大小等信息中的至少一个。比如：可以结合预先设置的应用程序的话务模型和当前应用程序的吞吐量确定应用程序的繁忙程度，话务模型是根据应用程序的应用场景确定的应用程序在不同时段预期的负荷情况，可以将系统的吞吐量与预期的负荷情况进行对比，可以将得到的比值作为指示系统繁忙程度的值。

触发裁决单元，用于根据信息收集单元收集的数据以及预先设置的裁决策略确定是否需要触发垃圾回收；若需要触发，则输出触发消息；以保证当系统忙时不触发或少触发垃圾回收，以及保证用户的需求。

触发裁决单元中的裁决策略可以根据用户的需求设置，所述用户的需求包括：系统JVM的内存占用率的设定阀值、系统要求的垃圾回收的执行频率和垃圾回收执行的时段要求中的至少一个。

触发裁决单元可以根据系统的运行信息确定系统的空闲状况，可以由接收到的应用程序的运行信息确定应用程序的运行状况，再结合预先设置的裁决策略确定是否需要触发垃圾回收。比如，具体的触发裁决过程可以包括：触发裁决单元可以根据整个系统的CPU的占用率是否超过指定阀值来确定系统是否处于空闲状况，根据当前应用程序的吞吐量和预先设置的应用程序的话务模型来确定应用程序是否处于空闲状态，当系统和应用程序同时处于空闲状态时，若预先设置的裁决策略为垃圾回收执行的时段要求，则再判断是否满足该时段要求，若满足，则执行垃圾回收，否则，不执行垃圾回收。

执行装置可以和系统同属一个JVM。当执行装置收到触发裁决单元发送的触发垃圾回收的触发消息后，调用内部处理，触发执行垃圾回收。

该触发执行单元可以调用系统提供的垃圾回收程序执行垃圾回收，比如：该调用的内部处理可以由Java提供的一个函数System.gc()来调用。该函数执行后并不会立即启动垃圾回收，而是在现有的JVM垃圾回收算法中加权，以触发垃圾回收。执行单元可以采用调用多次System.gc()的方法，每次调用后检查JVM的输出是否执行了GC，若未执行则重新调用该函数并检查JVM输出，循环执行，至到GC执行或者调用的次数达到了设定的门限，停止调用。

在本发明实施例中，可以在控制垃圾回收的装置，以及设置于系统中的执行装置之间设置第一通信单元和第二通信单元，用于传送控制垃圾回收的装置和执行装置之间的消息指令或数据信息。其中，第一通信单元位于控制垃圾回收的装置中，分别与信息收集单元和触发裁决单元相连，第二通信单元位于系统中，与执行装置相连；该第一、二通信单元相连。一方面，系统和应用程序的运行信息，如系统的吞吐量、JVM的堆栈占用情况等，需要通过第一通信单元和第二通信单元上报给信息收集单元；另一方面，触发裁决单元通过第一通信单元和第二通信单元发送触发GC的指令给执行装置，由执行装置触发执行GC的操作。

本发明实施例使得系统根据可预测的垃圾回收时间点进行自我保护，以保证系统在执行垃圾回收时减少系统的冲击，保证数据的完整性；使得系统可以控制垃圾回收在系统空闲时段或吞吐量小时执行，以降低垃圾回收导致的系统阻塞情况；使得系统可以有规律的垃圾回收，对于垃圾回收执行时长是可预测的，这样可以基于不同的系统调整垃圾回收的执行时间点、频率和时长，以降低系统的损失。

本发明实施例提供了一种垃圾回收的方法，流程图如图2所示，包括：

步骤1：信息收集单元收集系统的运行信息，以及应用程序的运行信息。信息收集单元还可以将接收到的所有数据进行统一归整，比如：将接收到的数据按照不同的格式进行归整，以便于将数据方便的输出给触发裁决单元；或，从收集到的数据中得出需要发送给触发裁决单元的信息。

所述系统的运行信息用于指示系统的繁忙程度，包括：系统的中央处理器CPU占用率、系统的一种程序设计语言JAVA虚拟机JVM的内存占用率、系统的内存占用率、和系统的当前时间中的至少一个。

所述应用程序的运行信息用于指示应用程序的繁忙程度以及上次垃圾回收的状况，所述应用程序的繁忙程度包括：当前应用程序的吞吐量、预先设置的应用程序的话务模型和当前应用程序占用的内存中的至少一个；所述上次垃圾回收的状况包括：上次垃圾回收的时间和上次垃圾回收的内存大小中的至少一个。

步骤2：信息收集单元上报收集的数据给触发裁决单元。需要说明的是，此步骤中也可以由触发裁决单元主动从信息收集单元中获取数据。

步骤3：触发裁决单元根据接收到的数据以及预先设置的裁决策略确定是否需要触发垃圾回收，以保证当系统忙时不触发或少触发垃圾回收，以及保证用户的需求；若需要触发，则输出触发消息给系统。具体可以根据预先设置的内部算法对收集到的数据进行运算和逻辑处理，判断是否需要对系统启动GC。

所述触发裁决单元中的裁决策略根据用户的需求设置，所述用户的需求包括：系统JVM的内存占用率的设定阀值、系统要求的垃圾回收的执行频率和垃圾回收执行的时段要求中的至少一个。

步骤4：系统中的执行装置根据接收到的触发消息，触发执行垃圾回收。该内部处理可以包括系统本身提供的各种垃圾回收方法，比如：可以为执行System.gc()操作，具体方法可以如图3所示，包括：调用System.gc()函数，根据JVM GC的输出结果来检查完全垃圾回收是否执行完成，若已执行完成则对结果进行详细记录，记录的内容包括执行时间、执行时长、收集的内存大小、调用System.gc的次数；若未执行完成，则继续调用System.gc()，直到完全垃圾回收被执行或调用次数超过系统设定的阀值，然后输出结果详细记录。

步骤5：信息收集单元收集步骤4的执行结果，并提供给触发裁决单元，以便于触发裁决单元进行下一次的触发裁决。

以上所述，仅为本发明较佳的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应该以权利要求书的保护范围为准。

Claims

1.一种控制垃圾回收的装置，其特征在于，所述装置包括：

所述信息收集单元收集的系统的运行信息用于指示系统的繁忙程度，包括：系统的中央处理器CPU占用率、系统的一种程序设计语言JAVA虚拟机JVM的内存占用率、系统的内存占用率和系统的当前时间中的至少一个；

2.如权利要求1所述的装置，其特征在于，所述信息收集单元接收到的应用程序的运行信息用于指示应用程序的繁忙程度以及上次垃圾回收的状况，所述应用程序的繁忙程度包括：当前应用程序的吞吐量、预先设置的应用程序的话务模型和当前应用程序占用的内存中的至少一个；所述上次垃圾回收的状况包括：上次垃圾回收的时间和上次垃圾回收的内存大小中的至少一个。

3.如权利要求1或2所述的装置，其特征在于，所述触发裁决单元中的裁决策略根据用户的需求设置，所述用户的需求包括：系统JVM的内存占用率的设定阀值、系统要求的垃圾回收的执行频率和垃圾回收执行的时段要求中的至少一个。

4.一种垃圾回收的系统，其特征在于，所述系统包括：控制垃圾回收的装置，以及执行装置，其中，

所述控制垃圾回收的装置具体包括：

信息收集单元，用于收集系统的运行信息，以及应用程序的运行信息；所述系统的运行信息用于指示系统的繁忙程度，包括：系统的中央处理器CPU占用率、系统的一种程序设计语言JAVA虚拟机JVM的内存占用率、系统的内存占用率和系统的当前时间中的至少一个；

触发裁决单元，用于根据信息收集单元收集的数据以及预先设置的裁决策略确定是否需要触发垃圾回收；若需要触发，则输出触发消息；

5.如权利要求4所述的系统，其特征在于，所述执行装置调用系统提供的垃圾回收程序执行垃圾回收。

6.如权利要求5所述的系统，其特征在于，所述垃圾回收程序包括：由JaVa提供的一个函数System.gc()；

所述执行装置调用多次System.gc()，每次调用后检查JVM的输出是否执行了垃圾回收，若未执行则重新调用该函数并检查JVM输出，循环执行，直到垃圾回收执行或者调用的次数达到了设定的门限，停止调用。

7.一种控制垃圾回收的方法，其特征在于，所述方法包括：

收集系统的运行信息，以及应用程序的运行信息；所述系统的运行信息用于指示系统的繁忙程度，包括：系统的中央处理器CPU占用率、系统的一种程序设计语言JAVA虚拟机JVM的内存占用率、系统的内存占用率和系统的当前时间中的至少一个；

根据收集到的数据确定系统以及应用程序是否处于空闲状态，并当系统以及应用程序处于空闲状态时，根据预先设置的裁决策略确定是否需要触发垃圾回收；若需要触发，则输出触发消息。

8.如权利要求7所述的方法，其特征在于，所述应用程序的运行信息用于指示应用程序的繁忙程度以及上次垃圾回收的状况，所述应用程序的繁忙程度包括：当前应用程序的吞吐量、预先设置的应用程序的话务模型和当前应用程序占用的内存中的至少一个；所述上次垃圾回收的状况包括：上次垃圾回收的时间和上次垃圾回收的内存大小中的至少一个。

9.如权利要求7或8所述的方法，其特征在于，所述裁决策略根据用户的需求设置，所述用户的需求包括：系统JVM的内存占用率的设定阀值、系统要求的垃圾回收的执行频率和垃圾回收执行的时段要求中的至少一个。

10.如权利要求7或8所述的方法，其特征在于，所述方法还包括：

执行装置根据接收到的触发消息，触发执行垃圾回收。

11.如权利要求10所述的方法，其特征在于，所述执行装置触发执行垃圾回收的方法具体包括：

所述执行装置调用系统提供的垃圾回收程序执行垃圾回收。

12.如权利要求11所述的方法，其特征在于，

所述垃圾回收程序包括：由Java提供的一个函数System.gc()；

所述执行装置调用系统提供的垃圾回收程序执行垃圾回收的方法具体包括：所述执行单元调用多次System.gc()，每次调用后检查JVM的输出是否执行了垃圾回收，若未执行则重新调用该函数并检查JVM输出，循环执行，至到垃圾回收执行或者调用的次数达到了设定的门限，停止调用。