java.lang.OutOfMemoryError异常解决方法

java.lang.OutOfMemoryError异常解决方法

 

 

 

原因：
常见的有以下几种：

 

1.内存中加载的数据量过于庞大，如一次从数据库取出过多数据；

 

2.集合类中有对对象的引用，使用完后未清空，使得JVM不能回收；

 

3.代码中存在死循环或循环产生过多重复的对象实体；

 

4.使用的第三方软件中的BUG；

 

5.启动参数内存值设定的过小；

6.加载太多资源到内存，导致GC耗时较多

 

常见错误提示：
1.tomcat:java.lang.OutOfMemoryError: PermGen space

 

2.tomcat:java.lang.OutOfMemoryError: Java heap space

 

3.weblogic:Root cause of ServletException java.lang.OutOfMemoryError

 

4.resin:java.lang.OutOfMemoryError

 

5.java:java.lang.OutOfMemoryError

6.java.lang.OutOfMemoryError：GC overhead limit exceeded

解决；

1.应用服务器提示错误的解决：
把启动参数内存值设置足够大。

2.Java代码导致错误的解决：

重点排查以下几点：

1)检查代码中是否有死循环或递归调用。

2)检查是否有大循环重复产生新对象实体。

3)检查对数据库查询中，是否有一次获得全部数据的查询。一般来说，如果一次取十万条记录到内存，就可能引起内存溢出。这个问题比较隐蔽，在上线前，数据库中数据较少，不容易出问题，上线后，数据库中数据多了，一次查询就有可能引起内存溢出。因此对于数据库查询尽量采用分页的方式查询。

4 )检查List、MAP等集合对象是否有使用完后，未清除的问题。List、MAP等集合对象会始终存有对对象的引用，使得这些对象不能被GC回收。

 

案例：
1.hibernate查询数据时，一次查询过多的数据，后来调整了该部分的代码，每次只取出指定量的数据，成功的解决该问题。
2.在做压力测试时，出现OutOfMemoryError，发现session的资源一直没有被释放产生的，最好通过session的invalidate()方法将session的资源释放。
3.程序中出现死循环。
4.tomcat部署、运行出现OutOfMemoryError，加大内存参数值，解决此问题。

 

tomcat中java.lang.OutOfMemoryError: Java heap space异常处理

 

一、Heap size 
JVM堆的设置是指java程序运行过程中JVM可以调配使用的内存空间的设置.JVM在启动的时候会自动设置Heap size的值，
其初始空间(即-Xms)是物理内存的1/64，最大空间(-Xmx)是物理内存的1/4。可以利用JVM提供的-Xmn -Xms -Xmx等选项可
进行设置。Heap size 的大小是Young Generation 和Tenured Generaion 之和。
提示：在JVM中如果98％的时间是用于GC且可用的Heap size 不足2％的时候将抛出此异常信息。
提示：Heap Size 最大不要超过可用物理内存的80％，一般的要将-Xms和-Xmx选项设置为相同，而-Xmn为1/4的-Xmx值。

二、解决：手动设置Heap size

修改TOMCAT_HOME/bin/catalina.sh
在“echo "Using CATALINA_BASE:   $CATALINA_BASE"”上面加入以下行：
JAVA_OPTS="-server -Xms800m -Xmx800m   -XX:MaxNewSize=256m"

tomcat中java.lang.OutOfMemoryError: PermGen space异常处理

 

一、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

 

Eclipse运行Jboss时java.lang.OutOfMemoryError：PermGen space异常处理

在Eclipse中运行Jboss时，时间太长可能有时候会出现java.lang.OutOfMemoryError：PermGen space的错误，这里给介绍大家一种解决方法：

1)点击debug图标旁边的小箭头；

2)点击”Debug Configurations…”菜单项；

3)选左边的“Generic Server”树下面的“JBoss v4.2 at localhost”；

4)点击右边的“Arguments”Tab页签，在“VM arguments”中添加：

-Dprogram.name=run.bat -Djava.endorsed.dirs="D:/JBoss405/bin/../lib/endorsed" -Xms128m -Xmx512m -XX:PermSize=64m -XX:MaxPermSize=256m

5)如果你是以命令行模式或者直接点击“run.bat”来运行JBoss，那你就要在 bin/run.conf 文件中对JVM选项作修改了，找到 JAVA_OPTS="-Xms128m -Xmx512m…” 这一段，然后在后面加上 “ -XX:PermSize=64m -XX:MaxPermSize=256m”。保存就OK了。

6)注意：其中128、512、64和256等数字可以根据自己机器的配置来做一些相应的调整，然后点击“Apply”就可以了。

 

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。
这两个值应该由系统管理员根据服务器的实际情况进行设置。

 

java.lang.OutOfMemoryError：GC overhead limit exceeded异常处理

原因：

java.lang.OutOfMemoryError：GC overhead limit exceeded导致服务起不来，查看日志发现加载了太多资源到内存，本地的性能也不好，gc时间消耗的较多。

OOM大家都知道，就是JVM内存溢出了，那GC overhead limit exceed呢？

GC overhead limt exceed检查是Hotspot VM 1.6定义的一个策略，通过统计GC时间来预测是否要OOM了，提前抛出异常，防止OOM发生。Sun 官方对此的定义是：“并行/并发回收器在GC回收时间过长时会抛出OutOfMemroyError。过长的定义是，超过98%的时间用来做GC并且回收了不到2%的堆内存。用来避免内存过小造成应用不能正常工作。“

听起来没啥用...预测OOM有啥用？起初开来这玩意只能用来Catch住释放内存资源，避免应用挂掉。后来发现一般情况下这个策略不能拯救你的应用，但是可以在应用挂掉之前做最后的挣扎，比如数据保存或者保存现场（Heap Dump）。

而且有些时候这个策略还会带来问题，比如加载某个大的内存数据时频繁OOM。

假如你也生产环境中遇到了这个问题，在不知道原因时不要简单的猜测和规避。可以通过-verbose:gc -XX:+PrintGCDetails看下到底什么原因造成了异常。通常原因都是因为old区占用过多导致频繁Full GC，最终导致GC overhead limit exceed。如果gc log不够可以借助于JProfile等工具查看内存的占用，old区是否有内存泄露。分析内存泄露还有一个方法-XX:+HeapDumpOnOutOfMemoryError，这样OOM时会自动做Heap Dump，可以拿MAT来排查了。还要留意young区，如果有过多短暂对象分配，可能也会抛这个异常。

日志的信息不难理解，就是每次gc时打条日志，记录GC的类型，前后大小和时间。举个例子。

33.125: [GC [DefNew: 16000K->16000K(16192K), 0.0000574 secs][Tenured: 2973K->2704K(16384K), 0.1012650 secs] 18973K->2704K(32576K), 0.1015066 secs]

100.667:[Full GC [Tenured: 0K->210K(10240K), 0.0149142 secs] 4603K->210K(19456K), [Perm : 2999K->2999K(21248K)], 0.0150007 secs] 

GC和Full GC代表gc的停顿类型，Full GC代表stop-the-world。箭头两边是gc前后的区空间大小，分别是young区、tenured区和perm区，括号里是该区的总大小。冒号前面是gc发生的时间，单位是秒，从jvm启动开始计算。DefNew代表Serial收集器，为Default New Generation的缩写，类似的还有PSYoungGen，代表Parallel Scavenge收集器。这样可以通过分析日志找到导致GC overhead limit exceeded的原因，通过调节相应的参数解决问题。

文中涉及到的名词解释，

Eden Space：堆内存池，大多数对象在这里分配内存空间。

Survivor Space：堆内存池，存储在Eden Space的gc中存活下来的对象。

Tenured Generation：堆内存池，存储Survivor Space中存活过几次gc的对象。

Permanent Generation：非堆空间，存储的是class和method对象。

Code Cache：非堆空间，JVM用来存储编译和存储native code。

解决：

1.增加参数，-XX:-UseGCOverheadLimit，关闭这个特性，同时增加heap大小，-Xmx1024m。

2.排查并优化消耗内存资源代码.