排查背景

最近在生产上部署 UDF 时，遇到一个两个环境完全相同，但是一个客户端报错另一个正常的情况，经过多次调试问题终于得以解决，现将解决思路记录一下，希望能对后来者有所帮助。(生产环境不便于截图。。。暂不展示了，各位脑补一下哈哈哈)

场景描述

由于两个环境的 CLASSPATH 完全相同，jar 包版本一致，但是有一个客户端报错，另一个客户端不报错，根据显示的报错信息（NullPointerException），初步猜测可能是由于加载的类不正确，导致代码报错,（由于是生产环境，没有远程调试环境，各位见谅）。

调试过程

1. 由于怀疑是类加载的不正确，所以我们可以根据报错的堆栈信息确定是哪个类出了问题，然后可以确定该类是从哪个 jar 包中加载的，我们可以在虚拟机启动时设置虚拟机参数：-XX:+TraceClassLoading 来输出类的加载信息，从而对比一下该类在不同的客户端是否来自同一个 Jar 包，经确认，在不同的客户端中，两个相同的类来自不同的 jar 包，说明该思路正确，确实是由于两个同名的类代码不同导致客户端报错。
2. 下一步就是找出为什么一个客户端从 A.jar 中加载，而另一个类从 B.jar 中加载？由于两个环境完全相同，实在是搞不明白对于含有同名的类的加载顺序，由于时间有限，也不太可能去看 jvm 的源码，那就用最简单的方式，手撸一个相同场景，测试类的加载顺序！
3. 分别在不同的 model 中创建两个相同的类：

package cn.gldwolf.classload;/** model A */
public class Messager {public String getMsg() {return "Hello model A!";}
}

package cn.gldwolf.classload;/** model B */	
public class Messager {public String getMsg() {return "Hello model B!";}
}

package cn.gldwolf.test;/** model C */	
public class TestDriver {public static void main(String[] args) {Object clazz = Class.forName("cn.gldwolf.classload.Messager");System.out.println("Loaded Class is: " + clazz);}
}

4. 将打包好 jar 包分别上传到测试环境，执行下列命令：

java -XX:+TraceClassLoading -cp ./*.jar cn.gldwolf.test.TestDriver

经过多次测试，发现类的加载来源和 modelA、modelB 的上传顺序有关，所以推断和 jvm 加载类时指定的 -cp 顺序有关，做如下测试：
java -XX:+TraceClassLoading -cp ./modelA.jar:./modelB.jar cn.gldwolf.test.TestDriver
java -XX:+TraceClassLoading -cp ./modelB.jar:./modelA.jar cn.gldwolf.test.TestDriver
根据现象可以得知，会按照 -cp 指定的顺序来确定从哪个 jar 包中加载。该方式可以解决部分问题，但是对于指定整个目录的方式（java -cp ./*.jar xxx.xxx.Main）的方式不能提供切实可行的方案。

5. 通过多次不同顺序上传 modelA.jar 和 modelB.jar 改变文件的创建时间，可以确定，jvm 在使用 java -cp ./*.jar 的方式会根据文件的创建顺序的先后来确定从哪个 jar 包中加载类（从最先创建的 jar 包中加载，和文件系统有关：本次测试基于 Linux 下的 xfs 文件系统）

6. 删除报错的客户端上相应的 jar 包，按正确的顺序重新上传 jar 包，问题解决。

至此，本次 debug 结束。