类加载机制

1、类加载分为：加载、验证、准备、解析、初始化、使用、卸载几个阶段

加载

通过类限定名找到类的二进制字节流，转化为方法区运行时数据结构，在内存中生成class对象。

验证

确保class文件的字节流包含的信息符合约束要求，不会危害虚拟机安全

准备

正式为类中定义的变量分配内存设置类变量初始值的阶段

解析

将常量池中符号引用替换为直接引用的过程

初始化

虚拟机执行类中编写的Java程序

2、类加载器

类加载器用于在加载阶段获取所需要的类，三个重要的系统提供的类加载器：启动类加载器（bootstrap classloader）、扩展类加载器（extension classloader）、应用程序类加载器（application classloader）

双亲委派模型的工作过程是：如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加

 

载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有

 

的加载请求最终都应该传送到最顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加

 

载请求（它的搜索范围中没有找到所需的类）时，子加载器才会尝试自己去完成加载。

 

使用双亲委派模型来组织类加载器之间的关系，一个显而易见的好处就是Java中的类随着它的类

 

加载器一起具备了一种带有优先级的层次关系。例如类java.lang.Object，它存放在rt.jar之中，无

 

论哪一个类加载器要加载这个类，最终都是委派给处于模型最顶端的启动类加载器进行加载，因此

 

Object类在程序的各种类加载器环境中都能够保证是同一个类。反之，如果没有使用双亲委派模

 

型，都由各个类加载器自行去加载的话，如果用户自己也编写了一个名为java.lang.Object的类，

 

并放在程序的ClassPath中，那系统中就会出现多个不同的Object类，Java类型体系中最基础的行

 

为也就无从保证，应用程序将会变得一片混乱。

 

3、破坏双亲委派

双亲委派模型的第一次“被破坏”其实发生在双亲委派模型出现之前——即JDK 1.2面世以前的“远古”时代。由于双亲委派模型在JDK 1.2之后才被引入，但是类加载器的概念和抽象类java.lang.ClassLoader则在Java的第一个版本中就已经存在，面对已经存在的用户自定义类加载器的代码，Java设计者们引入双亲委派模型时不得不做出一些妥协，为了兼容这些已有代码，无法再以技术手段避免loadClass()被子类覆盖的可能性，只能在JDK 1.2之后的java.lang.ClassLoader中添加一个新的protected方法findClass()，并引导用户编写的类加载逻辑时尽可能去重写这个方法，而不是在loadClass()中编写代码。如果父类加载失败，会自动调用自己的findClass()方法来完成加载，这样既不影响用户按照自己的意愿去加载类，又可以保证新写出来的类加载器是符合双亲委派规则的。

 

双亲委派模型的第二次“被破坏”是由这个模型自身的缺陷导致的，双亲委派很好地解决了各个类

加载器协作时基础类型的一致性问题（越基础的类由越上层的加载器进行加载），基础类型之所以被称为“基础”，是因为它们总是作为被用户代码继承、调用的API存在，但程序设计往往没有绝对不变的完美规则，如果有基础类型又要调用回用户的代码，那该怎么办呢？这并非是不可能出现的事情，一个典型的例子便是JNDI服务，JNDI现在已经是Java的标准服务，它的代码由启动类加载器来完成加载（在JDK 1.3时加入到rt.jar的），肯定属于Java中很基础的类型了。但JNDI存在的目的就是对资源进行查找和集中管理，它需要调用由其他厂商实现并部署在应用程序的ClassPath下的JNDI服务提供者接口（Service Provider Interface，SPI）的代码，现在问题来了，启动类加载器是绝不可能认识、加载这些代码的，那该怎么办？为了解决这个困境，Java的设计团队只好引入了一个不太优雅的设计：线程上下文类加载器（Thread Context ClassLoader）。这个类加载器可以通过java.lang.Thread类的setContext-ClassLoader()方法进行设置，如果创建线程时还未设置，它将会从父线程中继承一个，如果在应用程序的全局范围内都没有设置过的话，那这个类加载器默认就是应用程序类加载器。有了线程上下文类加载器，程序就可以做一些“舞弊”的事情了。JNDI服务使用这个线程上下文加载器去加载所需的SPI服务代码，这是一种父类加载器去请求子类加载器完成类加载的行为，这种行为实际上是打通了双亲委派模型的层次结构来逆向使用类加载器，已经违背了双亲委派模型的一般性原则，但也是无可奈何的事情。Java中涉及SPI的加载基本上都采用这种方式来完成，例如JNDI、JDBC、JCE、JAXB和JBI等。不过，当SPI的服务提供者多于一个的时候，代码就只能根据具体提供者的类型来硬编码判断，为了消除这种极不优雅的实现方式，在JDK 6时，JDK提供了java.util.ServiceLoader类，以META-INF/services中的配置信息，辅以责任链模式，这才算是给SPI的加载提供了一种相对合理的解决方案。

 

双亲委派模型的第三次“被破坏”是由于用户对程序动态性的追求而导致的，这里所说的“动态性”指的是一些非常“热”门的名词：代码热替换（Hot Swap）、模块热部署（Hot Deployment）等。说

白了就是希望Java应用程序能像我们的电脑外设那样，接上鼠标、U盘，不用重启机器就能立即使用，鼠标有问题或要升级就换个鼠标，不用关机也不用重启。对于个人电脑来说，重启一次其实没有什么大不了的，但对于一些生产系统来 说，关机重启一次可能就要被列为生产事故，这种情况下热部署就对软件开发者，尤其是大型系统或企业级软件开发者具有很大的吸引力。OSGi实现模块化热部署的关键是它自定义的类加载器机制的实现，每一个程序模块（OSGi中称为Bundle）都有一个自己的类加载器，当需要更换一个Bundle时，就把Bundle连同类加载器一起换掉以实现代码的热替换。

 

我们知道JVM虚拟机采用双亲委派模式来加载类，而且在类加载的整个过程中只有在加载阶段可以别程序员操作，加载器通过类的全限定名在class文件的二进制流中加载类，并创建类的唯一一个class对象，作为类的全局访问点。我们知道为了实现程序的动态性，我们可以自定义类加载器，通过重写findClas（）方法来实现自定义类加载器，再通过重写loadClass()方法打破双亲委派机制，这是一次打破双亲委派，那么还有一种就是使用线程上下文类加载器来打破双亲委派机制。

典型应用就是我们知道java提供一些第三方服务接口（SPI），用的最多的就是jdbc接口，提供数据库服务，允许不同的第三方来实现，但是我们需要来java代码中加载第三方驱动，获得具体的实现代码使用jdbcDriver连接数据库
（1）首先要导入数据库jar包

（2）加载驱动，创建连接

// Class.forName("com.mysql.jdbc.Driver"); 

con=DriverManager.getConnection("jdbc:mysql://localhost:3306/tsetjdbc","root", "123456");
其实我们发现没有第一句也能正常执行，原因就是线程上下文类加载器。

我们知道当调用DriverManager的静态方法getConnection（）方法，会触动类的初始化，并且执行静态代码块，在DriverManager类中有如下静态代码块，里面调用了loadInitialDrivers()方法，

loadInitialDrivers()方法如下：我们看到使用ServiceLoader类来加载，那么我们就来介绍一下这个类

 java.util.ServiceLoader（SPI加载的工具类）

 SPI规定使用SPI实现类比价导入驱动jar包，就是我们使用数据库第一步要做的事情，然后会生成META-INF文件夹，下面生成services包里面生成对应的文件（service文件），然后通过ServiceLoader的load()方法来加载。我们知道ServiceLoader类是加载在BootrapLoader中，但是service的jar路径又是在用户目录下，应该用ApplicationClassLoader来加载，但是根据双亲委派BootrapLoader类加载不到，这时候就会使用线程上下文类加载器，在JVM中会把当前线程的类加载器加载不到的类交给线程上下文类加载器来加载，直接使用Thread.currentThread().getContextClassLoader()来获得，默认返回的就是应用程序类加载器，也可以通过java.lang.Thread类的setContextClassLoader()方法进行设置。