一种Java虚拟机的垃圾回收、负载均衡方法及系统与流程

本发明涉及负载均衡技术领域，尤其涉及一种java虚拟机的垃圾回收、负载均衡方法及系统。

背景技术：

随着互联网技术的发展，服务器的应用越来越广泛，而java作为最流行的高级语言之一，被普遍应用于很多公司。为了提升服务器的性能，目前普遍采用负载均衡器加业务服务器模式。

由于java底层采用了jvm技术，有效解决了c/c++所带来的内存泄露问题，但其垃圾回收机制影响了其性能。jvm垃圾回收主要分两种，monitorgc和fullgc。monitorgc的时间较短，一般几十毫秒即可完成，对业务不会有太大影响，但fullgc有时候可能会长达数十秒，这种情况下就可能会影响业务。

java虚拟机(jvm)有分配内存的指令，却没有释放内存的指令。jvm自身负责决定如何释放、以及何时释放不再被应用系统引用的对象所占据的内存。通常，这个任务由jvm中的垃圾收集器来完成。

垃圾收集器的主要作用就是按一定的内存垃圾回收(gc)算法，自动回收不再被引用的对象所占用的内存。此外，垃圾收集器也可能移动那些还在被引用的对象，以此减少内存碎片。jvm中的内存管理，实质上是通过不同的垃圾收集器来实现的。垃圾收集器是依据垃圾收集算法运行的系统线程。

目前，主要的内存垃圾回收(gc)算法在做全局内存垃圾回收(fullgc)时，只有内存垃圾回收线程在工作，应用中所有其它线程会暂停工作，也就是说，此时系统会暂时停止响应外部请求，导致系统出现“假死”现象。

公开号为cn103514102a的专利提供了一种java虚拟机实现内存垃圾回收的方法及装置，包括监控系统的内存垃圾回收情况，jvm触发全局内存垃圾回收前，创建新的java应用环境，将原java应用系统环境的后续外部请求转发到新java应用环境的jvm中。该发明在jvm触发全局内存垃圾回收前，即创建好新的jvm应用环境，以便将原jvm应用环境中的后续外部请求在全局内存垃圾回收前就转移至新的jvm中，从而消除了原jvm出现的“假死”现象对应用执行的影响，同时也提高了系统的可用性。但是该发明还需创建新的jvm应用环境，操作复杂。

技术实现要素：

本发明要解决的技术问题目的在于提供一种java虚拟机的垃圾回收、负载均衡方法及系统，用以解决java虚拟机服务器在做全局垃圾回收时服务器产生停顿，影响业务的问题。

为了实现上述目的，本发明采用的技术方案为：

一种java虚拟机的垃圾回收方法，包括步骤：

s1、通过业务服务器的检测进程检测java虚拟机的老年代使用率；

s2、判断所述老年代使用率是否达到预设阈值，若是，发送暂停当前业务服务器的业务请求的通知至负载均衡器的通知进程并开始垃圾回收，否则，继续等待。

进一步地，还包括步骤：

s3、通过jvm日志判断所述垃圾回收是否已经结束，若是，则发送恢复当前业务服务器的业务请求的通知至所述负载均衡器的通知进程；否则，继续等待。

进一步地，步骤s1之前还包括步骤：

按预设时间间隔t检测java虚拟机的jvm信息和jvm日志。

一种java虚拟机的负载均衡方法，包括步骤：

sa、通过负载均衡器的通知进程检测负载均衡列表；

sb、当收到业务服务器发送的暂停业务请求的通知时，暂停所述业务服务器的业务请求并将所述业务服务器移除所述负载均衡列表。

进一步地，还包括步骤：

sc、当收到所述暂停业务请求的业务服务器发送的恢复业务请求的通知时，恢复所述业务服务器的业务请求并将所述业务服务器重新添加至所述负载均衡列表。

一种java虚拟机的垃圾回收系统，包括：

老年代检测模块，用于通过业务服务器的检测进程检测java虚拟机的老年代使用率；

垃圾回收模块，用于判断所述老年代使用率是否达到预设阈值，若是，发送暂停当前业务服务器的业务请求的通知至负载均衡器的通知进程并开始垃圾回收，否则，继续等待。

进一步地，还包括：

回收结束模块，用于通过jvm日志判断所述垃圾回收是否已经结束，若是，则发送恢复当前业务服务器的业务请求的通知至所述负载均衡器的通知进程；否则，继续等待。

进一步地，还包括：

定时检测模块，用于按预设时间间隔t检测java虚拟机的jvm信息和jvm日志。

一种java虚拟机的负载均衡系统，包括：

负载检测模块，用于通过负载均衡器的通知进程检测负载均衡列表；

移除模块，用于当收到业务服务器发送的暂停业务请求的通知时，暂停所述业务服务器的业务请求并将所述业务服务器移除所述负载均衡列表。

进一步地，还包括：

添加模块，用于当收到所述暂停业务请求的业务服务器发送的恢复业务请求的通知时，恢复所述业务服务器的业务请求并将所述业务服务器重新添加至所述负载均衡列表。

本发明与传统的技术相比，有如下优点：

采用本发明，解决了集群环境下，由于java虚拟机垃圾回收产生的服务器停顿问题。

附图说明

图1是实施例一提供的一种java虚拟机的垃圾回收方法流程图；

图2是实施例一提供的一种java虚拟机的垃圾回收系统结构图；

图3是实施例二提供的一种java虚拟机的垃圾回收方法流程图；

图4是实施例二提供的一种java虚拟机的垃圾回收系统结构图；

图5是实施例三提供的一种java虚拟机的垃圾回收方法流程图；

图6是实施例三提供的一种java虚拟机的垃圾回收系统结构图；

图7是实施例四提供的一种java虚拟机的负载均衡方法流程图；

图8是实施例四提供的一种java虚拟机的负载均衡系统结构图；

图9是本发明提供的一种java虚拟机的负载均衡部署方式示意图；

图10是本发明提供的一种java虚拟机的架构方式示意图。

具体实施方式

以下是本发明的具体实施例并结合附图，对本发明的技术方案作进一步的描述，但本发明并不限于这些实施例。

实施例一

本实施例提供了一种java虚拟机的垃圾回收方法，如图1所示，包括步骤：

s11：通过业务服务器的检测进程检测java虚拟机的老年代使用率；

s12：判断老年代使用率是否达到预设阈值，若是，发送暂停当前业务服务器的业务请求的通知至负载均衡器的通知进程并开始垃圾回收，否则，继续等待。

java虚拟机的缩写是jvm。jvm是一种用于计算设备的规范，它是一个虚构出来的计算机，是通过在实际的计算机上仿真模拟各种计算机功能来实现的。

为了提升服务器性能，目前普遍采用负载均衡器加业务服务器模式，如图9所示，图9为本发明提供的一种java虚拟机的负载均衡部署方式示意图。

一台负载均衡器连接多台业务服务器。

其中，负载均衡器是一种把网络请求分散到一个服务器集群中的可用服务器上去，通过管理进入的web数据流量和增加有效的网络带宽的硬件设备。

传统的java虚拟机在全局垃圾回收(fullgc)时，可能会影响业务。

本实施例提供的方法对传统的负载均衡器和业务服务器进行了改进，在业务服务器侧检测jvm的老年代剩余空间，当检测到老年代的空间利用率达到预设阈值，则发送信号至jvm进程，通知jvm开始全局垃圾回收(fullgc)，同时通知负载均衡器，将该业务服务器从负载列表中移除，那么在全局垃圾回收(fullgc)期间，负载均衡器不会发送新的请求到业务服务器。

如图10所示，图10是本发明的一种java虚拟机的架构方式示意图。与传统技术相比，改进点有如下两个：

1.在负载均衡器中添加通知进程；

2.在业务服务器中添加检测进程。

本实施例中，步骤s11为通过业务服务器的检测进程检测java虚拟机的老年代使用率。

java中的堆是java虚拟机所管理的最大的一块内存空间，主要用于存放各种类的实例对象。在java中，堆被划分成两个不同的区域：新生代和老年代。这样划分的目的是为了使jvm能够更好的管理堆内存中的对象，包括内存的分配以及回收。

全局垃圾回收(fullgc)是发生在老年代的垃圾收集动作，所采用的是标记-清除算法。

因此，业务服务器的检测进程先检测java虚拟机的老年代使用率。

本实施例中，步骤s12为判断老年代使用率是否达到预设阈值，若是，发送暂停当前业务服务器的业务请求的通知至负载均衡器的通知进程并开始垃圾回收，否则，继续等待。

具体的，若检测到老年代的空间利用率达到预设阈值，如99％，通知负载均衡器暂停当前业务服务器的业务请求，同时发送信号给jvm进程，通知jvm开始全局垃圾回收(fullgc)。在业务服务器全局回收垃圾(fullgc)时，不会有新的业务请求。若检测到老年代的空间利用率未达到预设阈值，则继续等待老年代的空间利用率达到预设阈值再进行全局垃圾回收(fullgc)。

本实施例还提供了一种java虚拟机的垃圾回收系统，如图2所示，包括：

老年代检测模块21，用于通过业务服务器的检测进程检测java虚拟机的老年代使用率；

垃圾回收模块22，用于判断老年代使用率是否达到预设阈值，若是，发送暂停当前业务服务器的业务请求的通知至负载均衡器的通知进程并开始垃圾回收，否则，继续等待。

具体的，老年代检测模块21中业务服务器的检测进程先检测java虚拟机的老年代使用率。若老年代检测模块21检测到老年代的空间利用率达到预设阈值，如99％，垃圾回收模块22通知负载均衡器暂停当前业务服务器的业务请求，同时发送信号给jvm进程，通知jvm开始全局垃圾回收(fullgc)。在业务服务器全局回收垃圾(fullgc)时，不会有新的业务请求。若老年代检测模块21检测到老年代的空间利用率未达到预设阈值，则垃圾回收模块22继续等待老年代的空间利用率达到预设阈值再进行全局垃圾回收(fullgc)。

当老年代的空间利用率达到预设阈值，暂停负载均衡器发送业务请求至当前业务服务器，可以避免因全局垃圾回收时间过长影响业务请求的问题。

实施例二

本实施例提供了一种java虚拟机的垃圾回收方法，如图3所示，包括步骤：

s31：通过业务服务器的检测进程检测java虚拟机的老年代使用率；

s32：判断老年代使用率是否达到预设阈值，若是，发送暂停当前业务服务器的业务请求的通知至负载均衡器的通知进程并开始垃圾回收，否则，继续等待；

s33：通过jvm日志判断垃圾回收是否已经结束，若是，则发送恢复当前业务服务器的业务请求的通知至负载均衡器的通知进程；否则，继续等待。

本实施例与实施例一不同之处在于，还包括步骤s33。

具体的，通过jvm日志判断垃圾回收是否已经结束。当jvm完成全局垃圾回收(fullgc)后，会产出gc日志，当获取到jvm日志产生了gc日志，说明该业务服务器可以恢复正常工作了，判定垃圾回收已经结束。业务服务器发送恢复当前业务服务器的业务请求的通知至负载均衡器。业务服务器在结束全局垃圾回收(fullgc)后，又能恢复正常工作。

本实施例还提供了一种java虚拟机的垃圾回收系统，如图4所示，包括：

老年代检测模块41，用于通过业务服务器的检测进程检测java虚拟机的老年代使用率；

垃圾回收模块42，用于判断老年代使用率是否达到预设阈值，若是，发送暂停当前业务服务器的业务请求的通知至负载均衡器的通知进程并开始垃圾回收，否则，继续等待；

回收结束模块43，用于通过jvm日志判断垃圾回收是否已经结束，若是，则发送恢复当前业务服务器的业务请求的通知至负载均衡器的通知进程，否则，继续等待。

与实施例一不同之处在于，还包括回收结束模块43。

具体的，回收结束模块43通过jvm日志判断垃圾回收是否已经结束。当获取到jvm日志产生了gc日志，说明该业务服务器可以恢复正常工作了，判定垃圾回收已经结束。业务服务器发送恢复当前业务服务器的业务请求的通知至负载均衡器。业务服务器在结束全局垃圾回收(fullgc)后，又能恢复正常工作。若垃圾回收没有结束，则继续等待回收。

当全局垃圾回收结束后，发送通知至负载均衡器，负载均衡器重新恢复当前业务服务器的业务请求。不影响业务工作，也能很好地进行全局垃圾回收。

实施例三

本实施例提供了一种java虚拟机的垃圾回收方法，如图5所示，包括步骤：

s51：按预设时间间隔t检测java虚拟机的jvm信息和jvm日志；

s52：通过业务服务器的检测进程检测java虚拟机的老年代使用率；

s53：判断老年代使用率是否达到预设阈值，若是，发送暂停当前业务服务器的业务请求的通知至负载均衡器的通知进程并开始垃圾回收，否则，继续等待；

s54：通过jvm日志判断垃圾回收是否已经结束，若是，则发送恢复当前业务服务器的业务请求的通知至负载均衡器的通知进程；否则，继续等待。

与实施例一、实施例二不同之处在于，还包括步骤s51。

具体的，业务服务器的通知进程定时检测jvm信息和jvm日志。

每隔预设时间间隔t检测java虚拟机的jvm信息和jvm日志。以此来判断老年代使用率以及垃圾回收是否结束。t为预设时间间隔，通过设置时间间隔及时掌握业务服务器的运行状态。

本实施例还提供了一种java虚拟机的垃圾回收系统，如图6所示，包括：

定时模块61，用于按预设时间间隔t检测java虚拟机的jvm信息和jvm日志；

老年代检测模块62，用于通过业务服务器的检测进程检测java虚拟机的老年代使用率；

垃圾回收模块63，用于判断老年代使用率是否达到预设阈值，若是，发送暂停当前业务服务器的业务请求的通知至负载均衡器的通知进程并开始垃圾回收，否则，继续等待；

回收结束模块64，用于通过jvm日志判断垃圾回收是否已经结束，若是，则发送恢复当前业务服务器的业务请求的通知至负载均衡器的通知进程，否则，继续等待。

与实施例一、二不同之处在于，还包括定时模块61。

具体的，定时模块61每隔预设时间间隔t检测java虚拟机的jvm信息和jvm日志。以此来判断老年代使用率以及垃圾回收是否结束。通过设置时间间隔t及时掌握业务服务器的运行状态。

实施例四

本实施例提供了一种java虚拟机的负载均衡方法，如图7所示，包括步骤：

s71：通过负载均衡器的通知进程检测负载均衡列表；

s72：当收到业务服务器发送的暂停业务请求的通知时，暂停业务服务器的业务请求并将业务服务器移除负载均衡列表；

s73：当收到暂停业务请求的业务服务器发送的恢复业务请求的通知时，恢复业务服务器的业务请求并将业务服务器重新添加至负载均衡列表。

负载均衡器是一种把网络请求分散到一个服务器集群中的可用服务器上去，通过管理进入的web数据流量和增加有效的网络带宽的硬件设备。

本实施例的负载均衡器还包括通知进程。

本实施例中，步骤s71为通过负载均衡器的通知进程检测负载均衡列表。

负载均衡列表是指负载均衡器发送业务请求的业务服务器。在列表中的业务服务器，负载均衡器会发送业务请求至各业务服务器，不在列表中的业务服务器，负载均衡器不会发送业务请求。

本实施例中，步骤s72为当收到业务服务器发送的暂停业务请求的通知时，暂停业务服务器的业务请求并将业务服务器移除负载均衡列表。

具体的，业务服务器在进行全局垃圾回收(fullgc)时，发送暂停当前业务服务器的业务请求的通知至负载均衡器。当负载均衡器的通知进程接收到业务服务器发送的暂停当前业务请求的通知时，负载均衡器暂停当前业务服务器的业务请求，并且将当前业务服务器从负载均衡列表移除。负载均衡器不再发送业务请求至当前业务服务器。

本实施例中，步骤s73为当收到暂停业务请求的业务服务器发送的恢复业务请求的通知时，恢复业务服务器的业务请求并将业务服务器重新添加至负载均衡列表。

具体的，业务服务器在全局垃圾回收(fullgc)结束后，发送恢复当前业务服务器的业务请求通知至负载均衡器。当负载均衡器的通知进程接收到业务服务器发送的恢复当前业务请求的通知时，负载均衡器恢复当前业务服务器的业务请求，并且将当前业务服务器恢复至负载均衡列表。负载均衡器重新开始发送业务请求至当前业务服务器。

本实施例还提供了一种java虚拟机的负载均衡系统，如图8所示，包括：

负载均衡模块81，用于通过负载均衡器的通知进程检测负载均衡列表；

移除模块82，用于当收到业务服务器发送的暂停业务请求的通知时，暂停业务服务器的业务请求并将业务服务器移除负载均衡列表；

添加模块83，用于当收到暂停业务请求的业务服务器发送的恢复业务请求的通知时，恢复业务服务器的业务请求并将业务服务器重新添加至负载均衡列表。

本实施例中，负载均衡模块81用于通过负载均衡器的通知进程检测负载均衡列表。

具体的，负载均衡模块81检测到在列表中的业务服务器，负载均衡器会发送业务请求至各业务服务器，不在列表中的业务服务器，负载均衡器不会发送业务请求。

本实施例中，移除模块82用于当收到业务服务器发送的暂停业务请求的通知时，暂停业务服务器的业务请求并将业务服务器移除负载均衡列表。

具体的，业务服务器在进行全局垃圾回收(fullgc)时，发送暂停当前业务服务器的业务请求的通知至负载均衡器。当负载均衡器的通知进程接收到业务服务器发送的暂停当前业务请求的通知时，负载均衡器暂停当前业务服务器的业务请求，并且移除模块82将当前业务服务器从负载均衡列表移除。负载均衡器不再发送业务请求至当前业务服务器。

本实施例中，添加模块83用于当收到暂停业务请求的业务服务器发送的恢复业务请求的通知时，恢复业务服务器的业务请求并将业务服务器重新添加至负载均衡列表。

具体的，业务服务器在全局垃圾回收(fullgc)结束后，发送恢复当前业务服务器的业务请求通知至负载均衡器。当负载均衡器的通知进程接收到业务服务器发送的恢复当前业务请求的通知时，负载均衡器恢复当前业务服务器的业务请求，并且添加模块83将当前业务服务器恢复至负载均衡列表。负载均衡器重新开始发送业务请求至当前业务服务器。

根据负载均衡器的通知进程从业务服务器接收的通知，并通过在负载均衡列表移除或添加业务服务器，很好地解决了业务服务器在全局垃圾回收(fullgc)时暂停工作，避免了因全局垃圾回收(fullgc)时间过长产生服务停顿的问题。

本文中所描述的具体实施例仅仅是对本发明精神作举例说明。本发明所属技术领域的技术人员可以对所描述的具体实施例做各种各样的修改或补充或采用类似的方式替代，但并不会偏离本发明的精神或者超越所附权利要求书所定义的范围。