java - 何时以及如何将 java 类加载器标记为垃圾收集？

Question

我们正在创建多个子类加载器，以将多个子应用程序加载到 Java 应用程序“容器”中，对热部署进行原型(prototype)设计。当特定类加载器的类路径发生更改(即添加、删除、更新 jar)时，旧的类加载器将被丢弃(未引用)，并为新的 jar 类路径创建一个新的类加载器。

更新类路径后，触发热部署，我们进行了堆转储。堆转储(使用内存分析器)表明旧的类加载器没有被垃圾收集。父类加载器中的某些类正在缓存旧的类加载器。调用了以下内容来清除这些缓存:

java.lang.ResourceBundle.clearCache(classLoader);
org.apache.commons.logging.LogFactory.release(classLoader);
java.beans.Introspector.flushCaches();

即使在清除了上述缓存之后，旧的类加载器仍然没有被垃圾回收。对类加载器的其余引用包括以下内容:

• 类加载器加载的类
• java.lang.Package 由类加载器自己创建
• 类加载器自己创建的java.lang.ProtectionDomain

以上都是类加载器中的循环引用，应该会触发垃圾回收。我不确定为什么不是。有谁知道为什么即使使用循环引用，旧的类加载器仍然没有被垃圾收集？

Answer 1

我一直听说 Classloader 卸载有问题。他们是 theoretically当没有对对象实例的引用并且不需要卸载类时收集垃圾，但实际上它似乎更有问题。微妙的引用可能会泄漏并阻止 Classloader 被回收。在应用服务器中，经过多次重新部署循环，我有时会遇到 OutOfMemoryError: PermGen space。

所有这一切都是说我猜某处有一个讨厌的引用阻止它被收集——也许内存分析器没有正确地跟踪链接。正如这些文章中所述，这一切似乎都可能发生:

• Classloader leaks: the dreaded PermGen space exception
• How to fix the dreaded PermGen space exception

另外，我不知道你在做什么，但如果你可以等待 JDK 7，你可以看看 AnonymousClassLoader。将引入它们以更好地支持动态语言，如本文所述:

• A first taste of InvokeDynamic

希望对你有帮助。