最近,我在我的web应用程序中遇到了这个错误:
java.lang.OutOfMemoryError:永久生成空间
它是一个典型的Hibernate/JPA + IceFaces/JSF应用程序,运行在Tomcat 6和JDK 1.6上。 显然,这可能发生在重新部署应用程序几次之后。
是什么原因导致的,如何避免呢? 我该如何解决这个问题?
最近,我在我的web应用程序中遇到了这个错误:
java.lang.OutOfMemoryError:永久生成空间
它是一个典型的Hibernate/JPA + IceFaces/JSF应用程序,运行在Tomcat 6和JDK 1.6上。 显然,这可能发生在重新部署应用程序几次之后。
是什么原因导致的,如何避免呢? 我该如何解决这个问题?
当前回答
outofmemoryerror: PermGen space消息表示内存中的永久生成区域已耗尽。
任何Java应用程序都允许使用有限的内存。特定应用程序可以使用的确切内存量是在应用程序启动时指定的。
Java内存被划分为不同的区域,如下图所示:
Metaspace:一个新的内存空间诞生
JDK 8 HotSpot JVM现在使用本机内存来表示类元数据,被称为Metaspace;类似于Oracle的JRockit和IBM的JVM。
好消息是,这意味着不再存在java.lang.OutOfMemoryError: PermGen空间问题,也不再需要使用Java_8_Download或更高版本来调优和监视这个内存空间。
其他回答
另外,如果你在你的webapp中使用log4j,检查log4j文档中的这段。
似乎如果你正在使用propertyconfiguration . configureandwatch ("log4j.properties"),当你取消部署你的web应用程序时,你会导致内存泄漏。
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
如果存在真正的内存泄漏,增加永久生成大小或调整GC参数将不起作用。如果您的应用程序或某些第三方库使用,泄漏类加载器,唯一真正和永久的解决方案是找到这个泄漏并修复它。有许多工具可以帮助您,最近的一个工具是Plumbr,它刚刚发布了一个具有所需功能的新版本。
他们说Tomcat的最新版本(6.0.28或6.0.29)可以更好地处理重新部署servlet的任务。
App server PermGen errors that happen after multiple deployments are most likely caused by references held by the container into your old apps' classloaders. For example, using a custom log level class will cause references to be held by the app server's classloader. You can detect these inter-classloader leaks by using modern (JDK6+) JVM analysis tools such as jmap and jhat to look at which classes continue to be held in your app, and redesigning or eliminating their use. Usual suspects are databases, loggers, and other base-framework-level libraries.
参见类加载器泄漏:可怕的“java.lang。OutOfMemoryError: PermGen space”异常,特别是它的后续帖子。