哪种免费 JVM 实现具有最好的 PermGen 处理能力？
我在 Sun 的 JRE6 中运行 Tomcat6，每对部署者都会遇到 OutOfMemoryException: PermGen。 我已经完成了 PermGen 解决方案的谷歌搜索并尝试了许多修复。 没有工作。 我读了很多关于 Oracle 的 JRockit 的好文章，以及它的 PermGen 分配如何可以达到巨大的大小（与 Sun 的 128M 相比），虽然它不能解决问题，但它允许我在 PermGen 异常之间重新部署 100 次，而不是 2 次。现在。
JRockit 的问题是要在生产中使用它，您需要购买 WebLogic，这要花费数千美元。 还有哪些其他（免费）选项对 PermGen 扩展更宽容？ 下面的 JVM 在这方面表现如何？
- IBM JVM
- Open JDK
- Blackdown
- Kaffe
...其他？
更新： 有人问我为什么认为 PermGen max 是 128M。 原因是因为任何时候我尝试将其提高到 128M 以上时，我的 JVM 都无法初始化：
[2009-06-18 01:39:44] [info] Error generated during iteration of VM [2009-06-18 01:39:44] [info] 无法为对象堆保留足够的空间 [2009-06-18 01:39:44] [395 javajni.c] [error] CreateJavaVM Failed
奇怪的是，它尝试为对象堆保留空间失败，尽管我不确定它是“the”堆而不是“a”堆。
我使用 1024MB 初始堆和 1536MB 最大堆启动 JVM。
我将关闭这个问题，因为它已经得到回答，即。 “切换是无用的”并询问 为什么我的 Sun JVM 在 PermGen 设置较大时会失败？
I'm running Tomcat6 in Sun's JRE6 and every couple deploys I get OutOfMemoryException: PermGen. I've done the Googling of PermGen solutions and tried many fixes. None work. I read a lot of good things about Oracle's JRockit and how its PermGen allocation can be gigs in size (compare to Sun's 128M) and while it doesn't solve the problem, it would allow me to redeploy 100 times between PermGen exceptions compared to 2 times now.
The problem with JRockit is to use it in production you need to buy WebLogic which costs thousands of dollars. What other (free) options exist that are more forgiving of PermGen expansion? How do the below JVMs do in this area?
- IBM JVM
- Open JDK
- Blackdown
- Kaffe
...others?
Update: Some people have asked why I thought PermGen max was 128M. The reason is because any time I try to raise it above 128M my JVM fails to initialize:
[2009-06-18 01:39:44] [info] Error occurred during initialization of VM
[2009-06-18 01:39:44] [info] Could not reserve enough space for object heap
[2009-06-18 01:39:44] [395 javajni.c] [error] CreateJavaVM Failed
It's strange that it fails trying to reserve space for the object heap, though I'm not sure it's "the" heap instead of "a" heap.
I boot the JVM with 1024MB initial and 1536MB max heap.
I will close this question since it has been answered, ie. "switching is useless" and ask instead Why does my Sun JVM fail with larger PermGen settings?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
IBM JVM 没有（2009 年也没有）永久代。 您可以阅读有关其 Generational Concurrent Garbage Collector 这是 Java 7 的默认 GC。
我有时会在 IBM JVM 上运行 Eclipse IDE，因为使用我最喜欢的插件它会经常填满HotSpot JVM 的 permgen。 当然，可能存在内存泄漏，应该有人修复，但同时我的 IDE 没有崩溃，而且我也没有忙于尝试不同的设置。
The IBM JVM does not (and did not in 2009) have a permgen. You can read more about its Generational Concurrent Garbage Collector which is its default GC for Java 7.
I have sometimes run the Eclipse IDE on IBM JVM specifically because with my favorite plugins it would frequently fill up the HotSpot JVM's permgen. Sure, there was probably a memory leak that someone should have fixed, but meanwhile my IDE was not crashing and I was not busy experimenting with different settings.
我同意 Michael Borgwardt 的观点，即您可以增加 PermGen 大小，但我不同意这主要是由于内存泄漏造成的。 PermGen 空间被大量使用反射的应用程序大量占用。 因此，基本上，如果您有一个在 Tomcat 中运行的 Spring/Hibernate 应用程序，请准备好大幅增加 PermGen 空间。
I agree with Michael Borgwardt in that you can increase the PermGen size, I disagree that it's primarily due to memory leaks. PermGen space gets eaten up aggressively by applications which implement heavy use of Reflection. So basically if you have a Spring/Hibernate application running in Tomcat, be prepared to bump that PermGen space up a lot.
是什么让您想到 Sun 的 JVM 仅限于 128M PermGen？ 您可以使用 -XX:MaxPermSize 命令行选项自由设置； 默认为64M。
然而，问题的真正原因可能是应用程序中的内存泄漏，它阻止了类被垃圾收集； 这些可能非常微妙，特别是当涉及类加载器时，因为它所需要的只是对任何地方的任何类的单个引用。 这篇文章详细描述了该问题，并且这个提出了修复它的方法。
What gave you the idea that Sun's JVM is restricted to 128M PermGen? You can set it freely with the -XX:MaxPermSize command line option; the default is 64M.
However, the real cause of your problem is probably a memory leak in your application that prevents the classes from getting garbage collected; these can be very subtle, especially when ClassLoaders are involved, since all it takes is a single reference to any of the classes, anywhere. This article describes the problem in detail, and this one suggests ways to fix it.
从技术上讲，“PermGen”内存池是 Sun JVM 的东西。 其他 JVM 并不这么称呼它，但它们都有一个或多个非堆内存池的想法。
但是，如果您的 Sun JVM 中存在 permgen 问题，那么迁移到另一个 JVM 不太可能解决任何问题，它只会以不同的名称显现出来。
如果多次重新部署导致出现问题，只需将虚拟机的 PermGen 提高到较大值即可。 由于这个问题，我们不久前尝试过 JRockit，它也遇到了同样的重新部署耗尽问题。 我们又回到了 SUn JVM。
Technically, the "PermGen" memory pool is a Sun JVM thing. Other JVMs don't call it that, but they all have the idea of one or more non-heap memory pools.
But if you have a problem with permgen in your Sun JVM, moving to another JVM is very unlikely solve anything, it'll just manifest itself under a different name.
If multiple redeployments are causing your problems, just boost the VM's PermGen up to large values. We tried JRockit a while back because of this very problem, and it suffers from the same redeployment exhaustion. We moved back to SUn JVM.
改变JVM并不是万能的。 您可能会遇到新的意外问题（例如，请参阅一篇文章 关于在 4 个不同的 JVM 下启动应用程序）。
从我过去的经验来看，调试这种泄漏是最常见的泄漏之一我曾经经历过一种棘手的调试。
[更新]
有用的文章如何消除类加载器应用程序重新部署的链接。
Changing JVM is not a panacea. You can get new unexpected issues (e.g. see an article about launching an application under 4 different JVM).
From my past experience, debugging that kind of leak is one of the most tricky kind of debugging that I've ever had.
[UPDATED]
Useful article how to eliminate classloader link on an application redeploy.
我使用 JRockit，如果我不增加（通过 -XX:MaxPermSize）内存，我仍然会收到 PermGen 错误。 我也无法采取任何措施来避免这种情况（除了增加它）。
I use JRockit and I still get PermGen errors if I don't bump up (via -XX:MaxPermSize) the memory. I also can't get anything to work to avoid getting this (other than increasing it).
Perm gen 可能是最简单的内存处理，我怀疑各种虚拟机实现之间会有很大差异。
确保所有在生产中标记为关闭的 Tomcat 配置都在生产中关闭。
是的，一些框架确实会动态生成大量类，但它们应该会自行清理，并且无论如何，您可以在 128Mb 中容纳多个类。
说真的，如果永久代持续上升，那么这就是一个泄漏，应该修复，尽管这可能不是你需要修复的问题。
Perm gen is probably the simplest memory to handle, I doubt there'd be much difference between the various vm implementations.
Make sure all those Tomcat configs that are marked turn off in production are turned off in production.
Yes, some frameworks that do generate a lot of classes an the fly, but they should be cleaning up after themselves, and, in any case, you can fit more than a few classes in 128Mb.
Seriously, if perm gen keeps going up then thats a leak a should be fixed, though it may not be your problem to fix.