使用多个类加载器节省 PermGen 空间
我们正在 Scala 中编写一个包含大量类的大型 GUI 应用程序，并且我们必须增加 PermGen 空间才能加载所有类。该应用程序本身显示了一系列基于屏幕的活动，每个活动都加载自己的大量类。在任何时间点仅加载/显示一个活动。经过几次活动后，我们在 PermGen 空间中遇到了 OutOfMemoryError。
我知道 PermGen 空间是 像堆的其余部分一样收集的垃圾，但我有兴趣看看是否可以通过每个活动拥有一个 ClassLoader 来减少所需的 PermGen 空间，以便允许类卸载。
所以：
- 我知道系统 ClassLoader 加载的类无法卸载，因为它们将永远被其类加载器引用。这是真的吗？
- 如果周围不再有由我的自定义类加载器加载的类的实例，并且该类加载器可以被垃圾回收，那么它的类是否会被卸载，从而释放 PermGen 空间？
- 关于类卸载是否有任何警告（或常见错误会阻止）？
We're writing a large GUI app in Scala with a lot of classes, and we've had to increase the PermGen space to be able to load all classes. The app itself shows a series of screen-based activities, each of which loads its own large set of classes. Only one activity is ever loaded/displayed at the any point in time. After going through a couple of activities, we had an OutOfMemoryError in the PermGen space.
I understand that the PermGen space is garbage collected just like the rest of the heap, but I'm interested to see if I can reduce the PermGen space needed by having e.g. one ClassLoader per activity so as to allow class unloading.
So:
- I understand that classes loaded by the system ClassLoader cannot be unloaded, as they will forever be referenced by their class loader. Is that true?
- Provided no more instances of a class loaded by my custom class loader are around, and the class loader can be garbage collected, will its classes be unloaded, freeing PermGen space?
- Are there any caveats regarding (or common mistakes that would prevent) class unloading?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
是的，类有资格被卸载的唯一方法是所使用的类加载器被垃圾收集。这意味着对每个类和类加载器本身的引用必须为零。
你的永久代有多大？您可能只需
在命令行上使用 : 来碰撞 PermGen 就可以了。将其设置为 512m 并不罕见。如果您想要一个真正强大的解决方案，您将需要按照每个“活动”使用自定义类加载器的路线。为了帮助调试，请将以下不言自明的参数添加到命令行中：
这将在类加载到 JVM 中时将其打印到命令行。
Yes, the only way Classes are eligible to be unloaded is if the Classloader used is garbage collected. This means that the references to every single class and to the classloader itself need to be zero.
How big is your PermGen? You may get away with just bumping PermGen with :
on your command line. It's not uncommon to set it to 512m. If you want a truly robust solution, you will need to go the route of using a custom class loader per 'activity'. To help with debugging, add the following self explanatory argument to your command line as well:
This will print out classes as they are loaded in the JVM to the command line.