Java 线程上下文类加载器 - 它是如何工作的？

Question

我在互联网上找到了 OSGi 的以下加载器结构。

bootstrap classloader (Java standard libraries from jre/lib/rt.jar etc)
^
extension classloader
^
system classloader (ie stuff on $CLASSPATH, OSGi core code)
^ (** limited access to types from parent classloader
common OSGi classloader:
--|-- OSGi classloader for bundle1 -> (map of imported-package->classloader)
--|-- OSGi classloader for bundle2 -> (map of imported-package->classloader)
--|-- OSGi classloader for bundle3 -> (map of imported-package->classloader)

Here上面写着

A context classloader set on the executing thread. By default it is always set to System classloader or from the thread from where the new thread instance was created.

从上面的结构我们看到系统加载器(=上下文加载器)有更高的位置，据我所知，父类加载器从不询问它的 child 。

所以我的问题请解释当前线程如何与当前包中的类一起工作？

Answer 1

在 OSGi 中，线程上下文类加载器 (TCCL) 只是未定义。你不能期望或断言它会是任何特别的东西。事实上，很多时候它将是 null。

TCCL 是在 Java 1.2 中添加的一种 hack，用于支持 J2EE。具体来说，它需要支持像 Entity Beans 这样的东西；在现代世界中，它用于支持 JPA、JAXB、Hibernate 等技术。

双亲委派的问题在于，虽然底部的应用程序类可以看到父类加载器中的所有类，但不幸的是，父类加载器加载的类不可以看到应用程序类。实际上，这意味着您的应用程序代码可以加载(比方说)构成 Hibernate 的类，但 Hibernate 将无法加载您的领域类，因为它们在层次结构中位于它之下。

于是，TCCL 应运而生。在 J2EE 应用程序服务器中，TCCL 被创建为线程局部变量，并且它对您的所有应用程序类具有可见性。 Hibernate/JPA/JAXB 等可以查阅 TCCL 以找到应用程序类。这在 J2EE 中很容易做到，因为应用服务器控制所有入口点:它控制 Web 服务器，它控制 RMI 端点，并且作为应用程序开发人员，您不能创建自己的线程。

然而，OSGi 的编程环境受到的限制要少得多。任何 bundle 都可以创建自己的网络端点，启动自己的线程，或者几乎可以做任何事情。因此，OSGi 没有机会干预和强加具有应用程序类可见性的 TCCL。此外，“应用程序”的概念很模糊，因为我们有一个叫做模块化 的简洁的东西。一个应用程序由多个 bundle 组成...但是如何定义哪些 bundle 可以向 TCCL 提供类？

所以 OSGi 在这个问题上基本上是赌注。 TCCL 是未定义的，所以你不应该依赖它。幸运的是，大多数尝试使用的库仅将其作为他们尝试从中加载类的一系列位置之一。