java类加载

类加载机制
虚拟机把class文件加载到内存，并对数据进行校验，转换解析和初始化，形成可以被虚拟机直接使用的java类型，即java.lang.Class

1. 装载（Load）

查找和导入class文件

a) 通过一个类的全限定名获取定义次类的二进制字节流

b) 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构

c) 在java堆中生成一个代表这个类的java.lang.Class对象，作为对方法区中这些数据的访问入口。

2. 链接（Link）

2.1 验证（Verify）

保证被加载类的正确性

• 文件格式验证
• 元数据验证
• 字节码验证
• 符号引用验证

2.2 准备（Prepare）

为类的静态变量分配内存，并将其初始化为默认值

2.3 解析（Resolve）

把类中的符号引用转换为直接引用

3.初始化

---

对类的静态变量，静态代码块执行初始化操作

类装载器ClassLoader

在装载（Load）阶段，其中第（1）步：通过类的全限定名获取其定义的二进制字节流，需要借助类装载器完成，顾名思义，就是用来装载Class文件的。

1.分类

• Bootstrap ClassLoad 负责加载$JAVA_HOME中jre/lib/rt.jar里所有的class或Xbootclasspath选项指定的jar包。由C++实现，不是ClassLoader子类
• Extension ClassLoader负责加载java平台中扩展功能的一些jar包，包括$JAVA_HOME中jre/lib/*.jar或-Djava.ext.dirs指定目录下的jar包。
• App ClassLoader负责加载classpath中指定的jar包及Djava.class.path所指定目录下的类和jar包。
• Custom ClassLoader通过java.lang.ClassLoader的子类自定义加载class，属于应用程序根据自身需要定义的ClassLoader，如tomcat、jboss都会根据j2ee规范自行实现ClassLoader.

2.加载原则

检查某个类是否已经加载：顺序是自底向上，从Custom ClassLoader到BootStrap ClassLoader逐层检查，只要某个ClassLoader已加载，就视为已加载此类，保证此类只被所有ClassLoader加载一次。

加载顺序:加载的顺序是自顶向下，也就是由上层来逐层尝试加载此类。

双亲委派机制:

定义：如果一个类加载器在接到加载类的请求时，它首先不会自己尝试去加载这个类，而是把这个请求任务委托给父类加载器完成，依次递归，如果父类加载器可以完成此类加载任务，就成功返回；只有父类加载器无法完成此加载任务时，才自己去加载。

优势：Java类随着加载它的类加载器一起聚类一种优先级的层次关系。比如：java中的Object类，它存放在rt.jar之中，无论哪一个类加载器需要加载这个类，最终都是委派给处于模型最顶端的启动类加载器进行加载，因此Object在各种类加载环境中都是同一个类。如果不采用双亲委派模型，那么由各个类加载器自己去加载的话，那么系统中会存在多种不同的Object类。

破坏双亲委派模型

线程上下文类加载器

双亲委派模型并不能解决Java应用开发中会遇到的类加载器的全部问题。

Java提供了很多服务提供者接口（SPI），允许第三方为这些接口提供实现。

常见的SPI有JDBC,JCE,JNDI,JAXP和JBI等。这些SPI的接口由Java核心库提供，如JAXP的SPI接口定义包含在javax.xml.parses中。

这些SPI的实现代码很可能是作为Java应用所依赖的jar包被包含进来，可以通过类路径（ClassPath）来找到，如实现了JAXP SPI的Apache Xerces锁包含的jar包。SPI接口中的代码经常需要加载具体的实现类。如JAXP中的javax.xml.parses.DocumentBuilderFactory类中的newInstance()方法用来生成一个新的DocumentBuilderFactory的实例。

这里的实例的真正的类是继承自java.xml.parsers.DocumentBuilderFactory，由SPI的实现锁提供的。

而问题在于，SPI的接口是Java核心库的一部分，由Bootstrap类加载器加载的，而SPI实现的Java类一般是由系统类加载器加载的。引导类加载器是无法找到SPI的实现类的，因为它只加载Java的核心库。

它也不能委派给系统类加载器，因为它是系统类加载器的祖先类加载器。也就是说，类加载器的双亲委派模型无法解决这个问题。

为了解决这个问题，Java设计团队只好引入了一个不太优雅的设计：线程上下文类加载器（Thread Context ClassLoader）

有了线程上下文类加载器，就可以做一些“舞弊”的事情了，JNDI服务使用这个线程上下文类加载器去加载所需要的SPI代码，也就是父类加载器请求子类加载器去完成类加载器的动作，这种行为实际上就是打通了双亲委派模型的层次结构来逆向使用类加载器，已经违背了双亲委派模型的一般性原则。

JDBC为什么要破坏双亲委派模型

因为类加载器收到加载范围的限制，在某些情况下父类加载器无法加载到需要的文件，这时候就需要委托子类加载器去加载class文件。

JDBC的Driver接口定义在JDK中，其实现由各个数据库的服务商来提供，比如MySQL驱动包。DriverManager类中要加载各个实现了Driver接口的类，然后进行管理，但是DriverManager位于$JAVA_HOME中jre/lib/rt.java包，由BootStrap类加载器加载，而其Driver接口的实现类是位于服务商提供的jar包，

根据类加载机制，当被状态的类引用了另外一个类的时候，虚拟机就会使用装载第一个类的类装载器装载被引用的类。

这就是说BootStrap类加载器还要去加载jar包中的Driver接口的实现类。
我们知道，BootStrap类加载器默认只负责加载$JAVA_HOME中的jre/lib/rt.jar里的所有的class，所以需要由子类加载器去加载Driver实现，这就破坏了双亲委派模型。

Tomcat为什么要破坏双亲委派模型

每个Tomcat的webappClassLoader加载自己的目录下的class文件，不会传递给父类加载器

事实上，tomcat之所以造了一堆自己的classLoader，大致是出于下面三个目的：

• 对于各个webapp中的class和lib，需要相互隔离，不能出现一个应用加载的类库会影响另一个应用的情况，而对于许多应用，需要共享的lib以便不浪费资源。

• 与jvm一样的安全性问题。使用单独的classloader去装载tomcat自身的类库，以免其他恶意或无意的破坏。

• 热部署。