[英]The behavior of the classloader in multiple threads
如何理解
在多线程环境中,由于不同的类加载器,您可能会有类型转换异常
我看到了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()是自然的首选,因此不同的上下文可以可靠地设置其私有类加载器重写。 尽管大多数情况下,额外的类加载器用于加载较低级别的类加载器未提供的类,但另一种用法是在某些情况下使用某些类的特定实现。
当这与类的类型标识包含已加载该类的类加载器的事实结合时,就有可能使两个具有相同(绝对)类名称的类仍然不是同一类型。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.