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

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

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

你在做什么?

处理的交易数量是多少?

加载了多少数据?

etc.

etc.

etc

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

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

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

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

如果存在真正的内存泄漏，增加永久生成大小或调整GC参数将不起作用。如果您的应用程序或某些第三方库使用，泄漏类加载器，唯一真正和永久的解决方案是找到这个泄漏并修复它。有许多工具可以帮助您，最近的一个工具是Plumbr，它刚刚发布了一个具有所需功能的新版本。

在部署和取消部署一个复杂的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();