(String name, boolean resolve)

　　 throws ClassNotFoundException{

　　 // First check if the class is already loaded

　　 Class c = findLoadedClass(name);

　　 if (c == null) {

　　 try {

　　　　 if (parent != null) {

　　　　　　 c = parent.loadClass(name, false);

　　　　 } else {

　　　　　　 c = findBootstrapClass0(name);

　　　　 }

　　 } catch (ClassNotFoundException e) {

　　　　 // If still not found, then invoke

　　　　 // findClass to find the class.

　　　　 c = findClass(name);

　　 }

　　 }

　　 if (resolve) {

　　　　 resolveClass(c);

　　 }

　　 return c; 　　} 　　我们可以使用ClassLoader的两种构造方法来设置父类加载器:

　　public class MyClassLoader extends ClassLoader{

　　 public MyClassLoader(){

　　 super(MyClassLoader.class.getClassLoader());

　　 } 　　} 　　或

　　public class MyClassLoader extends ClassLoader{

　　 public MyClassLoader(){

　　 super(getClass().getClassLoader());

　　 } 　　} 　　第一种方式较为常用，因为通常不建议在构造方法里调用getClass()方法，因为对象的初始化只是在构造方法的出口处才完全完成。因此，如果父类加载器被正确建立，当要示从一个类加载器的实例获得一个类时，如果它不能找到这个类，它应该首先去访问其父类。如果父类不能找到它(即其父类也不能找不这个类，等等)，而且如果findBootstrapClass0()方法也失败了，则调用findClass()方法。findClass()方法的缺省实现会抛出ClassNotFoundException，当它们继承java.lang.ClassLoader来订制类加载器时开发者需要实现这个方法。findClass()的缺省实现方式如下:

　　 protected Class findClass(String name)

　　 throws ClassNotFoundException {

　　 throw new ClassNotFoundException(name);

　　 }

　　在findClass()方法内部，类加载器需要获取任意来源的字节码。来源可以是文件系统，URL，数据库，可以产生字节码的另一个应用程序，及其他类似的可以产生java规范的字节码的来源。你甚至可以使用BCEL (Byte Code Engineering Library:字节码工程库)，它提供了运行时创建类的捷径。BCEL已经被成功地使用在以下方面:编译器，优化器，混淆器，代码产生器及其他分析工具。一旦字节码被检索，此方法就会调用defineClass()方法，此行为对不同的类加载实例是有差异的。因此，如果两个类加载实例从同一个来源定义一个类，所定义的结果是不同的。

　　JAVA语言规范(Java language specification)详细解释了JAVA执行引擎中的类或接口的加载(loading)，链接(linking)或初始化(initialization)过程。

　　图一显示了一个主类称为MyMainClass的应用程序。依照之前的阐述，MyMainClass.class会被AppClassLoader加载。 MyMainClass创建了两个类加载器的实例:CustomClassLoader1 和 CustomClassLoader2,他们可以从某数据源(比如网络)获取名为Target的字节码。这表示类Target的类定义不在应用程序类路径或扩展类路径。在这种情况下，如果MyMainClass想要用自定义的类加载器加载Target类，CustomClassLoader1和CustomClassLoader2会分别独立地加载并定义Target.class类。这在java中有重要的意义。如果Target类有一些静态的初始化代码，并且假设我们只希望这些代码在JVM中只执行一次，而这些代码在我们目前的步骤中会执行两次——分别被不同的CustomClassLoaders加载并执行。如果类Target被两个CustomClassLoaders加载并创建两个实例Target1和Target2，如图一显示，它们不是类型兼容的。换句话说，在JVM中无法执行以下代码:

　　Target target3 = (Target) target2;

　　以上代码会抛出一个ClassCastException。这是因为JVM把他们视为分别不同的类，因为他们被不同的类加载器所定义。这种情况当我们不是使用两个不同的类加载器CustomClassLoader1 和 CustomClassLoader2，而是使用同一个类加载器CustomClassLoader的不同实例时，也会出现同样的错误。这些会在本文后边用具体代码说明。

关于类加载、定义和链接的更多解释，请参考Andreas Schaefer的"Inside Class Loaders."

　　为什么我们需要我们自己的类加载器

　　原因之一为开发者写自己的类加载器来控制JVM中的类加载行为，java中的类靠其包名和类名来标识，对于实现了java.io.Serializable接口的类，serialVersionUID扮演了一个标识类版本的重要角色。这个唯一标识是一个类名、接口名、成员方法及属性等组成的一个64位的哈希字段，而且也没有其他快捷的方式来标识一个类的版本。严格说来，如果以上的都匹配，那么则属于同一个类。

　　但是让我们思考如下情况:我们需要开发一个通用的执行引擎。可以执行实现某一特定接口的任何任务。当任务被提交到这个引擎，首先需要加载这个任务的代码。假设不同的客户对此引擎提交了不同的任务，凑巧，这些所有的任务都有一个相同的类名和包名。现在面临的问题就是这个引擎是否可以针对不同的用户所提交的信息而做出不同的反应。这一情况在下文的参考一节有可供下载的代码样例，samepath 和 differentversions，这两个目录分别演示了这一概念。在samepath 中，类version.Version保存在v1和v2两个子目录里，两个类具有同样的类名和包名，唯一不同的是下边这行: