Java中的类加载器层级结构是怎样的_Bootstrap/Ext/App各司其职-java教程-PHP中文网

java类加载器是父子委托链（bootstrap→ext→app），bootstrap无父类且不可获取；getsystemclassloader()返回appclassloader因其为应用默认加载器；class.forname()触发初始化并使用上下文类加载器，loadclass()不初始化且用显式实例；自定义加载器应重写findclass()而非loadclass()以保障双亲委派安全。

java中的类加载器层级结构是怎样的_bootstrap/ext/app各司其职

Java类加载器不是并列关系，而是父子委托链：Bootstrap → Ext → App，但App类加载器的父级是Ext，Ext的父级是Bootstrap——而Bootstrap本身没有父类加载器（它由C++实现）。

为什么`ClassLoader.getSystemClassLoader()`返回的是AppClassLoader而不是Bootstrap

因为JVM启动后，应用代码默认由AppClassLoader加载，它负责加载-cp或CLASSPATH指定的路径；getSystemClassLoader()这个方法名里的“system”指的是“系统默认给应用用的”，不是“JVM系统级”的意思。Bootstrap和Ext不对外暴露实例，你拿不到它们的Java对象引用。

BootstrapClassLoader用C++写在JVM里，Java层连类名都没有（null）
ExtClassLoader和AppClassLoader是java.lang.ClassLoader子类，能拿到实例
调用getClassLoader()查一个类的加载器时，String.class.getClassLoader()返回null，这就是Bootstrap在起作用

`Class.forName()`和`ClassLoader.loadClass()`委托行为差异

两者都走双亲委派，但触发时机不同：前者默认会初始化类（执行static块），后者只加载不初始化；更重要的是，Class.forName(String)内部用的是当前线程上下文类加载器（Thread.currentThread().getContextClassLoader()），而loadClass()用的是显式调用它的那个ClassLoader实例。

Java JDK 25

Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。

下载

Web容器中，Class.forName("com.mysql.jdbc.Driver")能成功，靠的是线程上下文类加载器被设为Web应用自己的URLClassLoader
直接用AppClassLoader.loadClass("com.mysql.jdbc.Driver")可能失败——如果驱动jar不在CLASSPATH里，而是在WEB-INF/lib下
自定义类加载器若没重写loadClass()，默认仍走双亲委派；想绕过就得重写并避免调用super.loadClass()

自定义`ClassLoader`时，为什么`findClass()`比`loadClass()`更安全

因为loadClass()默认包含双亲委派逻辑，如果你直接重写它又忘了调用父类，就可能破坏核心类（比如自己加载一个假的java.lang.Object），导致NoClassDefFoundError甚至JVM崩溃；而findClass()是空壳，专门留给子类实现“从哪找字节码”，由父类loadClass()统一调度。

正确姿势：继承ClassLoader，重写findClass(String name)，在里面读取字节码、调用defineClass()
错误姿势：重写loadClass(String name)却不调用super.loadClass(name)，等于废掉双亲委派
注意defineClass()对类名和文件路径有强校验——传入com.example.Foo，字节码里ClassName字段必须严格匹配，否则抛ClassFormatError

真正容易被忽略的是：双亲委派不是语法强制，而是ClassLoader.loadClass()的默认实现逻辑；一旦你重写了它，又没手动转发，整个层级就断了——这时候连java.util.ArrayList都可能加载失败，报错却只显示ClassNotFoundException，看不出是委派链断了还是路径错了。