OutOfMemoryError异常总结
来源:互联网 发布:caffe实现fcn 编辑:程序博客网 时间:2024/06/15 00:32
java.lang.OutOfMemoryError这个错产生的原因大都出于以下原因:JVM内存过小、程序不严密,产生了过多的垃圾。
导致OutOfMemoryError异常的常见的原因有以下几种:
(1)内存中加载的数据量过于庞大,如一次性从数据库中取出过多的数据;
(2)集合类中有对对象的引用,使用完之后未清空,使得JVM不能回收;
(3)代码中存在死循环或循环产生过多重复的对象实体;
(4)使用的第三方软件中的BUG;
(5)启动参数内衬值设定的过小;
此错误常见的错误提示:
(1)tomcat:java.lang.OutOfMemoryError:PermGen space
(2)tomcat:java.OutOfMemoryError:java heap space
(3)weblogic:Root cause of ServletException java.lang.OutOfMemoryError
(4)resin:java.lang.OutOfMemoryError
(5)java:java.lang.OutOfMemoryError
解决java.lang.OutOfMemoryError的方法如下:
一、增加jvm的内存大小。
方法有:
1)在执行某个class文件时候,可以使用java -Xmx256M aa.class来设置运行aa.class时jvm所允许占用的最大内存为256M。
2)对tomcat容器,可以在启动时对jvm设置内存限度。对tomcat,可以在catalina.bat中添加:
set CATALINA_OPTS=-Xms128M -Xmx256Mset JAVA_OPTS=-Xms128M -Xmx256M
或者把%CATALINA_OPTS%和%JAVA_OPTS%代替为-Xms128M -Xmx256M
3)对resin容器,同样可以在启动时对jvm设置内存限度。在bin文件夹下创建一个startup.bat文件,内容如下:
@echo offcall "httpd.exe" "-Xms128M" "-Xmx256M":end其中"-Xms128M"为最小内存,"-Xmx256M"为最大内存。
二、优化程序,释放垃圾。
主要包括避免死循环,应该及时释放种资源:内存, 数据库的各种连接,防止一次载入太多的数据。导致java.lang.OutOfMemoryError的根本原因是程序不健壮。因此,从根本上解决Java内存溢出的唯一方法就是修改程序,及时地释放没用的对象,释放内存空间。 遇到该错误的时候要仔细检查程序,嘿嘿,遇多一次这种问题之后,以后写程序就会小心多了。
Java代码导致OutOfMemoryError错误的解决:
需要重点排查以下几点:
- 检查代码中是否有死循环或递归调用。
- 检查是否有大循环重复产生新对象实体。
- 检查对数据库查询中,是否有一次获得全部数据的查询。一般来说,如果一次取十万条记录到内存,就可能引起内存溢出。这个问题比较隐蔽,在上线前,数据库中数据较少,不容易出问题,上线后,数据库中数据多了,一次查询就有可能引起内存溢出。因此对于数据库查询尽量采用分页的方式查询。
- 检查List、MAP等集合对象是否有使用完后,未清除的问题。List、MAP等集合对象会始终存有对对象的引用,使得这些对象不能被GC回收。
tomcat中java.lang.OutOfMemoryError: PermGen space异常处理
PermGen space的全称是Permanent Generation space,是指内存的永久保存区域,这块内存主要是被JVM存放Class和Meta信息的,Class在被Loader时就会被放到PermGen space中,它和存放类实例(Instance)的Heap区域不同,GC(Garbage Collection)不会在主程序运行期对PermGen space进行清理,所以如果你的应用中有很多CLASS的话,就很可能出现PermGen space错误,这种错误常见在web服务器对JSP进行pre compile的时候。如果你的WEB APP下都用了大量的第三方jar, 其大小超过了jvm默认的大小(4M)那么就会产生此错误信息了。解决方法: 手动设置MaxPermSize大小修改TOMCAT_HOME/bin/catalina.sh在
echo "Using CATALINA_BASE: $CATALINA_BASE"
上面加入以下行:
JAVA_OPTS="-server -XX:PermSize=64M -XX:MaxPermSize=128m
建议:将相同的第三方jar文件移置到tomcat/shared/lib目录下,这样可以达到减少jar 文档重复占用内存的目的。
weblogic中java.lang.OutOfMemoryError异常处理
错误提示: Root cause of ervletException java.lang.OutOfMemoryError
解决办法:调整bea/weblogic/common中CommEnv中参数
:sun if "%PRODUCTION_MODE%" == "true" goto sun_prod_mode set JAVA_VM=-client set MEM_ARGS=-Xms256m -Xmx512m -XX:MaxPermSize=256m set JAVA_OPTIONS=%JAVA_OPTIONS% -Xverify:none goto continue :sun_prod_mode set JAVA_VM=-server set MEM_ARGS=-Xms256m -Xmx512m -XX:MaxPermSize=256m goto continue
Resin下java.lang.OutOfMemoryError异常处理
产生内存溢出的原因:
出现这个错误,一般是因为JVM物理内存过小。默认的Java虚拟机最大内存仅为64兆,这在开发调试过程中可能没有问题,但在实际的应用环境中是远远不能满足需要的,除非你的应用非常小,也没什么访问量。否则你可能会发现程序运行一段时间后包java.lang.OutOfMemoryError的错误。因此我们需要提升resin可用的虚拟机内存的大小。
解决方法:
修改/usr/local/resin/bin/httpd.sh中的args选项添加参数-Xms
(初始内存)和-Xmx
(最大能够使用内存大小)可以用来限制JVM的物理内存使用量。例如:
args="-Xms128m -Xmx256m"
设置后,JVM初始物理内存是128m,最大能使用物理内存为256m。
这两个值应该由系统管理员根据服务器的实际情况进行设置。
JVM内存区域中,除了程序计数器外,其他几个运行时区域都有可能发生OutOfMemoryError(OOM)异常。本文对OOM异常进行总结,通过代码验证JVM规范中描述的运行时区域存储的内容;了解可能导致这些区域OOM异常的代码,能够在工作中根据异常代码对内存哪一出区域进行定位。
基于Sun的HotSpot虚拟机,在Eclipse中Run/Arguments中可以进行虚拟机启动参数的设置,这些参数对实验结果有直接影响,不能忽略。
Java堆溢出
Java堆用于存储对象实例,只要不断地创建对象,并且保证GC Roots到对象之间有可达路径来避免垃圾回收机制清除这些对象,对象数量达到最大堆容量限制,则发生溢出。
限制Java堆的大小为20MB,最小值和最大值相同(不可扩展)。当虚拟机出现内存溢出异常时Dump出当前的内存堆转储快照以便事后分析。
package com.jvm.OutOfMemoryError;import java.util.List;import java.util.ArrayList;/** * Java堆溢出 * VM Args:-Xms20m -Xmx20m -XX:+HeapDumpOnOutOfMemoryError */public class HeapOOM { public static void main(String[] args) { List<OOMObject> list = new ArrayList<OOMObject>(); while(true) { // list保留引用,避免Full GC 回收 list.add(new OOMObject()); } } static class OOMObject { }}
运行结果:
java.lang.OutOfMemoryError: Java heap spaceDumping heap to java_pid7768.hprof ...Heap dump file created [27987840 bytes in 0.142 secs]
这种异常比较常见,一般先通过内存映像分析工具(如Eclipse Memory Analyzer)对Dump出来的堆转储快照进行分析,确实是内存泄露还是内存溢出。
- 内存泄露 查看泄露对象到GC Roots的引用链,定位泄露代码位置。
- 内存溢出 如果不存在泄露,即内存中的对象确实都还必须活着,检查JVM堆参数(-Xmx与-Xms),调大参数,检查代码是否存在某些对象生命周期过长,持有状态过长的情况,减少程序运行期的内存消耗。
虚拟机栈和本地方法栈溢出
HotSpot不区分虚拟机栈和本地方法栈,栈容量只能由-Xss参数设定。
- StackOverFlow:线程申请的栈深度超过允许的最大深度
- OutOfMemoryError: 虚拟机扩展时无法申请到足够的内存空间
StackOverFlow的情况:递归调用方法,定义大量的本地变量,增大此方法帧中本地变量表的长度。
package com.jvm.OutOfMemoryError;/** * 虚拟机栈和本地方法栈溢出 StackOverFlow * VM Args:-Xss128k */public class JavaVMStackSOF { private int stackLength = 1; // 递归调用方法,定义大量的本地变量,增大此方法帧中本地变量表的长度 public void stackLeak() { stackLength++; stackLeak(); } public static void main(String[] args) { JavaVMStackSOF oom = new JavaVMStackSOF(); try { oom.stackLeak(); } catch (Throwable e) { System.out.println("stack length: " + oom.stackLength); throw e; } }}
运行结果:
stack length: 999Exception in thread "main" java.lang.StackOverflowError at com.jvm.OutOfMemoryError.JavaVMStackSOF.stackLeak(JavaVMStackSOF.java:26) at com.jvm.OutOfMemoryError.JavaVMStackSOF.stackLeak(JavaVMStackSOF.java:26) at com.jvm.OutOfMemoryError.JavaVMStackSOF.stackLeak(JavaVMStackSOF.java:26)
OutOfMemoryError:多线程下的内存溢出,与栈空间是否足够大并不存在任何联系。为每个线程的栈分配的内存越大(参数-Xss),那么可以建立的线程数量就越少,建立线程时就越容易把剩下的内存耗尽,越容易内存溢出。在这种情况下,如果不能减少线程数目或者更换64位虚拟机时,减少最大堆和减少栈容量能够换区更多的线程。
注意:Windows平台虚拟机中,Java的线程映射到操作系统的内核线程上执行,下面代码执行可能造成系统假死!
package com.jvm.OutOfMemoryError;/** * 虚拟机栈和本地方法栈溢出 * * !!!!!注意!!!!! * 运行该代码可能造成系统假死!!!! * * VM Args:-Xss2M(可以适当大一点) */public class JavaVMStackOOM { private void dontStop() { while(true) { } } // 多线程方式造成栈内存溢出 OutOfMemoryError public void stackLeakByThread() { while(true) { Thread thread = new Thread(new Runnable() { @Override public void run() { dontStop(); } }); thread.start(); } } public static void main(String[] args) { JavaVMStackOOM oom = new JavaVMStackOOM(); oom.stackLeakByThread(); }}
方法区和运行常量池溢出
运行时常量池
JDK1.7开始逐步“去永久代”,下面的讨论可以测试下实际影响。
String.intern()是一个Native方法,它的作用是:如果运行时常量池中已经包含一个等于此String对象内容的字符串,则返回常量池中该字符串的引用;如果没有,则在常量池中创建与此String内容相同的字符串,并返回常量池中创建的字符串的引用。JDK7的intern()方法的实现有所不同,当常量池中没有该字符串时,不再是在常量池中创建与此String内容相同的字符串,而改为在常量池中记录堆中首次出现的该字符串的引用,并返回该引用。
在JDK1.6之前,常量池分配在永久代,以下代码在JDK1.6下运行才回发生内存溢出,如果在JDK1.7及其之后的版本运行,则是死循环:
package com.jvm.OutOfMemoryError;import java.util.ArrayList;import java.util.List;/** * 运行时常量池溢出 * * jdk1.7 及其以后的版本已经“去永久代”,jdk1.6之前的环境下运行才会出现溢出 * -XX:PermSize=10M -XX:MaxPermSize=10M (间接指定常量池容量大小) */public class RuntimeConstantPoolOOM { public static void main(String[] args) { List<String> list = new ArrayList<String>(); int i = 0; while(true) { // list保留引用,避免Full GC 回收 list.add(String.valueOf(i++).intern()); } }}
运行结果:
Exception in thread "main" java.lang.OutOfMemoryError: PermGen space at java.lang.String.intern(Native Method) ......
方法区
方法区用于存放Class的相关信息,如果运行时产生大量的类去填满方法区,就可能发生方法区的内存溢出。 例如主流框架spring、hibernate对大量的类进行增强时,利用CGLib字节码生成动态类;大量JSP或动态JSP(JSP第一次运行时需要编译为Java类)。
下面为CGLib动态生成类导致的方法区溢出:
package com.jvm.OutOfMemoryError;import java.lang.reflect.Method;import com.jvm.OutOfMemoryError.HeapOOM.OOMObject;import net.sf.cglib.proxy.Enhancer;import net.sf.cglib.proxy.MethodInterceptor;import net.sf.cglib.proxy.MethodProxy;/** * 方法区溢出 * -XX:PermSize=10M -XX:MaxPermSize=10M */public class JavaMethodAreaOOM { public static void main(String[] args) { while(true) { Enhancer enhancer = new Enhancer(); enhancer.setSuperclass(OOMObject.class); enhancer.setUseCache(false); enhancer.setCallback(new MethodInterceptor() { @Override public Object intercept(Object obj, Method m, Object[] objs, MethodProxy proxy) throws Throwable { // TODO Auto-generated method stub return proxy.invokeSuper(obj, objs); } }); enhancer.create(); } }}
运行结果:
Caused by: java.lang.OutOfMemoryError: PermGen space at java.lang.ClassLoader.defineClass1(Native Method) ......
本地直接内存溢出
Java虚拟机可以通过参数-XX:MaxDirectMemorySize设定本机直接内存可用大小,如果不指定,则默认与java堆内存大小相同。JDK中可以通过反射获取Unsafe类(Unsafe的getUnsafe()方法只有启动类加载器Bootstrap才能返回实例)直接操作本机直接内存。通过使用-XX:MaxDirectMemorySize=10M,限制最大可使用的本机直接内存大小为10MB。
import java.lang.reflect.Field;public class DirectMemoryOOM { private static final int _1MB = 1024 * 1024 * 1024; public static void main(String[] args) throws Exception { Field unsafeField = Unsafe . class .getDeclaredFields()[0]; unsafeField.setAccessible( true ); Unsafe unsafe = ( Unsafe ) unsafeField.get( null ); while ( true ) { // unsafe 直接想操作系统申请内存 unsafe.allocateMemory( _1MB ); } }}
运行结果:
Exception in thread "main" java.lang.OutOfMemoryError at sun.misc.Unsafe.allocateMemory(Native Method) ......
这种异常的明显特征是在Heap Dump文件中看不见明显的异常。如果OOM之后Dump的文件比较小,程序中直接或间接用到了IO/NIO,可以考虑是否是这方面的原因。
参考
1、周志明,深入理解Java虚拟机:JVM高级特性与最佳实践,机械工业出版社
更多参考:http://blog.csdn.net/u011080472/article/details/51322119
【深入理解JVM】:OutOfMemoryError异常总结
- OutOfMemoryError异常总结
- OutOfMemoryError异常总结
- java中OutOfMemoryError异常总结
- java.lang.OutOfMemoryError异常处理总结
- 【深入理解JVM】:OutOfMemoryError异常总结
- OutOfMemoryError异常
- OutOfMemoryError异常
- OutOfMemoryError异常
- OutOfMemoryError异常
- OutOfMemoryError总结
- OutOfMemoryError异常 (笔记)
- 虚拟机堆OutOfMemoryError异常
- tomcat异常OutOfMemoryError
- JVM OutOfMemoryError异常
- JVM > OutOfMemoryError异常
- 实战:OutOfMemoryError 异常
- OutOfMemoryError异常实战
- OutOfMemoryError异常实例
- 添加ppa源后导致update无法下载
- 网易2017 跳石板问题
- ionic3框架开发之-SRM移动应用之通讯录开发
- Android根据byte数组,生成图片,图片名字以当前时间作为名字
- Nginx配置SSI
- OutOfMemoryError异常总结
- 2017 Multi-University Training Contest
- php接口接收json数据
- nodejs+mongoose连
- 单例模式
- 关于radio 单选框在项目中的一些心得
- leetcode10
- 超绚丽的HTML5地图分布动画
- 一个简易的“返回顶部”页面效果