Thread.currentThread().getContextClassLoader().loadClass(className)和Class.forName(className)的区别

一、正文:

  有去看开源框架的童鞋,应该会经常看到如下代码:Thread.currentThread().getContextClassLoader().loadClass(className),那这个和Class.forName(className)有什么区别?

  带着这个问题,笔者查了一些资料,现整理分享如下,如果不当之处还望斧正:

  通常情况下,一个JVM中的所有类加载器被组织成一个层次结构,使得每一个类加载器(除了启动整个JVM的原始类加载器)都有一个父加载器。当被要求加载一个类时,每一个类加载器都将先委托父加载器来加载,只有父加载器都不能成功加载时当前类加载器才会加载(即“双亲委派”机制,想了解这方面知识的,请参见“深入探讨java类加载机制”)。在这种情况下,如下的委派链中:ClassLoader A -> System class loader -> Extension class loader -> Bootstrap class loader,委派链左边的ClassLoader就可以很自然的使用右边的ClassLoader所加载的类。但如果情况要反过来,是右边的ClassLoader所加载的代码需要反过来去找委派链靠左边的ClassLoader去加载东西怎么办呢?没辙,parent delegation是单向的,没办法反过来从右边找左边的~

  那有没有这种逆向的加载场景呢?有!通常发生在有些JVM核心代码必须动态加载由应用程序开发人员提供的资源时。以JNDI举例:它的核心内容(从J2SE1.3开始)在rt.jar中的引导类中实现了,但是这些JNDI核心类可能加载由独立厂商实现和部署在应用程序的classpath中的JNDI提供者。这个场景要求一个父类加载器(这个例子中的原始类加载器,即加载rt.jar的加载器)去加载一个在它的子类加载器(系统类加载器)中可见的类。此时通常的J2SE委托机制不能工作,解决办法是让JNDI核心类使用线程上下文加载器,从而有效建立一条与类加载器层次结构相反方向的“通道”达到正确的委托。

  知识补充:每一个线程分配一个上下文类加载器(除非线程由本地代码创建)。该加载器是通过Thread.setContextClassLoader()方法来设置。如果你在线程构造后不调用这个方法,这个线程将会从它的父线程中继承上下文类加载器。如果你在整个应用中不做任何设置,所有线程将以系统类加载器作为它们自己的上下文加载器

二、参考链接

http://hllvm.group.iteye.com/group/topic/38709

http://tyrion.iteye.com/blog/1958814

上一篇:Mac进行 usr/bin 目录下修改权限问题,operation not permitted


下一篇:Mac 更改/usr/bin 目录权限失败