双亲委派机制是Java类加载的核心规则：先委托父加载器加载，失败后才由当前加载器调用findClass；它通过parent引用形成委托链，而非继承，确保核心类不被替换、避免重复加载、保障类唯一性。
Java类加载器的双亲委派，核心就一句话：先让父加载器试，父不行再自己干。它不是靠继承实现的“父子”，而是每个加载器内部持有一个parent引用，形成逻辑上的委托链。
三类内置加载器的职责分工
JVM默认提供三个层级的类加载器，自上而下依次是：
-
启动类加载器（Bootstrap ClassLoader）：C++实现，不可在Java中直接获取（调用
String.class.getClassLoader()返回null）。负责加载$JAVA_HOME/jre/lib下的核心类，如java.lang.*、java.util.*等。 -
扩展类加载器（Extension ClassLoader）：Java实现，类名是
sun.misc.Launcher$ExtClassLoader。加载$JAVA_HOME/jre/lib/ext目录或java.ext.dirs指定路径下的JAR包。 -
应用程序类加载器（Application ClassLoader）：也叫系统类加载器，类名是
sun.misc.Launcher$AppClassLoader。加载classpath路径下的所有类——也就是你写的代码、引入的第三方JAR（如log4j、spring-core）。
双亲委派的具体执行流程
当你调用MyClass.class.getClassLoader().loadClass("com.example.Service")时，实际走的是ClassLoader.loadClass(String, boolean)方法，内部逻辑如下：
- 先查缓存：
findLoadedClass(name)，如果已加载过，直接返回Class对象； - 没命中缓存，就向上委托：
if (parent != null) parent.loadClass(name, false)； - 若
parent为null（即到达顶层），则调用findBootstrapClassOrNull(name)，由JVM底层尝试加载； - 所有上级都返回
ClassNotFoundException后，才轮到当前加载器调用findClass(name)——这个方法默认抛异常，需子类重写才能真正从文件、网络或数据库读取字节码。
为什么必须双亲委派？关键在三点
这个机制不是为了炫技，而是解决真实问题：
立即学习“Java免费学习笔记（深入）”；
-
防止核心类被替换：比如你自己写个
java.lang.String，放在classpath里。由于双亲委派，ApplicationClassLoader会先把请求交给Bootstrap，而Bootstrap早已加载了真正的String，所以你的假String根本不会被用到——避免恶意篡改基础API。 - 避免重复加载同一类：同一个全限定名的类，只要被任一层加载器成功加载，就会缓存在该加载器中。后续请求直接命中缓存，不走完整流程，节省内存和开销。
-
保证类的唯一性与一致性：JVM判定两个类是否相同，依据是“类全限定名 + 加载它的类加载器”。双亲委派确保像
Object这种类永远由Bootstrap加载，不同模块拿到的Object.class一定是同一个Class对象，类型转换、反射、instanceof才不会出错。
怎么打破双亲委派？慎用！
想绕过默认流程，常见方式是自定义加载器并重写loadClass方法——跳过委托步骤，直接调用findClass。但要注意：
- Tomcat就是这么做的：每个Web应用用独立的
WebAppClassLoader，优先加载WEB-INF/classes和lib，再委派给父加载器，实现应用间类隔离； - OSGi、某些热部署框架也打破委派，但代价是复杂度陡增——可能引发
NoClassDefFoundError、LinkageError或静态变量多份副本等问题； - 除非明确需要类隔离或动态加载（如插件系统），否则不建议手动打破。
基本上就这些。
