1 自定义类加载器
自定义类加载器的代码很简单，只需要继承ClassLoader类，覆写findClass方法即可
其默认实现是会抛出一个异常：
import java.io.FileInputStream; public class MyClassLoader extends ClassLoader { private String classPath; public MyClassLoader(String classPath) { this.classPath = classPath; } private byte[] loadByte(String name) throws Exception { name = name.replaceAll("\\.", "/"); FileInputStream fis = new FileInputStream(classPath + "/" + name + ".class"); int len = fis.available(); byte[] data = new byte[len]; fis.read(data); fis.close(); return data; } @Override protected Class<?> findClass(String name) { byte[] data = new byte[0]; try { data = loadByte(name); } catch (Exception e) { e.printStackTrace(); } return defineClass(name, data, 0, data.length); }}这里是会读取指定的类路径classPath下的class文件。
相应的测试代码如下所示：
public class MyClassLoaderTest { public static void main(String[] args) throws Exception { MyClassLoader classLoader = new MyClassLoader("D:/test"); Class clazz = classLoader.loadClass("com.hys.test.User"); System.out.println(clazz.getClassLoader().getClass().getName()); }}这里以User类代码为例，将其class文件放到D:/test指定目录下：
随后需要注意的是，需要将当前工作空间中的User.java文件删除。
如果不删除，根据双亲委派模型，该类会由AppClassLoader来加载，不会由自定义的的MyClassLoader来进行加载，最后运行测试代码
结果如下：
2 打破双亲委派模型
在像一些Tomcat的源码中，WebappClassLoader会打破双亲委派机制。这里我们也来简单模拟一下。
实现代码依然很简单，只需要在上述MyClassLoader类中覆写loadClass方法即可，如下：
@Overrideprotected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException { synchronized (getClassLoadingLock(name)) { Class<?> c = findLoadedClass(name); if (c == null) { c = findClass(name); } if (resolve) { resolveClass(c); } return c; }}这里loadClass方法的代码使用的是父类ClassLoader的源码，然后把其中使用双亲委派的代码删掉，这样MyClassLoader不用再向上去找类加载器，只会在本类中处理，这样就打破了双亲委派模型。
然后因为运行时需要加载Object类，所以将Object.class文件复制到D:/test目录下
如下所示：
随后再次运行测试类
结果如下：
可以看到，java.lang包的代码禁止被自定义的类加载器加载，防止核心API被篡改。
这是Java内部的安全检查机制。这里我们这种写法是将所有的类都交由MyClassLoader来处理，所以无法加载Java核心的类库，但是Tomcat中的类加载机制只是自定义的WebappClassLoader和CommonClassLoader打破了双亲委派模型，而其上面的BootstrapClassLoader、ExtensionClassLoader和AppClassLoader仍然还是会走双亲委派的，所以不会有问题。
以上为个人经验，希望能给大家一个参考，也希望大家多多支持。