前言
大家在項(xiàng)目中肯定有碰到過(guò)Maven的Jar包沖突問(wèn)題挚赊，經(jīng)常出現(xiàn)的場(chǎng)景為：
本地運(yùn)行報(bào)NoSuchMethodError藻三，ClassNotFoundException洪橘。明明在依賴?yán)镉羞@個(gè)Jar包啊。怎么運(yùn)行不了？妹薄熄求？
項(xiàng)目中明明定義著某個(gè)jar包版本為2.0.2，怎么打包之后變成2.5.0了６焊拧弟晚？
A項(xiàng)目引xxx.jar包運(yùn)行好好的，B項(xiàng)目同樣引入xxx.jar后逾苫，運(yùn)行報(bào)錯(cuò)了卿城。。是B項(xiàng)目有問(wèn)題铅搓，還是xxx.jar包有問(wèn)題Ｔ逖？
本地環(huán)境和測(cè)試環(huán)境運(yùn)行的好好的狸吞，到了生產(chǎn)就報(bào)一堆NoSuchMethodError，是我人品有問(wèn)題還是生產(chǎn)環(huán)境有問(wèn)題Ｖ讣濉蹋偏？
這樣的問(wèn)題如果不熟悉maven依賴機(jī)制的同學(xué)排查起來(lái)，估計(jì)挺頭痛的至壤。
而且maven依賴結(jié)構(gòu)不好的項(xiàng)目威始，在引入新的Jar包時(shí)的風(fēng)險(xiǎn)也是巨大的。小則影響性能像街，大則引起生產(chǎn)發(fā)布和運(yùn)行時(shí)異常黎棠。
其實(shí)以上問(wèn)題的根源都來(lái)自于Maven的Jar包沖突和使用不當(dāng)?shù)囊蕾噦鬟f晋渺。這篇文章我就好好分析下以下3個(gè)內(nèi)容：
- 依賴傳遞的原則和產(chǎn)生Jar包沖突的原理分析
- 定位沖突以及解決Jar包沖突的幾個(gè)簡(jiǎn)單技巧
- 如何寫(xiě)一個(gè)干凈依賴關(guān)系的
POM文件
依賴傳遞原則
幾乎所有的Jar包沖突都和依賴傳遞原則有關(guān)，所以我們先說(shuō)Maven中的依賴傳遞原則：
最短路徑優(yōu)先原則
假如引入了2個(gè)Jar包A和B脓斩，都傳遞依賴了Z這個(gè)Jar包：
A -> X -> Y -> Z(2.5)
B -> X -> Z(2.0)
那其實(shí)最終生效的是Z(2.0)這個(gè)版本木西。因?yàn)樗穆窂礁佣獭Ｈ绻冶镜匾昧薢(3.0)的包随静，那生效的就是3.0的版本八千。一樣的道理。
最先聲明優(yōu)先原則
如果路徑長(zhǎng)短一樣燎猛，優(yōu)先選最先聲明的那個(gè)恋捆。
A -> Z(3.0)
B -> Z(2.5)
這里A最先聲明，所以傳遞過(guò)來(lái)的Z選擇用3.0版本的重绷。
Jar包沖突的原理
假設(shè)我們項(xiàng)目中依賴了A和B兩個(gè)Jar包沸停。而A和B各自又有以下傳遞依賴
A -> X -> Z(2.0)
B -> X -> Y -> Z(2.5)
那最終系統(tǒng)中Z包就產(chǎn)生了沖突，2.0和2.5兩個(gè)版本沖突昭卓。但是classpath中只會(huì)依賴一個(gè)版本的Z包愤钾。根據(jù)傳遞依賴的最短路徑優(yōu)先原則，最終依賴的應(yīng)該是2.0版本葬凳。
如果Y包中用了Z包2.5版本中新的method時(shí)候绰垂，當(dāng)運(yùn)行到這段邏輯的時(shí)候。就會(huì)報(bào)NoSuchMethodError了火焰。因?yàn)楸緛?lái)依賴的是2.5版本劲装，但是因?yàn)镴ar包沖突Maven選擇了2.0版本，2.0版本中又沒(méi)有這個(gè)新的method昌简，導(dǎo)致出錯(cuò)占业。
但要注意的是，不是所有沖突都會(huì)引起運(yùn)行異常纯赎。相反谦疾，大部分公司的項(xiàng)目都會(huì)有一些Jar包沖突，但其實(shí)沒(méi)有造成運(yùn)行時(shí)的問(wèn)題犬金。
這是因?yàn)楹芏鄠鬟f依賴的Jar包念恍，不管是2.0版本也好，2.5版本也好晚顷，都可以運(yùn)行峰伙。
只有高版本Jar包不向下兼容，或者新增了某些低版本沒(méi)有的API才有可能導(dǎo)致這樣的問(wèn)題
定位沖突
IDEA提供了一個(gè)maven依賴分析神器：Maven Helper
用這個(gè)插件能很好的顯示出項(xiàng)目中所有的依賴樹(shù)和沖突
這里面紅色高亮的部分该默，就表明這個(gè)Jar包有了沖突瞳氓。選中這個(gè)jar包，可以看到這2個(gè)版本的沖突的來(lái)源栓袖。
上圖的例子匣摘，表明cruator-client這個(gè)Jar包店诗，有2個(gè)傳遞依賴，分別為2.5.0版本和4.0.1版本音榜。沖突的描述為：
omitted for conflict with 2.5.0. 由于與2.5.0版本沖突而被省略
具體的層級(jí)在右邊也一目了然了庞瘸，所以maven最終根據(jù)最短路徑優(yōu)先原則選擇了2.5.0版本，4.0.1版本被忽略囊咏。
這時(shí)候有同學(xué)會(huì)問(wèn)：本地環(huán)境我可以利用Maven Helper來(lái)定位恕洲，那么預(yù)生產(chǎn)或者生產(chǎn)環(huán)境呢。又沒(méi)有IDEA梅割，如何定位沖突的細(xì)節(jié)霜第？
可以利用mvn命令來(lái)解決：
mvn dependency:tree -Dverbose
此處一定不要省略
-Dverbose參數(shù)，要不然是不會(huì)顯示被忽略的包的
其實(shí)mvn命令行一樣好用户辞。非常清晰明確泌类。
解決Jar包沖突的幾個(gè)實(shí)用技巧
排除法
還是上面的那個(gè)例子，現(xiàn)在生效的是2.5.0底燎，如果想生效4.0.1刃榨。只需要在2.5.0上面點(diǎn)exclude就行了。
版本鎖定法
如果很多個(gè)依賴都傳遞了Jar包A双仍，涉及了很多個(gè)版本枢希，但是你只想指定一個(gè)版本。用排除法一個(gè)個(gè)去exclude太麻煩朱沃，而且exclude在pom文件中也會(huì)體現(xiàn)苞轿，太多的話，也影響代碼整潔和閱讀感受逗物。
這時(shí)候需要用到版本鎖定法
何謂版本鎖定法搬卒？公司的項(xiàng)目一般都會(huì)有父級(jí)pom，你想指定哪個(gè)版本只需要在你項(xiàng)目的父POM中(當(dāng)然在本工程內(nèi)也可以)定義如下：（還是舉上個(gè)例子翎卓，指定4.0.1版本）
<dependencyManagement>
<dependency>
<groupId>org.apache.curator</groupId>
<artifactId>curator-client</artifactId>
<version>4.0.1</version>
</dependency>
</dependencyManagement>
鎖定版本法可以打破2個(gè)依賴傳遞的原則契邀，優(yōu)先級(jí)為最高
鎖定版本后，依賴樹(shù)為：
都統(tǒng)一變成4.0.1失暴，鎖定版本有一個(gè)好處：版本鎖定并不排除Jar包坯门，而且顯示的把所有版本不一致的Jar包變成統(tǒng)一一個(gè)版本，這樣在閱讀代碼時(shí)比較友好逗扒。也不用忍受一大堆的exclude標(biāo)簽田盈。
如何寫(xiě)一個(gè)干凈依賴關(guān)系的POM文件
我本人是有些輕度代碼潔癖的人，所以即便是pom文件的依賴關(guān)系也想干凈而整潔缴阎。如何寫(xiě)好干凈的POM呢，作者認(rèn)為有幾點(diǎn)技巧要注意：
- 盡量在父POM中定義
<dependencyManagement>简软，來(lái)進(jìn)行本項(xiàng)目一些依賴版本的管理蛮拔，這樣可以從很大程度上解決一定的沖突 - 如果是提供給別人依賴的Jar包述暂，盡可能不要傳遞依賴不必要的Jar包
- 使用
mvn dependency:analyze-only命令用于檢測(cè)那些聲明了但是沒(méi)被使用的依賴，如有有一些是你自己聲明的建炫，那盡量去掉 - 使用
mvn dependency:analyze-duplicate命令用來(lái)分析重復(fù)定義的依賴畦韭，清理那些重復(fù)定義的依賴
最后
其實(shí)龐大的項(xiàng)目依賴傳遞也一定多。但是不管多復(fù)雜的依賴關(guān)系肛跌，看到不要害怕艺配。就這么幾條原則，細(xì)心的去分析衍慎，所有的依賴都有跡可循转唉。
這些傳遞依賴如果管理的好，能讓你的維護(hù)成本大大降低稳捆。如果管不好赠法，這群野孩子每一個(gè)都可能是引發(fā)下一個(gè)NoSuchMethodError的導(dǎo)火索。
關(guān)注作者
如果你喜歡作者的文章乔夯，歡迎微信公眾號(hào)關(guān)注 「元人部落」
一個(gè)只做原創(chuàng)的技術(shù)科技分享號(hào)
關(guān)注后回復(fù)“資料”獲取50G的技術(shù)資料
