概述

class物理文件加载到JVM内存中，可以有多种加载方式：

3种JDK自带的ClassLoader.
自定义的ClassLoader（重写ClassLoader）
反射、JDK动态代理、CGLIB也可以实现运行期编译生成一个新的java对象

类的加载器和核心类

核心类加载器

BootstrapClassLoader 最顶层的加载类,负责加载lib下的rt.jar、resources.jar、charsets.jar和class等
ExtentionClassLoader 加载目录%JRE_HOME%\lib\ext目录下的jar包和class文件
AppClassLoader 加载当前应用的classpath的所有类
自定义ClassLoader，可以突破class文件包路径的限制，可以修改类加载机制（比如热加载），需要重写findClass()缓存查找方法制定寻找路径即可

加载的特点

不同包路径下的类由不同的类加载器加载
jvm懒加载，根据需要去动态加载
父加载器不是父类，双亲委托：自下而上，先挨个找缓存，到了顶层缓存中还没有，就开始初始化，从各自对应负责的包路径下查找，有就创建，没有给就子加载器加载
加载之后存在缓存当中

加载的结果

将class文件加载在内存中。
将静态数据结构(数据存在于class文件的结构)转化成方法区中运行时的数据结构(数据存在于JVM时的数据结构)。
在堆中生成一个代表这个类的java.lang.Class对象，作为数据访问的入口。

核心方法： loadClass、 findLoadedClass、parent.loadClass、findBootStrapClass、findClass

自定义类加载器

实现自定义class文件加载路径，实现，class文件包路径的限制

https://www.cnblogs.com/gdpuzxs/p/7044963.html

实现逻辑：写一个classloader类（构造函数里面需要传入包真实的路径），重写findClass方法，

public class MyClassLoader extends ClassLoader{
    public MyClassLoader(String classpath) {
        this.classpath = classpath;
    }

    @Override
    protected Class<?> findClass(String name) throws ClassNotFoundException {
        try {
            byte [] classDate=getDate(name);
            
            if(classDate==null){}
            
            else{
                return defineClass(name,classDate,0,classDate.length);
            }
            
        } catch (IOException e) {
            
            e.printStackTrace();
        }
        
        return super.findClass(name);
    }
}

实现类的每次重新加载，实现热加载

本来重写 findLoadedClass()即可，直接返回null，实现热加载，但是ClassLoader把该方法设置为final了，不希望去破坏这个规则
所以直接通过重写过的findClass来实现,相当于在上面的基础上做修改，findClass的路径为当前路径，每次loadClass，直接调用findClass方法即可，虽然只能修改本地的class类
findClass需要defineClass来最终把字节码文件加载进内存当中，JVM默认相同的类加载器不能加载相同全路径的类，所以每次重新加载的时候需要new一个自定义加载器，否则会报错

    String currentPath=Class.class.getClass().getResource("/").getPath()

    MyClassLoader myClassLoader=new MyClassLoader(currentPath);
    Class c=myClassLoader.findClass("com.test.Action.Test");
    
    MyClassLoader myClassLoader2=new MyClassLoader(currentPath);
    Class c2=myClassLoader2.findClass("com.test.Action.Test");

tomcat的类加载模型

tomcat本身也是一个依赖JDK的应用
tomcat/bin目录下有自己的jar包需要AppClassLoader加载：tomcat-juli.jar、bootstrap.jar等等
每个独立的应用有自己的class路径，通过WebappClassloader加载，应用也依赖JDK的加载，所以应用的类加载机制：缓存加载-->AppClassLoader JDK系统加载-->自己加载-->父类加载

核心加载器

CommonClassLoader（默认父加载器为AppClassLoader）。加载一些tomcat/lib下面的jar包，servlet-api.jar、jsp-api.jar等
catalinaClassLoader（默认是空，有需要的话需要自己配置）
sharedClassLoader（默认是空，有需要的话需要自己配置）
WebAppClassLoader（tomcat下 WebRoot/应用程序/WEB-INF/lib 和 class包下的类

层级结构

tomcat下每个应用程序都有一个独立的类加载器，WebAppClassLoader，因为不同应用程序的类不能乱加载，更不能公用啊。
但是有一些通用的类，比如JUnit、Log4j类，是不同应用程序公用的类，所以有sharedClassLoader出场，可以设置路径来实现这个类加载器，从而实现不同应用程序共同加载一些通用工具类
再上一层就是CommonClassLoader：下面由shardClassLoader和CatalinaClassLoader，一个是所有应用程序，一个是tomcat容器的扩展类加载器
再上一层就是AppClassLoader了，就是传统的模式往上走了

加载逻辑（源码 org.apache.catalina.loader.WebappClassLoader#loadClass)
tomcat的类加载机制是违反了双亲委托原则的:先本地缓存查找，再全局缓存查找，再系统加载，再自己加载，最后再父加载器加载

先在本地缓存中查找是否已经加载过该类（clazz = findLoadedClass0(name)）
再查询JVM缓存中查找是否已经加载过该类（ clazz = findLoadedClass(name)）
让系统类加载器(AppClassLoader)尝试加载该类，主要是为了防止一些基础类会被web中的类覆盖（tomcat bin下包)（clazz = system.loadClass(name)）
web应用的类加载器将自行加载（findClass),这里也违背了双亲（clazz = findClass(name);）
最后还是加载不到的话，则委托父类加载器(Common ClassLoader)去加载。（clazz = Class.forName(name, false, parentLoader);）

反射和Spring IOC

反射是运行期编译，只有执行到这个方法，确定了参数:类名的时候才编译出对应的class文件，再加载到内存当中
Class tc = Class.forName("com.java.dbtest.TestConnection");
CGLIB也是运行期编译，Enhancer类继承代理类，拦截相应的方法，实现代理