对于内存泄露问题如果处理不当很容易造成down机尤其是应用服务器Java容器上出现内存泄漏经常给人一种天要塌下来的感觉。下面从四个方面来系统说一下内存泄露。1. 为什么会出现内训泄露问题编写java程序最为方便的地方就是我们不需要管理内存的分配和释放一切由jvm来进行处理当java对象不再被应用时等到Heap内存不够用时jvm会进行垃圾回收清除这些对象占用的Heap内存空间如果对象一直被应用jvm无法对其进行回收创建新的对象时无法从Heap中获取足够的内存分配给对象这时候就会导致内存溢出。而出现内存泄露的地方一般是不断的往容器中存放对象而容器没有相应的大小限制或清除机制。容易导致内存溢出。2. 内存泄漏的现象程序内存泄漏最基本的表现就是程序中得到一个OutOfMemoryError。在大多数情况下一个OutOfMemoryError是内存泄漏的标志。在《彻底搞懂内存泄露》这篇文章详细介绍了内存泄露的情况3. 发现内存泄漏3.1常用命令jstat -gc pid可以显示gc的信息查看gc的次数及时间。 其中最后五项分别是young gc的次数young gc的时间full gc的次数full gc的时间gc的总时间。jstat -gccapacity pid可以显示VM内存中三代young,old,perm对象的使用和占用大小 如PGCMN显示的是最小perm的内存使用量PGCMX显示的是perm的内存最大使用量 PGC是当前新生成的perm内存占用量PC是但前perm内存占用量。 其他的可以根据这个类推 OC是old内纯的占用量。jstat -gcutil pid统计gc信息统计。jstat -gcnew pid年轻代对象的信息。jstat -gcnewcapacity pid年轻代对象的信息及其占用量。3.2 一个Java内存泄漏的排查案例某个业务系统在一段时间突然变慢我们怀疑是因为出现内存泄露问题导致的于是踏上排查之路。1确定频繁Full GC现象首先通过“虚拟机进程状况工具jps”找出正在运行的虚拟机进程最主要是找出这个进程在本地虚拟机的唯一IDLVMIDLocal Virtual Machine Identifier因为在后面的排查过程中都是需要这个LVMID来确定要监控的是哪一个虚拟机进程。 同时对于本地虚拟机进程来说LVMID与操作系统的进程IDPIDProcess Identifier是一致的使用Windows的任务管理器或Unix的ps命令也可以查询到虚拟机进程的LVMID。jps命令格式为 jps [ options ] [ hostid ] 使用命令如下 使用jpsjps -l 使用psps 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%。程序运行以来共发生MinorGCYGC表示Young GC101次总耗时1.961秒发生Full GCFGC表示Full GC7次FullGC总耗时3.022秒总的耗时GCT表示GC Time为4.983秒。2找出导致频繁Full GC的原因分析方法通常有两种1把堆dump下来再用MAT等工具进行分析但dump堆要花较长的时间并且文件巨大再从服务器上拖回本地导入工具这个过程有些折腾不到万不得已最好别这么干。2更轻量级的在线分析使用“Java内存影像工具jmap”生成堆转储快照一般称为headdump或dump文件。jmap命令格式jmap [ option ] vmid使用命令如下jmap -histo:live 20954查看存活的对象情况如下图所示存活对象按照一位IT友的说法数据不正常十有八九就是泄露的。在我这个图上对象还是挺正常的。我在网上找了一位博友的不正常数据如下可以看出HashTable中的元素有5000多万占用内存大约1.5G的样子。这肯定不正常。3定位到代码定位带代码有很多种方法比如EclipseMAT的出现使这个问题变得非常简单。EclipseMAT是著名的SAP公司贡献的一个工具可以在Eclipse网站下载到它完全免费的。通过MAT查看Histogram即可找出是哪块代码。也可以使用BTrace。4 如何规避内存泄露问题好的编码实践可能会大大降低内存溢出的产生。1. 编码规范认真执行。找几个资深程序猿或者整个项目组讨论后写一个Java编码规范让项目组成员尽量遵守。一目了然的代码更容易定位问题当然也更能让人写出好的代码。2. 单元测试要覆盖所有分支与边界条件。不要拿某种情况不会出现做借口。有句老话说常在河边站哪有不湿鞋学名墨菲定律。3. 代码审查要走。代码写完了找资深程序猿扫扫代码没有坏处。4. 有条件的项目组要充分利用测试人员的能动性。5. 如果项目的期望较高就把上面的尽量、可能等词汇改成一定要。以上五条建议对非性命攸关型项目足够了。
对于内存泄露问题如果处理不当很容易造成down机尤其是应用服务器Java容器上出现内存泄漏经常给人一种天要塌下来的感觉。下面从四个方面来系统说一下内存泄露。1. 为什么会出现内训泄露问题编写java程序最为方便的地方就是我们不需要管理内存的分配和释放一切由jvm来进行处理当java对象不再被应用时等到Heap内存不够用时jvm会进行垃圾回收清除这些对象占用的Heap内存空间如果对象一直被应用jvm无法对其进行回收创建新的对象时无法从Heap中获取足够的内存分配给对象这时候就会导致内存溢出。而出现内存泄露的地方一般是不断的往容器中存放对象而容器没有相应的大小限制或清除机制。容易导致内存溢出。2. 内存泄漏的现象程序内存泄漏最基本的表现就是程序中得到一个OutOfMemoryError。在大多数情况下一个OutOfMemoryError是内存泄漏的标志。在《彻底搞懂内存泄露》这篇文章详细介绍了内存泄露的情况3. 发现内存泄漏3.1常用命令jstat -gc pid可以显示gc的信息查看gc的次数及时间。 其中最后五项分别是young gc的次数young gc的时间full gc的次数full gc的时间gc的总时间。jstat -gccapacity pid可以显示VM内存中三代young,old,perm对象的使用和占用大小 如PGCMN显示的是最小perm的内存使用量PGCMX显示的是perm的内存最大使用量 PGC是当前新生成的perm内存占用量PC是但前perm内存占用量。 其他的可以根据这个类推 OC是old内纯的占用量。jstat -gcutil pid统计gc信息统计。jstat -gcnew pid年轻代对象的信息。jstat -gcnewcapacity pid年轻代对象的信息及其占用量。3.2 一个Java内存泄漏的排查案例某个业务系统在一段时间突然变慢我们怀疑是因为出现内存泄露问题导致的于是踏上排查之路。1确定频繁Full GC现象首先通过“虚拟机进程状况工具jps”找出正在运行的虚拟机进程最主要是找出这个进程在本地虚拟机的唯一IDLVMIDLocal Virtual Machine Identifier因为在后面的排查过程中都是需要这个LVMID来确定要监控的是哪一个虚拟机进程。 同时对于本地虚拟机进程来说LVMID与操作系统的进程IDPIDProcess Identifier是一致的使用Windows的任务管理器或Unix的ps命令也可以查询到虚拟机进程的LVMID。jps命令格式为 jps [ options ] [ hostid ] 使用命令如下 使用jpsjps -l 使用psps 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%。程序运行以来共发生MinorGCYGC表示Young GC101次总耗时1.961秒发生Full GCFGC表示Full GC7次FullGC总耗时3.022秒总的耗时GCT表示GC Time为4.983秒。2找出导致频繁Full GC的原因分析方法通常有两种1把堆dump下来再用MAT等工具进行分析但dump堆要花较长的时间并且文件巨大再从服务器上拖回本地导入工具这个过程有些折腾不到万不得已最好别这么干。2更轻量级的在线分析使用“Java内存影像工具jmap”生成堆转储快照一般称为headdump或dump文件。jmap命令格式jmap [ option ] vmid使用命令如下jmap -histo:live 20954查看存活的对象情况如下图所示存活对象按照一位IT友的说法数据不正常十有八九就是泄露的。在我这个图上对象还是挺正常的。我在网上找了一位博友的不正常数据如下可以看出HashTable中的元素有5000多万占用内存大约1.5G的样子。这肯定不正常。3定位到代码定位带代码有很多种方法比如EclipseMAT的出现使这个问题变得非常简单。EclipseMAT是著名的SAP公司贡献的一个工具可以在Eclipse网站下载到它完全免费的。通过MAT查看Histogram即可找出是哪块代码。也可以使用BTrace。4 如何规避内存泄露问题好的编码实践可能会大大降低内存溢出的产生。1. 编码规范认真执行。找几个资深程序猿或者整个项目组讨论后写一个Java编码规范让项目组成员尽量遵守。一目了然的代码更容易定位问题当然也更能让人写出好的代码。2. 单元测试要覆盖所有分支与边界条件。不要拿某种情况不会出现做借口。有句老话说常在河边站哪有不湿鞋学名墨菲定律。3. 代码审查要走。代码写完了找资深程序猿扫扫代码没有坏处。4. 有条件的项目组要充分利用测试人员的能动性。5. 如果项目的期望较高就把上面的尽量、可能等词汇改成一定要。以上五条建议对非性命攸关型项目足够了。
