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

Question

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

引导类加载器（来自 jre/lib/rt.jar 的 Java 标准库 等）
^
扩展类加载器
^
系统 类加载器（即 $CLASSPATH 上的东西，OSGi 核心代码）
^ (** 限制从父类加载器访问类型
common OSGi 类加载器：
--|-- 用于 bundle1 的 OSGi 类加载器->（导入包的映射->类加载器）
--|-- 用于 bundle2 的 OSGi 类加载器->（导入包的映射->类加载器）
--|-- bundle3 的 OSGi 类加载器 -> (imported-package->classloader 的映射)

Here 上面写着

在执行线程上设置的上下文类加载器。默认情况下是 始终设置为 System classloader 或从新的线程 线程实例已创建。

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

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

Answer 1

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

TCCL 是在 Java 1.2 中添加的一个 hack，用于支持 J2EE。具体来说，它需要支持实体 Bean 之类的东西；在现代世界中，它用于支持 JPA、JAXB、Hibernate 等技术。

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

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

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

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