内存泄漏的产生原因:
- JVM内存过小;
- 程序不严谨,产生了过多的垃圾;
程序的体现:
- 内存中加载的数据量过于庞大,如一次从数据库中取出过多的数据。
- 集合类中有对对象的引用,使用完后未清空,使得JVM不能回收。
- 代码中存在死循环或循环产生过多重复的对象实体。
- 使用第三方软件中的BUG。
- 启动参数内存值设定的过小。
错误的提示:
解决方法:
1)增加JVM的内存大小
对于Tomcat容器,找到Tomcat在电脑中的安装目录,进入这个目录,然后进入bin目录中,在windows环境下找到bin目录中的catalina.bat,在linux环境下找到catalina.sh。
编辑catalina.bat文件,找到JAVA_OPTS(具体来说是set“JAVA_OPTS=%JAVA_OPTS% %LOGGING_MANAGER%”)这个选项的位置,这个参数是Java启动的时候,需要的启动参数。
也可以在操作系统的环境变量中对JAVA_OPTS进行设置,因为Tomcat在启动的时候,也会读取操作系统中环境变量的值,进行加载。
如果是修改了操作系统的环境变量,需要重启机器,再重启Tomcat,如果修改的是Tomcat的配置文件,需要将配置文件保存,然后重启Tomcat,设置就能生效了。
2)优化程序,释放垃圾
主要思路就是避免程序体现上出现的情况。避免死循环,防止一次载入太多的数据,提高程序健壮性及时释放。因此,从根本上解决Java内存溢出的唯一方法就是修改程序,及时地释放没用的对象,释放内存空间。
内存泄漏
指程序在申请内存之后,无法释放已申请的内存空间,一次内存泄漏危害可以忽略,但内存泄漏堆积后果很严重,无论多少内存,迟早会被占光。
在Java中,内存泄漏就是存在一些被分配的对象,这些对象有下面两个特点。
1)首先,这些对象是可达的,即在有向图中,存在通路可以与其相连;
2)其次,这些对象是无用的,即程序以后不会再使用这些对象。
如果对象满足这两个条件,这些对象就可以判定为Java中的内存泄漏,这些对象不会被GC回收,然而它却占用内存。
关于内存泄漏的处理页,就是提高程序的健壮性,因为内存泄漏是纯代码层面的问题。
内存溢出和内存泄漏的联系
内存泄漏最终会导致内存溢出。
相同点:都会导致应用程序运行出现问题,性能下降或者挂起。
不同点:
1)内存泄漏时导致内存溢出的原因之一,内存泄漏积累起来将导致内存溢出。
2)内存泄漏可以通过完善代码来避免,内存溢出可以通过调整配置来减少发生频率,但无法彻底避免。
一个Java内存泄漏的排查案例
某个业务系统在一段时间突然变慢,怀疑是因为出现内存泄漏问题导致的,于是踏上了排查之路。
确定频繁Full GC现象
首先通过“虚拟机经常状况工具:jps”找出正在运行的虚拟机进程,最主要是找出这个进程在本地虚拟机的唯一ID(LVMID,Local Virtual Machine Identifier),因为在后面的排查过程中都是需要这个LVMID来确定要监控的是哪一个虚拟机进程。
同时,对于本地虚拟机进程来说,LVMID与操作系统的进程ID(PID,Processor Identifier)是一致的,使用windows的任务管理器或Unix的ps命令也可以查询到虚拟机进程的LVMID。
jps命令格式为:jps [ options ] [ hostid ]
使用命令如下:
使用jps:jps -l
使用ps:
ps aux | grep tomat
找到你需要监控的ID(假设为20954),再利用“虚拟机统计信息监视工具:jstat”监视虚拟机各种运行状态信息。
jstat命令格式为:
jstat [ option vmid [interval[s|ms] [count]] ]
使用命令如下:jstat -gcutil 20954 1000
意思是每1000毫秒查询一次,一直查。gcutil的意思是已使用空间站总空间的百分比。
jstat执行结果
查询结果表明:这台服务器的新生代Eden区(E,表示Eden)使用了28.30%(最后)的空间,两个Survivor区(S0、S1,表示Survivor0、Survivor1)分别是0和8.93%,老年代(O,表示Old)使用了87.33%。程序运行以来共发生Minor GC(YGC,表示Young GC)101次,总耗时1.961秒,发生Full GC(FGC,表示Full GC)7次,Full GC总耗时3.022秒,总的耗时(GCT,表示GC Time)为4.983秒。
找出导致频繁Full GC的原因
分析方法通常有两种:
1)把堆dump下来再用MAT等工具进行分析,但dump堆要花较长的时间,并且文件巨大,再从服务器上拖回本地导入工具,这个过程有些折腾,不到万不得已最好别这么干。
2)更轻量级的在线分析,使用“Java内存影像工具:jmap”生成堆转储快照(一般称为headdump或dump文件)。
jmap命令格式:jmap [ option ] vmid
使用命令如下:jmap -histo:live 20954
存活对象
按照一位IT友的说法,数据不正常,十有八九就是泄露的。在我这个图上对象还是挺正常的。
我在网上找了一位博友的不正常数据,如下:
可以看出HashTable中的元素有5000多万,占用内存大约1.5G的样子。这肯定不正常。