spring

品牌型号：联想ThinkPad X1

系统：Windows10家庭版

软件版本：Spring 5.3.7

Spring项目写多了会发现，Bean注入这件事看着简单，但是用起来需要注意的地方也有很多。开发时加个@Autowired基本成了肌肉记忆，大部分时候确实能顺利跑起来，但真实项目中注入方式其实不止一种写法，什么场景该用哪种，为什么团队规范里更推荐某一种，很多人都想不明白，一旦项目结构变复杂，或者依赖关系绕了几层，各种报错都出来了，排查起来经常摸不着头脑。下面给大家介绍一下Spring注入Bean的方式有几种，Spring Bean注入注解异常是什么原因的相关内容。

一、Spring注入Bean的方式有几种

Spring注入Bean有很多种方式，例如可以使用构造器进行注入，通过类的构造方法把依赖传进来。我们在构造函数的形参里声明我们需要的依赖类型，Spring在创建这个Bean的时候就会自动找到匹配的依赖对象，通过构造方法传进去。可能有些小伙伴没有注意过，如果一个类只有一个构造方法，其实从Spring 4.3开始，这个构造方法上的@Autowired注解其实可以省略，容器会自动识别。

如果我们在类里给依赖字段提供对应的setter方法，方法上加@Autowired，容器实例化对象之后，调用这个setter方法也能把依赖注入进去。

字段注入是直接在成员变量上加@Autowired，不需要手动编写构造方法与setter方法，容器通过反射直接把值塞进字段，虽然写法简单，但依赖关系不直观，而且不方便编写单元测试，所以在项目里不建议各位大量使用。

Spring还支持用@Resource、@Inject这类注解完成类似的注入效果，只是匹配规则略有差异，@Autowired默认按类型匹配，@Resource默认按名称匹配。

二、Spring Bean注入注解异常是什么原因

我们在开发中注入时出现异常的频率不低，那么都是什么原因导致的呢？如果报错信息是NoSuchBeanDefinitionException，那可能是容器找不到对应的Bean，出现这个问题，通常是目标类压根没有被纳入容器管理，可能是类上忘了加@Component、@Service这类注解，也许是类所在的包没有被组件扫描覆盖到，容器启动的时候根本不知道这个类的存在，自然也就找不到对应的Bean。

如果依赖类型匹配到了多个Bean，会出现NoUniqueBeanDefinitionException，匹配到多个Bean会导致容器不知道该注入哪一个。在同一个接口有多个实现类的场景，我们使用@Autowired默认按类型匹配，如果类型对应不止一个Bean，又没有进一步指定该用哪个，容器就会因为无法判断而报错，这时候可以考虑配合@Qualifier注解指定具体的Bean名称或者用@Primary标记一个默认优先的实现。

也可能是循环依赖导致的异常，例如两个或多个Bean互相依赖，A依赖B，B又依赖A，容器在创建对象的时候会陷入死循环，没法正常完成实例化。Spring对setter注入和字段注入形式的循环依赖，通过三级缓存机制能解决部分场景的循环依赖问题，但如果用的是构造器注入，循环依赖基本是无解的，只能从设计层面拆开这层依赖关系。

以上就是Spring注入Bean的方式有几种，Spring Bean注入注解异常是什么原因的全部内容了。Bean注入的几种写法，构造器、setter、字段注入各有各自的使用场景，平时开发时选哪种，更多看团队习惯和具体需求。虽然注入时出现异常让人很头疼，但是几乎都是因为容器找不到Bean、类型匹配到多个、循环依赖，这几种情况，我们在遇到问题时，先看清楚异常类型，再对照排查思路去定位，比盲目改代码效率高得多。