如何判断java应用程序是否接近内存不足

Arc*_*hie 6 java heap garbage-collection

我的简单目标:监视Java应用程序的内存使用情况,以便在应用程序危险地接近抛出时,可以收到警告OutOfMemoryError.

是的,简单说明,但提出正确的解决方案似乎非常复杂.一些复杂因素是:

  • 有不同的堆区域,每个区域都可以抛出OutOfMemoryError:
    • permgen空间,它有它自己的大小限制(通过设置-XX:MaxPermSize=)
    • 整个堆空间(设置为-Xmx)
  • 在烦扰垃圾收集之前,VM可能会分配几乎所有堆.如果应用程序使用了很多软引用,那么事实上肯定会发生这种情况.因此,只有高堆分配百分比并不意味着应用程序接近投掷OutOfMemoryError.
  • 如果System.gc()保证VM将回收所有可能可回收的对象(未引用和/或弱引用的对象),那将是很好的,但事实并非如此.所以调用System.gc()然后Runtime.freeMemory()不可靠.
  • 排队等待最终确定的对象占用内存,但(通常)在完成后将被释放.那么终结器线程是否已经到达它们会影响(明显的)内存使用量(在抛出OOM之前,VM是否将终结器作为最后一个绝对的行为运行?看起来不像它.)
  • 本机代码也会占用内存,过多使用它会导致OOM(在我的特定应用程序中这不是一个可能的情况,但确实会给整个图片增加另一个复杂性).

那么回答这个问题的好方法OutOfMemoryError什么呢?我的Java应用程序是否可以投入?

换句话说,假设应用程序版本X运行良好且没有内存泄漏,但版本X + 1具有缓慢的无法识别的内存泄漏.我希望在版本X + 1抛出之前通过此监视发出警报OutOfMemoryError,但我希望完全相同的监视不会给版本X带来误报.设置此监视可能需要一些调整 - 这没关系.

一个可能的答案可能是这样的结果:在GC运行之后,堆栈利用率在过去的N次"完整"GC运行中的最大值是多少?如果此值超过总分配内存的X%,则发出警报声.

这个想法是确定"应用程序内存使用"的简单数字,如百分比,甚至像LOW,MEDIUM或HIGH,然后监视此值.

jstat命令给出了大量的相关资料,问题就沸腾它归结为一个简单的答案,并避免由于上面列出的复杂因素误报(或否定).

Ern*_*ill 6

如果您观看长时间运行的应用程序的内存图(例如,使用像jconsole这样的工具收集),您将看到一个特征锯齿模式:内存使用率攀升,然后GC返回基线,然后它爬升再次.对于健康的应用程序,峰和谷是两条直线水平线.然而,对于泄漏的应用程序,基线攀升.这真的是你需要注意的:如果每个连续GC的效果都不如上一次,那么丹麦就会出现问题.