Arc*_*hie 6 java heap garbage-collection
我的简单目标:监视Java应用程序的内存使用情况,以便在应用程序危险地接近抛出时,可以收到警告OutOfMemoryError.
是的,简单说明,但提出正确的解决方案似乎非常复杂.一些复杂因素是:
OutOfMemoryError:
permgen空间,它有它自己的大小限制(通过设置-XX:MaxPermSize=)-Xmx)OutOfMemoryError.System.gc()保证VM将回收所有可能可回收的对象(未引用和/或弱引用的对象),那将是很好的,但事实并非如此.所以调用System.gc()然后Runtime.freeMemory()不可靠.那么回答这个问题的好方法是OutOfMemoryError什么呢?我的Java应用程序是否可以投入?
换句话说,假设应用程序版本X运行良好且没有内存泄漏,但版本X + 1具有缓慢的无法识别的内存泄漏.我希望在版本X + 1抛出之前通过此监视发出警报OutOfMemoryError,但我希望完全相同的监视不会给版本X带来误报.设置此监视可能需要一些调整 - 这没关系.
一个可能的答案可能是这样的结果:在GC运行之后,堆栈利用率在过去的N次"完整"GC运行中的最大值是多少?如果此值超过总分配内存的X%,则发出警报声.
这个想法是确定"应用程序内存使用"的简单数字,如百分比,甚至像LOW,MEDIUM或HIGH,然后监视此值.
该jstat命令给出了大量的相关资料,问题就沸腾它归结为一个简单的答案,并避免由于上面列出的复杂因素误报(或否定).
如果您观看长时间运行的应用程序的内存图(例如,使用像jconsole这样的工具收集),您将看到一个特征锯齿模式:内存使用率攀升,然后GC返回基线,然后它爬升再次.对于健康的应用程序,峰和谷是两条直线水平线.然而,对于泄漏的应用程序,基线攀升.这真的是你需要注意的:如果每个连续GC的效果都不如上一次,那么丹麦就会出现问题.