程序员需要了解依赖冲突的原因以及解决方案

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,从而导致运行直接失败。

除了上述问题,依赖冲突还可能导致应用抛出 ClassNotFoundExceptionNoClassDefFoundError 等错误。

抛出错误这种情况还算好,还比较容易定位问题。怕就怕,不同版本同一个类内部逻辑不同,从而导致业务异常。这种问题,真的很让人抓狂,让人头秃。

仔细分析依赖冲突,主要可以分为两类:

  • 项目同一依赖应用,存在多版本,每个版本同一个类,可能存在差异。
  • 项目不同依赖应用,存在包名,类名完全一样的类。

下面我们分析一下依赖冲突产生的原因。

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

compileMaven 默认属性,将会使依赖包参与项目的编译,测试,运行阶段。当然,项目打包之后将会包含该依赖。

provided

provided 意味着依赖仅参与项目编译,测试的阶段。若有如下依赖关系:

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

C 的 scopeprovided,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

systemprovided 范围一致,只不过 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 的 scopeprovided/test, C 只在 B 中起作用,不会通过间接依赖传递给 A。

当且仅当 B 的 scopecompile,且 C scoperuntime ,A 将会间接依赖 C,且 scoperuntime。其他情况下,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-lang3common-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

原文地址:https://www.cnblogs.com/goodAndyxublog/p/12355528.html

时间: 2024-10-08 08:07:42

程序员需要了解依赖冲突的原因以及解决方案的相关文章

Java程序员面试失败的5大原因

下面是Java程序员面试失败最有可能的5大原因,当然也许这5点原因适用于所有的程序员,所以,如果你是程序员,请认真阅读以下内容. #1 说得太少 尤其是那些开放式的问题,如“请介绍下你自己”或“请讲一下你曾经解决过的复杂问题”.面试官会通过你对这些技术和非技术问题的回答来评估你的激情.他们也会通过模拟团队氛围和与你的交流互动来判断你的经验和能力. 所以,仅仅只用两三句话来回答不但不能显示出你对这个专业的兴趣,还会让整个面试过程显得非常无聊.如果你不能很好地说明你的经验.成就和技能可以给企业带来的

java基础知识强化52:Java程序员面试失败的5大原因

下面是Java程序员面试失败最有可能的5大原因,当然也许这5点原因适用于所有的程序员,所以,如果你是程序员,请认真阅读以下内容. 1 说得太少 尤其是那些开放式的问题,如“请介绍下你自己”或“请讲一下你曾经解决过的复杂问题”.面试官会通过你对这些技术和非技术问题的回答来评估你的激情.他们也会通过模拟团队氛围和与你的交流互动来判断你的经验和能力. 所以,仅仅只用两三句话来回答不但不能显示出你对这个专业的兴趣,还会让整个面试过程显得非常无聊.如果你不能很好地说明你的经验.成就和技能可以给企业带来的价

Java程序员面试失败的5大原因!

如今的企业不仅要程序员做的了专职码农,还要你有一定的工作经验和过硬的技术,不仅找的到bug还能搞的定产品,不仅逻辑思维细密还要能抗压力,这样多的要求要在一场短短的半个小时面试中完全展现,那么在面试中怎么让程序员大放异彩,而Java程序员在面试中到底应该注意哪些方面呢?达妹为大家总结了程序员面试失败的原因,大家有则改之无则加勉吧:糟糕的礼仪和态度 迟到,不适宜的着装,抖手抖脚,没有眼神接触,过于紧张,没有提问,显示不出对这份职业的兴趣,"我什么都知道"的高傲态度,贬低你的现在和以前的雇主

依赖冲突的原因以及解决办法

原创 鸭血粉丝 Java极客技术 0x00. 前言 依赖冲突是日常开发中经常碰到的过程,如果运气好,并不会有什么问题.偏偏阿粉有点背,碰到好几次生产问题,排查一整晚,最后发现却是依赖冲突的引起的问题. 没碰到过这个问题同学可能没什么感觉,阿粉举两个最近碰到例子,让大家感受一些. 例子 1: 我们公司有个古老的业务基础包 A.B,C 业务依赖这个包.某个团队拷贝 A 的部分代码进行重构,类名与路径完全一样,然后重新打包成 D 发布. 一次业务改动,B 业务也引入了 D 包,测试环境运行的时候,一切

为什么国外程序员爱用 Mac?

from http://www.vpsee.com/2009/06/why-programmers-love-mac/ Mac 在国外很受欢迎,尤其是在 设计/web开发/IT 人员圈子里.普通用户喜欢 Mac 可以理解,毕竟 Mac 设计美观,简单好用,没有病毒.那么为什么专业人士也对 Mac 情有独钟呢?从个人使用经验来看我想有下面几个原因: 1.Mac OS X 是基于 Unix 的.这一点太重要了,尤其是对开发人员,至少对于我来说很重要,这意味着Unix 下一堆好用的工具都可以随手捡到.

程序员的价值观与网络的复杂性

网络是极其复杂的,这种复杂包含混沌和不确定性,网络是一个典型的复杂系统.然而网络映射到程序员的心里,它只是一条确定的管道!这种思路会带来问题.程序员与运维/网管之间的斗争依然在继续,在这个无休止的争论中,我不断切换着自己的角色,这一次,我将站在程序员的对立面.        从我的故事说起,这些故事我故意打乱了时间顺序,请看到此文的人并且知道这些事的,不要往自己身上映射,纯技术讨论,无关褒贬! 我的故事一:手机访问慢 那是我刚毕业的时候了,在一家小公司做VOIP,我接手了一个Symbian UI

程序员该如何处理人际关系

程序员该如何处理人际关系,以下峰峰为您分享: 良好的人际关系是一个人获得幸福感的重要指标之一,如果不能维护好与家人.朋友.同事的关系,工作再出色也无法让你快乐. 很多人对程序员的印象都是内向.呆板.邋遢.闷骚,然而这并不是真实的程序员.导致这种情况的原因大致是因为:编程的工作需要记忆很多程序逻辑,必有高度集中精力,因此工作中会尽量少跟人说话,工作后需要大量的时间休息.其次,对于普通人来说,编程语言太高深,他们工作的内容无法跟你分享,导致聊天话题减少,这是很正常的,并不是他们不喜欢聊天. 如果你有

程序员论

[青铜程序员] 熟悉相关专业技术,通过询问和参考别人的代码能开发功能模块,代码较规范 [白银程序员] 熟悉公司的基本开发平台和框架,能独立完成分配的模块,代码优质 [黄金程序员] 深入了解公司封装的工具类,了解平台结构的利弊,独立或简单参考资料就能重新搭建平台 对于业务模块,能根据公司现有框架,从技术角度上解剖需求,代码处处是亮点,给人启发 [铂金程序员] 不依赖IDE工具(使用各种IDE都能结合现有平台开发),熟悉IDE的实现细节 对apache下的开源项目有一定的了解,根据公司需求能将一些成

黑衣路人:当过了30岁,程序员的出路在哪里?

年过30,有时候会觉得前半生走来,一切都在懵懂中跌跌撞撞,不知道想要追逐什么,也没有想到要去思考想要追逐什么.但现在却越来越觉得迷茫,是一直在技术钻研的道路上走下去,还是寻求其他的职业发展通道(主要指往管理岗).其实管理岗毕竟数量有限,一批人中最终能上去的就一两个,那些没上去的人会怎么走?公司里看到好些10多年的老员工,顶着一个技术经理的头衔在浑浑度日,感受不到激情和奋进,这让我恐慌,深怕自己也会成为这样的一员. 而我,身在1.5线城市,最近在考虑是否换一个环境,毕业后一直在一家公司效力8年,提