Java类加载机制与JPMS深度协同：模块路径取代类路径，新增平台类加载器，模块声明驱动访问控制，ServiceLoader依赖模块感知，双亲委派在模块策略下受控调整。
Java 类加载机制与模块化系统（JPMS）不是彼此独立的两套体系，而是深度协同、相互支撑的设计。模块化系统依赖类加载机制实现封装、隔离和依赖验证，而类加载机制也因模块化被重构出更精细的控制粒度。
模块路径取代类路径，驱动类加载器行为变化
JDK 9 引入模块路径（--module-path）后，JVM 不再仅依据传统类路径查找类，而是按模块边界组织加载逻辑。模块路径上的 JAR 若含 module-info.class，即被视为具名模块（Named Module），由平台类加载器（Platform ClassLoader）或系统类加载器按模块图解析加载；而类路径上的资源统一归入匿名模块（Unnamed Module），仍可访问所有导出包，但失去模块级封装能力。这种路径区分直接决定了类加载器“看什么”“从哪找”“能否访问”。
类加载器层级新增平台类加载器，适配模块分层
Java 9 起，标准类加载器由三层变为四层：启动类加载器（Bootstrap）→ 平台类加载器（Platform）→ 系统类加载器（System/App）→ 自定义类加载器。其中平台类加载器专门负责加载 JDK 平台模块（如 java.base、java.sql），它不继承自 ClassLoader，也不暴露给应用代码，但参与双亲委派链——当加载 java.time.LocalDate 时，系统类加载器会先委托平台类加载器，后者依据模块声明决定是否导出该类型。这使核心 API 的可见性不再仅靠包名前缀（如 java.*），而由模块的 exports 指令精确控制。
模块声明驱动类加载的访问控制逻辑module-info.java 中的 exports、opens、requires 等指令，本质是向类加载器注入元数据规则：
-
exports com.example.api→ 类加载器允许其他模块访问该包下的 public 类型； -
opens com.example.internal to my.app→ 类加载器在反射场景下，只对指定模块开放该包的深层访问； -
requires java.sql→ 类加载器在启动阶段验证java.sql模块是否在模块路径中且已导出所需包，缺失则直接启动失败，而非运行时抛NoClassDefFoundError。
这些规则在类加载的“解析”（Resolution）阶段被强制执行，使访问控制从运行时检查前移到加载期决策。
服务加载与模块协作依赖类加载器的模块感知能力ServiceLoader 在模块化环境中不再扫描整个类路径，而是按模块图查找：
- 调用方模块声明
uses com.example.spi.Service； - 提供方模块声明
provides com.example.spi.Service with com.impl.ServiceImpl； - 类加载器在加载调用方时，根据
uses声明定位到提供方模块，并通过其provides元数据加载实现类。
这一过程要求类加载器能识别模块描述符、解析跨模块依赖，且确保服务实现类所在的包已被正确导出或开放。
打破双亲委派的例外场景由模块策略显式管理
传统双亲委派模型下，类加载优先向上委托。但在模块化中，某些场景需“向下穿透”：例如框架（如 Spring）需反射访问用户模块的私有成员。此时可通过 --add-opens JVM 参数，让平台或系统类加载器在初始化时动态打开指定包，相当于临时修改模块的 opens 策略——这不是绕过机制，而是模块化系统预留的、受控的封装突破通道。
