通过IDEA快速定位和排除依赖冲突

太过爱你忘了你带给我的痛 2021-12-14 23:09 262阅读 0赞

# 1 |**前言** #

我们程序员在开发的时候经常会遇到各种各样的 BUG 问题，其中大部分是业务逻辑异常，还有一些是代码书写不规范造成的异常例如：NullPointException（NPE），IndexOutOfBoundsException 等等，其实这些我们都好定位和修复。但是还有一些运行时异常定位起来是特别头疼的，那就是 jar 包冲突引起的异常。

一般程序在运行时发生类似于 *java.lang.ClassNotFoundException*，*Method not found: '......'*，或者莫名其妙的异常信息，这种情况一般很大可能就是 jar包依赖冲突的问题引起的了。

至于为什么会发生 jar包依赖冲突？这种问题大致可以归纳为如下几个原因：

*  **版本不匹配，高版本依赖了低版本，或者低版本依赖了高版本。**例如引入第三方库，但是第三方库基于的是 JDK7，而你们项目使用的是JDK8。
 *  **重复引入不同版本jar包，造成使用错误。**很多时候我们引入第三方轮子，它们依赖引入某个基础工具使用的是 v 1.0 的 jar，但是我们项目中自己也引入了该 jar，但是版本是 v 2.3，这时就会造成项目中使用同一个组件但是依赖了两个不同版本的jar，冲突就会发生。

可以看到，其实总的来说 jar 包冲突的主要原因就是依赖的版本冲突。

# **2|异常发生** #

项目中需要导出报表，技术选型的时候，一般是选用 Apache POI，但是 POI 的使用方式比较基础，开发量大，容易出现内存溢出的问题。

考虑到阿里开源了一套解析和生成Excel的工具 - EasyExcel，具有避免内存溢出OOM的情况发生，而且使用方便简单，所以就将它引入到了我们的项目中，具体的使用版本是 1.0.2。

<dependency>
       <groupId>com.alibaba</groupId>
        <artifactId>easyexcel</artifactId>
        <version>1.0.2</version>
    </dependency>

而另一个模块需要使用 POI 的将 Word 转成 PDF 的功能，所以同时又引入了如下 POI 的依赖：

<dependency>
        <groupId>org.apache.poi</groupId>
        <artifactId>poi</artifactId>
        <version>3.15</version>
    </dependency>
    <dependency>
        <groupId>org.apache.poi</groupId>
        <artifactId>poi-ooxml</artifactId>
        <version>3.15</version>
    </dependency>

我们从 [Maven Repository][] 可以发现，阿里 EasyExcel 1.0.2 依赖的 POI 也是 3.15，所以照理说应该是没问题的。

![13894260-cc5ef2b2098ace03.png][]

[image][]

但是在接口调试的时候还是出问题了，而且异常信息很奇怪，不是看一眼就能知道问题原因的并解决的。

Caused by: java.lang.AbstractMethodError: org.apache.xerces.dom.DocumentImpl.getXmlStandalone()Z
        at com.sun.org.apache.xalan.internal.xsltc.trax.DOM2TO.setDocumentInfo(DOM2TO.java:377)
        at com.sun.org.apache.xalan.internal.xsltc.trax.DOM2TO.parse(DOM2TO.java:131)
        at com.sun.org.apache.xalan.internal.xsltc.trax.DOM2TO.parse(DOM2TO.java:98)
        at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transformIdentity(TransformerImpl.java:693)
        at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:737)
        at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:351)
        at org.apache.poi.openxml4j.opc.StreamHelper.saveXmlInStream(StreamHelper.java:80)
        at org.apache.poi.openxml4j.opc.internal.marshallers.ZipPartMarshaller.marshallRelationshipPart(ZipPartMarshaller.java:181)
        at org.apache.poi.openxml4j.opc.ZipPackage.saveImpl(ZipPackage.java:560)
        at org.apache.poi.openxml4j.opc.OPCPackage.save(OPCPackage.java:1557)
        at org.apache.poi.POIXMLDocument.write(POIXMLDocument.java:248)
        at org.apache.poi.xssf.streaming.SXSSFWorkbook.write(SXSSFWorkbook.java:941)
        at com.alibaba.excel.write.ExcelBuilderImpl.finish(ExcelBuilderImpl.java:64)
        at com.alibaba.excel.ExcelWriter.finish(ExcelWriter.java:95)
        at com.pingan.haofang.creams.common.utils.ExcelUtil.writeExcel(ExcelUtil.java:71)
        ......
        ... 65 common frames omitted

提取关键信息，可以看到错误类型 `java.lang.AbstractMethodError`，这个错误类型望名知义：抽象方法错误。这种类型的错误和我们上面说的 ClassNotFoundException 类似，很大可能就是 Jar包依赖冲突所导致的。

# **3|异常定位** #

那我们来定位下是哪个 jar 包冲突了，只需要将冲突的 jar 包排除掉，留下正确的就可以了。

我们可以看到错误类型是 *java.lang.AbstractMethodError*，错误类型后面是具体的错误信息描述 ：*org.apache.xerces.dom.DocumentImpl.getXmlStandalone()Z*，意思是在包 *org.apache.xerces.dom* 下的类`DocumentImpl`它的方法`getXmlStandalone()`调用出现了错误。

那么具体是谁在调用呢？我们在异常信息的紧密下一行可以看到如下这一行代码：

at com.sun.org.apache.xalan.internal.xsltc.trax.DOM2TO.setDocumentInfo(DOM2TO.java:377)

在包路径 *com.sun.org.apache.xalan.internal.xsltc.trax* 下，`DOM2TO` 类代码的的第377行，有个`setDocumentInfo`方法，我们鼠标左键点进去，在该行加个 Debug 断点。

![13894260-577c31844a3cb871.png][]

[image][image 1]

我们发现这个 DOM2TO 类是 JDK1.8中 rt.jar 包里面的，具体类路径如下：

![13894260-70485600a1002d2d.png][]

[image][image 2]

通过断点调试得知，这个 document 对象是 DocumentImpl 实例，

![13894260-607004f7501ed2ce.png][]

[image][image 3]

这个DocumentImpl 的真实路径也是 JDK1.8中 rt.jar 包里面的，它是 CoreDocumentImpl 的子类，CoreDocumentImpl 是接口Document 的实现类。

package com.sun.org.apache.xerces.internal.dom;
    
    public class DocumentImpl
        extends CoreDocumentImpl
        implements DocumentTraversal, DocumentEvent, DocumentRange {
    
        ......
    }

CoreDocumentImpl

package com.sun.org.apache.xerces.internal.dom;
    
    public class CoreDocumentImpl
            extends ParentNode implements Document {
    
           ......
    }

我们在 CoreDocumentImpl 类中第983行发现了`getXmlStandalone`方法。

![13894260-06e149d1c85050d3.png][]

[image][image 4]

这时报错原因赤条条的摆在我们面前了，显而易见，DOM2TO类中 setDocumentInfo 方法的参数 Document 是属于 JDK1.8 中 rt.jar 包下类路径 *com.sun.org.apache.xerces.internal.dom* 下的实现类 DocumentImpl。而我们报错的信息提示中是：

Caused by: java.lang.AbstractMethodError: org.apache.xerces.dom.DocumentImpl.getXmlStandalone()Z

这个 *org.apache.xerces.dom.DocumentImpl* 明显不属于我们 JDK1.8 的 rt.jar 包，而且也没有 getXmlStandalone 这个方法。

所以得知，我的项目中 jar 包依赖冲突了，我们只需要排除掉 *org.apache.xerces.dom.DocumentImpl* 所属的 jar 包就可以了。如何排除呢？

# **4|排除冲突** #

我们在 IDEA 中双击 Shift 键，输入 DocumentImpl，得到如下结果：

![13894260-2aba461da0930c4c.png][]

[image][image 5]

可以发现，这里有两个 CoreDocumentImpl，一个是我们的 JDK1.8的，一个是属于 xerce的，而且确实在依赖的 maven jar 包中发现了 xercesImpl-2.4.0.jar，这个 jar包就是需要排除的 jar包。

![13894260-6bfd38579fa8fbdb.png][]

[image][image 6]

发现了冲突的 jar包，我全局搜索关键字 xerces，并没有发现哪一个 pom 中有依赖的代码，所以很可能是其他的 jar 包传递依赖进来的。

我们借助 IDEA 的 maven 工具，在 maven 栏右键项目模块，选择 `show Dependencies` 或 `Ctrl + Shift + Alt + U`，这时候会展示当前模块的 jar 包依赖图，如下：

![13894260-db2217b19abf772b.png][]

[image][image 7]

虽然这里展示了很多冲突的jar包，其中红线连接的就是冲突的jar 包，但是我们 `Ctrl + F` 查询 xerces 还是没有结果。

所以我们需要额外的方式来解决，这时我想到了 IDEA 有个插件 `Maven Helper`，下载好插件后，我们打开 pom.xml 文件，在pom.xml 文件的左下方有个 `Dependency Analyzer`，我们点击之后显示如下：

![13894260-a9e35a971a625583.png][]

[image][image 8]

*  **Conflicts**：展示所有冲突。
 *  **All Dependencies as List**：以列表的方式展示所有依赖。
 *  **All Dependencies as Tree**：以树形的方式展示所有依赖。

我们输入 xerces，选择以树形展示所有依赖，得到如下的信息显示。

![13894260-b35df169aaefa320.png][]

[image][image 9]

清晰明了，原来这个罪魁祸首是被 file-web-sdk 带进来的，我们右键选择 `Jump To Source`或者 F4 定位到这个 jar 在 pom.xml 的依赖引入位置，如下图所示，我们通过 exclusion 标签排除 xercesImpl 的引入即可。

<dependency>
        <groupId>com.xx.xx.gov.fileservice</groupId>
        <artifactId>file-web-sdk</artifactId>
        <exclusions>
            <exclusion>
                <groupId>xerces</groupId>
                <artifactId>xercesImpl</artifactId>
            </exclusion>
        </exclusions>
    </dependency>

再次启动项目，测试接口发现功能正常了，整个排查过程也就结束了，IDEA的功能还是很强大的。

# **5|总结** #

很多时候的 jar 包冲突，有些是我们很容易排除，例如在pom.xml 中我们就可以发现一些重复引入，但是版本不相同的依赖。还有一些是其他依赖传递依赖进来的，我们在 pom.xml 文件中不能很直观的发现，这时候我们借助工具可以发现这种冲突的依赖。

但是还有一些是更隐秘的冲突，就像本文中描述的依赖冲突，这时候我们需要分析异常信息，并定位冲突的原因和找到具体冲突的依赖引入，最后将它排除就可以了。

本文比较详细的介绍了异常的分析和冲突的定位，以及最后的排除。类似的依赖冲突基本都可以参考上述的方式进行排查，希望通过本篇文章对大家解决项目中依赖冲突有所帮助。

[Maven Repository]: https://links.jianshu.com/go?to=https%3A%2F%2Fmvnrepository.com%2Fartifact%2Fcom.alibaba%2Feasyexcel%2F1.0.2
[13894260-cc5ef2b2098ace03.png]: /images/20211214/d558a434783c410a9d898c8ab23c5864.png
[image]: https://links.jianshu.com/go?to=https%3A%2F%2Fimg2018.cnblogs.com%2Fblog%2F1162587%2F201906%2F1162587-20190611114341101-1901601103.png
[13894260-577c31844a3cb871.png]: /images/20211214/207e1e61675d40ec926947ed1a165878.png
[image 1]: https://links.jianshu.com/go?to=https%3A%2F%2Fimg2018.cnblogs.com%2Fblog%2F1162587%2F201906%2F1162587-20190611164922538-862397553.png
[13894260-70485600a1002d2d.png]: /images/20211214/5f61f7a25b2246848724cf607e2e4ae6.png
[image 2]: https://links.jianshu.com/go?to=https%3A%2F%2Fimg2018.cnblogs.com%2Fblog%2F1162587%2F201906%2F1162587-20190611165408472-814474754.png
[13894260-607004f7501ed2ce.png]: /images/20211214/f619e073d82f48bcb26529aaa0239f8c.png
[image 3]: https://links.jianshu.com/go?to=https%3A%2F%2Fimg2018.cnblogs.com%2Fblog%2F1162587%2F201906%2F1162587-20190611165510424-1341955663.png
[13894260-06e149d1c85050d3.png]: /images/20211214/bdb8b851a834497d97bbc0f4173c6800.png
[image 4]: https://links.jianshu.com/go?to=https%3A%2F%2Fimg2018.cnblogs.com%2Fblog%2F1162587%2F201906%2F1162587-20190611170331273-1754717293.png
[13894260-2aba461da0930c4c.png]: /images/20211214/c6436884262343159e88677f9003e2df.png
[image 5]: https://links.jianshu.com/go?to=https%3A%2F%2Fimg2018.cnblogs.com%2Fblog%2F1162587%2F201906%2F1162587-20190611174002430-1456527611.png
[13894260-6bfd38579fa8fbdb.png]: /images/20211214/2fa37556e8514f1a9ea06eab89766e4a.png
[image 6]: https://links.jianshu.com/go?to=https%3A%2F%2Fimg2018.cnblogs.com%2Fblog%2F1162587%2F201906%2F1162587-20190611174230612-130377471.png
[13894260-db2217b19abf772b.png]: /images/20211214/ad939c1623654f22b30cfd7f0d293eda.png
[image 7]: https://links.jianshu.com/go?to=https%3A%2F%2Fimg2018.cnblogs.com%2Fblog%2F1162587%2F201906%2F1162587-20190611204304430-822190298.png
[13894260-a9e35a971a625583.png]: /images/20211214/d5751fb8d92e443c8965903c9cc44fa2.png
[image 8]: https://links.jianshu.com/go?to=https%3A%2F%2Fimg2018.cnblogs.com%2Fblog%2F1162587%2F201906%2F1162587-20190611211411601-1019856784.png
[13894260-b35df169aaefa320.png]: /images/20211214/1519c5e737944ea7bded306b5174b8b5.png
[image 9]: https://links.jianshu.com/go?to=https%3A%2F%2Fimg2018.cnblogs.com%2Fblog%2F1162587%2F201906%2F1162587-20190611212202815-1399810303.png