0x00. 前言

依賴衝突是日常開發中經常碰到的過程，如果運氣好，並不會有什麼問題。偏偏小黑哥有點背，碰到好幾次生產問題，排查一整晚，最後發現卻是依賴衝突的引起的問題。

沒碰到過這個問題同學可能沒什麼感覺，小黑哥舉兩個最近碰到例子，讓大家感受一些。

例子 1：

我們公司有個古老的業務基礎包 A。B，C 業務依賴這個包。某個團隊拷貝 A 的部分程式碼進行重構，類名與路徑完全一樣，然後重新打包成 D 釋出。

一次業務改動，B 業務也引入了 D 包，測試環境執行的時候，一切 OK，但是在生產執行時，卻丟擲 NoSuchMethodError。

問題原因在於 B 業務依賴 A，D。而 A,D 存在兩個同包同名類，執行的時候，具體載入誰，不同環境還真不一樣。

例子 2：

A 業務使用 Dubbo 進行 RPC 呼叫， Dubbo 需要依賴 javassist。當前依賴關係為：

A------->Dubbo------->javassist-3.18.1.GA

某次改動中引入另外一個第三方開源包，其依賴 javassist-3.15.0-GA 。生產釋出的時候，將 javassist-3.15.0-GA 打包到應用中，由於生產環節為 JDK1.8，從而導致執行直接失敗。

除了上述問題，依賴衝突還可能導致應用丟擲 ClassNotFoundException，NoClassDefFoundError 等錯誤。

丟擲錯誤這種情況還算好，還比較容易定位問題。怕就怕，不同版本同一個類內部邏輯不同，從而導致業務異常。這種問題，真的很讓人抓狂，讓人頭禿。

仔細分析依賴衝突，主要可以分為兩類：

• 專案同一依賴應用，存在多版本，每個版本同一個類，可能存在差異。
• 專案不同依賴應用，存在包名，類名完全一樣的類。

下面我們分析一下依賴衝突產生的原因。

0x01. 依賴衝突原因

1.1 依賴機制

Maven 依賴分為兩種情況，直接依賴與間接依賴，這個比較好理解，大家直接看圖就好。

1.2 仲裁機制

如果 A 應用間接依賴多個 C 應用，且版本都不一樣，Maven 將會通過仲裁機制選擇：

• 優先按照依賴管理元素中指定的版本宣告進行仲裁時，下面的兩個原則都無效了
• 短路徑優先
• 若路徑相同，將看 pom 中宣告的順序。

第一條原則，我們下面再說。

第二條原則，如下圖：

A 間接依賴兩個版本 E，這種情況下，由於 A 到 E-1.0 路徑最短，所以 A 中將會使用 E-1.0。

如果路徑恰好一樣，那麼這種情況下 Maven 只能根據 pom 中的順序，選擇最先宣告的，這也是個無奈的選擇。

1.3 scope 屬性

Maven 專案可以分為三個階段：編譯階段，測試階段，執行階段了。通過 scope 屬性，我們可以決定依賴應用是否參與以上階段，也將會影響依賴傳遞。

Maven 提供 6 種 scope ：

• compile
• provided
• runtime
• test
• system
• import

compile

compile 是 Maven 預設屬性，將會使依賴包參與專案的編譯，測試，執行階段。當然，專案打包之後將會包含該依賴。

provided

provided 意味著依賴僅參與專案編譯，測試的階段。若有如下依賴關係：

A----->B----->C

C 的 scope 為provided，C 將會參與 B 的編譯，測試階段，但是 C 不會傳遞給 A。如果 A 執行過程需要 C，需要自己直接引入 C 依賴。典型如 Servlet API，因為 Tomcat 等容器內部會提供。

runtime

runtime 代表依賴不再參與專案編譯階段，只參與測試，執行階段。

若依賴不參與編譯階段，這種情況 IDE 中是無法匯入相應的類的。若存在依賴類，編譯過程中將會報錯。

典型的例子是 JDBC 驅動包，如 mysql :

<dependency>
    <groupId>mysql</groupId>
    <artifactId>mysql-connector-java</artifactId>
    <version>6.0.6</version>
    <scope>runtime</scope>
</dependency>

知識點：這個好處在於，只能使用 JDBC 標準介面，這樣就不會與特定的資料庫繫結。後續若切換資料庫，只需要更換 pom，然後修改相應的引數即可。

test

test 僅參與測試階段的工作，典型的例子為 junit：

<dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <version>4.12</version>
    <scope>test</scope>
</dependency>

system

system 與 provided 範圍一致，只不過 system 需要使用 systemPath 屬性指定本地路徑，而 provided 將會從 Maven 倉庫拉取。

import

import 比較特殊，不會參與以上階段執行。其只能在 dependencyManagement下使用，且 type 需要為 pom。典型的例子為 Spring-boot 依賴。

    <dependencyManagement>
        <dependencies>
            <!-- Spring Boot -->
            <dependency>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-dependencies</artifactId>
                <version>2.1.6.RELEASE</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
        </dependencies>
    </dependencyManagement>

知識點：通過這種方式，解決單繼承問題，也可以更好將依賴分類。

另外 Maven scope 將會影響依賴傳遞。

如果依賴關係為： A--->B--->C,A 依賴 B，B 依賴 C。最左列代表 B 的 scope 屬性，第一行代表 C 的 scope 屬性

如上所示，當 C 的 scope 為 provided/test, C 只在 B 中起作用，不會通過間接依賴傳遞給 A。

當且僅當 B 的 scope 為 compile，且 C scope 為 runtime ，A 將會間接依賴 C，且 scope 為 runtime。其他情況下，C 的 scope 將會與 B 的 scope 一致。

0x02. 解決衝突的方法

2.1 使用 Maven 屬性控制依賴傳遞

依賴衝突時，根據錯誤日誌，定位到衝突類，定位相應 jar 包，最後通過 excludes 排除相應的包。

另外可以結合 IDEA Maven Helper 外掛，主動檢查衝突依賴，提前排除。

通過外掛，我們可以清晰看到衝突包，以及依賴路徑，還有相應的 Scope。

除了排除依賴，我們可以通過合理的設定 scope 屬性，不讓依賴傳播下去。比如說，A 需要是使用 Spring-beans 包中某些類。如果其他專案鐵定會使用 Spring，那麼我們可以將 A 中 Spring-beans scope 設定為 provided，讓其他專案自己選擇引入 Spring-beans 的版本。

這個適合公共基礎包，其他包不要隨便使用provided，若使用一定要寫清楚，使用過程中需要引入的依賴。

以上方法雖然治標，但是不治本。如果想依賴衝突不發生，我們需要提前建立一定的規範，團隊一起遵守，才能有效避免該類問題。

1. 應用專案中使用 dependencyManagement 統一管理基礎依賴，定義統一的版本，如常用中間包，工具包，日誌包。
2. 二方包中不要引入無關的依賴，做到儘量少的依賴。團隊開發中，比較常見情況是二方包繼承公共的父 pom，從而導致繼承許多無相關的依賴，這種情況可以單獨管理。
3. 二方包做好向下相容，不要隨意改動現有類名，方法名，欄位名。
4. 專案應用上線之前，將 snapshot 替換成正式版本。雖然 snapshot 修改起來很方便，但是正因為這個特性，可以被隨便修改。如果某次生產打包釋出不注意，就會引入。
5. 二方包不要使用同一個包名，類名。一般來說，團隊開發中，包名，類名一樣概率比較小。這種比較容易出現在一些重構專案，複製原來類，重構打包釋出。對於情況下可以修改包名。如 cmomon-lang3 是 common-lang 升級版， cmomon-lang3 包名為 org.apache.commons.lang3,而 common-lang 包名為 org.apache.commons.lang

0x03. 總結

如果我們把 NPE 問題當做新手村普通怪物，那麼依賴衝突問題就是人馬這種精英怪。剛開始遇到，我們會被虐的比較慘。只有我們不斷升級，學習掌握技巧，然後才能可以從容不迫解決。

ps:塞爾達中，你們第一次遇見人馬，打了幾次？小黑哥記得那天整整從晚上九點打到凌晨兩點，就是打不過啊~

最後用一張思維導圖，總結文章內容。

0x04. 幫助文件

Maven Dependency Scopes

Maven optional關鍵字透徹圖解

這篇文章寫的很好，大家可以看下。，重新看待Jar包衝突問題及解決方案

包管理原則

歡迎關注我的公眾號：程式通事，獲得日常乾貨推送。如果您對我的專題內容感興趣，也可以關注我的部落格：studyidea.cn