在项目开展历程里, 依赖注入属于核心基础关键能力, 并且注解差不多是多数从事开发工作者的“默认性选择”。然而, 有不少从事开发工作者在项目施行升级操作、多项Bean之间进行匹配情形、循环依赖问题展开排查过程中, 频繁地遭遇困境, 甚至因为这些状况而引发出生产环节故障 —— 为何平常经常会用到的竟然会变成技术层面潜在危险性? 且官方最终真正所推荐的依赖注入具体方案究竟是什么? 这是每一位从事Java后端开发工作的人员都必然需要切实理清的关键重要问题。 引发的技术痛点跟着, 框架进行迭代升级, 特别是在Boot 2.6版本往后, 注解的局限性渐渐显现出来, 于实际项目里引发了许多技术方面的问题:循环依赖隐患旧的版本, 能够借助三级缓存去处理, 针对 字段注入所产生的作用, 是循环依赖, 然而, Boot 2.6 以及高于 2.6 的版本, 在默认的情况下, 是将循环依赖允许配置给禁用掉了的。在.main.allow 被设置为 false 的情况下, 那些大量运用 字段注入的项目, 在升级之后直接启动就会失败。举例来说, 像订单服务与支付服务之间存在的双向 依赖, 具体表现为在新版本当中会直接引发 Bean 创建时的循环依赖报错, 进而阻碍应用的启动。多 Bean 匹配歧义默认依照类型进行注入, 在接口存有多个实现类 Bean 的情形下, 将会抛出。就在这个时候, 开发者需要另外搭配上注解以此来指定 Bean 名称, 这不但增加了代码的冗余成分, 而且还提高了维护所需的成本。比如说在支付接口同时存在支付宝、微信支付实现的情况下, 单纯的是没有办法精确匹配目标 Bean 的。测试与可维护性短板字段注入的Bean不能经由构造器直接进行初始化, 在单元测试的时候要依赖等特殊注解, 并且有反射注入的局限性与此同时, 字段级别的依赖注入致使类的依赖关系不透明代码可读性以及可维护性大幅下滑。依据官方文档的阐述能够获知其态度, “尽管能够运用实施注入, 然而构造器注入一般而言更具可取性, 因为它可保证依赖项是能够使用的并且是不可改变的”, 这样的一种表述实际上是在暗示并非是最佳的解决办法。依赖注入的分层选型策略结合官方所制定的规范以及实际操作过程中积累的实战经验, 能够采用一种分层依赖注入方案, 便是以构造器注入作为主要的方式, 将之作为主体, 而对于则作为辅助手段, 对其使用要谨慎, 谨慎对待, 具体情况如下:核心依赖优先构造器注入对于类的核心业务所依赖的部分像订单服务依赖的仓储层、支付工厂类这样的情况, 应当采用构造器注入这种方式。这种方式能够在编译期的时候就将循环依赖问题暴露出来, 与此同时还支持使用final字段进行修饰, 以此保证依赖是不可变的, 并且也方便在单元测试的时候直接借助构造器来Mock依赖。示例代码如下:Service public class OrderService { // 核心依赖通过构造器注入保证不可变 private final OrderRepository orderRepository; private final PaymentServiceFactory paymentServiceFactory; public OrderService(OrderRepository orderRepository, PaymentServiceFactory paymentServiceFactory) { this.orderRepository orderRepository; this.paymentServiceFactory paymentServiceFactory; } }可选依赖: 针对非核心的那种可选依赖像通知服务、缓存模板这类, 采用 精准注入, 能够使用 注解, 遵循 JSR - 250 标准, 会优先依据名称来注入 Bean, 在没有歧义的情况下不需要额外的注解, 并且注入效率比 要高大概 39.8%这是基于 10000 个 Bean 的实测数据。在存在多实现 Bean 的场景当中, 能够借助 name 属性直接去指定目标 Bean, 如下是示例:RestController RequestMapping(/api/orders) public class OrderController { // 核心依赖构造器注入 private final OrderService orderService; // 可选依赖Resource注入指定Bean名称解决多实现歧义 Resource(name primaryOrderMapper) private OrderMapper orderMapper; Resource private RedisTemplate redisTemplate; public OrderController(OrderService orderService) { this.orderService orderService; } }特殊场景 的限定使用只有在兼容旧系统的情况下, 并且是没有多 Bean 歧义的简单场景内, 才能够少量使用 , 不过要避免字段注入, 要改用 注入的方式, 与此同时标注false 来降低强依赖风险。落地效果与总结某电商项目曾有过这样的变革, 即从 “全字段注入” 转变为分层依赖注入的重构操作, 对其进行重构之后, 有诸多数据得以呈现, 具体如下: 应用启动所耗费的时间, 从原本的3.2秒, 缩短到了2.8秒, Bean注入所消耗的时间, 由347毫秒降低至259毫秒, 循环依赖风险, 从 “高“ 的程度降至 “低” 的程度, 单元测试通过率, 提升了30%, 代码的可读性以及可维护性, 有了很明显的改善。广大Java后端开发者, 要摒弃那种“万能”的一贯认知, 去遵循官方的依赖注入优先级规范, 依据此在项目里落实“构造器 ”的分层方案, 而且建议团队在代码里面强化对于依赖注入规范的校验, 以此从源头避免技术方面的隐患。要是你于依赖注入选型期间碰到过特殊场景下的疑难问题, 又或者有着更优的实践方案, 那么欢迎在评论区留言交流, 一块儿去完善技术栈的最佳实践体系