1.Maven依赖冲突体验。在模块y中，我写了一个Encryptor类，主要使用了DigestUtils、MessageDigest、HmacUtils等类。要加密字符串(以下代码是随机写的，仅表示使用这些类)，如下:import org . Apache . commons . codec . binary . hex；导入org . Apache . commons . codec . digest . digest utils；导入org . Apache . commons . codec . digest . hmacutils；导入Java . nio . charset . standard charsets；导入Java . security . message digest；公共类加密器{ public String encrypt(String s){ message digest sha 256 digest = digest utils . getsha 256 digest()；string result = hex . encodehexstring(sha 256 digest . digest(s . getbytes(standard charsets。UTF _ 8)))；返回hex . encodehexstring(hmacutils . gethmacsha 256(result . getbytes())。do final(result . getbytes())；} public static void main(String[]args){ Encryptor Encryptor = new Encryptor()；String s = " teststring result = encryptor . encrypt(s)；System.out.println(结果)；}/* *输出:FDD 04 DCAC 94e 9803 a 72e 4268141 f 773 e 2024 a 8 Fe 46 ba 19 a 263 be 22 C5 ca 83 e 931 * */} Y模块下的单元测试运行时不会报错，但是当整个应用程序启动后，作为程序入口的X模块调用Y模块中的加密器时，会出现IllegalAccessError错误。 根据图中具体的错误信息，表示我没有权限访问getSha256Digest方法。我点击Ctrl+B访问getSha256Digest方法，如下:image.pnggetSha256Digest方法是public的访问级别，我看着很傻。 因为这个方法很简单，既然报错了，我就干脆不用了，我就这样写。 public String encrype(String s){ try { message digest sha 256 digest = message digest . getinstance(" SHA-256 ")；string result = hex . encodehexstring(sha 256 digest . digest(s . getbytes(standard charsets。UTF _ 8)))；返回hex . encodehexstring(hmacutils . gethmacsha 256(result . getbytes())。do final(result . getbytes())；} catch(nosuch algorithm exception e){ e . printstacktrace()；返回“错误”；}}}又报错了，嗯，真的是无法避免啊！错误如下:image这次报告了ClassNotFoundException。找不到HmacUtils类。 但是我Ctrl+B进去，这个类在那里没问题。 这个时候我重点思考是否存在Maven依赖冲突。 我打开pom.xml，用依赖分析器检查了一下。果然，我用的commons-codec包有冲突。 在图像y模块中，依赖关系:y->:B-& gt；c->；commons-编解码器-1.10 在x模块中，包A被引用:x->:A-& gt；Commons-codec-1.6，也指Y模块:X->:Y-& gt；b-& gt；c->；commons-编解码器-1.10 可以看到commons-codec包有两个版本，1.6和1.10，所以Maven会调解依赖关系。第一条规则是“最短路径优先”，自然只会用1.6版本的包。 而且我看1.6的包，getSha256Digest方法是私有访问级别，HmacUtils类不存在。 解释了之前的错误。 要处理这种冲突，可以通过排除依赖关系来处理，排除包A下的commons-codec，如下所示: 2.为什么Maven需要依赖中介的问题已经解决了。你也明白为什么依赖冲突经常导致NoClassDefFoundError、NoSuchMethodException、IllegalAccessError之类的错误了吧？ 虽然Y模块在编译时因为引入了commons-codec 1.10可以正常编译，但是在运行时因为依赖冲突无法正常运行，只加载了1.6版本的包。 注意:代码的编译只是编译当前代码。 编译成功后，最终能否正常运行，取决于运行时环境是否等于或兼容编译时环境。 我们来思考一下Maven为什么需要依赖中介，如果不需要，会不会起作用？ 在使用Maven时，如果同时引入一个groupId和artifactId相同但版本不同的包，Maven会认为存在依赖冲突，会进行依赖调解，通过两个准则决定使用哪个版本的包:第一个准则，最短路径优先，如上所述。 如果路径相同，则使用第二个标准，pom中的第一个公告优先。 而当我们点击Run来运行时，classpath中只会有一个显式版本的包。 想想吧。 Java在运行的时候，可以引入不同版本的包吗？ 这个问题其实是在问，java命令的classpath参数中可以有多个不同版本的包吗？当然有可能。 Classpath参数用于指示JVM如何搜索类文件。当classpath中指定的路径下有多个版本不同的包时，JVM会在jar包下搜索类文件进行加载。至于class能不能成功加载，就看ClassLoader的逻辑了。当一个同名的类被加载后，就不会再被加载，也就是说，同一个类只会被加载一次。 这也意味着当有多个不同版本的包时，包在类路径中的顺序决定了哪个包的类可以首先被加载。 这个不确定。 在生产环境中，jar包通常由shell命令拼接而成:lib _ dir = liblib _ jars = ` ls＄lib _ dir | grep . jar | awk ' { print " '＄lib _ dir '/" $ 0 } ' | tr " \ n " ":" `不同环境下获得的jar包顺序可能不同。 Maven的依赖中介将只让包的一个显式版本参与构造，从而避免不确定性。 3.一个解决在线问题的利器——ArthasArthas，我早就听说过，但从来没用过。这一次，我试了一下，觉得真的还可以。安利下。 对于上面提到的依赖冲突，当IllegalAccessError报错时，可以通过Arthas直接查看运行状态下的DigestUtils。 我们把代码改成初始的情况，在主类中增加一个无限循环，为了让程序不至于死，通过阿尔萨斯来观察。 public class Main { public static void Main(String[]args){ while(true){ try { Encryptor Encryptor = new Encryptor()；String s = " 1234567890string result = encryptor . encrypt(s)；System.out.println(结果)；} catch (throwable e) {}}}打开阿尔萨斯连接我们的程序(可以通过官方教程了解)， 然后通过sc命令检查digest utils:[Arthas @ 32328]$ sc-D org . Apache . commons . codec . digest . digest utils class-info org . Apache . commons . codec . digest . digest utils code-source/D:/maven repo/commons-codec/commons-codec/commons-codec-1.6 . jar name org . Apache . commons . codec . digest utils is interface false is annotation false is enum f alse is anonymous class false isArray false locaisl 通过jad命令，可以在线反编译和观看代码。 好用！