Thread.currentThread().getContextClassLoader() 和 Class.getClassLoader()区别
查了一些资料也不是太明白两个的区别，但是前者是最安全的用法
|
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。。。。