JVM 和 Spark 中类路径加载遵循严格优先级：Bootstrap > Extension > User；Spark 还区分 SystemClasspath（官方 JAR）优先于 UserClassPath（提交的 JAR），可通过 userClassPathFirst 配置反转，-verbose:class 等方法可验证实际加载来源。
System Classpath 和 User Classpath 的加载顺序不是“并列选择”，而是有明确层级和覆盖关系的：JVM 或 Spark 等运行时环境会按固定优先级逐层查找类，先命中即用，后续路径不再生效。
Java 原生类加载器的三层优先级
Java 虚拟机规范虽未强制路径顺序，但 Oracle HotSpot 实现中采用严格分层机制：
-
Bootstrap Classpath（启动类路径）：加载
rt.jar、sun.misc.*等核心类，由 C++ 实现的 Bootstrap ClassLoader 加载，无法被 Java 代码直接替换 -
Extension Classpath（扩展类路径）：默认为
$JAVA_HOME/jre/lib/ext，用于加载可插拔的扩展库；其优先级高于用户路径，但低于启动路径 -
User Classpath（用户类路径）：即通常说的 CLASSPATH，包括当前目录（
.）、-cp指定路径、或环境变量CLASSPATH；它排在最后，且一旦用-cp显式指定，就会完全覆盖默认的.和环境变量值
Spark 中 SystemClasspath 与 UserClassPath 的实际行为
Spark 在 JVM 基础上叠加了自身调度逻辑，其依赖加载顺序更聚焦于部署稳定性：
-
SystemClasspath 指 Spark 安装目录下
jars/中的官方依赖（如spark-core_2.11-2.2.0.jar），由 Spark 自身 ClassLoader 加载，优先级最高 -
UserClassPath 包含两类：一是
spark-submit --jars提交的额外 JAR，二是应用主 JAR（app.jar或 shadowJar）；它们统一归入用户路径，在 SystemClasspath 之后尝试加载 - 同名类若同时存在于 System 和 User 路径中，SystemClasspath 中的版本始终生效；这是为了防止用户误覆盖 Spark 内部关键类导致任务失败
如何主动改变默认优先级？
当必须使用高版本第三方库（如较新 Jackson）而 Spark 自带版本过旧时，可启用用户路径优先策略，但需谨慎评估兼容性：
- 对 Driver 端：添加配置
--conf spark.driver.userClassPathFirst=true - 对 Executor 端：添加配置
--conf spark.executor.userClassPathFirst=true - 该配置会让 Spark 在加载类时，先扫描 UserClassPath，再回退到 SystemClasspath；适用于明确知道冲突类来源且已验证无副作用的场景
- 不推荐全局开启，尤其在集群多作业共存环境下——不同作业可能依赖互斥版本，易引发类加载不一致或
LinkageError
验证类实际加载来源的方法
快速定位某个类究竟从哪加载，避免靠猜测调试：
- 启动时加 JVM 参数：
-verbose:class，运行后观察控制台输出中类似[Loaded org.apache.spark.SparkConf from file:/opt/spark/jars/spark-core_2.11-2.2.0.jar]的日志 - 在代码中打印类位置：
MyClass.class.getProtectionDomain().getCodeSource().getLocation() - Spark UI 的 Environment 页面 → “System Properties” 或 “Classpath Entries” 标签页，可查看 Driver/Executor 实际生效的路径列表
