最近,我在我的web应用程序中遇到了这个错误:

java.lang.OutOfMemoryError:永久生成空间

它是一个典型的Hibernate/JPA + IceFaces/JSF应用程序,运行在Tomcat 6和JDK 1.6上。 显然,这可能发生在重新部署应用程序几次之后。

是什么原因导致的,如何避免呢? 我该如何解决这个问题?


当前回答

内存的配置取决于应用程序的性质。

你在做什么?

处理的交易数量是多少?

加载了多少数据?

etc.

etc.

etc

也许你可以配置你的应用程序,并开始清理一些模块从你的应用程序。

显然,这可能发生在重新部署应用程序几次之后

Tomcat采用热部署,但占用内存。试着每隔一段时间重新启动容器。此外,您还需要知道在生产模式下运行所需的内存量,这似乎是进行研究的好时机。

其他回答

First step in such case is to check whether the GC is allowed to unload classes from PermGen. The standard JVM is rather conservative in this regard – classes are born to live forever. So once loaded, classes stay in memory even if no code is using them anymore. This can become a problem when the application creates lots of classes dynamically and the generated classes are not needed for longer periods. In such a case, allowing the JVM to unload class definitions can be helpful. This can be achieved by adding just one configuration parameter to your startup scripts:

-XX:+CMSClassUnloadingEnabled

默认情况下,它被设置为false,因此要启用它,您需要显式地在Java选项中设置以下选项。如果你启用了CMSClassUnloadingEnabled, GC也会扫描PermGen并删除不再使用的类。请记住,此选项仅在UseConcMarkSweepGC也使用下面的选项启用时才有效。因此,当运行ParallelGC或串行GC时,请确保您已经通过指定将GC设置为CMS:

-XX:+UseConcMarkSweepGC

人们常犯的错误是认为堆空间和永久空间是相同的,这是完全错误的。您可能在堆中有很多剩余空间,但仍然可能在permgen中耗尽内存。

Common causes of OutofMemory in PermGen is ClassLoader. Whenever a class is loaded into JVM, all its meta data, along with Classloader, is kept on PermGen area and they will be garbage collected when the Classloader which loaded them is ready for garbage collection. In Case Classloader has a memory leak than all classes loaded by it will remain in memory and cause permGen outofmemory once you repeat it a couple of times. The classical example is Java.lang.OutOfMemoryError:PermGen Space in Tomcat.

现在有两个方法来解决这个问题: 1. 检查内存泄漏的原因或是否存在内存泄漏。 2. 通过使用JVM参数-XX:MaxPermSize和-XX:PermSize来增加PermGen空间的大小。

你也可以在Java中查看Java.lang. outofmemoryerror的2 Solution来了解更多细节。

我遇到了完全相同的问题,但不幸的是,建议的解决方案都不适合我。这个问题在部署过程中没有发生,我也没有进行任何热部署。

在我的例子中,这个问题每次都发生在我的web应用程序执行期间的同一时间点,同时(通过hibernate)连接到数据库。

这个链接(前面也提到过)提供了足够的内部组件来解决这个问题。将jdbc-(mysql)-driver从WEB-INF移到jre/lib/ext/文件夹中似乎已经解决了这个问题。这不是理想的解决方案,因为升级到更新的JRE需要重新安装驱动程序。 另一个可能导致类似问题的候选是log4j,因此您可能也想移动它

Jrockit也帮我解决了这个问题;但是,我注意到servlet的重启时间要短得多,所以虽然在生产环境中效果更好,但在开发过程中却有点拖后腿。

1)增加永久内存大小

The first thing one can do is to make the size of the permanent generation heap space bigger. This cannot be done with the usual –Xms(set initial heap size) and –Xmx(set maximum heap size) JVM arguments, since as mentioned, the permanent generation heap space is entirely separate from the regular Java Heap space, and these arguments set the space for this regular Java heap space. However, there are similar arguments which can be used(at least with the Sun/OpenJDK jvms) to make the size of the permanent generation heap bigger:

 -XX:MaxPermSize=128m

默认为64m。

2)启用扫地功能

另一种方法是允许类被卸载,这样你的PermGen就永远不会用完:

-XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled

这种方法在过去对我很有效。不过,有一件事是,使用这些有一个显著的性能权衡,因为永久扫描将像额外的2个请求,你发出的每一个请求或类似的东西。您需要在使用和权衡之间取得平衡。

您可以找到这个错误的详细信息。

http://faisalbhagat.blogspot.com/2014/09/java-outofmemoryerror-permgen.html