浅谈Java类加载

Java在加载类时，采用的是代理模式，即，类加载器在尝试自己去查找某个类的字节代码并定义它时，会先代理给其父类加载器，由父类加载器先去尝试加载这个类，以此类推。在说明代理模式背后的原因之前，首先需要说明一下Java虚拟机是如何判定两个java类是相同的。Java虚拟机不仅要看类的全名是否相同，还要看加载此类的类加载器是否一样。只有两者都相同，才认为两个类时相同的。即便是同样的字节代码，被不同的类加载器加载之后所得到的类，也是不同的，如果此时试图对这两个类的对象进行相互赋值，会抛出运行时异常ClassCastException。
了解到这一点，就可以理解代理模式的设计动机了。代理模式是为了保证Java核心库的类型安全，所有的Java应用都至少需要引用java.lang.Object类，也就是说在运行时，java.lang.Object这个类需要被加载到Java虚拟机中。如果这个过程由Java应用自己的类加载器来完成的话，很可能就存在多个版本的java.lang.Object类，可是这些类之间是不兼容的。通过代理模式，对于Java核心库的类的加载工作由引导类加载器统一完成，保证了Java应用所使用的都是同一个版本的Java核心库的类，是相互兼容的。
Java中的类加载器大致可以分为两类，一类是系统提供的，另外一类则是由Java应用开发人员编写的。系统提供的类加载器主要有下面三个：

• 引导类加载器 (bootstrap class loader)：它用来加载Java的核心库，是用原生代码实现的，并不继承自java.lang.ClassLoader。
• 扩展类加载器 (extensions class loader)：它用来加载Java的扩展库。Java虚拟机的实现会提供一个扩展库目录。该类加载器在此目录里面查找并加载Java类。
• 系统类加载器 (system class loader)：它根据Java应用的类路径(CLASSPATH)来加载Java类。一般来说，Java应用的类都是由它来完成加载的。可以通过ClassLoader.getSystemClassLoader()来或其它。

除了系统提供的类加载器以外，开发人员可以通过继承java.lang.ClassLoader类的方式实现自己的类加载器。
除了引导类加载器以外，所有的类加载器都有一个父类加载器。对于系统提供的类加载器来说，系统类加载器的父类加载器是扩展类加载器，而扩展类加载器的父类是引导类加

载器。一般来说，开发人员编写的类加载器的父类加载器是系统类加载器。