Thread.currentThread().getContextClassLoader()和Class.getClassLoader的区别

阅读数:104 评论数: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

秒吧学习