破坏双亲委派模型的情况

破坏双亲委派模型

双亲委派主要出现过三次较大规模的“被破坏”的情况。

• JDK1.2之后，为避免loadClass()被子类覆盖的可能，建议用户重写findClass()方法
• JNDI作为java的标准服务，需要调用启动类加载器不认识的外部接口（其他厂商实现的）
• IBM公司OSGI实现模块化热部署的关键是自定义类加载器机制，更换Bundle（程序模块）时，类加载器也会被换掉，然而类加载机制与双亲委派机制不同。

第一种情况

• 问题：类加载器的概念和抽象类的概念在java的第一个版本中就出现了，但是在jdk1.2及以前并没有双亲委派机制，所以当java设计者想要引入双亲委派机制时就不得不做出一点妥协，包含兼容用户自己自己的代码（用户自定义类加载器的代码），无法再以技术手段避免loadClass()被子类覆盖的可能性。
• 解决：java设计者想出的办法是在java.lang.ClassLoader()中添加一个新的protected方法findClass()，并引导用户编写类加载逻辑时尽可能去重=写这个方法，而不是在loadClass中编写代码。

loadClass()：先检查请求加载的类型是否已经被加载过，若没有则调用父加载器的loadClassQ方法，若父加载器为空则默认使用启动类加载器作为父加载器。假如父类加载器加载失败，抛出 ClassNotFoundException异常的话，才调用自己的findClass()方法尝试进行加载。

protected synchronized Classc<?> 1oadClass(String name，boolean resolve) throw
classNotFoundException{
	//首先，检查请求的类是否已经被加载过了
    Class c = findLoadedclass(name);
    if (c == null){
		try {
		if (parent != null) {
				c = parent.loadClass(name,false);
        } else {
				c = findBootstrapClassOrNull(name);
        }
		}catch (ClassNotFoundException e){
		//如果父类加载器抛出classNotFoundException
		//说明父类加载器无法完成加载请求
        }
		if (c == null）{
		//在父类加载器无法加载时
		//再调用本身的findclass方法来进行类加载c = findclass (name);
    }
	if (resolve) {
        resolveClass(c);
    }
    return c;
}

第二种情况

• 问题：JNDI服务是java的标准服务，其代码是由启动类加载器加载的，属于非常基础的类型，然而JNDI的目的就会为了查找资源并对其集中管理，需要调用由其他应用厂商实现并部署 JDNI 服务提供者接口代码，所以会出现类加载器不认识和加载这些代码。
• 解决：引入线程上下文类加载器（Thread Context ClassLoader），JNDI使用这个类加载器去加载所需的SPI服务代码，这是一种父类加载器请求子类加载器完成类加载的行为，打破了双亲委派模型的层次结构来逆向使用类加载器，即违背了双亲委派模型的一般原则。

什么是SPI？

第三种情况

• 问题：用户对程序动态性的追求导致的，“动态性”指的是：代码热替换、模块化热部署。这种情况下，例如OSGi实现模块化热部署的关键是它自定义的类加载器机制的实现，每个程序模块（Bundle）都有自己的类加载器，更换一个Bundle就得替换类加载器以实现代码的热替换。
• OSGi环境下，类加载器不再使用双亲委派机制，而是使用更加复杂的网状结构。OSGi类加载搜索过程如下，

1. 将以java.*开头的类，委派给父类加载器加载。 // 符合双亲委派机制
2. 否则,将委派列表名单内的类，委派给父类加载器加载。// 符合双亲委派机制
3. 否则，将Import列表中的类，委派给Export这个类的 Bundle的类加载器加载。// 不符合，下同
4. 否则,查找当前Bundle的 ClassPath,使用自己的类加载器加载。
5. 否则,查找类是否在自己的Fragment Bundle中，如果在，则委派给Fragment Bundle的类加载器加载。
6. 否则,查找 Dynamic Import列表的 Bundle，委派给对应 Bundle的类加载器加载。
7. 否则,类查找失败。