关于Java类加载机制的几个基本概念：
- JDK提供的基本类加载器：引导类加载器（Bootstrap Class Loader）－用于加载JDK中的核心类、扩展类加载器（Ext Class Loader）－用于加载JRE扩展库目录中的类、系统（应用）类加载器（System/App Class Loader）－用于从启动参数-classpath或环境变量CLASSPATH中加载类；
- 类加载器的树状结构：在JVM中，所有类加载器实例按树状结构组织，根结点为引导类加载器。除根结点外的所有类加载器都有一个非空的父类加载器，从而构成树状结构；
- 双亲委托（代理）模型：当类加载器收到加载类或资源的请求时，通常都是先委托给父类加载器加载，也就是说只有当父类加载器找不到指定类或资源时，自身才会执行实际的类加载过程；
- 类的判等：即使类完全相同（名称相同、字节码相同），不同类加载器实例加载的类对象也是不相等的；这一条规则是Java类加载机制中非常核心且重要的规则，它保证了类加载机制实现“类隔离”、“保护JDK中的基础类”等目标得以实现；
- 线程上下文类加载器机制：在Java中我们和类加载机制打交道的最简单的方法是通过Class.forName方法来加载类，该方法默认情况下是以调用者的类加载器来加载指定的类。这在大多数情况下都足够了，少数情况下我们可以使用和线程关联的类加载器来加载类（即线程上下文类加载器）。线程上下文类加载器通常在实现JDK的SPI或编写框架程序时使用；
- 类的垃圾回收：只有当类加载器可被作为垃圾回收的前提下，其加载的类才有可能被回收；
Java的类加载机制涉及的概念并不多，但是要真正理解，可能还需要花一些功夫。下面以问答的形式谈谈我对Java类加载机制的理解：
- Q：JDK为什么要提供三个类基本类加载器？
- A：由于类加载器本身也是一个类，它也需要加载，这就是引导类加载器必须存在的理由之一；系统类加载器是最常使用的类加载器，用于处理java命令行参数-classpath或环境变更CLASSPATH，有了系统类加载器，大多数Java应用就不需要编写自己的类加载器了；扩展类加载器呢？几乎感觉不到它的存在和作用；
- Q：JDK如何保证类加载器之间形成树状结构？
- A：所有类加载器必须从ClassLoader类派生，该类的构造器保证了所有类加载器一定存在一个父类加载器，这就保证了树状结构的形成。不过，父类加载器其实是可以为null的，Java的类加载机制中将null视为引导类加载器；
- Q：双亲委托模型是必须的吗？
- A：双亲委托模型只能算是JDK的“最佳实践”，自己编写类加载器时，完全可以不遵循双亲委托模型。类似Tomcat这样的WEB容器就实现了与双亲委托模型相反的机制，即加载类时总是先在自身中加载，加载不到时再到父加载器中加载；
- Q：是否可以通过类加载机制实现应用重写JDK中的类？
- A：不可以！自定义的类加载器主要功能是实现字节码的加载，将字节码转换为Class对象的方法是在ClassLoader类中定义的。ClassLoader方法在从字节码构建Class对象的方法中控制了要加载的类名不能以"java."开头；即所有java包及其子包中的类都不允许通过类加载机制重载；
- Q：编写框架程序和普通程序在动态类加载方面有没有什么不同？
- A：普通程序通常不需要考虑类加载机制，如果需要动态加载类，一般使用最简单的Class.forName(String)方法就够了；但编写框架程序时，往往不能这么简单地处理，原因是你不清楚要动态加载的类是否能被加载框架类的类加载器所加载，这时通常可以使用线程上下文类加载器动态加载类；
参考资料：