Java 代码执行流程

类加载过程

加载 -> 验证 -> 准备 -> 解析 -> 初始化 -> 使用 -> 卸载

类加载时机：代码使用到这个类时

验证阶段

".class”加载到内存里之后，必须先验证一下，校验他必须完全符合JM规范，后续才能交给VM来运行。

准备阶段

给加载的类分配内存空间

给类变量（static 修饰）分配内存空间

给类变量赋默认初始值

解析阶段

实际上就是把符号引用替换为直接引用的过程

加载 -> 验证 -> 准备 -> 解析：分配类内存空间，分配类变量内存空间，类变量赋默认值。

初始化阶段

类初始化代码：

public class ReplicaManager {
public static int flushInterval = Configuration.getInt( "replica.flush.interval");
}

准备阶段会给变量分配内存空间和初始值 0

初始化阶段会执行代码 Configuration.getInt( "replica.flush.interval"); 读取配置并赋值。

类初始化的时机：

1.当创建某个类的新实例时（如通过new或者反射，克隆，反序列化等）

2.当调用某个类的静态方法时

3.当使用某个类的接口或静态字段时

4.调用Java API中的某些反射方法时，比如类Class中的方法，或者java.lang.reflect中的类的方法时

5.当初始化某个子类时

6.当虚拟机启动某个被标明为启动类的类

类加载器和双亲委派机制

启动类加载器

Bootstrap ClassLoader：负责加载 java 安装目录（lib）下的核心类

扩展类加载器

Extension ClassLoader：负责加载 java 安装目录（lib\ext）下的扩展类

应用程序类加载器

Application ClassLoader：负责加载 “ClassPath” 环境变量所指定的路径中的类，即写好的 java 代码

自定义类加载器

自定义的类加载器，根据自己需求加载类

双亲委派机制图解

类加载器加载类时不会尝试自己去加载，而是会去询问自己的上级类加载器能否加载这个类，

以此类推，直到顶级类加载器，父级加载器无法完成加载就会下推加载权力给子类加载器，

这就是所谓的双亲委派机制：先找父级加载，未找到就交给子级加载。优势：避免重复加载，防止核心库被篡改

Tomcat 类加载机制

对于任意一个类，都需要由加载它的类加载器和这个类本身一同确立其在Java虚拟机中的唯一性，

每—个类加载器，都拥有一个独立的类名称空间。

也就是说，判断2个类是否“相等”，只有在这2个类是由同一个类加载器加载的前提下才有意义，

否则即使这2个类来源于同一个Class文件，被同一个虚拟机加载，只要加载它们的类加载器不同，这2个类必定不相等。

基于双亲委派模型设计，那么Java中基础的类，类似Object类重复多次的问题就不会存在了，

因为经过层层传递，加载请求最终都会被Bootstrap ClassLoader所响应。

加载的Object类也会只有一个，否则如果用户自己编写了一个java.lang.0bject类，并把它放到了ClassPath中，

会出现很多个Object类，这样Java类型体系中最最基础的行为都无法保证，应用程序也将一片混乱

打破双亲委派机制则不仅要继承ClassLoader类，还要重写loadClass和findClass方法。

tomcat需要破坏双亲委派模型的原因：

(1)tomcat中的需要支持不同web应用依赖同一个第三方类库的不同版本，jar类库需要保证相互隔离；

(2)同一个第三方类库的相同版本在不同web应用可以共享

(3)tomcat自身依赖的类库需要与应用依赖的类库隔离

(4)jsp需要支持修改后不用重启tomcat即可生效为了上面类加载隔离和类更新不用重启，定制开发各种的类加载器