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

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操作符创建对象，并且在运行时在堆上为新对象分配内存。垃圾收集是一种自动释放程序不再引用的对象所包含的内存的机制。

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

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

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