加载过程

1) 加载:根据查找路径找到相应的class文件,然后导入。类的加载方式分为隐式加载和显示加载两种。
隐式加载指的是程序在使用new关键词创建对象时,会隐式的调用类的加载器把对应的类加载到jvm中。
显示加载指的是通过直接调用class.forName()方法来把所需的类加载到jvm中。
作用:
将外部的Class文件加载到JVM虚拟机&存储到方法区内
具体流程:
通过类的全限定名来获取定义此类的二进制字节流
在内存中生产一个代表这个类的java.lang.class对象,作为方法区该类的各种数据的访问入口
注:
数组类通过Java虚拟机直接创建,不通过类加载器创建

2) 验证:检查夹加载的class文件的正确性,符合Java虚拟机的要求,代码逻辑不会损坏虚拟机。
(文件格式校验、元数据校验、字节码校验、符号引用验证)

3) 准备;给类中的静态变量分配内存空间,设置类变量(static)的初始值。将变量的初始值设置为0,并不是开发者定义的值
注意:
实列变量不在该阶段分配内存
若类变量被final修饰,直接会赋值成开发者定义的值

4) 解析:虚拟机将常量池中的符号引用替换成直接引用的过程。符号引用就理解为一个标示,
而在直接引用直接指向内存中的地址。

5) 初始化:对静态变量和静态代码块执行初始化工作。

自定义类加载器的代码很简单,

只需要继承ClassLoader类,覆写findClass方法即可,其默认实现是会
抛出一个异常:

public class MyClassLoader extends ClassLoader {
        private String classPath;
        public MyClassLoader(String classPath) {
            this.classPath = classPath;
        }
        private byte[] loadByte(String name) throws Exception {
            name = name.replaceAll("\\.", "/");
            FileInputStream fis = new FileInputStream(classPath + "/" + name +
                    ".class");
            int len = fis.available();
            byte[] data = new byte[len];
            fis.read(data);
            fis.close();
            return data;
        }
        @Override
        protected Class<?> findClass(String name) {
            byte[] data = new byte[0];
            try {
                data = loadByte(name);
            } catch (Exception e) {
                e.printStackTrace();
            }
            return defineClass(name, data, 0, data.length);
        }
    }

这里是会读取指定的类路径classPath下的class文件。相应的测试代码如下所示:

 public class MyClassLoaderTest {
        public static void main(String[] args) throws Exception {
            MyClassLoader classLoader = new MyClassLoader("D:/test");
            Class clazz = classLoader.loadClass("com.hys.test.User");
            System.out.println(clazz.getClassLoader().getClass().getName());
        }
    }

图片说明
随后需要注意的是,需要将当前工作空间中的User.java文件删除。如果不删除,根据双亲委派模型,该
类会由AppClassLoader来加载,不会由自定义的的MyClassLoader来进行加载,
图片说明

打破双亲委派模型

在像一些Tomcat的源码中,WebappClassLoader会打破双亲委派机制。这里我们也来简单模拟一下。
实现代码依然很简单,只需要在上述MyClassLoader类中覆写loadClass方法即可,如下:

   @Override
    protected Class<?> loadClass(String name, boolean resolve) throws  ClassNotFoundException {
        synchronized (getClassLoadingLock(name)) {
            Class<?> c = findLoadedClass(name);
            if (c == null) {
                c = findClass(name);
            }
            if (resolve) {
                resolveClass(c);
            }
            return c;
        }

这里loadClass方法的代码使用的是父类ClassLoader的源码,然后把其中使用双亲委派的代码删掉,这
样MyClassLoader不用再向上去找类加载器,只会在本类中处理,这样就打破了双亲委派模型。
然后因为运行时需要加载Object类,所以将Object.class文件复制到D:/test目录下(test/java/lang/Object.class)

java.lang包的代码禁止被自定义的类加载器加载,防止核心API被篡改。这是Java内部的安全检查机制。
这里我们这种写法是将所有的类都交由MyClassLoader来处理,所以无法加载Java核心的类库,
但是
Tomcat中的类加载机制只是自定义的WebappClassLoader和CommonClassLoader打破了双亲委派模型,
而其上面的BootstrapClassLoader、ExtensionClassLoader和AppClassLoader仍然还是会走双亲
委派的,所以不会有问题

Tomcat 的类加载器是怎么设计的?

我们思考一下:Tomcat是个web容器, 那么它要解决什么问题:
1. 一个web容器可能需要部署两个应用程序,不同的应用程序可能会依赖同一个第三方类库的不同版
本,不能要求同一个类库在同一个服务器只有一份,因此要保证每个应用程序的类库都是独立的,
保证相互隔离。

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

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

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

再看看我们的问题:Tomcat 如果使用默认的类加载机制行不行?
答案是不行的。为什么?我们看,

第一个问题,如果使用默认的类加载器机制,那么是无法加载两个相同类库的不同版本的,默认的累加
器是不管你是什么版本的,只在乎你的全限定类名,并且只有一份。

第二个问题,默认的类加载器是能够实现的,因为他的职责就是保证唯一性。

第三个问题和第一个问题一样。我们再看

第四个问题,我们想我们要怎么实现jsp文件的热修改(楼主起的名字),jsp 文件其实也就是class文
件,那么如果修改了,但类名还是一样,类加载器会直接取方法区中已经存在的,修改后的jsp是不会重
新加载的。那么怎么办呢?我们可以直接卸载掉这jsp文件的类加载器,所以你应该想到了,每个jsp文
件对应一个唯一的类加载器,当一个jsp文件修改了,就直接卸载这个jsp类加载器。重新创建类加载
器,重新加载jsp文件

四个重要的加载器:

commonLoader:Tomcat最基本的类加载器,加载路径中的class可以被Tomcat容器本身以及各个Webapp访问;
catalinaLoader:Tomcat容器私有的类加载器,加载路径中的class对于Webapp不可见;
sharedLoader:各个Webapp共享的类加载器,加载路径中的class对于所有Webapp可见,但是对于Tomcat容器不可见;
WebappClassLoader:各个Webapp私有的类加载器,加载路径中的class只对当前Webapp可见;
很显然,tomcat 为了实现隔离性,每个webappClassLoader加载自己的目录下的class文件,不会传递给父类加载器。

我们扩展出一个问题:如果tomcat 的 Common ClassLoader 想加载 WebApp ClassLoader 中的类,该怎么办?

看了前面的关于破坏双亲委派模型的内容,我们心里有数了,我们可以使用线程上下文类加载器实现,
使用线程上下文加载器,可以让父类加载器请求子类加载器去完成类加载的动作。牛逼吧。

ClassLoader cl = Thread.currentThread().getContextClassLoader();

这条语句获取本地线程然后实现上下类加载。牛逼了,所以这个地方Bootstrap Classloader加载器拿到
了Application ClassLoader加载器应该加载的类,就打破了双亲委派模型