最近,我在我的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上。 显然,这可能发生在重新部署应用程序几次之后。
是什么原因导致的,如何避免呢? 我该如何解决这个问题?
解决方案是在启动Tomcat时将这些标志添加到JVM命令行:
-XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled
您可以通过关闭tomcat服务,然后进入tomcat /bin目录并运行tomcat6w.exe来做到这一点。在“Java”选项卡下,将参数添加到“Java选项”框。单击“确定”,然后重新启动服务。
如果你得到一个错误,指定的服务不存在作为一个安装的服务,你应该运行:
tomcat6w //ES//servicename
其中servicename是在services.msc
来源:orx对Eric敏捷回答的评论。
或者,你可以切换到JRockit,它处理permgen的方式不同于sun的jvm。它通常也有更好的性能。
http://www.oracle.com/technetwork/middleware/jrockit/overview/index.html
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”异常,特别是它的后续帖子。
内存的配置取决于应用程序的性质。
你在做什么?
处理的交易数量是多少?
加载了多少数据?
etc.
etc.
etc
也许你可以配置你的应用程序,并开始清理一些模块从你的应用程序。
显然,这可能发生在重新部署应用程序几次之后
Tomcat采用热部署,但占用内存。试着每隔一段时间重新启动容器。此外,您还需要知道在生产模式下运行所需的内存量,这似乎是进行研究的好时机。
你最好尝试-XX:MaxPermSize=128M而不是-XX:MaxPermGen=128M。
我不能确切地说出这个内存池的使用情况,但它与装入JVM中的类的数量有关。(因此,为tomcat启用类卸载可以解决这个问题。)如果您的应用程序在运行时生成和编译类,则更可能需要比默认值更大的内存池。
我有一个Hibernate+Eclipse RCP的组合,尝试使用-XX:MaxPermSize=512m和-XX:PermSize=512m,它似乎对我有用。
设置-XX:PermSize=64m -XX:MaxPermSize=128m。稍后,您还可以尝试增加MaxPermSize。希望能管用。对我来说也是一样。只设置MaxPermSize对我没用。
“他们”是错误的,因为我运行的是6.0.29,即使设置了所有选项也有同样的问题。正如蒂姆·豪兰所说,这些选择只会推迟不可避免的事情。它们允许我在遇到错误之前重新部署3次,而不是每次重新部署。
In case you are getting this in the eclipse IDE, even after setting the parameters --launcher.XXMaxPermSize, -XX:MaxPermSize, etc, still if you are getting the same error, it most likely is that the eclipse is using a buggy version of JRE which would have been installed by some third party applications and set to default. These buggy versions do not pick up the PermSize parameters and so no matter whatever you set, you still keep getting these memory errors. So, in your eclipse.ini add the following parameters:
-vm <path to the right JRE directory>/<name of javaw executable>
还要确保将eclipse中的首选项中的默认JRE设置为正确的java版本。
对我来说,唯一有效的方法就是JRockit JVM。我有MyEclipse 8.6。
JVM的堆存储运行中的Java程序生成的所有对象。Java使用new操作符创建对象,并且在运行时在堆上为新对象分配内存。垃圾收集是一种自动释放程序不再引用的对象所包含的内存的机制。
我有我们在这里谈论的问题,我的场景是eclipse-helios + tomcat + jsf,而您所做的是将一个简单的应用程序部署到tomcat。我在这里展示了同样的问题,解决方法如下。
在eclipse转到服务器选项卡双击注册服务器在我的情况下tomcat 7.0,它打开我的文件服务器一般注册信息。在“一般信息”部分单击“打开启动配置”链接,这将打开在虚拟机参数参数选项卡中添加的服务器选项的执行,最后添加这两个条目
-XX: MaxPermSize = 512m
-XX: PermSize = 512m
和准备好了。
我遇到了完全相同的问题,但不幸的是,建议的解决方案都不适合我。这个问题在部署过程中没有发生,我也没有进行任何热部署。
在我的例子中,这个问题每次都发生在我的web应用程序执行期间的同一时间点,同时(通过hibernate)连接到数据库。
这个链接(前面也提到过)提供了足够的内部组件来解决这个问题。将jdbc-(mysql)-driver从WEB-INF移到jre/lib/ext/文件夹中似乎已经解决了这个问题。这不是理想的解决方案,因为升级到更新的JRE需要重新安装驱动程序。 另一个可能导致类似问题的候选是log4j,因此您可能也想移动它
另外,如果你在你的webapp中使用log4j,检查log4j文档中的这段。
似乎如果你正在使用propertyconfiguration . configureandwatch ("log4j.properties"),当你取消部署你的web应用程序时,你会导致内存泄漏。
在部署和取消部署一个复杂的web应用程序时,我也遇到过这个问题,我想我应该加上一个解释和我的解决方案。
当我在Apache Tomcat上部署一个应用程序时,会为该应用程序创建一个新的ClassLoader。然后使用ClassLoader加载所有应用程序的类,在取消部署时,一切都应该很好地消失。然而,在现实中,事情并没有那么简单。
在web应用程序生命周期中创建的一个或多个类持有一个静态引用,该引用在某个地方引用ClassLoader。由于引用最初是静态的,所以再多的垃圾收集也不会清理这个引用——ClassLoader和它所加载的所有类都留在这里。
在几次重新部署之后,我们遇到了OutOfMemoryError。
现在这已经成为一个相当严重的问题。我可以确保在每次重新部署后重新启动Tomcat,但这会使整个服务器停机,而不仅仅是重新部署的应用程序,这通常是不可行的。
因此,我用代码组合了一个解决方案,它可以在Apache Tomcat 6.0上工作。我没有在任何其他应用服务器上进行测试,并且必须强调,如果不进行修改,在任何其他应用服务器上都很可能无法工作。
我还想说,就我个人而言,我讨厌这段代码,如果现有代码可以更改为使用适当的关闭和清理方法,那么任何人都不应该使用这段代码作为“快速修复”。只有当您的代码所依赖的外部库(在我的例子中,它是RADIUS客户端)不提供清理其自身静态引用的方法时,才应该使用这种方法。
不管怎样,继续写代码。这应该在应用程序被取消部署时调用——例如servlet的destroy方法或(更好的方法)ServletContextListener的contextDestroyed方法。
//Get a list of all classes loaded by the current webapp classloader
WebappClassLoader classLoader = (WebappClassLoader) getClass().getClassLoader();
Field classLoaderClassesField = null;
Class clazz = WebappClassLoader.class;
while (classLoaderClassesField == null && clazz != null) {
try {
classLoaderClassesField = clazz.getDeclaredField("classes");
} catch (Exception exception) {
//do nothing
}
clazz = clazz.getSuperclass();
}
classLoaderClassesField.setAccessible(true);
List classes = new ArrayList((Vector)classLoaderClassesField.get(classLoader));
for (Object o : classes) {
Class c = (Class)o;
//Make sure you identify only the packages that are holding references to the classloader.
//Allowing this code to clear all static references will result in all sorts
//of horrible things (like java segfaulting).
if (c.getName().startsWith("com.whatever")) {
//Kill any static references within all these classes.
for (Field f : c.getDeclaredFields()) {
if (Modifier.isStatic(f.getModifiers())
&& !Modifier.isFinal(f.getModifiers())
&& !f.getType().isPrimitive()) {
try {
f.setAccessible(true);
f.set(null, null);
} catch (Exception exception) {
//Log the exception
}
}
}
}
}
classes.clear();
我尝试了几个答案,最终完成工作的唯一一件事是在pom中的编译器插件的配置:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.3.2</version>
<configuration>
<fork>true</fork>
<meminitial>128m</meminitial>
<maxmem>512m</maxmem>
<source>1.6</source>
<target>1.6</target>
<!-- prevent PermGen space out of memory exception -->
<!-- <argLine>-Xmx512m -XX:MaxPermSize=512m</argLine> -->
</configuration>
</plugin>
希望这一点能有所帮助。
人们常犯的错误是认为堆空间和永久空间是相同的,这是完全错误的。您可能在堆中有很多剩余空间,但仍然可能在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来了解更多细节。
如果存在真正的内存泄漏,增加永久生成大小或调整GC参数将不起作用。如果您的应用程序或某些第三方库使用,泄漏类加载器,唯一真正和永久的解决方案是找到这个泄漏并修复它。有许多工具可以帮助您,最近的一个工具是Plumbr,它刚刚发布了一个具有所需功能的新版本。
你也可以通过以下方法来解决这个问题:
rm -rf <tomcat-dir>/work/* <tomcat-dir>/temp/*
清除工作目录和临时目录将使Tomcat重新启动。
我添加-XX: MaxPermSize = 128m(你可以实验哪个工作得最好)到虚拟机参数,因为我使用eclipse ide。在大多数JVM中,默认的PermSize大约是64MB,如果项目中有太多的类或大量的字符串,就会耗尽内存。
对于eclipse,在answer中也有描述。
步骤1:在Servers选项卡中双击tomcat服务器
步骤2:打开启动Conf,并在现有VM参数的末尾添加-XX: MaxPermSize = 128m。
从Tomcat的bin目录打开tomcat7w,或者在开始菜单中键入Monitor Tomcat (打开一个带有各种服务信息的选项卡窗口)。 在Java Options文本区域中添加这一行: - xx: MaxPermSize = 128 “初始内存池”设置为“1024”(可选)。 “最大内存池”设置为“1024”(可选)。 单击Ok。 重启Tomcat服务。
目前最简单的答案是使用Java 8。
它不再专门为PermGen空间保留内存,允许PermGen内存与常规内存池混合。
请记住,您将必须删除所有非标准的-XXPermGen…JVM启动参数,如果你不想让Java 8抱怨它们什么都不做的话。
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
由于使用了较大的空间而不是jvm提供的空间来执行代码,会发生Perm gen space错误。
在UNIX操作系统中,这个问题的最佳解决方案是更改bash文件上的一些配置。以下步骤可以解决该问题。
在终端上执行gedit .bashrc命令。
用以下值创建JAVA_OTPS变量:
export JAVA_OPTS="-XX:PermSize=256m -XX:MaxPermSize=512m"
保存bash文件。在终端上执行exec bash命令。重新启动服务器。
我希望这个方法能解决你的问题。如果您使用低于8的Java版本,有时会出现此问题。但是如果你使用Java 8,这个问题就不会发生。
我也有类似的问题。 我的是基于JDK 7 + Maven 3.0.2 + Struts 2.0 +谷歌GUICE依赖注入的项目。
当我尝试运行mvn清洁包命令时,它显示以下错误和“BUILD FAILURE”发生
org.apache.maven.surefire.util.SurefireReflectionException: java.lang.reflect.InvocationTargetException;java.lang.reflect.InvocationTargetException: null java.lang.reflect.InvocationTargetException 由:java.lang.OutOfMemoryError: PermGen space引起
我尝试了上面所有有用的技巧,但不幸的是,没有一个对我有效。 对我有效的方法如下:=>
转到pom.xml 搜索<artifactId>maven-surefire-plugin</artifactId> 添加一个新的<configuration>元素和<argLine>子元素,其中pass -Xmx512m -XX:MaxPermSize=256m,如下所示=>
< configuration > < argLine > -Xmx512m -XX: MaxPermSize = 256m < / argLine > < / configuration >
希望能有所帮助,编程愉快:)
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
outofmemoryerror: PermGen space消息表示内存中的永久生成区域已耗尽。
任何Java应用程序都允许使用有限的内存。特定应用程序可以使用的确切内存量是在应用程序启动时指定的。
Java内存被划分为不同的区域,如下图所示:
Metaspace:一个新的内存空间诞生
JDK 8 HotSpot JVM现在使用本机内存来表示类元数据,被称为Metaspace;类似于Oracle的JRockit和IBM的JVM。
好消息是,这意味着不再存在java.lang.OutOfMemoryError: PermGen空间问题,也不再需要使用Java_8_Download或更高版本来调优和监视这个内存空间。
为Tomcat分配更多内存不是正确的解决方案。
正确的解决方案是在销毁和重新创建上下文(热部署)之后进行清理。解决方案是停止内存泄漏。
如果Tomcat/Webapp服务器告诉您未能注销驱动程序(JDBC),那么请注销它们。这将阻止内存泄漏。
您可以创建一个ServletContextListener并在web.xml中配置它。下面是一个示例ServletContextListener:
import java.sql.Driver;
import java.sql.DriverManager;
import java.sql.SQLException;
import java.util.Enumeration;
import javax.servlet.ServletContextEvent;
import javax.servlet.ServletContextListener;
import org.apache.log4j.Logger;
import com.mysql.jdbc.AbandonedConnectionCleanupThread;
/**
*
* @author alejandro.tkachuk / calculistik.com
*
*/
public class AppContextListener implements ServletContextListener {
private static final Logger logger = Logger.getLogger(AppContextListener.class);
@Override
public void contextInitialized(ServletContextEvent arg0) {
logger.info("AppContextListener started");
}
@Override
public void contextDestroyed(ServletContextEvent arg0) {
logger.info("AppContextListener destroyed");
// manually unregister the JDBC drivers
Enumeration<Driver> drivers = DriverManager.getDrivers();
while (drivers.hasMoreElements()) {
Driver driver = drivers.nextElement();
try {
DriverManager.deregisterDriver(driver);
logger.info(String.format("Unregistering jdbc driver: %s", driver));
} catch (SQLException e) {
logger.info(String.format("Error unregistering driver %s", driver), e);
}
}
// manually shutdown clean up threads
try {
AbandonedConnectionCleanupThread.shutdown();
logger.info("Shutting down AbandonedConnectionCleanupThread");
} catch (InterruptedException e) {
logger.warn("SEVERE problem shutting down AbandonedConnectionCleanupThread: ", e);
e.printStackTrace();
}
}
}
然后在web.xml中进行配置:
<listener>
<listener-class>
com.calculistik.mediweb.context.AppContextListener
</listener-class>
</listener>
如果有人在netbeans中遇到同样的错误,那么下面是我解决它的方法。
在Netbeans:
进入服务选项卡——>在服务器右侧——>选择属性——>进入平台选项卡——>在虚拟机内部选项类型-Xms1024m
在我的情况下,我给了-Xms4096m
以下是截图:
谁在IntelliJ中调试JBoss应用程序时遇到了同样的问题: 我刚刚在运行/调试配置的虚拟机选项中添加了-XX: MaxPermSize = 128m。你可以把它增加到256m,以确保它会工作。
增加Tomcat内存
C:\Program Files\Apache软件基础\Tomcat 9.0\bin
或者任何使用tomcat的地方。并运行tomcat9w或任何您使用的版本。
然后跟着图片走
改变128到1024,也最大改变到1024或更多你想要的。