Spring Bean 依赖注入常见错误问题

有时我们会使用@Value自动注入,同时也存在注入到集合、数组等复杂类型的场景。这都是方便写 bug 的场景。

1 @Value未注入预期值

在字段或方法/构造函数参数级别使用,指示带注释元素的默认值表达式。

通常用于表达式驱动或属性驱动的依赖注入。 还支持处理程序方法参数的动态解析

例如,在 Spring MVC 中,一个常见的用例是使用#{systemProperties.myProp} systemProperties.myProp #{systemProperties.myProp}样式的 SpEL(Spring 表达式语言)表达式注入值。

或可使用${my.app.myProp}样式属性占位符注入值。

@Value实际处理由BeanPostProcessor执行,这意味着不能在BeanPostProcessor或BeanFactoryPostProcessor类型中使用 @Value

V.S Autowired

在装配对象成员属性时,常使用@Autowired来装配。但也使用@Value进行装配:

  • 使用@Autowired一般都不会设置属性值
  • @Value必须指定一个字符串值,因其定义做了要求:

    B11CF401-7402-8D3E-E76B-E45FFAB35CA0.png

一般都会因 @Value 常用于String类型的装配,误以为其不能用于非内置对象的装配。

可用如下方式注入一个属性成员:

669EE6F7-3ABA-F665-6CD1-9A9C7D967905.png

使用 @Value更多是用来装配String,而且支持多种强大的装配方式

6A1BB2F5-16C5-465A-348C-8892DB66454C.png

application.properties配置了这样一个属性:

user=admin
password=pass

然后我们在一个Bean中,分别定义两个属性来引用它们:

894E29DD-404E-EEAC-3007-D9428CC535D0.png

password返回了配置值,但user却不是配置文件的指定值,而是PC用户名。

答疑

有一个正确的,说明 @Value使用姿势没问题,但user为啥不正确?

这就得精通Spring到底如何根据 @Value查询值。

@Value的核心工作流程
DefaultListableBeanFactory#doResolveDependency
@Nullable
public Object doResolveDependency(DependencyDescriptor descriptor, @Nullable String beanName,
      @Nullable Set<String> autowiredBeanNames, @Nullable TypeConverter typeConverter) throws BeansException {
    // ...
    Class<?> type = descriptor.getDependencyType();
      // 寻找@Value
      Object value = getAutowireCandidateResolver().getSuggestedValue(descriptor);
      if (value != null) {
         if (value instanceof String) {
            // 解析Value值
            String strVal = resolveEmbeddedValue((String) value);
            BeanDefinition bd = (beanName != null && containsBean(beanName) ?
                  getMergedBeanDefinition(beanName) : null);
            value = evaluateBeanDefinitionString(strVal, bd);
         }
         
         // 转化Value解析的结果到装配的类型
         TypeConverter converter = (typeConverter != null ? typeConverter : getTypeConverter());
         try {
            return converter.convertIfNecessary(value, type, descriptor.getTypeDescriptor());
         }
         catch (UnsupportedOperationException ex) {}
      }
    // ...
  }

@Value 的工作大体分为以下三个核心步骤。

1 寻找@Value

判断这个属性字段是否标记为@Value:

QualifierAnnotationAutowireCandidateResolver#findValue
  • valueAnnotationType就是 @Value

    9E77DF80-38D7-2B0F-8755-D9926BABA675.png

    64D2D0EF-F3E7-E6AA-DDE2-27CF805B6D1E.png

2 解析@Value的字符串值

若一个字段标记了 @Value,则可拿到对应字符串值,然后根据字符串值解析,最终解析的结果可能是一个字符串or对象,取决于字符串怎么写。

3 将解析结果转化为待装配的对象的类型

当拿到上一步生成的结果后,我们会发现可能和我们要装配的类型不匹配。

比如定义的是UUID,而结果是个字符串,此时就会根据目标类型来寻找转化器执行转化:

F4A6116D-4EEE-3D67-C5D1-B1B5B6D60244.png

分析可得问题关键在第二步,执行过程:

5C3D4A9A-D8BE-EB40-B635-8D342EF79D36.png

这里是在解析嵌入的值,替换掉占位符。使用PropertySourcesPlaceholderConfigurer根据PropertySources替换。

当使用 ${user} 获取替换值时,最终执行的查找并非只在application.property文件。

可以发现如下“源”都是替换的依据:

5B26C2FB-EA83-26BE-1614-00A419EAB50A.png

而具体的查找执行,通过

PropertySourcesPropertyResolver#getProperty

获取执行方式

7E97016F-8C4D-219B-2EA4-7A9C2C01278A.png

在解析Value字符串有顺序,源都存在CopyOnWriteArrayList,启动时就被按序固定下来了,一个一个“源”顺序查找,在其中一源找到后,就直接返回。

查看systemEnvironment源,发现刚好有个user和自定义的重合,且值不是admin。

FE9F0E6A-ADA5-47C2-162C-F0162D04378F.png

所以这真是冤家路窄了,刚好系统环境变量(systemEnvironment)含同名配置。若没有意识到它们的存在,起了同名字符串作为 @Value,就容易引发这类问题。

修正

避免使用同一个名称,具体修改如下:

user.name=admin
user.password=pass

其实还是不行。

在systemProperties这个PropertiesPropertySource源中刚好存在user.name,真是无巧不成书。所以命名时,我们一定要注意不仅要避免和环境变量冲突,也要注意避免和系统变量等其他变量冲突,才能从根本解决该问题。

Spring给我们提供了很多好用的功能,但是这些功能交织到一起后,就有可能让我们误入一些坑,只有了解它的运行方式,我们才能迅速定位问题、解决问题。

收藏 (0)
评论列表
正在载入评论列表...
我是有底线的
为您推荐
    暂时没有数据