openEuler 社区 9 月 9 日刊发的《一文讲懂 JVM 与调优》中，双亲委派模型（Parents Delegation Model）部分写得尤为清楚。一句话概括：类加载器收到加载请求时，先交给父加载器尝试加载，父加载器加载不了才自己加载——请求向上委托、查找向下回传。

四层类加载器各司其职：启动类加载器（Bootstrap ClassLoader）由 C++ 实现内嵌在 JVM 里，加载 JAVA_HOME/lib 下的核心类（java.lang.String、Object、ArrayList）；扩展类加载器（JDK 9 后改名平台类加载器）加载 ext 目录扩展包；应用程序类加载器加载 classpath 下的业务代码，是默认的系统类加载器；最底下是自定义类加载器（热部署、加密 class 等场景）。完整流程：应用类加载器收到 com.demo.Test 的请求后先不自己加载，逐层上抛到 Bootstrap——找得到就自己加载返回，找不到逐层回传，最终抛 ClassNotFoundException。

为什么要这么设计？文章给出两大必背理由：一是沙箱安全——用户自己写一个 java.lang.String，加载请求上抛到 Bootstrap 后直接返回 JDK 原生 String，自定义的恶意类永远不会被加载；没有双亲委派就是巨大的安全漏洞。二是类的全局唯一性——同一个类由“全限定名 + 类加载器”唯一标识，保证全路径相同的类在整个 JVM 只加载一次，避免重复加载与类型转换异常。

文章同时覆盖了打破双亲委派的经典场景：SPI（JDBC 驱动、Slf4j、Dubbo SPI）里 JDK 核心包定义接口、实现在第三方 jar，父加载器看不到子类资源，需要线程上下文类加载器反向委派；Tomcat 每 Web 应用独立类加载器实现依赖隔离；OSGi 与热部署框架需要优先加载新 class。对 Java 面试与 JVM 调优，这是一篇把“背定义”变成“讲得清为什么”的实战梳理。