双亲委派模型是什么
在Java的世界里，类加载机制是运行时环境的重要组成部分。而“双亲委派模型”就是这套机制中的核心设计之一。它不是指父母共同委托孩子办事，而是描述了类加载器之间的一种层级关系和协作方式。
当你运行一个Java程序时，虚拟机会需要加载各种类，比如你写的Main类，或者用到的String、ArrayList这些系统类。但类从哪里来？谁负责加载？怎么避免重复加载？这些问题都由类加载器（ClassLoader）来处理。JVM里有多个类加载器，它们像家族一样分层管理。
类加载器的层级结构
最常见的三类加载器分别是：启动类加载器（Bootstrap ClassLoader）、扩展类加载器（Extension ClassLoader）和应用类加载器（Application ClassLoader）。它们之间形成一条向上的链条。
比如你的代码中用到了java.lang.String这个类。JVM不会直接让应用类加载器去加载，而是先交给它的“父”加载器去尝试。这个过程就像孩子遇到问题先问爸妈，爸妈搞不定再找爷爷。
工作流程：先问爹，再自己上
当一个类加载器收到加载类的请求时，它不会立刻自己动手，而是先把请求委派给父类加载器去完成。每一层都这么做，直到最顶层的启动类加载器。如果父类加载器无法加载（比如在它的路径下找不到），才会由子类加载器尝试自己加载。
这种自上而下的委派过程，保证了像Object、String这类核心类始终由最可信的启动类加载器加载，避免被开发者自定义的类冒名顶替。试想一下，如果有人写了个伪造的java.lang.String，放在项目里，没有双亲委派，系统可能就会加载这个恶意类，后果不堪设想。
代码视角看流程
虽然我们通常不手动实现类加载器，但了解其逻辑有助于理解机制。下面是简化版的类加载流程示意：
protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
synchronized (getClassLoadingLock(name)) {
// 先查看是否已经被加载
Class<?> c = findLoadedClass(name);
if (c == null) {
try {
if (parent != null) {
c = parent.loadClass(name, false);
} else {
c = findBootstrapClassOrNull(name);
}
} catch (ClassNotFoundException e) {
// 父类加载器加载失败
}
if (c == null) {
// 父类加载器都没搞定，自己来
c = findClass(name);
}
}
if (resolve) {
resolveClass(c);
}
return c;
}
}这段代码体现了“先委派，后自己干”的原则。只有在父类加载器无法完成任务时，才调用自身的findClass方法去磁盘或网络等位置查找类文件。
打破双亲委派的场景
虽然双亲委派是默认规则，但在某些特殊情况下也会被打破。比如SPI（服务提供接口）机制中，JDK的核心接口由启动类加载器加载，但其实现类往往位于应用程序的classpath中，只能由应用类加载器加载。这时候就需要通过Thread.currentThread().getContextClassLoader()获取上下文类加载器来反向“向下委托”，绕过常规流程。
另一个典型例子是热部署、模块化系统（如OSGi），它们需要更灵活的类加载控制，因此会自定义加载策略，不再严格遵守向上委派。
双亲委派模型看似简单，实则巧妙地解决了类加载的安全性和一致性问题。它像一套家庭规矩，让每个类加载器各司其职，既防止了核心类被篡改，又保留了扩展的可能性。理解它，就像是摸清了JVM内部运作的一条暗线，对排查NoClassDefFoundError、ClassNotFoundException等问题大有帮助。