Thread.currentThread().getContextClassLoader()和Class.getClassLoader的区别
阅读数:166 评论数:0
跳转到新版页面分类
python/Java
正文
一、概述
1、两种类加载方式的选择
前者是最安全的方法。
比如,如果你使用Test.class.getClassLoader(),可能会导制和当前线程所运行的类加载器不一致。(因为Java是多线程的)
Test.class.getClassLoader一般用在getResource,因为资源文件的位置相对是固定的。
2、父级优先加载机制(双亲委派加载机制)
如果一个类加载器收到了类加载的请求,它首先不会自己去加载这个类,而是把请求委托给父加载器去完成,依次向上,只有当父加载器没有找到所需的类时,子加载器才会尝试去加载该类。
这种加载机制的好处:
(1)避免类的重复加载。
(2)核心API类型不会被随意替换。
二、JAVA类加载器
JVM启动一个项目的时候,它将缺省使用以下三种类加载器:
1.启动(Bootstrap)类加载器
负载装载JAVA_HOME/lib下的核心类库或-Xbootclasspath选项指定的jar包。程序无法直接获取此加载器,无法对其进行任何操作。
2.扩展(Extension)类加载器
扩展类加载器由sun.misc.Laucher.ExtClassLoader实现的。负载加载JAVA_HOME/lib/ext或者由系统变量-Djava.ext.dir指定位置中的类库。程序可以访问并使用此加载器。
3.系统(System)类加载器
由sun.misc.Laucher.AppClassLoader实现,也叫应用程序类加载器,负载加载系统类路径-classpath或-Djava.class.path变量所指定的目录下的类库。
这里的父子并不是继承。
protected Class<?> loadClass(String name, boolean resolve)
throws ClassNotFoundException
{
synchronized (getClassLoadingLock(name)) {
// 若本加载器之前是否已加载过,直接取缓存,native方法实现
Class c = findLoadedClass(name);
if (c == null) {
try {
// 只要有父加载器就先委派父加载器来加载
if (parent != null) {
// 注意此处递归调用
c = parent.loadClass(name, false);
} else {
// ext的parent为null,因为Bootstrap是无法被程序被访问的,默认parent为null时其父加载器就是Bootstrap
// 此时直接用native方法调用启动类加载加载,若找不到则抛异常
c = findBootstrapClassOrNull(name);
}
} catch (ClassNotFoundException e) {
// 对ClassNotFoundException不做处理,仅用作退出递归
}
if (c == null) {
// 如果父加载器无法加载那么就在本类加载器的范围内进行查找
// findClass找到class文件后将调用defineClass方法把字节码导入方法区,同时缓存结果
c = findClass(name);
}
}
// 是否解析,默认false
if (resolve) {
resolveClass(c);
}
return c;
}
}
三、理解线程上下文类加载器
ThreadContextClassLoader,下文使用TCCL表示。
Java提供了很多服务提供者接口(Service Provider Interface, SPI),允许第三方为这些接口提供实现。常见的SPI有JDBC、JCE、JNDI、JAXP和JBI等。
这些SPI的接口由Java核心库来提供,而这些SPI的实现代码则作为Java应用所依赖的jar包被包含进classpath里。SPI接口中的代码经常需要加载具体的实现类,那么问题来了,SPI的接口是Java核心库的一部分,是由启动类加载器(Bootstrap Classloader)来加载的,SPI的实现类是由系统类加载器(System ClassLoader)来加载的。引导类加载器是无法找到SPI的实现类的,因为依照双亲委派模型,BootrapClassLoader无法委派AppClassLoader来加载类。
而线程上下文类加载器破坏了“双亲委派模型”,可以在执行线程中抛弃双亲委派加载链模式,使用程序可以逆向使用类加载器。
JDBC案例分析
// 加载Class到AppClassLoader(系统类加载器),然后注册驱动类
// Class.forName("com.mysql.jdbc.Driver").newInstance();
String url = "jdbc:mysql://localhost:3306/testdb";
// 通过java库获取数据库连接
Connection conn = java.sql.DriverManager.getConnection(url, "name", "password");
以上就是mysql注册驱动及获取connection的过程,可以发现经常写的Class.forName被注释掉了,但依然可以正常运行,这是为什么呢?这是因为从Java 1.6开始自带的jdbc 4.0版本已支持SPI服务加载机制,只要mysql的jar包在类的路径上,就可以注册mysql驱动。
那到底是哪一步自动注册了mysql driver的呢?重点就是DriverManager.getConnection()中。DriverManager的静态代码块:
static {
loadInitialDrivers();
println("JDBC DriverManager initialized");
}
private static void loadInitialDrivers() {
String drivers;
try {
// 先读取系统属性
drivers = AccessController.doPrivileged(new PrivilegedAction<String>() {
public String run() {
return System.getProperty("jdbc.drivers");
}
});
} catch (Exception ex) {
drivers = null;
}
// 通过SPI加载驱动类
AccessController.doPrivileged(new PrivilegedAction<Void>() {
public Void run() {
ServiceLoader<Driver> loadedDrivers = ServiceLoader.load(Driver.class);
Iterator<Driver> driversIterator = loadedDrivers.iterator();
try{
while(driversIterator.hasNext()) {
driversIterator.next();
}
} catch(Throwable t) {
// Do nothing
}
return null;
}
});
// 继续加载系统属性中的驱动类
if (drivers == null || drivers.equals("")) {
return;
}
String[] driversList = drivers.split(":");
println("number of Drivers:" + driversList.length);
for (String aDriver : driversList) {
try {
println("DriverManager.Initialize: loading " + aDriver);
// 直接获取当前系统类加载器(即AppClassloader),与TCCL相同(详情请看之前写的文章末尾处:[java类加载器不完整分析](https://blog.csdn.net/yangcheng33/article/details/52464898))
Class.forName(aDriver, true,
ClassLoader.getSystemClassLoader());
} catch (Exception ex) {
println("DriverManager.Initialize: load failed: " + ex);
}
}
}
Java SPI的具体约定,当服务的提供者提供了服务接口的一种实现之后,在jar包的META-INF/services/目录里同时创建一个以服务接口命名的文件。该文件里就是实现该服务接口的具体的实现类。而当外部程序装配这个模块的时候,就能通过该jar包META-INF/services/里的配置文件找到具体的实现类名,并装载实例化,完成模块的注入。基于这样一个约定就能很好的找到服务接口的实现类,而不需要在代码里制定,jdk提供服务实现查找的工具类:java.util.ServiceLoader.
注意driverInterator.next()最终调用Class.forName(DriverName,false,loader)方法,这个loader是怎么来的?因为forName在类java.util.ServiceLoader中,而ServiceLoader.class又加载在BootrapLoader中,因为传给forName的loader必然不能是BootstrapLoader,所以需要使用TCCL,而TCCL默认使用当前执行代码所在应用的系统类加载器AppClassLoader。
再看下ServiceLoader.load(Class)代码,的确如此:
public static <S> ServiceLoader<S> load(Class<S> service) {
ClassLoader cl = Thread.currentThread().getContextClassLoader();
return ServiceLoader.load(service, cl);
}
最后欢迎大家访问我的个人网站:1024s