何时以及如何将java classloader标记为垃圾收集？ [英] When and how is a java classloader marked for garbage collection?
问题描述
我们正在创建多个子类加载器，以将多个子应用程序加载到Java应用程序容器中，进行热部署原型设计。当特定类加载器的类路径发生改变时（即已经添加，删除，更新了jar），旧的类加载器被抛弃（未引用），并为新的jar类路径创建一个新的类加载器。
更新类路径后，触发热部署，我们进行了堆转储。堆转储（使用Memory Analyzer）表明旧的类加载器未被垃圾收集。父类加载器中的某些类正在缓存旧的类加载器。下面的东西被调用来清除这些缓存：
java.lang.ResourceBundle.clearCache（classLoader）;
org.apache.commons.logging.LogFactory.release（classLoader）;
java.beans.Introspector.flushCaches（）;
即使在清除上述缓存之后，旧的类加载器仍未被垃圾收集。其余对类加载器的引用如下所示：
- 类加载器加载的类
- java .lang.Package由类加载器本身创建
- 类加载器本身创建的java.lang.ProtectionDomain
以上所有都是类加载器中的循环引用，它应该触发垃圾回收。我不确定它为什么不是。有人知道为什么旧的类加载器仍然没有被垃圾收集，即使是循环引用吗？
我总是听说 Classloader 卸载有问题。他们在理论上收集垃圾时没有引用对象实例并且类没有必要卸载，但实际上似乎更成问题。微妙的引用可能会泄漏并阻止回收 Classloader 。在应用程序服务器中，经过大量重新部署周期后，我有时会得到一个 OutOfMemoryError：PermGen空间。
所有这一切说，我猜想有一个令人讨厌的参考，阻止它被收集 - 也许内存分析器没有正确地跟踪链接。看起来，所有这些都可能发生，正如这些文章中所描述的： .au / 2006/10 / classloader-leaks-dreaded-permgen-space.htmlrel =noreferrer>类加载器泄漏：可怕的PermGen空间异常 href =http://frankkieviet.blogspot.com.au/2006/10/how-to-fix-dreaded-permgen-space.html =noreferrer>如何解决令人畏惧的PermGen空间异常
另外，我并不确切知道您在做什么，但是如果您可以等待JDK 7，看看 AnonymousClassLoader 。他们将被介绍来更好地支持动态语言，正如在这篇文章中所解释的那样：
我希望它能帮助你。
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.
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
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?
I always heard that Classloader unloading was problematic. They are theoretically garbage 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 Classloader from being reclaimed. In application servers, after numerous redeploy cycle, I sometimes got a 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:
I hope it will help you.
这篇关于何时以及如何将java classloader标记为垃圾收集？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
