JVM-类加载机制

• loadClass 的类加载过程有如下几步（使用到时才加载）：加载 >> 验证 >> 准备 >> 解析 >> 初始化 >> 使用 >> 卸载

  • 

  • 加载：在硬盘上查找并通过IO读入字节码文件，使用到类时才会加载

    • 在加载阶段会在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口

  • 验证：校验字节码文件的正确性

  • 准备：给类的静态变量分配内存，并赋予默认值

  • 解析：将符号引用替换为直接引用（静态链接过程）

    • 静态链接过程（类加载期间完成）：该阶段会把一些静态方法（符号引用，比如main()方法）替换为指向数据所存内存的指针或句柄等（直接引用）
    • 动态链接是在程序运行期间完成的将符号引用替换为直接引用

  • 初始化：对类的静态变量初始化为指定的值，执行静态代码块

• 类被加载到方法区中后主要包含：运行时常量池、类型信息、字段信息、方法信息、类加载器的引用、对应class实例的引用等信息
  • 类加载器的引用：这个类到类加载器实例的引用
  • 对应class实例的引用：类加载器在加载类信息放到方法区中后，会创建一个对应的 Class 类型的对象实例放到堆(Heap)中, 作为开发人员访问方法区中类定义的入口和切入点
• 类加载器
  • 引导类加载器：负责加载支撑JVM运行的位于JRE的lib目录下的核心类库
  • 扩展类加载器：负责加载支撑JVM运行的位于JRE的lib目录下的ext扩展目录中的JAR
  • 应用程序类加载器：负责加载 ClassPath 路径下的类包
  • 自定义加载器：负责加载用户自定义路径下的类包
• 类加载器初始化过程
  • 创建JVM启动器实例 sun.misc.Launcher （单例）
  • 在Launcher构造方法内部，创建了两个类加载器
    • sun.misc.Launcher.ExtClassLoade（扩展类加载器）
    • sun.misc.Launcher.AppClassLoader（应用类加载器）
  • JVM 默认使用 Launcher 的 getClassLoader() 方法返回的类加载器 AppClassLoader 的实例加载我们的应用程序
• 双亲委派机制：先找父亲加载，不行再由儿子自己加载

  • 

    • 加载某个类时会先委托父加载器寻找目标类
    • 找不到再委托上层父加载器加载
    • 如果所有父加载器在自己的加载类路径下都找不到目标类，则在自己的类加载路径中查找并载入目标类

  • AppClassLoader 的 loadClass 方法最终会调用其父类 ClassLoader 的 loadClass 方法

    • 首先，检查一下指定名称的类是否已经加载过，如果加载过了，就不需要再加载，直接返回
    • 如果此类没有加载过，那么，再判断一下是否有父加载器；如果有父加载器，则由父加载器加载（即调用parent.loadClass(name, false);）或者是调用 bootstrap 类加载器来加载
    • 如果父加载器及bootstrap类加载器都没有找到指定的类，那么调用当前类加载器的 findClass 方法来完成类加载

  • 为什么要设计双亲委派机制

    • 沙箱安全机制：自己写的java.lang.String.class类不会被加载，这样便可以防止核心API库被随意篡改
    • 避免类的重复加载：当父亲已经加载了该类时，就没有必要子ClassLoader再加载一次，保证被加载类的唯一性
• 自定义类加载器：继承 java.lang.ClassLoader 类，主要是重写 findClass 方法
  • 也可以重写 loadClass 方法打破双亲委派（[[…/Tomcat/Tomcat-类加载机制&热加载&热部署|Tomcat-类加载机制&热加载&热部署]]）
• 全盘负责委托机制：当一个ClassLoder装载一个类时，除非显示的使用另外一个ClassLoder，该类所依赖及引用的类也由这个ClassLoder载入
• 同一个 JVM 内，两个相同包名和类名的类对象可以共存，因为他们的类加载器可以不一样，所以看两个类对象是否是同一个，除了看类的包名和类名是否都相同之外，还需要他们的类加载器也是同一个才能认为他们是同一个

---