Java 自定义类加载器实现插件式开发

最近接触Solr比较多，感觉Solr提供的插件式开发方式很酷，Solr对开发者提供了一个核心api jar包，开发者如果想扩展Solr某一项功能 比如 中文分词，只需要继承Solr提供的分词接口添加自己的实现，然后把自己的分词jar包拷贝到Solr指定目录，并在solr配置文件中配置，重启即可生效。

本文会涉及到自定义类加载，所以先介绍一下java类加载器的原理和工作机制，熟悉的同学可以直接跳过。

java类加载器

类加载器是一个用来加载类文件的类。Java源代码通过javac编译器编译成类文件。然后JVM来执行类文件中的字节码来执行程序。类加载器负责加载文件系统、网络或其他来源的类文件。有三种默认使用的类加载器：Bootstrap类加载器、Extension类加载器和System类加载器（或者叫作Application类加载器）。每种类加载器所负责加载的类也各不相同。
JVM三种预定义类型类加载器

1. Bootstrap ClassLoader : 将存放于<JAVA_HOME>\lib目录中的，或者被-Xbootclasspath参数所指定的路径中的，并且是虚拟机识别的（仅按照文件名识别，如 rt.jar 名字不符合的类库即使放在lib目录中也不会被加载）类库加载到虚拟机内存中。启动类加载器无法被Java程序直接引用
2. Extension ClassLoader : 将<JAVA_HOME>\lib\ext目录下的，或者被java.ext.dirs系统变量所指定的路径中的所有类库加载。开发者可以直接使用扩展类加载器。
3. Application ClassLoader : 负责加载用户类路径(ClassPath)上所指定的类库,开发者可直接使用。

类加载器的代理模式

类加载器在尝试自己去查找某个类的字节代码并定义它时，会先代理给其父类加载器，由父类加载器先去尝试加载这个类，依次类推。在介绍代理模式背后的动机之前，首先需要说明一下 Java 虚拟机是如何判定两个 Java 类是相同的。Java 虚拟机不仅要看类的全名是否相同，还要看加载此类的类加载器是否一样。只有两者都相同的情况，才认为两个类是相同的。即便是同样的字节代码，被不同的类加载器加载之后所得到的类，也是不同的。比如一个 Java 类 com.example.Sample，编译之后生成了字节代码文件 Sample.class。两个不同的类加载器 ClassLoaderA和 ClassLoaderB分别读取了这个 Sample.class文件，并定义出两个 java.lang.Class类的实例来表示这个类。这两个实例是不相同的。对于 Java 虚拟机来说，它们是不同的类。试图对这两个类的对象进行相互赋值，会抛出运行时异常 ClassCastException。

一句话总结就是：查找某个类的时候从下至上，加载某个类的时候从上至下。

自定义类加载器

因为我们需要加载指定路径下的jar文件，所以我们需要自定义类加载器来扫描指定路径下的jar包，代码如下：

package com.bytebeats.switcher.core;

import com.bytebeats.switcher.util.IoUtils;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import java.io.File;
import java.io.FileFilter;
import java.net.MalformedURLException;
import java.net.URL;
import java.net.URLClassLoader;

/**
 *
 * @author Ricky Fung
 * @creat