线程的上下文类加载器和普通的类加载器之间的区别

Question

线程的上下文类加载器和普通的类加载器有什么区别？

也就是说，如果Thread.currentThread().getContextClassLoader()和getClass().getClassLoader()返回不同的类加载器对象，将使用哪一个？

Answer 1

每个类都将使用自己的类加载器来加载其他类。因此，如果ClassA.class引用ClassB.class，那么ClassB需要在ClassA或其父母的类加载器的类路径上。

线程上下文类加载器是当前线程的当前类加载器。可以从ClassLoaderC中的类创建对象，然后将其传递给ClassLoaderD拥有的线程。在这种情况下，如果对象需要加载其自己的类加载器上不可用的资源，则需要直接使用Thread.currentThread().getContextClassLoader()。

Answer 2

有一篇关于javaworld.com的文章解释了差异=> Which ClassLoader should you use

(1)

线程上下文类加载器为类加载委托方案提供了一个后门。

以JNDI为例：它的内容由rt.jar中的引导类实现（从J2SE 1.3开始），但这些核心JNDI类可以加载由独立供应商实现并可能部署在应用程序的-classpath中的JNDI提供程序。此方案要求父类加载器（在本例中为原始类加载器）加载对其子类加载器之一可见的类（例如，系统类）。正常的J2SE委派不起作用，解决方法是使核心JNDI类使用线程上下文加载器，从而在与正确委托相反的方向上有效地“隧穿”通过类加载器层次结构。

（2）来自同一来源：

这种困惑可能会持续Java一段时间。使用任何类型的动态资源加载任何J2SE API，并尝试猜测它使用的加载策略。这是一个抽样：

• JNDI使用上下文类加载器
• Class.getResource（）和Class.forName（）使用当前的类加载器
• JAXP使用上下文类加载器（从J2SE 1.4开始）
• java.util.ResourceBundle使用调用者的当前类加载器
• 通过java.protocol.handler.pkgs系统属性指定的URL协议处理程序仅在引导程序和系统类加载器中查找
• Java Serialization API默认使用调用者的当前类加载器

Answer 3

这不回答原始问题，但由于问题是高度排名和链接的任何ContextClassLoader查询，我认为重要的是回答应该使用上下文类加载器的相关问题。简答：从不使用上下文类加载器！但是当你必须调用一个缺少getClass().getClassLoader()参数的方法时，将其设置为ClassLoader。

当来自一个类的代码要求加载另一个类时，要使用的正确类加载器与调用者类（即getClass().getClassLoader()）是相同的类加载器。这是99.9％的时间工作方式，因为this is what the JVM does itself是第一次构造新类的实例，调用静态方法或访问静态字段。

如果要使用反射创建类（例如反序列化或加载可配置的命名类），执行反射的库应始终通过从应用程序接收ClassLoader作为参数来询问应用程序使用哪个类加载器。应用程序（知道需要构建的所有类）应该传递它getClass().getClassLoader()。

获取类加载器的任何其他方法都是错误的。如果一个库使用诸如Thread.getContextClassLoader()，sun.misc.VM.latestUserDefinedLoader()或sun.reflect.Reflection.getCallerClass()之类的黑客攻击，那么它就是由API缺陷引起的错误。基本上，Thread.getContextClassLoader()的存在只是因为设计ObjectInputStream API的人忘记接受ClassLoader作为参数，而这个错误一直困扰着Java社区。

也就是说，许多JDK类使用一些黑客来猜测一些类加载器使用。有些使用ContextClassLoader（当你在共享线程池上运行不同的应用程序时失败，或者当你离开ContextClassLoader null时失败），有些使用堆栈（当类的直接调用者本身是库时失败），有些使用系统class loader（这很好，只要它被记录为只使用CLASSPATH中的类）或bootstrap类加载器，有些使用上述技术的不可预测的组合（这只会让事情更加混乱）。这导致了许多牙齿的哭泣和咬牙切齿。

使用这样的API时，首先尝试查找接受类加载器作为参数的方法的重载。如果没有合理的方法，那么尝试在API调用之前设置ContextClassLoader（并在之后重置它）：

ClassLoader originalClassLoader = Thread.currentThread().getContextClassLoader();
try {
    Thread.currentThread().setContextClassLoader(getClass().getClassLoader());
    // call some API that uses reflection without taking ClassLoader param
} finally {
    Thread.currentThread().setContextClassLoader(originalClassLoader);
}

Answer 4

添加到@David Roussel答案，类可以由多个类加载器加载。

让我们了解class loader的工作原理。

来自javarevisited的javin paul博客：

ClassLoader遵循三个原则。

Delegation principle

在需要时，用Java加载类。假设您有一个名为Abc.class的特定于应用程序的类，首先加载此类的请求将来到Application ClassLoader，它将委托给它的父ExtensionLoader，它进一步委托给Primordial或Bootstrap类加载器。

• Bootstrap ClassLoader负责从rt.jar加载标准JDK类文件，它是Java中所有类加载器的父级。 Bootstrap类加载器没有任何父级。
• 扩展ClassLoader将类加载请求委托给其父级Bootstrap，如果不成功，则加载类表单jre / lib / ext目录或java.ext.dirs系统属性指向的任何其他目录
• 系统或应用程序类加载器，它负责从CLASSPATH环境变量，-classpath或-cp命令行选项，JAR中的Manifest文件的Class-Path属性加载特定于应用程序的类。
• Application类加载器是Extension ClassLoader的子类，它由sun.misc.Launcher$AppClassLoader类实现。

注意：除了Bootstrap类加载器（主要在C语言中使用本机语言实现）之外，所有Java类加载器都是使用java.lang.ClassLoader实现的。

Visibility Principle

根据可见性原则，Child ClassLoader可以看到由Parent ClassLoader加载的类，反之亦然。

Uniqueness Principle

根据这个原则，父类加载的类不应再次由Child ClassLoader加载