在什么场景下我们会使用 Thread.getContextClassLoader() 和 ClassLoader.getSystemClassLoader() 可以理解吗？答案

【问题标题】：In where scenario we will use Thread.getContextClassLoader() and ClassLoader.getSystemClassLoader() can instand of it?在什么场景下我们会使用 Thread.getContextClassLoader() 和 ClassLoader.getSystemClassLoader() 可以理解吗？
【发布时间】：2012-03-15 14:32:10
【问题描述】：

通过谷歌我确实找不到如何使用 Thread.getContextClassLoader() 的示例，

也许这个问题是重复的，如下所示 Difference between thread's context class loader and normal classloader

我的问题是回顾如下：我知道使用 Thread.getContextLoader 的场景，因为 /lib/rt.jar 中包含的 JNDI 核心类但是那些JNDI Core（也许它们只是一些接口）没有bean实现，在其他工作中如果你想使用JNDI的功能你必须提供一个 JNDI 的实现，然后我们将这些实现（可能是 jars）放入系统类路径中，但是现在核心 JDNI 类由 Bootstrap 加载，这些核心类必须使用它的实现类，好的，我们为他提供一个 Thread.getContextClassLoader()（如果你没有任何操作默认是 ClassLoader.getSystemClassLoader()），它现在可以加载那些，我只是想为什么核心 JNDI 类使用这种方式直接获取 systemClassLoader 'ClassLoader.getSystemClassLoader()'？

也许我解释的一些观点不正确..

但我只是想了解我们是否可以使用 ClassLoader.getSystemClassLoader() 代替 Thread.getClassLoader() 加载系统类路径类或类中的资源由引导类加载器加载？

【问题讨论】：

在你想把你的程序弄得一团糟的地方使用getContextClassLoader。

标签： java classloader

【解决方案1】：

Thread.getContextClassLoader() 不是从一开始就被引入 java 的。它在多类加载器环境中非常有用，很快对于在容器中运行的 Java EE 应用程序，通常为每个企业应用程序分配私有类加载器。因此，可以使用上下文类加载器检索与此应用程序一起打包的资源。

它也用于日志系统的自我配置，如 commons logging 和 log4j。

【讨论】：

是的，感谢您的及时评论，我已重命名此问题标题（也许我必须这样做以澄清我的疑问），您能解释一下为什么这些类（由引导程序加载）使用 Thread.getContextClassLoader () 作为一个类加载器来加载那些放在 -classpath 中的类，我认为 Thread.getContextClassLoader() 的返回结果与 ClassLoader.getSystemClassLoader() 相同，但是为什么我们不能使用 ClassLoader.getSystemClassLoader() 替换 contextCloadr 来获取资源也许我们真的可以做到？