詳解Maven JAR包沖突問題排查及解決方案

Posted on by

前言

寫這篇文章的初衷是因為今天在使用mvn dependency:tree命令時，突然想起一年前面試阿裡的一道面試題。面試題是說假設線上發生JAR包沖突，應該怎麼排查？我那時候的回答是IDEA有個Maven Helper的插件，可以幫忙分析依賴沖突，然後還有一種辦法是如果一個類import的時候提示兩個地方可導入，那就說明有沖突。現在回頭想想確實太不專業瞭，以下是一次JAR包沖突的一個比較正規的流程，是通過整理幾篇博客後總結的希望對大傢也有幫助，如果有錯誤的地方也歡迎指出

GitHub地址:https://github.com/RobertoHuang

JAR沖突產生的原因

   Pom.xml
   /  \
  B    C
 / \   / \
 X  Y  X  M

在以上依賴關系中項目除瞭會引入B、C還會引入X、Y、M的依賴包，但是如果B依賴的X版本會1.0而C依賴的X版本為2.0時，那最後項目使用的到底是X的1.0版本還是2.0版本就無法確定瞭。這是就要看ClassLoader的加載順序，假設ClassLoader先加載1.0版本那就不會加載2.0版本，反之同理

使用mvn -Dverbose dependency:tree排查沖突

[INFO] +- org.apache.tomcat:tomcat-servlet-api:jar:7.0.70:compile
[INFO] +- org.apache.tomcat:tomcat-jsp-api:jar:7.0.70:compile
[INFO] | +- org.apache.tomcat:tomcat-el-api:jar:7.0.70:compile
[INFO] | \- (org.apache.tomcat:tomcat-servlet-api:jar:7.0.70:compile - omitted for duplicate)
[INFO] +- net.sf.jasperreports:jasperreports:jar:5.6.0:compile
[INFO] | +- (commons-beanutils:commons-beanutils:jar:1.8.0:compile - omitted for conflict with 1.8.3)
[INFO] | +- commons-collections:commons-collections:jar:3.2.1:compile
[INFO] | +- commons-digester:commons-digester:jar:2.1:compile
[INFO] | | +- (commons-beanutils:commons-beanutils:jar:1.8.3:compile - omitted for duplicate)
[INFO] | | \- (commons-logging:commons-logging:jar:1.1.1:compile - omitted for duplicate)

遞歸依賴的關系列的算是比較清楚瞭，每行都是一個jar包，根據縮進可以看到依賴的關系

  • 最後寫著compile的就是編譯成功的
  • 最後寫著omitted for duplicate的就是有JAR包被重復依賴瞭，但是JAR包的版本是一樣的
  • 最後寫著omitted for conflict with xx的，說明和別的JAR包版本沖突瞭，該行的JAR包不會被引入

該命令可配合-Dincludes和-Dexcludes進行使用，隻輸出自己感興趣/不感興趣的JAR
參數格式為:[groupId]:[artifactId]:[type]:[version]
每個部分（冒號分割的部分）是支持*通配符的，如果要指定多個格式則可以用,分割，如: 

mvn dependency:tree -Dincludes=javax.servlet,org.apache.*

解決沖突，使用exclusion標簽將沖突的JAR排除

<dependency>
  <groupId>com.alibaba</groupId>
  <artifactId>dubbo</artifactId>
  <version>2.8.3.2</version>
  <exclusions>
    <exclusion>
      <artifactId>guava</artifactId>
      <groupId>com.google.guava</groupId>
    </exclusion>
    <exclusion>
      <artifactId>spring</artifactId>
      <groupId>org.springframework</groupId>
    </exclusion>  
  </exclusions>
</dependency>

解決瞭沖突後的樹(解決沖突的策略是:就近原則，即離根近的依賴被采納)

查看運行期類來源的JAR包

有時你以為解決瞭但是偏偏還是報類包沖突，典型癥狀是java.lang.ClassNotFoundException或Method不兼容等異常，這時你可以設置一個斷點，在斷點處通過下面這個工具類來查看Class所來源的JAR包

public class ClassLocationUtils {
  public static String where(final Class clazz) {
    if (clazz == null) {
      throw new IllegalArgumentException("null input: cls");
    }
    URL result = null;
    final String clazzAsResource = clazz.getName().replace('.', '/').concat(".class");
    final ProtectionDomain protectionDomain = clazz.getProtectionDomain();
    if (protectionDomain != null) {
      final CodeSource codeSource = protectionDomain.getCodeSource();
      if (codeSource != null) result = codeSource.getLocation();
      if (result != null) {
        if ("file".equals(result.getProtocol())) {
          try {
            if (result.toExternalForm().endsWith(".jar") || result.toExternalForm().endsWith(".zip")) {
              result = new URL("jar:".concat(result.toExternalForm()).concat("!/").concat(clazzAsResource));
            } else if (new File(result.getFile()).isDirectory()) {
              result = new URL(result, clazzAsResource);
            }
          } catch (MalformedURLException ignore) {

          }
        }
      }
    }
    if (result == null) {
      final ClassLoader clsLoader = clazz.getClassLoader();
      result = clsLoader != null ? clsLoader.getResource(clazzAsResource) : ClassLoader.getSystemResource(clazzAsResource);
    }
    return result.toString();
  }
}

然後隨便寫一個測試設置好斷點，在執行到斷點出使用ALT+F8動態執行代碼，如

ClassLocationUtils.where(Logger.class)

即可馬上找到對應的JAR，如果這個JAR不是你期望的就說明是IDE緩存造成的，清除緩存後重試即可

到此這篇關於詳解Maven JAR包沖突問題排查及解決方案的文章就介紹到這瞭,更多相關Maven JAR包沖突 內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet！

推薦閱讀：