何时以及如何标记 java 类加载器进行垃圾收集？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/2344964/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
When and how is a java classloader marked for garbage collection?
提问by onejigtwojig
We are creating multiple child classloaders to load in multiple subapplications into a Java application "container", prototyping hot deployment. When the classpath of a particular classloader has changed (i.e. jars have been added, deleted, updated), the old classloader is thrown away (unreferenced) and a new classloader is created for the new classpath of jars.
我们正在创建多个子类加载器，以将多个子应用程序加载到 Java 应用程序“容器”中，对热部署进行原型设计。当特定类加载器的类路径发生变化（即 jar 已添加、删除、更新）时，旧的类加载器将被丢弃（未引用）并为 jar 的新类路径创建一个新的类加载器。
After updating the classpath, triggering the hot deployment, we took a heap dump. The heap dump (using Memory Analyzer) indicates that the old classloaders were not being garbage collected. Certain classes in the parent classloader were caching the old classloaders. The following things were invoked to clear these caches:
更新类路径后，触发热部署，我们进行了堆转储。堆转储（使用内存分析器）表明旧的类加载器没有被垃圾收集。父类加载器中的某些类正在缓存旧的类加载器。调用以下内容来清除这些缓存：
java.lang.ResourceBundle.clearCache(classLoader);
org.apache.commons.logging.LogFactory.release(classLoader);
java.beans.Introspector.flushCaches();
Even after clearing the above caches, the old classloader were still not being garbage collected. The remaining references to the classloader included the following:
即使清除了上述缓存，旧的类加载器仍然没有被垃圾收集。对类加载器的其余引用包括以下内容：
- the classes loaded by the classloader
- java.lang.Package's created by the classloader itself
- java.lang.ProtectionDomain created by the classloader itself
- 类加载器加载的类
- java.lang.Package 由类加载器本身创建
- 由类加载器本身创建的 java.lang.ProtectionDomain
All the above are circular references within the classloader, which should trigger a garbage collection. I'm not sure why it is not. Does anybody know why the old classloaders are still not being garbage collected even with the circular references?
以上都是类加载器中的循环引用，应该会触发垃圾回收。我不确定为什么不是。有人知道为什么即使使用循环引用，旧的类加载器仍然没有被垃圾收集吗？
采纳答案by ewernli
I always heard that Classloaderunloading was problematic. They are theoreticallygarbage collected when there is not reference to the object instances and class unloading is not necessary, but in practice it seems like to be more problematic. Subtle references may leak and prevent the Classloaderfrom being reclaimed. In application servers, after numerous redeploy cycle, I sometimes got a OutOfMemoryError: PermGen space.
一直听说Classloader卸货有问题。当没有对对象实例的引用并且没有必要卸载类时，它们理论上会被垃圾收集，但在实践中似乎更成问题。微妙的引用可能会泄漏并阻止Classloader回收。在应用服务器中，经过无数次的重新部署周期后，我有时会得到一个OutOfMemoryError: PermGen space.
All that to say that I guess there is a nasty reference somewhere that prevent it from being collected -- maybe the memory analyzer didn't followed the link correctly. It seems like all this can happen, as described in these articles:
综上所述，我猜想某处有一个令人讨厌的引用阻止它被收集——也许内存分析器没有正确遵循链接。正如这些文章中所述，这一切似乎都可能发生：
- Classloader leaks: the dreaded PermGen space exception
- How to fix the dreaded PermGen space exception
Also, I don't know exactly what you are doing, but if you can wait for JDK 7, you could have a look at AnonymousClassLoader. They will be introduced to better support dynamic language, as explained in this post:
另外，我不知道你在做什么，但如果你可以等待 JDK 7，你可以看看AnonymousClassLoader. 它们将被引入以更好地支持动态语言，如本文所述：
I hope it will help you.
我希望它会帮助你。
