处理“java.lang.OutOfMemoryError: PermGen space” 错误

Question

最近我在我的网络应用程序中遇到了这个错误：

java.lang.OutOfMemoryError：永久代空间

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

是什么原因导致它以及可以采取哪些措施来避免它？ 我该如何解决这个问题？

Answer 1

解决方案是在 Tomcat 启动时将这些标志添加到 JVM 命令行：

-XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled

您可以通过关闭 tomcat 服务，然后进入 Tomcat/bin 目录并运行 tomcat6w.exe 来完成此操作。 在“Java”选项卡下，将参数添加到“Java 选项”框中。 单击“确定”，然后重新启动服务。

如果您收到错误指定的服务不作为已安装的服务存在，您应该运行：

tomcat6w //ES//servicename

其中服务名称是所查看的服务器名称在 services.msc

来源：orx 对 的评论Eric 的敏捷答案。

Answer 2

您最好尝试 -XX:MaxPermSize=128M 而不是 -XX:MaxPermGen=128M。

我无法说出这个内存池的具体使用情况，但它与加载到 JVM 中的类的数量有关。 （因此为 tomcat 启用类卸载可以解决该问题。）如果您的应用程序在运行时生成并编译类，则很可能需要比默认值更大的内存池。

Answer 3

多次部署后发生的应用程序服务器 PermGen 错误很可能是由容器对旧应用程序的类加载器的引用引起的。 例如，使用自定义日志级别类将导致应用程序服务器的类加载器保留引用。 您可以使用现代 (JDK6+) JVM 分析工具（例如 jmap 和 jhat）来检测这些类加载器间泄漏，以查看哪些类继续保留在您的应用程序中，并重新设计或消除它们的使用。 通常的嫌疑人是数据库、记录器和其他基础框架级库。

请参阅 类加载器泄漏：可怕的“java.lang.OutOfMemoryError： PermGen space”例外，尤其是其 后续帖子。

Answer 4

人们常犯的错误是认为堆空间和永久代空间是相同的，但事实并非如此。 堆中可能有大量剩余空间，但永久代中仍然可能会出现内存不足的情况。

PermGen 中 OutofMemory 的常见原因是 ClassLoader。 每当一个类被加载到 JVM 中时，它的所有元数据以及 Classloader 都保存在 PermGen 区域中，当加载它们的 Classloader 准备好进行垃圾回收时，它们将被垃圾回收。 如果类加载器存在内存泄漏，那么它加载的所有类都将保留在内存中，并且一旦重复几次就会导致 permGen 内存不足。 经典的例子是 Java.lang.OutOfMemoryError: Tomcat 中的 PermGen Space。

现在有两种方法可以解决这个问题：
1. 查找Memory Leak的原因或者是否存在内存泄漏。
2. 使用 JVM 参数 -XX:MaxPermSize 和 -XX:PermSize 增加 PermGen Space 的大小。

您还可以查看2 Java.lang.OutOfMemoryError的解决方案 Java 了解更多详细信息。

Answer 5

对于 Sun JVM，使用命令行参数 -XX:MaxPermSize=128m（显然用 128 代替您需要的任何大小）。

Answer 6

尝试 -XX:MaxPermSize=256m ，如果问题仍然存在，请尝试 -XX:MaxPermSize=512m

Answer 7

我添加 -XX: MaxPermSize = 128m（您可以试验哪个效果最好）到VM 参数 因为我正在使用 eclipse ide。 在大多数 JVM 中，默认 PermSize 约为 64MB 如果项目中有太多类或大量字符串，则会耗尽内存。

对于 Eclipse，answer 中也有描述。

第 1 步：在服务器选项卡中双击 tomcat 服务器

第 2 步：打开启动会议并将 -XX: MaxPermSize = 128m 添加到现有VM 争论的末尾< /强>。

Answer 8

在部署和取消部署复杂的 Web 应用程序时，我也一直在努力解决这个问题，并认为我应该添加一个解释和我的解决方案。

当我在 Apache Tomcat 上部署应用程序时，会为该应用程序创建一个新的类加载器。 然后，类加载器用于加载应用程序的所有类，并且在取消部署时，一切都会顺利消失。 然而，实际上事情并不那么简单。

在 Web 应用程序生命周期中创建的一个或多个类拥有一个静态引用，该引用在该过程中的某个位置引用了类加载器。 由于引用最初是静态的，因此任何垃圾收集都无法清理该引用 - 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();

Answer 9

java.lang.OutOfMemoryError: PermGen space 消息表示内存中的永久代区域已耗尽。

任何 Java 应用程序都可以使用有限的内存量。 您的特定应用程序可以使用的确切内存量是在应用程序启动期间指定的。

Java 内存被分为不同的区域，如下图所示：

元空间：新的内存空间诞生

JDK 8 HotSpot JVM现在使用本机内存来表示类元数据，称为元空间； 类似于 Oracle JRockit 和 IBM JVM。

好消息是，这意味着不再有 java.lang.OutOfMemoryError: PermGen 空间问题，并且无需再使用 Java_8_Download 或更高版本。

Answer 10

或者，您可以切换到 JRockit，它处理 permgen 的方式与 sun 的 jvm 不同。 它通常也具有更好的性能。

http://www.oracle.com/technetwork/middleware/jrockit/overview /index.html

Answer 11

1）增加PermGen内存大小

首先可以做的就是增大永久代堆空间的大小。 这不能使用通常的 –Xms（设置初始堆大小）和 –Xmx（设置最大堆大小）JVM 参数来完成，因为如上所述，永久生成堆空间与常规 Java 堆空间完全分开，
这些参数设置此常规 Java 堆空间的空间。 但是，可以使用类似的参数（至少对于 Sun/OpenJDK jvm）来增大永久生成堆的大小：

 -XX:MaxPermSize=128m

默认值为 64m。

2) 启用清理

另一种永久解决这个问题的方法是允许卸载类，这样你的 PermGen 就永远不会用完：

-XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled

这样的东西在过去对我来说很神奇。 但有一件事是，使用这些会带来显着的性能权衡，因为永久扫描会为您发出的每个请求或类似的事情发出额外的 2 个请求。 您需要平衡您的使用和权衡。

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

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

Answer 12

我遇到了我们在这里讨论的问题，我的场景是 eclipse-helios + tomcat + jsf，您所做的是将一个简单的应用程序部署到 tomcat。 我在这里展示了同样的问题，解决如下。

在 Eclipse 中，转到服务器选项卡，双击注册的服务器（在我的情况下是 tomcat 7.0），它会打开我的文件服务器常规注册信息。 在“常规信息”部分，单击链接“打开启动配置”，这将在最后添加的 VM 参数中的“参数”选项卡中打开服务器选项的执行两个条目

-XX: MaxPermSize = 512m
-XX: PermSize = 512m

并准备就绪。

Answer 13

如今最简单的答案是使用 Java 8。

它不再专门为 PermGen 空间保留内存，允许 PermGen 内存与常规内存池混合。

请记住，如果您不希望 Java 8 抱怨它们不执行任何操作，则必须删除所有非标准 -XXPermGen...=... JVM 启动参数。

Answer 14

1. 从 Tomcat 的 bin 目录中打开 tomcat7w 或在开始菜单中键入 Monitor Tomcat
   （打开一个选项卡式窗口，其中包含各种服务信息）。

2. 在 Java 选项文本区域中添加此行：

   <前><代码>-XX:MaxPermSize=128m

3. 将初始内存池设置为 1024（可选）。
4. 将最大内存池设置为 1024（可选）。
5. 单击“确定”。
6. 重新启动 Tomcat 服务。

Answer 15

由于使用了大空间而不是 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，这个问题就不会出现。

Answer 16

如果确实存在内存泄漏，增加永久代大小或调整 GC 参数将无济于事。 如果您的应用程序或其使用的某些第三方库泄漏了类加载器，唯一真正且永久的解决方案是找到此泄漏并修复它。 有很多工具可以帮助您，最近的一个是 Plumbr，它刚刚发布了一个新版本，其中包含所需的能力。

Answer 17

另外，如果您在 Web 应用程序中使用 log4j，请检查 log4j 文档中的此段落< /a>.

看来，如果您使用 PropertyConfigurator.configureAndWatch("log4j.properties")，则在取消部署 Web 应用程序时会导致内存泄漏。

Answer 18

我有 Hibernate+Eclipse RCP 的组合，尝试使用 -XX:MaxPermSize=512m 和 -XX:PermSize=512m ，它似乎对我有用。

Answer 19

设置-XX:PermSize=64m -XX:MaxPermSize=128m。 稍后您还可以尝试增加 MaxPermSize。 希望它能起作用。 这对我来说同样有效。 仅设置 MaxPermSize 对我来说不起作用。

Answer 20

我尝试了几个答案，最终完成这项工作的唯一一件事是 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>

希望这个有帮助。

Answer 21

jrockit 也为我解决了这个问题； 然而，我注意到 servlet 的重启时间要差得多，所以虽然它在生产中更好，但在开发中却是一种拖累。

Answer 22

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

你在干什么？

处理的交易量是多少？

您正在加载多少数据？

等等

等等

也许

您可以分析您的应用程序并开始清理应用程序中的一些模块。

显然，重新部署应用程序几次后可能会发生这种情况

Tomcat 具有热部署功能，但会消耗内存。 尝试偶尔重新启动容器。 此外，您还需要知道在生产模式下运行所需的内存量，这似乎是进行该研究的好时机。

Answer 23

他们说 Tomcat 的最新版本（6.0.28 或 6.0.29）可以更好地处理重新部署 servlet 的任务。

Answer 24

我遇到了完全相同的问题，但不幸的是，所建议的解决方案都没有真正适合我。 部署的时候没有出现这个问题，我也没有做任何热部署。

就我而言，在我的网络应用程序执行期间（通过休眠）连接到数据库时，每次都会在同一点出现问题。

此链接（前面也提到过）确实提供了足够的内部信息来解决该问题。 将 jdbc-(mysql)-driver 从 WEB-INF 移出并放入 jre/lib/ext/ 文件夹似乎已经解决了问题。 这不是理想的解决方案，因为升级到较新的 JRE 需要您重新安装驱动程序。
另一种可能导致类似问题的候选者是 log4j，因此您可能也想移动该选项

Answer 25

在这种情况下，第一步是检查 GC 是否允许从 PermGen 卸载类。 标准 JVM 在这方面相当保守——类生来就是永远存在的。 因此，一旦加载，类就会保留在内存中，即使没有代码再使用它们。 当应用程序动态创建大量类并且生成的类在较长时间内不需要时，这可能会成为问题。 在这种情况下，允许 JVM 卸载类定义会很有帮助。 这可以通过在启动脚本中添加一个配置参数来实现：

-XX:+CMSClassUnloadingEnabled

默认情况下，该参数设置为 false，因此要启用此功能，您需要在 Java 选项中显式设置以下选项。 如果启用 CMSClassUnloadingEnabled，GC 也会清除 PermGen 并删除不再使用的类。 请记住，仅当使用以下选项启用 UseConcMarkSweepGC 时，此选项才有效。 因此，当运行 ParallelGC 或（上帝禁止）串行 GC 时，请确保已通过指定将 GC 设置为 CMS：

-XX:+UseConcMarkSweepGC

Answer 26

为 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>  

Answer 27

“他们”是错误的，因为我运行的是 6.0.29，即使设置了所有选项后也有同样的问题。 正如蒂姆·霍兰上面所说，这些选择只会推迟不可避免的事情。 它们允许我在出现错误之前重新部署 3 次，而不是每次都重新部署。

Answer 28

如果你在 Eclipse IDE 中得到这个，即使在设置参数之后
--launcher.XXMaxPermSize、-XX:MaxPermSize 等，如果您仍然遇到相同的错误，则很可能是 Eclipse 使用了有错误的 JRE 版本它可能已由某些第三方应用程序安装并设置为默认值。 这些有缺陷的版本不会获取 PermSize 参数，因此无论您设置什么，您仍然会不断收到这些内存错误。 因此，在 eclipse.ini 中添加以下参数：

-vm <path to the right JRE directory>/<name of javaw executable>

还要确保将 eclipse 首选项中的默认 JRE 设置为正确的 java 版本。

Answer 29

对我来说唯一有效的方法是使用 JRockit JVM。 我有 MyEclipse 8.6。

JVM 的堆存储了正在运行的 Java 程序生成的所有对象。 Java 使用 new 运算符创建对象，新对象的内存在运行时在堆上分配。 垃圾收集是自动释放程序不再引用的对象所包含的内存的机制。

Answer 30

我有类似的问题。
我的项目是 JDK 7 + Maven 3.0.2 + Struts 2.0 + Google GUICE 依赖注入。

每当我尝试运行 mvn clean package 命令时，它都会显示以下错误并发生“BUILD FAILURE”

org.apache.maven.surefire.util.SurefireReflectionException: java.lang.reflect.InitationTargetException; 嵌套异常是 java.lang.reflect.InitationTargetException: null
java.lang.reflect.InitationTargetException
引起原因：java.lang.OutOfMemoryError: PermGen space

我尝试了所有上述有用的提示和技巧，但不幸的是没有一个对我有用。
下面逐步描述了对我有用的内容：=>

1. 转到 pom.xml
2. 搜索 maven-surefire-plugin
3. 添加新的 元素，然后添加 < argLine> 子元素，其中传递 -Xmx512m -XX:MaxPermSize=256m 如下所示 =>

<代码><配置>
-Xmx512m -XX:MaxPermSize=256m

希望它有帮助，快乐的编程:)