public Object doResolveDependency(DependencyDescriptor descriptor, @Nullable String beanName,
@Nullable Set 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。
![](https://img-blog.csdnimg.cn/24b383c3c8a84d7a8edf3f98dfd42e78.png?x-oss-process=image/watermar 《一线大厂Java面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义》无偿开源 威信搜索公众号【编程进阶路】 k,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBASmF2YUVkZ2Uu,size_20,color_FFFFFF,t_70,g_se,x_16)
所以这真是冤家路窄了,刚好系统环境变量(systemEnvironment)含同名配置。若没有意识到它们的存在,起了同名字符串作为 @Value,就容易引发这类问题。
[](()修正
避免使用同一个名称,具体修改如下:
user.name=admin
user.password=pass