JDK 9+ 并未废除双亲委派，而是将其纳入模块系统，通过模块图裁定加载权限，再由对应模块层加载器执行；模块路径（--module-path）取代类路径，命名模块、自动模块和未模块化类分属不同加载器管辖，类加载器职责解耦，并新增ModuleLayer.Loader实现模块层隔离与可见性约束。
JDK 9+ 并没有废除双亲委派，而是把它“收编”进模块系统——类加载不再只靠“谁先加载谁说了算”，而是先由模块图（Module Graph）裁定“能不能加载”，再由对应模块层的加载器执行。核心不是替换机制，而是叠加一层模块可见性约束。
模块路径取代类路径成为加载主干
传统 classpath 被 --module-path 取代，JVM 启动时优先扫描该路径下的命名模块（named modules）和自动模块（automatic modules）。所有模块化 JAR（含 module-info.class）都按模块归属归入不同加载器管辖范围，而不再统一扔给 AppClassLoader；未模块化的 JAR 则退化为自动模块，仅保有隐式导出能力，且不被显式模块默认读取。
类加载器职责解耦，不再继承委派
- 启动类加载器（Bootstrap）仍加载 java.base 等核心模块，但由 JVM 内部模块系统驱动，不再直接处理文件系统路径
- 平台类加载器（Platform）专责 JAVA_HOME/lib 中的模块化系统模块（如 java.sql、java.xml），不再加载 ext 目录
- 应用类加载器（System/AppClassLoader）只负责非模块化类（即 classpath 上的普通类），对命名模块无权加载
- 新增 ModuleLayer.Loader：每个模块层拥有独立加载上下文，类加载请求必须先通过模块图验证可读性（requires）、包导出（exports）与开放（opens）规则
变量与符号引用寻址依赖模块可达性
静态字段访问、Class.forName()、反射调用等不再仅看类是否已加载，更要看模块间是否满足可见性契约：
- 若调用方模块未声明 requires 目标模块，或目标模块未 exports 对应包，即使类已存在也会抛 IllegalAccessError
- 反射访问需目标模块显式 opens 包给调用方模块（或 ALL-UNNAMED），setAccessible(true) 不再绕过模块封装
- 常量池中的符号引用解析失败时，错误类型从 NoClassDefFoundError 升级为 ResolutionException 或 IllegalAccessError，提示更精准
迁移老项目时的加载行为变化
将旧 JAR 放入 --module-path 后，它们变成自动模块，名字取自 JAR 文件名（如 guava-32.0-jre.jar → 模块名 guava），但存在关键限制：
立即学习“Java免费学习笔记（深入）”；
- 自动模块隐式导出全部包，也隐式 requires 所有其他模块，但无法被命名模块 requires（除非加 --add-reads）
- 多个自动模块导出同名包会触发启动期 ResolutionException，强制开发者厘清包归属
- 未模块化的类（如 main 方法所在类）运行在 unnamed module 中，它能读取所有模块，但无法被命名模块反向依赖
