商务网站建设的一般流程是什么意思,经典广告语,龙华网站优化,定制开发app软件报价单转载自 一次恐怖的 Java 内存泄漏排查实战
最近在看《深入理解Java虚拟机#xff1a;JVM高级特性与最佳实践》#xff08;第二版#xff09;这本书#xff0c;理论实践结合#xff0c;深入浅出#xff0c;强烈推荐给大家。
这两天对JVM内容进行了一个讨论#xff0c;…转载自 一次恐怖的 Java 内存泄漏排查实战
最近在看《深入理解Java虚拟机JVM高级特性与最佳实践》第二版这本书理论实践结合深入浅出强烈推荐给大家。
这两天对JVM内容进行了一个讨论讨论的内容主要包括如下几个方面。 1内存溢出和内存泄露的介绍 2如何排查和处理内存泄露 一、内存溢出和内存泄露
一种通俗的说法。 1、内存溢出你申请了10个字节的空间但是你在这个空间写入11或以上字节的数据出现溢出。 2、内存泄漏你用new申请了一块内存后来很长时间都不再使用了按理应该释放但是因为一直被某个或某些实例所持有导致 GC 不能回收也就是该被释放的对象没有释放。点击此处查看内存泄漏更多说明。 下面具体介绍。
1.1 内存溢出
java.lang.OutOfMemoryError是指程序在申请内存时没有足够的内存空间供其使用出现OutOfMemoryError。点击此处查看内存泄漏更多说明。
产生原因 产生该错误的原因主要包括 JVM内存过小。 程序不严密产生了过多的垃圾。
程序体现 一般情况下在程序上的体现为 内存中加载的数据量过于庞大如一次从数据库取出过多数据。 集合类中有对对象的引用使用完后未清空使得JVM不能回收。 代码中存在死循环或循环产生过多重复的对象实体。 使用的第三方软件中的BUG。 启动参数内存值设定的过小。
错误提示 此错误常见的错误提示
tomcat:java.lang.OutOfMemoryError: PermGen space
tomcat:java.lang.OutOfMemoryError: Java heap space
weblogic:Root cause of ServletException java.lang.OutOfMemoryError
resin:java.lang.OutOfMemoryError
java:java.lang.OutOfMemoryError 解决方法
1增加JVM的内存大小 对于tomcat容器找到tomcat在电脑中的安装目录进入这个目录然后进入bin目录中在window环境下找到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内存溢出的唯一方法就是修改程序及时地释放没用的对象释放内存空间。 1.2 内存泄露
Memory Leak是指程序在申请内存后无法释放已申请的内存空间一次内存泄露危害可以忽略但内存泄露堆积后果很严重无论多少内存迟早会被占光。 在Java中内存泄漏就是存在一些被分配的对象这些对象有下面两个特点。 1首先这些对象是可达的即在有向图中存在通路可以与其相连 2其次这些对象是无用的即程序以后不会再使用这些对象。 如果对象满足这两个条件这些对象就可以判定为Java中的内存泄漏这些对象不会被GC所回收然而它却占用内存。
关于内存泄露的处理页就是提高程序的健壮型因为内存泄露是纯代码层面的问题。点击此处查看内存泄漏更多说明。 1.3 内存溢出和内存泄露的联系
内存泄露会最终会导致内存溢出。
相同点都会导致应用程序运行出现问题性能下降或挂起。 不同点1) 内存泄露是导致内存溢出的原因之一内存泄露积累起来将导致内存溢出。2) 内存泄露可以通过完善代码来避免内存溢出可以通过调整配置来减少发生频率但无法彻底避免。 二、一个Java内存泄漏的排查案例
某个业务系统在一段时间突然变慢我们怀疑是因为出现内存泄露问题导致的于是踏上排查之路。
2.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%。程序运行以来共发生Minor GCYGC表示Young GC101次总耗时1.961秒发生Full GCFGC表示Full GC7次Full GC总耗时3.022秒总的耗时GCT表示GC Time为4.983秒。 2.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的样子。这肯定不正常。 2.3 定位到代码
定位带代码有很多种方法比如前面提到的通过MAT查看Histogram即可找出是哪块代码。——我以前是使用这个方法。也可以使用BTrace我没有使用过。
