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

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

对于Sun JVM，使用命令行参数-XX:MaxPermSize=128m(显然是将128替换为您需要的任何大小)。

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版本。

outofmemoryerror: PermGen space消息表示内存中的永久生成区域已耗尽。

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

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

Metaspace:一个新的内存空间诞生

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

好消息是，这意味着不再存在java.lang.OutOfMemoryError: PermGen空间问题，也不再需要使用Java_8_Download或更高版本来调优和监视这个内存空间。

Jrockit也帮我解决了这个问题;但是，我注意到servlet的重启时间要短得多，所以虽然在生产环境中效果更好，但在开发过程中却有点拖后腿。

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