类的加载机制

类加载

• 加载:

• • 获取类的字符流
  • 将类的静态数据结构解析成方法区的运行时数据结构
  • 提供一个Class对象访问方法区的数据结构

• 验证

• • 校验魔术因子，版本等

• 准备

• • 将类变量初始化成0值，final赋常量初始值

• 解析

• • 将符号引用转换成直接引用

• 初始化

• • 执行类的<clinit>方法，由编译器收集类的成员变量赋值，static块组合成此方法，绝对的线程安全。与构造函数不同，不需要显示的调用父类的<clinit>方法，虚拟机会保证。<clinit>方法对类以及接口并非必须，如果没有成员变量或者静态块，则没有此方法。

实例化

• 分配内存空间
• 初始化对象头
• 执行实例化方法

 

类加载器

• 由不同的类加载器加载得到的类在执行equal(),instance of,isAssignForm(),isInstance()返回false

 

类加载器的关系不是以继承和实现，而是采用组合实现

 

破坏双亲委派模型

之所以要采用双亲委派模型，是因为用户类要调用基础类的API，如果基础类要调用用户类的API，则要破坏双亲委派模型。实现方式，通过Thread类的setContextClassLoader()实现，父类加载器请求子类加载器实现类的加载。

JDBC由于其DriveManager依赖于Drive的实现，所以本应该由根加载器加载的类换成了系统类加载器加载。

 

Tomcat破坏双亲委派模型的原因

1. 一个web容器可能需要部署两个应用程序，不同的应用程序可能会依赖同一个第三方类库的不同版本，不能要求同一个类库在同一个服务器只有一份，因此要保证每个应用程序的类库都是独立的，保证相互隔离。

2. 部署在同一个web容器中相同的类库相同的版本可以共享。否则，如果服务器有10个应用程序，那么要有10份相同的类库加载进虚拟机，这是扯淡的。

3. web容器也有自己依赖的类库，不能于应用程序的类库混淆。基于安全考虑，应该让容器的类库和程序的类库隔离开来。

4. web容器要支持jsp的修改，我们知道，jsp 文件最终也是要编译成class文件才能在虚拟机中运行，但程序运行后修改jsp已经是司空见惯的事情，否则要你何用？ 所以，web容器需要支持 jsp 修改后不用重启。

 

我们看，第一个问题，如果使用默认的类加载器机制，那么是无法加载两个相同类库的不同版本的，默认的累加器是不管你是什么版本的，只在乎你的全限定类名，并且只有一份。第二个问题，默认的类加载器是能够实现的，因为他的职责就是保证唯一性。第三个问题和第一个问题一样。我们再看第四个问题，我们想我们要怎么实现jsp文件的热修改（楼主起的名字），jsp 文件其实也就是class文件，那么如果修改了，但类名还是一样，类加载器会直接取方法区中已经存在的，修改后的jsp是不会重新加载的。那么怎么办呢？我们可以直接卸载掉这jsp文件的类加载器，所以你应该想到了，每个jsp文件对应一个唯一的类加载器，当一个jsp文件修改了，就直接卸载这个jsp类加载器。重新创建类加载器，重新加载jsp文件