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
的时候。
如果你的
WEB APP
下都用了大量的第三方
jar,
其大小
超过了
jvm
默认的大小
(4M)
那么就会产生此错误信息了。
解决方法： 手动设置 MaxPermSize 大小
改正方法： -Xms256m -Xmx256m -XX:MaxNewSize=256m -XX:MaxPermSize=256m
解决方法： 手动设置 MaxPermSize 大小
改正方法： -Xms256m -Xmx256m -XX:MaxNewSize=256m -XX:MaxPermSize=256m
修改
TOMCAT_HOME/bin/catalina.sh
JAVA_OPTS="-server -XX:PermSize=64M -XX:MaxPermSize=128m
建议：将相同的第三方 jar 文件移置到 tomcat/shared/lib 目录下，这样可以达到减少 jar 文档重复占用内存的目的。
JAVA_OPTS="-server -XX:PermSize=64M -XX:MaxPermSize=128m
建议：将相同的第三方 jar 文件移置到 tomcat/shared/lib 目录下，这样可以达到减少 jar 文档重复占用内存的目的。
Sun文档是这样解释的：
java.lang.OutOfMemoryError: PermGen space
The detail message PermGen space indicates that the permanent generation is full. The permanent generation is the area of the heap where class and method objects are stored. If an application loads a very large number of classes, then the size of the permanent generation might need to be increased using the -XX:MaxPermSize option.
Interned java.lang.String objects are also stored in the permanent generation. The java.lang.String class maintains a pool of strings. When the intern method is invoked, the method checks the pool to see if an equal string is already in the pool. If there is, then the intern method returns it; otherwise it adds the string to the pool. In more precise terms, the java.lang.String.intern method is used to obtain the canonical representation of the string; the result is a reference to the same class instance that would be returned if that string appeared as a literal. If an application interns a huge number of strings, the permanent generation might need to be increased from its default setting.
When this kind of error occurs, the text String.intern or ClassLoader.defineClass might appear near the top of the stack trace that is printed.
The jmap -permgen command prints statistics for the objects in the permanent generation, including information about internalized String instances. See 2.6.4 Getting Information on the Permanent Generation.
下面是某人遇到的问题：
SUN JDK+Tomcat 5.5.20运行服务的时候遇到问题，服务器跑几天后就会挂掉，并报
java.lang.OutOfMemoryError: PermGen space异常。
发现很多人把问题归因于：
spring,hibernate,tomcat，因为他们动态产生类
,导致
JVM中的
permanent heap溢出 。然后解决方法众说纷纭，有人说升级
tomcat版本到最新甚至干脆不用
tomcat。还有人怀疑
spring的问题，在
spring论坛上讨论很激烈，因为
spring在
AOP时使用
CBLIB会动态产生很多类。
但问题是为什么这些王牌的开源会出现同一个问题呢，那么是不是更基础的原因呢？ tomcat在 Q&A很隐晦的回答了这一点。（ Why does the memory usage increase when I redeploy a web application? Because the Classloader (and the Class objects it loaded) cannot be recycled. They are stored in the permanent heap generation by the JVM, and when you redepoy a new class loader is created, which loads another copy of all these classes. This can causeOufOfMemoryErrors eventually. ）
但问题是为什么这些王牌的开源会出现同一个问题呢，那么是不是更基础的原因呢？ tomcat在 Q&A很隐晦的回答了这一点。（ Why does the memory usage increase when I redeploy a web application? Because the Classloader (and the Class objects it loaded) cannot be recycled. They are stored in the permanent heap generation by the JVM, and when you redepoy a new class loader is created, which loads another copy of all these classes. This can causeOufOfMemoryErrors eventually. ）
于是有人对更基础的JVM做了检查，发现了问题的关键。原来
SUN 的
JVM把内存分了不同的区，其中一个就是
permanent区用来存放用得非常多的类和类描述。本来
SUN设计的时候认为这个区域在
JVM启动的时候就固定了，但他没有想到现在动态会用得这么广泛。而且这个区域有特殊的垃圾收回机制，现在的问题是动态加载类到这个区域后，
gc根本没办法回收！
在
tomcat
中
redeploy
时出现
outofmemory
的错误
.
可以有以下几个方面的原因 :
１ , 使用了 proxool, 因为 proxool 内部包含了一个老版本的 cglib.
2, log4j, 最好不用 , 只用 common-logging
3, 老版本的 cglib, 快点更新到最新版。
４，更新到最新的 hibernate3.2
3 、 这里以 tomcat 环境为例，其它 WEB 服务器如 jboss,weblogic 等是同一个道理。
可以有以下几个方面的原因 :
１ , 使用了 proxool, 因为 proxool 内部包含了一个老版本的 cglib.
2, log4j, 最好不用 , 只用 common-logging
3, 老版本的 cglib, 快点更新到最新版。
４，更新到最新的 hibernate3.2
3 、 这里以 tomcat 环境为例，其它 WEB 服务器如 jboss,weblogic 等是同一个道理。
二、
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 "
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下面有多个应用，尽可能的把lib下共用的jar文件放到Tomcat的lib下，发布速度和运行速度上也有所提升。
题外话：经常看到网友抱怨
tomcat
的性能不如
...
，不稳定等，其实根据笔者几年的经验，从
"
互联星空
“
到现在的房产门户网，我们
均使用
tomcat
作为
WEB
服务器，每天访问量百万多，
tomcat
仍然运行良好。建议大家有问题多从自己程序入手，多看看
java
的
DOC
文档。
=======================================================
【解决办法】就是设定JVM启动的时候参数，可以如下设置：
java -XX: PermSize=64m -XX: MaxPermSize=128m
另外PermSize 和MaxPermSize如果设置为相同还可以在一定程度上提高性能，因为，PermSize在不断的变化中会需要转移其中的数据。如果固定了以后，则可以减少每次扩大PermSize带来的性能损失。
更多的请参考
【Java官方站点】
另外，还可以在Java启动的时候添加下面的参数来看GC的运行情况：
Java -verbosegc
本文转自chainli 51CTO博客，原文链接：http://blog.51cto.com/lichen/192681，如需转载请自行联系原作者
