为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

以下是截图:

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

目前最简单的答案是使用Java 8。

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

请记住，您将必须删除所有非标准的-XXPermGen…JVM启动参数，如果你不想让Java 8抱怨它们什么都不做的话。

谁在IntelliJ中调试JBoss应用程序时遇到了同样的问题: 我刚刚在运行/调试配置的虚拟机选项中添加了-XX: MaxPermSize = 128m。你可以把它增加到256m，以确保它会工作。

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”异常，特别是它的后续帖子。