gpt4 book ai didi

java - 多线程中类加载器的行为

转载 作者:太空宇宙 更新时间:2023-11-04 10:15:15 25 4
gpt4 key购买 nike

如何理解

In a multi-threaded environment you might have type conversion exceptions due to different classloaders

我看到了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() 作为首选?

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

说实话,我看不懂

最佳答案

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

当这与类的类型标识包含加载该类的类加载器这一事实相结合时,可能会出现两个具有相同(绝对)类名但类型仍然不同的类。

关于java - 多线程中类加载器的行为,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/51799994/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com