多线程中类加载器的行为答案

【问题标题】：The behavior of the classloader in multiple threads多线程中类加载器的行为
【发布时间】：2019-01-18 20:46:17
【问题描述】：

如何理解

在多线程环境中，由于类加载器不同，您可能会遇到类型转换异常

我看到Spring的源代码是关于这个的：

public static ClassLoader getDefaultClassLoader() {
    ClassLoader classLoader = null;
    try {
        classLoader = Thread.currentThread().getContextClassLoader();
    } catch (Throwable ex) {
        ex.printStackTrace();
    }
    if (classLoader == null) {
        // No thread context class loader -> use class loader of this class
        classLoader = ClassUtil.class.getClassLoader();
        if (classLoader == null) {
            // getClassLoader() returning null indicates the bootstrap ClassLoader
            try {
                classLoader = ClassLoader.getSystemClassLoader();
            } catch (Throwable ex) {

            }
        }
    }
    return classLoader;
}

我不明白他们为什么选择 Thread.currentThread().getContextClassLoader() 作为首选？

有人告诉我导致类加载器的行为在多线程中可能会有所不同

说实话，我看不懂

【问题讨论】：

请显示该声明来源的链接以及您可以提供的任何相关背景/背景信息
“有人告诉我，因为类加载器的行为在多线程中可能会有所不同”——他们没有错，但你引用的 sn-p 非常令人困惑。 多类加载器 环境是问题的常见来源，而不是多线程。将不同的类加载器与不同的线程相关联很少会导致问题（除非这些类加载器本身有问题）。但是拥有多个类加载器确实会导致各种问题。

标签： java multithreading jvm classloader

【解决方案1】：

Thread.currentThread().getContextClassLoader() 将是自然的首选，因此不同的上下文可以可靠地设置它们的私有类加载器覆盖。虽然大多数情况下，附加类加载器用于加载低级类加载器未提供的类，但另一种用途是在某些上下文中使用某些类的特定实现。

当这与一个类的类型标识包含加载该类的类加载器这一事实相结合时，就有可能拥有两个具有相同（绝对）类名但仍不属于同一类型的类。

【讨论】：

鉴于各自的线程中有不同的类加载器，如果它们都可以加载一个名为com.test.test的类（但实际上是不同的类），那么在多线程环境中是可能的当另一个类加载器加载该类时，可能会发生意外情况，然后出现类型转换问题。