我的简单目标:监视
Java应用程序的内存使用情况,以便在应用程序危险地接近抛出OutOfMemoryError时收到警告.
是的,简单说明,但提出正确的解决方案似乎非常复杂.一些复杂因素是:
>有不同的堆区域,每个堆区域都可以抛出OutOfMemoryError:
> permgen空间,它有自己的大小限制(通过-XX:MaxPermSize =设置)
>整个堆空间(通过-Xmx设置)
>在烦扰垃圾收集之前,VM可能会分配几乎所有的堆.如果应用程序使用了很多软引用,那么事实上肯定会发生这种情况.因此,只有高堆分配百分比并不意味着应用程序接近抛出OutOfMemoryError.
>如果System.gc()保证VM将回收所有可能可回收的对象(未引用和/或弱引用的对象),那将是很好的,但事实并非如此.因此调用System.gc()然后调用Runtime.freeMemory()是不可靠的.
>排队等待最终确定的对象占用内存,但(通常)在完成后将被释放.那么终结器线程是否已经到达它们会影响(明显的)内存使用量(在抛出OOM之前,VM是否将终结器作为最后一个绝对的行为运行?Doesn’t look like it.)
>本机代码也会占用内存,过多使用它会导致OOM(在我的特定应用程序中这不是一个可能的情况,但确实会给整个图片增加另一个复杂性).
那么回答这个问题的好方法是什么呢?我的Java应用程序是否会抛出OutOfMemoryError?
换句话说,假设应用程序版本X运行良好并且没有内存泄漏,但是版本X 1具有缓慢的无法识别的内存泄漏.我希望在版本X 1抛出OutOfMemoryError之前通过此监视提醒您,但我希望完全相同的监视不会给版本X带来误报.设置此监视可能需要一些调整 – 这没关系.
一个可能的答案可能是这样的结果:在GC运行之后,堆栈利用率在过去的N次“完整”GC运行中的最大值是多少?如果此值超过总分配内存的X%,则发出警报声.
这个想法是确定“应用程序内存使用”的简单数字,如百分比,甚至像LOW,MEDIUM或HIGH,然后监视此值.
jstat命令提供了大量相关信息,问题是将其归结为一个简单的答案,并避免由上面列出的复杂因素引起的误报(或否定).