java程序中监控内存解决OutOfMemoryError: GC overhead limit exceeded

最近linux跑scala程序,内存占用较大时会出现gc错误。目前程序上没有可以优化的部分,可能是jvm参数设置不当,明天试试下面的方法。在程序中监控一下freememory是否足够。
Runtime监控项目内存使用情况

下面这篇解释得也比较好
Runtime类中的freeMemory,totalMemory,maxMemory方法,查看内存情况

最近在网上看到一些人讨论到java.lang.Runtime类中的freeMemory(),totalMemory(),maxMemory ()这几个方法的一些题目,很多人感到很迷惑,为什么,在java程序刚刚启动起来的时候freeMemory()这个方法返回的只有一两兆字节,而随着 java程序往前运行,创建了不少的对象,freeMemory()这个方法的返回有时候不但没有减少,反而会增加。这些人对freeMemory()这 个方法的意义应该有一些误解,他们以为这个方法返回的是操纵系统的剩余可用内存,实在根本就不是这样的。这三个方法反映的都是java这个进程的内存情 况,跟操纵系统的内存根本没有关系。下面结合totalMemory(),maxMemory()一起来解释。
maxMemory()这个方法返回的是java虚拟机(这个进程)能构从操纵系统那里挖到的最大的内存,以字节为单位,假如在运行java程 序的时 候,没有添加-Xmx参数,那么就是64兆,也就是说maxMemory()返回的大约是6410241024字节,这是java虚拟机默认情况下能 从操纵系统那里挖到的最大的内存。假如添加了-Xmx参数,将以这个参数后面的值为准,例如java -cp ClassPath -Xmx512m ClassName,那么最大内存就是51210240124字节。

totalMemory()这个方法返回的是java虚拟机现在已经从操纵系统那里挖过来的内存大小,也就是java虚拟机这个进程当时所占用的 所有 内存。假如在运行java的时候没有添加-Xms参数,那么,在java程序运行的过程的,内存总是慢慢的从操纵系统那里挖的,基本上是用多少挖多少,直 挖到maxMemory()为止,所以totalMemory()是慢慢增大的。假如用了-Xms参数,程序在启动的时候就会无条件的从操纵系统中挖- Xms后面定义的内存数,然后在这些内存用的差未几的时候,再往挖。

freeMemory()是什么呢,刚才讲到假如在运行java的时候没有添加-Xms参数,那么,在java程序运行的过程的,内存总是慢慢的 从操 作系统那里挖的,基本上是用多少挖多少,但是java虚拟机100%的情况下是会稍微多挖一点的,这些挖过来而又没有用上的内存,实际上就是 freeMemory(),所以freeMemory()的值一般情况下都是很小的,但是假如你在运行java程序的时候使用了-Xms,这个时候由于程 序在启动的时候就会无条件的从操纵系统中挖-Xms后面定义的内存数,这个时候,挖过来的内存可能大部分没用上,所以这个时候freeMemory()可 能会有些大。

所以运行java -jar时一定要设置Xms和Xmx参数。要牢记程序使用内存

解决方法:
目前想到的是,只能设置好一定的Xms和Xmx,在设置的时候要检查这个值得小于“系统”free内存,然后通过Runtime在程序中定时检查“jvm” free内存,free内存不足时输出已用内存,下次运行程序再往大调。


你可能感兴趣的:(java程序中监控内存解决OutOfMemoryError: GC overhead limit exceeded)