类加载

**类加载机制**

Java类如何进行加载

其中loadClass的类加载过程有如下几步： 加载 >> 验证 >> 准备 >> 解析 >> 初始化 >> 使用 >> 卸载
加载：在硬盘上查找并通过IO读入字节码文件，使用到类时才会加载，例如调用类的 main()方法，new对象等等，在加载阶段会在内存中生成一个代表这个类的 java.lang.Class对象，作为方法区这个类的各种数据的访问入口
验证：校验字节码文件的正确性 准备：给类的静态变量分配内存，并赋予默认值
解析：将符号引用替换为直接引用，该阶段会把一些静态方法(符号引用，比如 main()方法)替换为指向数据所存内存的指针或句柄等(直接引用)，这是所谓的静态链接过 程(类加载期间完成)，动态链接是在程序运行期间完成的将符号引用替换为直接引用，下 节课会讲到动态链接
初始化：对类的静态变量初始化为指定的值，执行静态代码块

类被加载到方法区中后主要包含 运行时常量池、类型信息、字段信息、方法信息、类加载器的 引用、对应class实例的引用等信息。 类加载器的引用：这个类到类加载器实例的引用 对应class实例的引用：类加载器在加载类信息放到方法区中后，会创建一个对应的Class 类型的 对象实例放到堆(Heap)中, 作为开发人员访问方法区中类定义的入口和切入点。

**

类加载器和双亲委派机制

类加载过程主要是通过类加载器来实现的，Java里有如下几种类加载器
引导类加载器：负责加载支撑JVM运行的位于JRE的lib目录下的核心类库，比如 rt.jar、charsets.jar等
扩展类加载器：负责加载支撑JVM运行的位于JRE的lib目录下的ext扩展目录中的JAR 类包
应用程序类加载器：负责加载ClassPath路径下的类包，主要就是加载你自己写的那 些类
自定义加载器：负责加载用户自定义路径下的类包
类默认使用应用程序类加载器加载Appclassloader

类加载器初始化过程：
参见类运行加载全过程图可知其中会创建JVM启动器实例sun.misc.Launcher。 sun.misc.Launcher初始化使用了单例模式设计，保证一个JVM虚拟机内只有一个 sun.misc.Launcher实例。 在Launcher构造方法内部，其创建了两个类加载器，分别是 sun.misc.Launcher.ExtClassLoader(扩展类加载器)和sun.misc.Launcher.AppClassLoader(应 用类加载器)。 JVM默认使用Launcher的getClassLoader()方法返回的类加载器AppClassLoader的实例加载我们 的应用程序。

  //Launcher的构造方法 
  public Launcher() {
	Launcher.ExtClassLoader var1;
  try {
  			//构造扩展类加载器，在构造的过程中将其父加载器设置为null
   			var1 = Launcher.ExtClassLoader.getExtClassLoader(); 
  	  } catch (IOException var10) {
   			throw new InternalError("Could not create extension class loader", var); 
	  } 
  try { 
 	      //构造应用类加载器，在构造的过程中将其父加载器设置为ExtClassLoader， 
 		  //Launcher的loader属性值是AppClassLoader，我们一般都是用这个类加载器来加载我们自己写的应用程序 
 	 	  this.loader = Launcher.AppClassLoader.getAppClassLoader(var1); 
 	  } catch (IOException var9) { 
 		 throw new InternalError("Could not create application class loader", var9); 
 	  } 
 	Thread.currentThread().setContextClassLoader(this.loader); 
 	String var2 = System.getProperty("java.security.manager");
 	 。。。 。。。 //省略一些不需关注代码 2223 
 }

双亲委派机制

这里类加载其实就有一个双亲委派机制，加载某个类时会先委托父加载器寻找目标类，找不到再 委托上层父加载器加载，如果所有父加载器在自己的加载类路径下都找不到目标类，则在自己的 类加载路径中查找并载入目标类。
比如我们的你classpath路径下的类，最先会找应用程序类加载器加载，应用程序类加载器会先委托扩展类加载 器加载，扩展类加载器再委托引导类加载器，顶层引导类加载器在自己的类加载路径里找了半天 没找到类，则向下退回加载Math类的请求，扩展类加载器收到回复就自己加载，在自己的 类加载路径里找了半天也没找到类，又向下退回Math类的加载请求给应用程序类加载器， 应用程序类加载器于是在自己的类加载路径里找类，结果找到了就自己加载了。。 双亲委派机制说简单点就是，先找父亲加载，不行再由儿子自己加载

类加载器AppClassLoader加载类的双亲委派机制源码

我们来看下应用程序类加载器AppClassLoader加载类的双亲委派机制源码，AppClassLoader 的loadClass方法最终会调用其父类ClassLoader的loadClass方法，该方法的大体逻辑如下：

1. 首先，检查一下指定名称的类是否已经加载过，如果加载过了，就不需要再加载，直接 返回。
2. 如果此类没有加载过，那么，再判断一下是否有父加载器；如果有父加载器，则由父加 载器加载（即调用parent.loadClass(name, false);）.或者是调用bootstrap类加载器来加 载。
3. 如果父加载器及bootstrap类加载器都没有找到指定的类，那么调用当前类加载器的 findClass方法来完成类加载。
4. 
   5.两张图片都是在同一个loadclass方法中,下面这张走的是上述源码中的第三步（如果父加载器及bootstrap类加载器都没有找到指定的类，那么调用当前类加载器的 findClass方法来完成类加载。）
   为什么要设计双亲委派机制？
   沙箱安全机制：自己写的java.lang.String.class类不会被加载，这样便可以防止核心 API库被随意篡改
   避免类的重复加载：当父亲已经加载了该类时，就没有必要子ClassLoader再加载一 次，保证被加载类的唯一性
   我给大家口述一下,比如你在你idea中创建一个类java.lang.String,调用这个类的一个方法,这个类的包名和类名和jdk中的类包名类名一致,在进行类加载的时候先看应用程序类加载器有没有加载该类,如果没有去扩展类加载器,如果没有去引导类加载器,因为jdk中的类都是引导类加载器加载的所以在这一步就找到了java.lang.String，然而jdk中的这个String类没有你调用的这个方法 故报错,大概就是这么个意思
   全盘负责委托机制 “全盘负责”是指当一个ClassLoder装载一个类时，除非显示的使用另外一个ClassLoder，该类 所依赖及引用的类也由这个ClassLoder载入。简单点来说加载该类的时候类中的其他类的类加载器类得加载完成，这个跟spring Bean的生命周期中依赖注入那个东西有点类似,建议同学有时间去看看spring底层
   自定义类加载器
   自定义类加载器只需要继承 java.lang.ClassLoader 类，该类有两个核心方法，一个是 loadClass(String, boolean)，实现了双亲委派机制，还有一个方法是findClass，默认实现是空 方法，所以我们自定义类加载器主要是重写findClass方法。
   打破双亲委派机制
   再来一个沙箱安全机制示例，尝试打破双亲委派机制，用自定义类加载器加载我们自己实现的类
   概述：拿刚刚的java.lang.String举例,如果我们只想用自己定义的类加载器加载自己的类,不用走双亲委派原则,
   不管是自定义类加载器还是应用程序类加载器他们都有一个共同的父类classloader，类加载时走的是classloader的loadclass方法，该方法中用的是双亲委派原则,你只需改一下自己的就行至于怎么改,有兴趣的加我想学习的加我q2668728903,密码欣欣，微信已经加满
   多一嘴,大家认为tomcat有没有打破双亲委派原则呢？有兴趣的小伙伴加我哦~~~

总结

首先c++创建jvm(不用我们操心)然后创建出引导类加载器，引导类加载器创建jvm启动器,jvm启动器创建出应用程序类加载器和扩展类加载器，类使用自己的类加载器(默认都是应用程序类加载器，可以自己自定义)加载该类(类是被加载进jvm的有兴趣的同学加我学习)，执行main方法到线程结束。