如何通过Spark Listener检测Databricks中指定类是否已安装

问题根因 #

类检测失败的核心原因是Java类加载器的双亲委派隔离机制：

• 你通过init脚本放到/mnt/driver-daemon/jars的Listener，是Spark启动阶段由根类加载器加载的，这个加载器只扫描/databricks/jars目录下的内置jar，启动完成后不会动态追加新的类路径。
• Databricks通过Libraries API/UI安装的依赖，是Spark完全启动后，由子级的可变类加载器动态加载的，按照双亲委派规则，父加载器无权访问子加载器持有的类路径，所以你用Listener自身绑定的父加载器去加载类，必然报ClassNotFoundException。
• 你之前在Notebook里测试URLClassLoader能成功，是因为Notebook代码本身就是被这个动态创建的子加载器执行的，和Listener运行时的类加载上下文完全不同；另外你之前的URLClassLoader实现存在逻辑错误：只传了目录路径，没有把目录下的具体jar逐个加入类路径——URLClassLoader本身不会自动扫描目录下的jar包，这也是之前在Listener里跑不通的直接原因。

按改造成本从低到高排序：

方案1：切换为线程上下文类加载器（优先推荐） #

不要硬编码使用Listener类自身的类加载器做类检测。Spark触发监听器回调时，会将持有所有动态安装依赖的子加载器绑定到当前执行线程的上下文上，直接取用这个加载器即可，代码改动极小：
将你原有代码中所有MyListener.class.getClassLoader().loadClass(待检测类全限定名)替换为Thread.currentThread().getContextClassLoader().loadClass(待检测类全限定名)。

注意事项：不要在Listener构造函数、onApplicationStart这类集群刚启动、库安装流程未完成的回调里执行检测，放到onJobStart、onStageStart这类作业提交后触发的回调中执行即可，此时Libraries安装流程已经走完，类路径更新完成。
这个方案不需要调整部署逻辑，也不需要自定义类加载器，可覆盖绝大多数生产场景。

方案2：动态扫描临时jar目录构造专属类加载器（兜底方案） #

如果方案1因Databricks版本差异存在类加载器绑定异常的问题，可以修正之前的URLClassLoader逻辑做兜底，需要做两处核心调整：

• 遍历/local_disk0/tmp目录下所有.jar后缀的文件，将每个jar的具体路径单独转为URL加入加载器路径列表，不要直接传目录路径。
• 每次执行检测前重新扫描目录生成新的类加载器实例，不要复用旧实例——用户随时可能通过UI/API新装依赖，新jar的文件名是随机生成的，旧类加载器无法读取新增的jar内容。
  参考实现片段：

// 扫描Databricks动态安装jar的临时目录
File tmpDir = new File("/local_disk0/tmp");
File[] jarFiles = tmpDir.listFiles((dir, fileName) -> fileName.endsWith(".jar"));
List<URL> jarUrlList = new ArrayList<>();
if (jarFiles != null) {
    for (File jar : jarFiles) {
        jarUrlList.add(jar.toURI().toURL());
    }
}
// 以当前线程上下文类加载器为父加载器，避免类版本冲突
try (URLClassLoader detectClassLoader = new URLClassLoader(
        jarUrlList.toArray(new URL[0]),
        Thread.currentThread().getContextClassLoader()
)) {
    // 执行类检测逻辑
    detectClassLoader.loadClass("com.microsoft.kusto.spark.datasource.DefaultSource");
}

方案3：监听环境变更事件缓存类状态（性能最优） #

如果需要高频执行类存在性检测，每次扫描目录+新建类加载器的开销较高，可以直接覆写Listener的onEnvironmentUpdate回调：Databricks完成库安装后会触发Spark环境更新事件，每次收到事件时从事件参数中提取最新的类路径条目，缓存已加载的类列表，后续检测直接查缓存即可，不需要重复执行类加载尝试。

• 不要尝试通过反射修改根类加载器的类路径，强行追加动态安装的jar。Databricks不同版本的类加载器实现差异极大，JDK9+模块化机制会拦截这类核心类修改操作，稳定性极差。
• 不要提前把所有待检测的依赖放到/databricks/jars目录，极易引发版本冲突：如果用户通过Libraries安装了不同版本的同名依赖，会被根目录下的旧版本优先加载，直接导致作业运行失败。

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