Spring Bean 依赖注入常见错误（下）

@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
• 

2 解析@Value的字符串值

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

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

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

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

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

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

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

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

而具体的查找执行，通过

PropertySourcesPropertyResolver#getProperty

获取执行方式

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

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

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

修正

避免使用同一个名称，具体修改如下：

user.name=admin
user.password=pass

其实还是不行。

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

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