为何同一集群运行的两个Java/Scala Uber-Jar出现Shading冲突？

你的核心误区是把普通Java应用的classpath类加载逻辑套用到了Spark分布式集群环境中，两者的类加载机制有本质区别，导致Uber-Jar没有实现预期的隔离效果。

为什么会出现冲突？ #

1. Spark默认的父优先类加载策略 #

Spark集群的类加载器默认采用父类加载器优先（Parent First）规则：

• 优先从Spark集群自带的类库（比如安装目录下的jars）加载类，再加载用户Uber-Jar中的类。
• 如果你的Uber-Jar包含的依赖版本与Spark集群自带版本不一致，就会出现类版本冲突。

2. Executor进程复用 #

Spark默认会复用Executor进程来提升性能：

• 第一个作业运行时，Executor会加载其Uber-Jar中的依赖类并缓存；
• 第二个作业复用这些Executor时，会直接使用已缓存的旧版本类，而非加载自身Uber-Jar中的新版本类，导致冲突。

3. Uber-Jar未做类隔离处理 #

你的sbt-assembly配置仅处理了文件合并策略，没有对冲突依赖进行Shading（类重命名），两个Uber-Jar中的依赖类全限定名完全一致，一旦类加载器缓存了其中一个版本，另一个作业就会加载错误的类。

解决方法 #

1. 开启用户类优先加载 #

在提交Spark作业时添加以下配置，让用户Uber-Jar中的类优先于Spark集群自带类加载：

--conf spark.driver.userClassPathFirst=true \
--conf spark.executor.userClassPathFirst=true

注意：该配置可能导致Spark自身依赖与用户依赖冲突（比如Spark依赖的Jackson版本与你Uber-Jar中的版本不兼容），需要充分测试。

2. 对冲突依赖进行Shading #

修改sbt-assembly配置，对冲突的依赖包进行重命名，以实现类隔离。比如对Jackson相关依赖Shading：

assembly / assemblyShadeRules := Seq(
  ShadeRule.rename("com.fasterxml.jackson.**" -> "myproject.shaded.com.fasterxml.jackson.@1")
    .inAllJars
)

这样两个Uber-Jar中的Jackson类会被重命名为不同的包路径，彻底避免类名冲突。

3. 禁用Executor复用 #

如果性能不是首要考虑，可以通过配置强制每个作业使用全新的Executor进程：

--conf spark.dynamicAllocation.enabled=true \
--conf spark.dynamicAllocation.executorIdleTimeout=10s

或者固定Executor实例，确保作业结束后释放资源：

--conf spark.executor.instances=X \
--conf spark.executor.cores=Y

关键知识点梳理 #

• 普通Java应用：classpath中先出现的类优先加载，类加载器是进程级隔离；
• Spark分布式集群：类加载器有层级结构，默认父优先，且Executor进程会复用，类加载隔离性弱于单机Java应用；
• Uber-Jar仅解决了单机环境的依赖打包问题，在分布式集群中仍需配合类加载配置或Shading实现隔离。

内容的提问来源于stack exchange，提问作者YFl