java.lang.OutOfMemoryError的解决方法 tomcat

服务器这几天很频繁的当机,看了下日志.
[2008-07-16 08:09:15][org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/].[jsp]][ERROR] Servlet.service() for servlet jsp threw exception
java.lang.OutOfMemoryError: PermGen space
[2008-07-16 08:33:53][org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/].[default]][ERROR] Servlet.service() for servlet default threw exception
java.lang.OutOfMemoryError: PermGen space


google了一下,找到个篇文章,先做个标记,再来处理



问题终于解决了,用的就是第一种方法.
修改TOMCAT_HOME/bin/catalina.sh
在“echo "Using CATALINA_BASE:   $CATALINA_BASE"”上面加入以下行：
JAVA_OPTS="-server -XX:PermSize=64M -XX:MaxPermSize=128m


[1]

java.lang.OutOfMemoryError: PermGen space及其解决方法
1、

PermGen space的全称是Permanent Generation space,是指内存的永久保存区域OutOfMemoryError: PermGen space从表面上看就是内存益出，解决方法也一定是加大内存。说说为什么会内存益出：这一部分用于存放Class和Meta的信息,Class在被 Load的时候被放入PermGen space区域，它和和存放Instance的Heap区域不同,GC(Garbage Collection)不会在主程序运行期对PermGen space进行清理，所以如果你的APP会LOAD很多CLASS的话,就很可能出现PermGen space错误。这种错误常见在web服务器对JSP进行pre compile的时候。
改正方法：-Xms256m -Xmx256m -XX:MaxNewSize=256m -XX:MaxPermSize=256m
2、
在tomcat中redeploy时出现outofmemory的错误.
可以有以下几个方面的原因:
１,使用了proxool,因为proxool内部包含了一个老版本的cglib.
2, log4j,最好不用,只用common-logging
3, 老版本的cglib,快点更新到最新版。
４，更新到最新的hibernate3.2

3、

这里以tomcat环境为例，其它WEB服务器如jboss,weblogic等是同一个道理。
一、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 文档重复占用内存的目的。
二、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"
三、实例，以下给出1G内存环境下java jvm 的参数设置参考：
JAVA_OPTS="-server -Xms800m -Xmx800m -XX:PermSize=64M -XX:MaxNewSize=256m -XX:MaxPermSize=128m -Djava.awt.headless=true "

三、相关资料
题外话：经常看到网友抱怨tomcat的性能不如...，不稳定等，其实根据笔者几年的经验，从"互联星空“到现在的房产门户网，我们
均使用tomcat作为WEB服务器，每天访问量百万多，tomcat仍然运行良好。建议大家有问题多从自己程序入手，多看看java的DOC文档
并详细了解JVM的知识。这样开发的程序才会健壮。








[2]
java.lang.OutOfMemoryError: PermGen space及其解决方法


今天tomcat出现了 如下错误：


Exception in thread "DefaultQuartzScheduler_Worker-3" java.lang.OutOfMemoryError: PermGen space  
那是发布了grails的应用以后出现的，经google以后，发现本文，在此以此作为备份，全部版权归真正作者所有


http://www.wujianrong.com/archives/2006/12/javalangoutofmemoryerror_permg.html(google的原文地址)
1、


PermGen space的全称是Permanent Generation space,是指内存的永久保存区域OutOfMemoryError: PermGen space从表面上看就是内存益出，解决方法也一定是加大内存。说说为什么会内存益出：这一部分用于存放Class和Meta的信息,Class在被 Load的时候被放入PermGen space区域，它和和存放Instance的Heap区域不同,GC(Garbage Collection)不会在主程序运行期对PermGen space进行清理，所以如果你的APP会LOAD很多CLASS的话,就很可能出现PermGen space错误。这种错误常见在web服务器对JSP进行pre compile的时候。

改正方法：-Xms256m -Xmx256m -XX:MaxNewSize=256m -XX:MaxPermSize=256m
2、

在tomcat中redeploy时出现outofmemory的错误.

可以有以下几个方面的原因:

１,使用了proxool,因为proxool内部包含了一个老版本的cglib.

2, log4j,最好不用,只用common-logging

3, 老版本的cglib,快点更新到最新版。

４，更新到最新的hibernate3.2


3、

这里以tomcat环境为例，其它WEB服务器如jboss,weblogic等是同一个道理。
一、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 文档重复占用内存的目的。

二、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"

三、实例，以下给出1G内存环境下java jvm 的参数设置参考：（ catalina.sh）

JAVA_OPTS="-server -Xms800m -Xmx800m  -XX:PermSize=64M -XX:MaxNewSize=256m -XX:MaxPermSize=128m -Djava.awt.headless=true "


三、相关资料

/show/3/7/20061112220131.htm

/show/3/7/20061112220054.htm

/show/3/7/20061112220201.htm

题外话：经常看到网友抱怨tomcat的性能不如...，不稳定等，其实根据笔者几年的经验，从"互联星空“到现在的房产门户网，我们
均使用tomcat作为WEB服务器，每天访问量百万多，tomcat仍然运行良好。建议大家有问题多从自己程序入手，多看看java的DOC文档
并详细了解JVM的知识。这样开发的程序才会健壮。




解决方案就是:在启动服务器时加上指定PermGen区域的内存大小的配置.-XX:PermSize=128m -XX:MaxPermSize=256m

比如:nohup /usr/java/jdk1.5.0_08/bin/java -Dcom.sun.management.jmxremote -Xms512m -Xm
x1024m -XX:=128m -XX:MaxPermSize=256m -jar oc4j.jar&

     HOHO,问题解决了,上网查了一个PermGen space是咋回事,原来:

     PermGen space的全称是Permanent Generation space,是指内存的永久保存区域,这块内存主要是存放Class和Meta信息的,Class在被Loader时就会被放到PermGen space中,它和存放类实例(Instance)的Heap区域不同,GC(Garbage Collection)不会在主程序运行期对PermGen space进行清理，所以如果APP会LOAD很多CLASS的话,就很可能出现PermGen space错误,这种错误常见在web服务器对JSP进行pre compile的时候。
     看到这,我就明白为什么偶的应用服务器会报这个错了,因为偶在一个Oc4j下,部署了4个APP,每个APP下都用了大量的第三方jar,如 Hibernate,Spring,apache-common,dwr,jar多了,也就是Class多,也就是占用更多的PermGen space区域喽










[3]
关于 java.lang.OutOfMemoryError: PermGen space2006-08-16 11:42java.lang.OutOfMemoryError: PermGen space

PermGen space,全称是Permanent Generation space,
就是说是永久保存的区域,用于存放Class和Meta信息,Class在被Load的时候被放入该区域
从字面看,和存放Instance的Heap区域不同,
GC(Garbage Collection)应该不会对PermGen space进行清理
所以如果你的APP会LOAD很多CLASS的话,就很可能出现PermGen space错误


解决方法： to increase the value specified with -XX:MaxPermSize.



下面转一篇不错的文章

OutOfMemoryError looks a bit better! OutOfMemoryError has always been a confusing error. For a long time the HotSpot Virtual Machine threw this error without a detail message or stack trace so typically the thread throwing the error would terminate with this:

Exception in thread "main" java.lang.OutOfMemoryError
That was confusing. Is my java heap full or does it mean something else? Those familiar with the heap layout that the HotSpot VM uses will know that the "something else" might mean the "permanent generation". This is place where reflective data such as class and method objects are allocated. It is also the place where interned strings are stored. If you've got an application that loads a huge number of classes or interns millions of strings then it's possible that the OutOfMemoryError is because the permanent generation is full rather than the java heap.

In 5.0 the error is less confusing as there is a detail message. This means you will see something like this:

Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
or:

Exception in thread "main" java.lang.OutOfMemoryError: PermGen full
In Mustang, there has been further changes to the way that OutOfMemoryError is reported. One obvious one is that the HotSpot VM will attempt to include a stack trace. This means you should see something like this:

Exception in thread "main" java.lang.OutOfMemoryError: Java heap space at ConsumeHeap$BigObject.(ConsumeHeap.java:22) at ConsumeHeap.main(ConsumeHeap.java:47)
In this example we see the stack trace where the allocation failed. If the OutOfMemoryError is because the perm gen it full then you might see String.intern or ClassLoader.defineClass near the top of the stack.

Is a stack trace useful? In some limited cases it can be. For example, suppose you've got a thread looping and in the loop it is allocating objects and putting them into a collection. In that case the stack trace might direct you to a good starting place. More generally, the stack trace is not likely to be useful. If you've got a busy application and the heap is nearly full, then OutOfMemoryError will be likely be thrown in some random place by some random mutator.

One useful improvement is the -XX:+HeapDumpOnOutOfMemoryError option which tells the HotSpot VM to generate a heap dump when an allocation from the java heap or the permanent generation cannot be satisfied. There isn't any overhead to running with this option so it should be useful for production systems where OutOfMemoryError takes weeks (or longer) to surface. The heap dump is in HPROF binary format so it can be analyzed using any tools that can import this format. If you read Sundar's blog then you'll know that Mustang includes a useful tool called jhat which can be used to do rudimentary analysis of the dump. jhat supports Object Query Language so you can easily create your own queries and mine the heap dump.

The next improvement is visible when the system is almost out of swap space and an allocation from the native heap fails in the VM. In that case the VM aborts and you get a one-line error such as the following:

Exception java.lang.OutOfMemoryError: requested 16 bytes for CHeapObj-new. Out of swap space?
This message has been known to confuse a lot of developers. At first glance it might it might look like that the java heap is full. Of course if you increase the size of the heap with the -mx option it might make the problem worse as the larger java heap means there is less native memory available.

In Mustang this condition will trigger the VM to invoke the fatal error handling mechanism. This means you should get a fatal error log as you would get with a normal (abnormal?) crash. The fatal error log is named hs_err_.log and contains useful information about the thread, process, and system at the time of the crash. In the case of native heap exhaustion then the heap memory and memory map information in the log can be useful. The exact format is version and platform specific and you will get more information in the J2SE Troubleshooting Guide.

Hopefully, developers will find these improvements useful. It should make OutOfMemoryError a little less confusing and it means the error is no longer a one-line wonder.


been known to confuse a lot of developers. At first glance it might it might look like that the java heap is full. Of course if you increase the size of the heap with the -mx option it might make the problem worse as the larger java heap means there is less native memory available.

In Mustang this condition will trigger the VM to invoke the fatal error handling mechanism. This means you should get a fatal error log as you would get with a normal (abnormal?) crash. The fatal error log is named hs_err_.log and contains useful information about the thread, process, and system at the time of the crash. In the case of native heap exhaustion then the heap memory and memory map information in the log can be useful. The exact format is version and platform specific and you will get more information in the J2SE Troubleshooting Guide.

Hopefully, developers will find these improvements useful. It should make OutOfMemoryError a little less confusing and it means the error is no longer a one-line wonder.