专利名称：：用于管理存储器使用的方法和计算设备的制作方法
技术领域：
：本发明的实施例一般涉及计算机软件领域，本发明的实施例具体涉及用于对虚拟机中的存储器(memory)使用进行管理的系统和制造物品。
背景技术：
：当前，可在服务器或客户计算机上部署计算机软件应用。某些应用可在由虚拟机提供的环境中被执行。虚拟机提供了对于可能以不同方式实现的计算设备的抽象规范。虚拟机允许计算机程序或应用在任何计算机平台上运行，而不论用什么底层硬件。假如虚拟机的版本可采用，为该虚拟机所编译的应用可在任何底层计算机系统上被执行。虚拟机典型地在软件而不是硬件中实现，并且经常被称作“运行时环境”。另外，为虚拟机所编译的源代码典型地被称作“字节码”。通常，虚拟机通过从字节码生成指令来执行应用，所述指令接着可由在底层计算机系统上的可用的物理处理器执行。可从SunMicrosystems得到的Java虚拟机是虚拟机的一个公知示例。Java虚拟机由字节码指令集、一组寄存器、堆栈、垃圾收集堆(即用于用户应用的存储空间)以及用于存储方法的存储空间。可对用Java编程语言所写的应用进行编译以生成字节码。字节码提供由Java虚拟机解释的、与平台无关的代码。实际上，计算机系统典型地向在系统上执行的虚拟机的每一实例分配存储池。随着时间的过去，池中的可用存储器可能由于虚拟机执行应用而减少或增加。这种情况是随着应用程序从存储池分配和释放存储对象而发生的。在某些情况下，在虚拟机上运行的应用可能试图分配比可用存储器更多的存储器。例如，应用所用的存储器可能超过向虚拟机所分配的存储器，或者，虚拟机可能耗尽可从底层主机系统获得的存储器。当这种情况发生时，发生“存储器不足”异常。这样的一种存储器不足异常可能导致应用、虚拟机或底层系统崩溃。作为崩溃的后果，应用所提供的服务可能停止工作，未保存的数据可能丢失，并且可能需要用户干预以重新启动系统或应用。防止发生存储器不足异常的一种方法包括使用垃圾收集过程。垃圾收集是指对不再使用的存储器的自动检测和释放。例如，Java虚拟机进行垃圾收集，因此不再需要程序员显式地释放对象及其他数据。实际上，可将虚拟机配置为对存储器使用进行监视，且一旦使用了存储器预先规定的百分比，则调用垃圾收集器以回收给定应用不再需要的存储器。在虚拟机上执行的、从应用回收存储器的这种过程被称作垃圾收集循环。一种垃圾收集方法被称为“跟踪”，其中，垃圾收集器确定存储对象是“可及的”(reachable)或“有根的”(rooted)。当存储对象仍被系统中某其他对象引用时，其被认为是可及的。如果正在运行的进程均不包含对一存储对象的引用，则该存储对象被认为是“不可及的”，并被认为是垃圾收集的候选者。典型地，垃圾收集器将不可及的存储对象返还给堆(即用户应用可从中分配存储器的存储空间)，从而为在虚拟机上运行的应用释放存储器。然而，即使采用垃圾收集器，应用可能消耗所有可由虚拟机获得的存储器，结果，触发“存储器不足”异常。另外，另一种存储器管理方法包括使系统管理员对存储器使用进行监视。目前，管理员可以对正在系统上运行的虚拟机的每一实例进行轮询以确定它们的存储器使用，并且识别任何潜在的存储器泄漏。“存储器泄漏”是用于描述可用存储器随时间损失的编程术语。存储器泄漏典型地发生在当程序分配存储器但在不再需要所分配的存储器时又未能将其返还(或“释放”)的时候。足够长的一段时间之后，过多的存储器泄漏可能导致程序故障。然而，存储器泄漏常常难以检测，尤其是在比较小的时候，或者是在它们发生在同时执行许多应用的复杂环境中、从而使得难以将存储器泄漏精确定位到一个应用时。另外，这种方法需要系统管理员对存储器使用的状态进行监视，这可能既耗时又易产生误差。此外，除非频繁并且始终进行，否则管理员会不能检测出存储器泄漏。因此，本领域需要一种用于在垃圾收集环境下管理存储器使用的方法。
发明内容本发明一般涉及一种用于预测何时可能发生存储器不足异常的方法、计算机可读取介质以及计算机系统。本发明的一个实施例提供了一种计算机实现的方法，其用于在垃圾收集的计算环境管理存储器使用。该方法一般包括在多个垃圾收集循环的每一个中，监视由多个应用所使用的、可从存储池获得的存储器，其中，每一应用可以动态地从存储池分配存储器以及将存储器返还到存储池。该方法一般进一步包括生成存储器使用概要(profile)，并基于存储器使用概要来预测是否可能发生存储器不足异常，其中，存储器使用概要表征在两个或两个以上垃圾收集循环中可从存储池获得的存储器的变化。当可从存储池获得的存储量达到预先确定的量时，可启动垃圾收集循环。本发明的另一实施例包括计算机可读取介质，其包含一种程序，当执行该程序时，该程序执行用于在垃圾收集的计算环境中管理存储器使用的操作。所述操作一般包括在多个垃圾收集循环的每一个中，监视由多个应用所使用的、可由存储池获得的存储量，其中，每一应用可以动态地从存储池分配存储器以及将存储器返还到存储池。该方法一般还包括生成存储器使用概要，并基于该存储器使用概要预测是否可能发生存储器不足异常，其中，所述存储器使用概要表征在两个或两个以上垃圾收集循环中可从存储池获得的存储器的变化。本发明的又一个实施例提供了一种计算设备。该计算设备一般包括处理器以及与处理器通信的存储器。存储器至少包含虚拟机程序，该虚拟机程序被配置为预测何时可能发生未来的存储器不足异常。该虚拟机程序可被配置为至少执行分配存储池以由多个应用所使用的步骤，其中，每一应用可以动态地从存储池分配存储器以及将存储器返还到存储池。所述步骤可进一步包括每当可在存储池中获得的存储量达到预先确定的量，就触发垃圾收集器过程以执行垃圾收集循环。所述步骤还可进一步包括在每一垃圾收集循环期间，对可从存储池获得的存储量进行监视，生成存储器使用概要，基于该存储器使用概要预测是否可能发生存储器不足异常，其中，所述存储器使用概要表征在两个或两个以上垃圾收集循环中可由存储池获得的存储器的变化。为了理解本发明的上述特征，可通过参考附图所示的典型实施例，阅读对上文简述的本发明的更详细描述。但应注意的是，由于本发明可允许其他同样有效的实施例，附图所示出的仅仅是本发明的典型实施例，且因此不应被看作是对本发明的范围的限定。图1的框图示出了运行虚拟机的计算机系统的一个实施例；图2的框图示出了根据本发明一个实施例、执行应用的虚拟机；图3的框图示出了虚拟机的一个实施例；图4的流程图示出了根据本发明一个实施例、用于预测何时将发生存储器不足事件的方法；图5的流程图示出了根据本发明一个实施例、用于收集数据以编制存储器概要的方法；图6示出了存储器概要数据表的实施例；图7为由存储器概要分析器(profiler)所收集数据的示例性图形表示。具体实施例方式本发明的实施例提供了用于预测垃圾收集环境下虚拟机的存储器使用何时可能导致发生“存储器不足”异常的方法、系统和制造物品。下面参照本发明的实施例。然而，应当明了的是，本发明并不限于所介绍的特定实施例。相反，可以考虑用下面的特征和元素的任意组合来实现和实践本发明，而无论它们是否涉及不同的实施例。另外，在各实施例中，本发明提供了优于现有技术的大量优点。然而，尽管本发明的实施例可获得优于其他可能的解决方案和/或优于现有技术的优点，某一具体优点是否由给定的实施例获得并不构成对本发明的限定。因此，下面的方面、特征、实施例和优点仅作说明之用而不应被看作是所附权利要求的要素或限定，除非权利要求中明确提出。类似地，谈到“本发明”不应被解释为对此处所披露的任何发明主题的概括，也不应被看作是所附权利要求的要素或限定，除非权利要求中明确提出。本发明的一个实施例被实现为与计算机系统一起使用的程序产品，该计算机系统比如举例来说为图1所示并在下面介绍的计算机系统。该程序产品的程序规定了实施例(包括这里介绍的方法)的功能并可被包含在多种信号承载介质中。典型的信号承载介质包括但不限于(i)永久存储在不可写存储介质(例如计算机中的只读存储器装置，例如可由CD-ROM驱动器读取的CD-ROM盘)上的信息；(ii)存储在可写存储介质(例如软盘驱动器中的软盘或磁盘驱动器)上的可更改的信息；以及(iii)通过例如包括无线通信在内的计算机或电话网络等通信介质传送给计算机的信息。后一实施例特别包括从因特网及其他网络下载的信息。当这种信号承载介质携带指导本发明功能的、计算机可读的指令时，其代表本发明的实施例。通常，所执行的实现本发明实施例的例程可以是操作系统或具体应用、组件、程序、模块、对象或指令序列的一部分。本发明的计算机程序典型地包括将被本机计算机转换为机器可读形式并因此为可执行指令的多个指令。另外，程序可包括位于程序局部或存在于存储器或存储设备上的变量和数据结构。另外，下面介绍的各程序可基于在本发明具体实施例中为其实现它们的应用来识别。但是，应该明了，下面任何具体的程序命名仅为了方便而使用，故而本发明不应当局限于仅用在由这种命名所识别和/或所意指的任何具体应用。图1的框图示出了根据本发明一实施例配置的计算机系统100。作为示例，计算机系统100包括存储器105和中央处理单元(CPU)115。另外，计算机系统100典型地包括例如非易失性存储器、网络接口设备、显示器、输入输出设备等附加部件。在一个实施例中，计算机系统100可包含例如桌面计算机、服务器计算机、膝上型计算机、平板计算机(tabletcomputer)等计算机系统。然而，这里介绍的系统和软件应用并不限于任何当前存在的计算环境或编程语言，而可适应于在新的计算系统以及编程语言可用时利用新的计算系统以及编程语言。在一个实施例中，一个或一个以上虚拟机110可位于存储器110中。计算机系统100上运行的每一虚拟机110被配置为执行为虚拟机110所创建的软件应用。例如，虚拟机110可包括可从SunMicrosystems公司得到的Java虚拟机和操作环境(或按照Java虚拟机规范创建的、等效的虚拟机)。在这里尽管本发明实施例以Java虚拟机为例进行介绍，本发明的实施例可在任何垃圾收集应用环境中实现。图2的框图进一步示出了根据本发明一实施例、执行应用210的虚拟机220的操作。如上所述，软件应用可用被配置为生成用于具体虚拟机220的字节码的编程语言和编译器编写。继而虚拟机220可通过由字节码生成本机指令230，来执行应用210。接着，本机指令可由CPU115执行。图3的框图进一步示出了虚拟机300的一个实施例。作为示例，虚拟机300包括垃圾收集过程315、存储器使用概要分析器过程320以及可用存储池325。另外，虚拟机300被示为执行多个应用3051至3053。应用3051至3053用与虚拟机300相关联的编程语言(例如Java编程语言)编写，并被编译成为可由虚拟机300执行的字节码。在一个实施例中，虚拟机300可被配置为在多个应用3051至3053间处理多任务。因此，尽管图3示出了在虚拟机300上执行的三个应用3051至3053，在任何给定时刻，在虚拟机300上可执行任何数量的应用305。在执行的时候，应用305可从存储池325(例如堆结构)动态分配存储器。例如，Java编程语言提供了用于在运行时从堆中分配存储器的“new”操作符。其他的编程语言提供了类似的构造。当对象不再被应用305引用时，其占据的堆空间可被回收，使得该空间能被后来的新对象所用。如上所述，垃圾收集是这样的过程，该过程自动释放出被分配给不再被应用305引用的这类对象的存储器。在一个实施例中，垃圾收集器315可被配置为执行垃圾收集过程或循环。执行垃圾收集循环使得未被使用的(但已被分配的)存储器能被回收。当对象被垃圾收集器315“收集”时，被分配给该对象的任何存储器可被返还到存储池325。如上所述，存储池325可包括应用可从中分配存储器的堆结构。因此，当垃圾收集器将被分配给对象的存储器作为“垃圾”收回时，其被返还到堆中。在一个实施例中，使用为虚拟机300的给定实例指定的固定参数确定存储池325的大小。如这里所用的，存储池325的大小用Mmax表示。对于Java虚拟机，Mmax以字节为单位定义了存储堆的大小。如果由应用305所分配的存储器超过了Mmax，则发生“存储器不足异常”。为了回收应用不再需要的存储器，虚拟机300被配置为启动垃圾收集器315。每当应用3051至3053使用了Mmax的预先规定的百分比时，可触发垃圾收集循环。在每一垃圾收集循环期间，垃圾收集器315试图释放应用3051至305n不再使用的存储器。在一个实施例中，垃圾收集器315通过保守估计何时存储池325(例如堆)中的存储对象未来将不被访问，来释放存储器。在每一垃圾收集循环期间，垃圾收集器315可检查由应用305之一所分配的每一存储对象。如果该存储对象在将来可能被访问(例如当应用305具有对该对象的引用时)，垃圾收集器315则让该对象保持原样。如果该存储对象在将来将不被访问(例如当应用305均不引用该对象时)，垃圾收集器315则回收被分配给该对象的存储器并将之返还给存储池325。然而，应用有时会保持对不再需要的对象的引用。在这种情况下，垃圾收集器315不能释放该存储器并将之返还到存储池325。例如，应用可能具有“存储器泄漏”。如较早所述的那样，“存储器泄漏”是用于描述存储器随时间的损失的编程术语。当应用分配了一块(chunk)存储器但在不再被需要时不能将之返还到系统时，可能发生“存储器泄漏”。例如，一旦由应用所分配的存储器不再需要，行为良好(well-behaved)的应用将释放被分配的该存储器。然而，在某些情况下，当被分配的存储器不再被需要时，应用可能未能将之释放出。由于该应用仍然引用该存储器，在垃圾收集循环中，垃圾收集器不能将之收回。如果应用继续分配存储对象且不能释放它们，则最终这样的一种程序将耗尽被分配给该虚拟机的全部存储器，导致发生“存储器不足异常”。许多其他的情况可能导致存储器泄漏。例如，链表或散列表可能包含被引用、但不再被需要的对象。发生存储器泄露的另一种常见方式是使用由Java虚拟编程语言提供的本机方法。在本机代码中，程序员可以显式地创建对对象的全局引用。直到该全局引用本身被移除，该全局引用都不会被垃圾收集器回收。因此，如果程序员疏忽了删除该全局引用，则可导致存储器泄漏。图3还示出了存储器使用概要分析器320。存储器使用概要分析器320可被配置为从存储池生成关于存储器使用的存储器使用概要。在一个实施例中，存储器使用概要分析器320被配置为确定是否有可能发生“存储器不足”异常。如果有可能，存储器使用概要分析器320可被进一步配置为将所预测的“存储器不足”异常向系统管理员或其他应用警告，或执行某种其他补救动作。存储器使用概要分析器320的操作参照图4至7进一步讨论。首先，图4示出了存储器使用概要分析器320构建关于存储池325的存储器使用概要的操作。在一个实施例中，虚拟机300可将方法400作为由垃圾收集器315所执行的每一垃圾收集循环的一部分启动。在步骤420中，存储器使用概要分析器320收集存储器概要数据。例如，概要分析器320可确定每一应用305已从存储池325分配了多少存储器。因此，在每一垃圾收集循环期间，概要分析器可获得存储器使用的快照。在步骤430中，存储器使用概要分析器320确定是否可获得足够数量的数据以构建存储器使用概要。例如，概要分析器320可被配置为在构建存储器使用概要之前，对于最少数量的垃圾收集循环收集存储器使用数据。如果否，存储器使用概要分析器320则返回到步骤420，并等待以在后续的垃圾收集循环期间收集更多的数据。否则，在步骤440中，存储器使用概要分析器320生成存储器使用概要。在一个实施例中，存储器分析是数据点的汇集，这些数据点表示虚拟机300、存储池325、和应用305随时间的存储器使用。一旦存储器使用概要分析器320收集到足够数量的存储器使用数据，概要分析器320可被配置为构建存储器使用概要。例如，存储器使用概要分析器320可使用在每个垃圾收集循环期间所收集的数据点来进行回归分析。可用的数据点越多，回归分析越准确。但是，任何合适的统计技术可被用于生成存储器使用概要。取决于应用305的实际存储器使用，所构建的存储器使用概要可能表现为线性或指数存储器使用概要。但存储器使用还可遵循其他的可预测模式。例如，存储器使用可能遵循多项式或正弦模式。无论何种具体存储器使用概要，将存储器使用概要用于预测虚拟机300上运行的应用305未来的存储器使用。例如，使用线性回归时，由存储器概要数据生成的线性方程式表示应用305随着时间的过去从池325中消耗存储器的速率。如果这样一种方程式指示应用305所使用的存储量正在不衰减地增长(例如如果表示存储器使用的线性方程式的斜率为正)，则不管垃圾收集器315释放存储对象的动作，最终可能发生“存储器不足”异常。在其他实施例中，可将其他技术用于预测何时可能发生存储器不足事件。例如，可将例如神经网络或机器学习技术等自学习试探法用于分析存储器使用概要数据。在步骤450中，基于从存储器使用数据所构建的存储器使用概要，存储器使用概要分析器320确定是否有可能发生“存储器不足”异常。如果是，存储器泄漏可能正在发生。通过使用存储器使用概要以及虚拟机可用的最大存储量Mmax，存储器使用概要分析器320能够预测何时可能发生“存储器不足”异常。如果是这样，在步骤460中，存储器使用概要分析器320可被配置为向系统管理员发送指示所预测的、何时可能发生“存储器不足”异常的消息。如果没有预测到“存储器不足”异常，则方法400在步骤470处终止。取决于存储器使用概要以及概要分析器320的配置，可执行多种补救动作。例如，如果存储器泄漏表现出线性增长模式，在某个时间内其可能不会成为危急问题。在这种情况下，存储器使用概要分析器可通过自动的电子邮件消息简单地通知系统管理员。或者，如果泄漏表现出指数增长模式，则虚拟机300的崩溃可能即将到来。在这种情况下，概要分析器320可被配置为进行更为积极的步骤来接触管理员(例如即时消息或移动电话传呼)，或者，概要分析器320可具有终止在虚拟机300上运行的进程的权限，从而以牺牲导致存储器泄漏的应用为代价允许其他应用305继续工作。另一种可能性包括请求增加被分配给虚拟机的存储量。这样做可能会延迟“存储器不足”异常发生前的时间。另外，存储器使用概要分析器320还可被配置为计算关于对是否(或何时)可能发生“存储器不足”事件的预测的置信度(confidencelevel)。在一个实施例中，存储器使用概要分析器320可被配置为使用所收集的存储器概要数据量来确定置信度。例如，可将已知的统计技术用于确定一组数据点与采用回归分析所生成的线性方程式的相关程度有多强。然而，可使用任何合适的统计技术。存储器使用概要分析器320可被配置为仅当预测高于指定的质量阈值时才发送“存储器不足”预测(或执行某种其他补救动作)。图5示出了根据本发明一个实施例、由存储器使用概要分析器320执行的用于生成存储器使用概要的方法500。方法500开始于步骤510并进行至步骤520。在步骤520中，在应用305执行的同时，虚拟机300对虚拟机环境中的存储器进行监视。例如，虚拟机300可被配置为监视在存储池325中剩余的空闲空间的量。在监视存储器使用的同时，在步骤530处，虚拟机300确定该空闲空间是否降到Mmax的预先规定的百分率之下。当这种情况发生时，虚拟机300触发由垃圾收集器315执行的垃圾收集循环。如上所述，垃圾收集器315检查由应用305所分配的存储对象并能回收或“释放”某些已分配的存储器，将其返还到存储池325。这样做有助于防止虚拟机300经历“存储器不足”异常。然而，在某些情况下，垃圾收集器315将不能够将已分配(但不再需要)的存储对象返还给虚拟机。例如，应用305之一可能具有“存储器泄漏”，其中，该应用305未能将其不再需要的存储器返还到存储池325。如果该应用305仍然引用所述已分配的存储器，垃圾收集器315不能将此存储器返还到存储池325。另外，如果该应用325继续分配存储对象，最终，该应用325会耗尽被分配给该虚拟机的全部存储器Mmax，而导致发生“存储器不足”异常。当存储器使用不高于Mmax的预先规定的百分比的时候，方法500保持在步骤520处。在步骤540中，一旦存储器使用高于此阈值，虚拟机300触发由垃圾收集器315执行的垃圾收集循环。在每一垃圾收集循环之后，存储器使用概要分析器320可确定从存储池325中分配给应用305的存储器的大小。如同这里所用的，这个存储量用变量“g”来表示。在垃圾收集循环完成后，“g”可被存储在表中，该表存储用于构建存储器使用概要的数据点。数据表的一个示例在图6中示出。在其他实施例中，存储器使用概要分析器320可被配置为在由垃圾收集器315执行的每一垃圾收集循环之前收集存储器使用概要数据。可选地，在步骤560处，通过在可从存储池325获得的存储器的总量即Mmax中减去已被分配的存储量即“g”，概要分析器320可计算存储池325中空闲存储器的量。此处将这个值用变量“am”(“可用存储器(availablememory)”的缩写)表示。在分配给虚拟机300的存储堆的大小可随时间变化的实施例中，“am”的值可能有用。否则，可不对每一垃圾收集循环计算“am”值，而代之以可在需要时从Mmax值和“g”值动态计算该值。如果已经计算，在步骤560处，概要分析器320将“am”的值记录在存储器使用概要表中。在完成垃圾收集循环并记录存储器使用数据后，该方法在步骤570处终止。图6示出了存储器概要数据表600的实施例。在表600中有几行所收集的存储器概要数据。每行6201-620n包含存储在表600的列中的多个数据元素。每一行6201-620n表示在垃圾收集器315所执行的垃圾收集循环期间所收集的存储器概要数据。列605包含虚拟机300触发垃圾收集器315以执行垃圾收集循环的时间。列610包含在每一垃圾收集循环之后正在被虚拟机所使用的存储器的量，即“g”值。如果已计算出，列615包含从存储池325可获得的空闲存储量，即“am”值。列615通过从Mmax中减去“g”计算得出。图7示出了根据本发明一个实施例、虚拟机中的存储器使用概要的图700。图700可从表6中的存储器概要数据值构建得出。作为示例，二维图700包含表示时间的横轴710以及表示存储器使用的纵轴705。在两轴之间为一实线，其表示虚拟机300的给定实例的存储器使用。通常，当虚拟机300的一个实例首先被启动且应用开始执行时，该应用可能迅速地从存储池325中分配存储器。这由实线755在初始化时期745的陡峭斜率示出。在初始化时期745之后，虚拟机300的存储器使用变得平稳起来。在某些情况下，虚拟机300和应用305可能从不会耗尽可从存储池325获取的全部存储器。然而，如果一应用305具有存储器泄漏，存储器使用可能逐渐增加，如图700中由线755在存储器泄漏时期750的逐渐向上的倾斜所示。当虚拟机300中的存储器使用达到Mmax的预先规定的百分率时，垃圾收集器315将执行垃圾收集循环并试图回收当前被分配给应用305的某些存储器。作为示例，垃圾收集器315的第一次运行发生在时刻“t1”。同时，被使用存储器的量“g1”725被记录在表600中。在时刻t2，垃圾收集器315执行第二次垃圾收集循环，且存储器使用概要分析器320收集概要数据点“g2”并将此值存储在表600中。在多个垃圾收集循环之后，存储器使用概要开始形成。如示出的那样，存储器使用概要由线755表示。在本示例中，虚拟机300正在经历存储器泄漏。存储器使用概要分析器320可使用在每一垃圾收集循环中所收集的数据点来确定虚拟机300未来的存储器使用。在该图中用虚线760绘出预期的存储器使用曲线。这表示虚拟机300被预测的存储器使用。由于虚拟机300可用的最大存储器是已知的(即Mmax740)，存储器使用概要可用于确定虚拟机300何时将经历“存储器不足”异常。也就是说，线755与表示Mmax740的水平线的交点为虚拟机将经历“存储器不足”异常的时间点。在该图中，该交点的时间用tfailure735示出。于是，“存储器不足”异常的这一预测时间tfailure735可以以如上所述的消息的形式发送给系统管理员。因此，本发明的实施例提供了预测何时可能发生“存储器不足”异常的方法。例如，可在由垃圾收集器所执行的每一垃圾收集循环期间收集存储器使用数据。使用如此收集的一组数据点，存储器使用概要分析器可确定存储器使用是平坦的、以恒定速率上升还是以指数速率上升。取决于存储器泄漏的严重性与所预测的增长率，可采取不同的补救动作。这样做使得系统管理员能够在必要时加以干预以防止正在进行的存储器泄漏打断系统的活动。同时，允许管理员集中在其他任务上，无需为检测任何此类存储器泄漏而不断地对垃圾收集环境下的存储器使用进行监视。尽管上述内容是关于本发明的实施例，在不脱离本发明基本范围的情况下，可做出其他的以及进一步的实施例。本发明的范围由所附权利要求书确定。权利要求1.一种用于管理垃圾收集计算环境中的存储器使用的、计算机实现的方法，包括在多个垃圾收集循环的每一循环期间，监视可从存储池获得的、由多个应用使用的存储量，其中，每一所述应用可动态地从所述存储池分配存储器和将存储器返还到所述存储池；基于所述监视到的、可从所述存储池获得的存储量生成存储器使用概要，其中，所述存储器使用概要表征在两个或两个以上的垃圾收集循环期间可从所述存储池获得的存储器的变化；以及基于所述存储器使用概要，预测是否可能发生存储器不足异常。2.如权利要求1所述的方法，其中，所述存储池由存储器管理器进行分配。3.如权利要求1所述的方法，进一步包括当可从所述存储池获得的存储器达到预先确定的量时，触发垃圾收集器过程以执行每一垃圾收集循环。4.如权利要求1所述的方法，其中，所述存储池包括存储堆。5.如权利要求1所述的方法，其中，垃圾收集计算环境包括虚拟机环境。6.如权利要求1所述的方法，进一步包括执行补救动作以防止所述预测到的存储器不足异常发生。7.如权利要求5所述的方法，其中，所述补救动作包括向系统管理员发送关于何时可能发生所述预测到的存储器不足异常的指示。8.如权利要求1所述的方法，其中，确定存储器使用概要包括基于从所述存储池分配的所述存储量来进行统计分析。9.如权利要求1所述的方法，进一步包括确定与关于是否可能发生存储器不足异常的所述预测相关联的置信度。10.一种计算机可读介质，该介质包括程序，该程序在被执行时执行前述方法权利要求的任何一个方法。11.一种被配置为管理垃圾收集计算环境中的存储器使用的计算装置，包括处理器；以及与所述处理器通信的存储器，所述存储器至少包括虚拟机程序，其中，所述虚拟机程序被配置为通过执行至少下列步骤来预测何时可能发生未来的存储器不足异常分配存储池以便由多个应用使用，其中，每一所述应用可动态地从所述存储池分配存储器并将存储器返还到所述存储池；当可从所述存储池获得的存储量达到预先确定的量时，触发垃圾收集器过程以执行垃圾收集循环；在每一垃圾收集循环期间，监视可从所述存储池获得的存储量；基于所述监视到的、可从所述存储池获得的存储量生成存储器使用概要，其中，所述存储器使用概要表征在两个或两个以上的垃圾收集循环期间可从所述存储池获得的存储器的变化；以及基于所述存储器使用概要，预测是否可能发生存储器不足异常。12.如权利要求11所述的方法，其中，所述操作进一步包括向系统管理员发送关于何时可能发生所述预测到的存储器不足异常的指示。13.如权利要求11所述的方法，其中，确定存储器使用概要包括基于从所述存储池分配的所述存储量来进行统计分析。14.如权利要求11所述的方法，其中，所述操作进一步包括确定与关于何时可能发生所述存储器不足异常的所述预测相关联的置信度。全文摘要公开了一种用于在垃圾收集环境中自动预测存储器不足异常的方法、制造物品和装置。一个实施例提供了一种用于预测存储器不足事件的方法，其包括在多个垃圾收集循环期间监视可从存储池获得的存储量。基于所监视的可获得的存储量，可生成存储器使用概要，并然后可将之用于预测是否可能发生存储器不足异常。文档编号G06F9/46GK1975696SQ20061011572公开日2007年6月6日申请日期2006年8月11日优先权日2005年11月30日发明者J·G·尼斯特勒,V·J·格罗斯申请人:国际商业机器公司