Thread.currentThread().getContextClassLoader()

忘记以前有没有问过这个问题,总之我现在有看到几个地方有这个:
Thread.currentThread().getContextClassLoader()
我总是想不出在什么情况下会用这种方式获得一个ClassLoader,因为好像默认情况下,它返回的是和加载应用的ClassLoader是同一个,比如说在一个类Test中写
ClassLoader cl = Thread.currentThread().getContextClassLoader();
为何不直接用Test.class.getClassLoader()

获得当前上下文的类加载器是啥意思?有啥好处?

 

 

 

Java code

?

1 2 3 4 5 6 7 8 9 10 11

public class Test { public static void main(String[] args) { // 此时三个ClassLoader是同一个对象 System.out.println(Thread.currentThread().getContextClassLoader()); // 当前线程的类加载器 System.out.println(Test. class .getClassLoader()); // 当前类的类加载器 System.out.println(ClassLoader.getSystemClassLoader()); // 系统初始的类加载器 } }

如果楼主了解过openfire应该对ClassLoader有比较深的理解。
打个简单的比方，你一个WEB程序，发布到Tomcat里面运行。
首先是执行Tomcat org.apache.catalina.startup.Bootstrap类，这时候的类加载器是ClassLoader.getSystemClassLoader()。
而我们后面的WEB程序，里面的jar、resources都是由Tomcat内部来加载的，所以你在代码中动态加载jar、资源文件的时候，首先应该是使用Thread.currentThread().getContextClassLoader()。如果你使用Test.class.getClassLoader()，可能会导致和当前线程所运行的类加载器不一致（因为Java天生的多线程）。
Test.class.getClassLoader()一般用在getResource，因为你想要获取某个资源文件的时候，这个资源文件的位置是相对固定的。

java的类加载机制（jvm规范）是委托模型，简单的说，如果一个类加载器想要加载一个类，首先它会委托给它的parent去加载，如果它的所有parent都没有成功的加载那么它才会自己亲自来，有点儿像儿子使唤老子的感觉。。jvm也拼爹啊，，，，，
在jvm中默认有三类loaer，bootstrap，ext，app，其中boot最大是爷爷，app最小是孙子，ext中间是爹。
它们有权限访问的classpath也不一样，boot是jdk或jre下面的lib目录，ext是jdk或jre的ext目录，而app是由用户指定的路径，比如用-cp参数指定的目录或jar。他们没有权力访问其他人的classpath，这样问题就来鸟，，，，可能有人会问狗司令大人闲得蛋疼啊，搞这么复杂，据说是为了安全考虑，避免用户的恶心意代码侵蚀jvm，，问题就是当bootstrap或ext想要加载用户指定classpath中的类就会失败，因为这俩货没有权限访问团app路径中的类的，，所以就搞了这么一个不伦不类的contextloader。。。。