上一篇spring getBean 源码学习（上）基本上把getBean的过程细节了解清楚了，还剩下一些疑问以及没有注意到的细节，本篇文章就来深入细节，解析之前遗留的问题，最好是配合着上篇一起看。
现在已知的存在不同类型（scope）的bean被存储在容器中
并不存在这样的，spring整个的bean管理容器是DefaultListableBeanFactory,他有很多个线程安全或者线程不安全的容器存有不同类型的数据，可是具体bean的信息是存储在BeanDefinition中的，在AbstractBeanDefinition中有个scope的数据，他就存储着bean的具体类型，在使用的时候直接判断其scope即可
把获取的bean列表 循环一遍依次实例化、填充数据
是这样操作的，在解析xml的时候，finishBeanFactoryInitialization方法会实例化所有还没处理的single对象
有一个问题不知道有没有想到，实际开发中很少有使用getBean操作去获取相应bean，那么那些注解依赖的bean是如何生成的呢？下面是我们使用的demo聊一聊这个问题
Teacher类加上了Component这个注解，spring启动的时候就会解析实例化这个类。
原因就在下面这个xml配置上
在spring xml的bean提取 源码学习文章中对NameSpace进行了详细的解释。在此不做过多说明，直接看图
很明显了，相关bean的注册操作就是依靠ComponentScanBeanDefinitionParser类完成，xml文件扫描完成之后，在refresh中的finishBeanFactoryInitialization完成实例化操作。如下代码完成了bean的注册工作。
ClassPathBeanDefinitionScanner 文件
protected Set<BeanDefinitionHolder> doScan(String... basePackages) {
Assert.notEmpty(basePackages, "At least one base package must be specified");
Set<BeanDefinitionHolder> beanDefinitions = new LinkedHashSet<BeanDefinitionHolder>();
for (String basePackage : basePackages) {
Set<BeanDefinition> candidates = findCandidateComponents(basePackage);
for (BeanDefinition candidate : candidates) {
ScopeMetadata scopeMetadata = this.scopeMetadataResolver.resolveScopeMetadata(candidate);
candidate.setScope(scopeMetadata.getScopeName());
String beanName = this.beanNameGenerator.generateBeanName(candidate, this.registry);
if (candidate instanceof AbstractBeanDefinition) {
postProcessBeanDefinition((AbstractBeanDefinition) candidate, beanName);
}
if (candidate instanceof AnnotatedBeanDefinition) {
AnnotationConfigUtils.processCommonDefinitionAnnotations((AnnotatedBeanDefinition) candidate);
}
if (checkCandidate(beanName, candidate)) {
BeanDefinitionHolder definitionHolder = new BeanDefinitionHolder(candidate, beanName);
definitionHolder =
AnnotationConfigUtils.applyScopedProxyMode(scopeMetadata, definitionHolder, this.registry);
beanDefinitions.add(definitionHolder);
registerBeanDefinition(definitionHolder, this.registry);
}
}
}
return beanDefinitions;
}
各种不同类型的容器，例如实例化好的，正在实例化的、正在被销毁的、已经销毁的
如下代码，在DefaultListableBeanFactory文件中有多种容器，以完成各种需求
// 工厂的序列号id，唯一性
private String serializationId;
// 允许bean出现覆盖的情况
private boolean allowBeanDefinitionOverriding = true;
// 是否提前加载，而不需要关系是否存在懒加载的情况
private boolean allowEagerClassLoading = true;
// 针对依赖列表的选择器
private Comparator<Object> dependencyComparator;
// 目前还没搞懂具体的含义
private AutowireCandidateResolver autowireCandidateResolver = new SimpleAutowireCandidateResolver();
// 依赖对应的具体对象
private final Map<Class<?>, Object> resolvableDependencies = new ConcurrentHashMap<Class<?>, Object>(16);
// 存储bean的容器，以name为key
private final Map<String, BeanDefinition> beanDefinitionMap = new ConcurrentHashMap<String, BeanDefinition>(256);
// 以className为key的线程安全的容器，包括了single和非single（prototype）
private final Map<Class<?>, String[]> allBeanNamesByType = new ConcurrentHashMap<Class<?>, String[]>(64);
// 单例single的容器，以className为key
private final Map<Class<?>, String[]> singletonBeanNamesByType = new ConcurrentHashMap<Class<?>, String[]>(64);
// beanName 为集合的list
private volatile List<String> beanDefinitionNames = new ArrayList<String>(256);
...
其中关键字allowBeanDefinitionOverriding很有意思，是关于重名bean的，可以查看spring 同名bean问题 源码学习 具体了解其中的用法
填充数据这部分操作得支持@value等类似操作
@value作为一个注解，在填充到bean中肯定需要从配置文件获取其值，然后才可以设置类的字段意思。接下来就具体学习下其中的原理
ComponentScanBeanDefinitionParser 类
这个类是为<context:component-scan base-package="com.demo"/>，他会注入接下来需要使用的AutowiredAnnotationBeanPostProcessor类
接下来，在填充值的时候就会利用到AutowiredAnnotationBeanPostProcessor类了。
AutowiredAnnotationBeanPostProcessor 文件
从populateBean函数进入的，设置属性值
public PropertyValues postProcessPropertyValues(PropertyValues pvs,
PropertyDescriptor[] pds, Object bean, String beanName)
throws BeanCreationException {
InjectionMetadata metadata = findAutowiringMetadata(beanName, bean.getClass(), pvs);
// 从该AutowiredAnnotationBeanPostProcessor的cache中获取该名称的注入元类信息
try {
metadata.inject(bean, beanName, pvs);
// 注入值
}
catch (BeanCreationException ex) {
throw ex;
}
catch (Throwable ex) {
throw new BeanCreationException(beanName, "Injection of autowired dependencies failed", ex);
}
return pvs;
}
InjectionMetadata 文件
public void inject(Object target, String beanName, PropertyValues pvs)
throws Throwable {
Collection<InjectedElement> elementsToIterate =
(this.checkedElements != null ? this.checkedElements : this.injectedElements);
// 获取的元素一次循环进行注入inject操作
if (!elementsToIterate.isEmpty()) {
boolean debug = logger.isDebugEnabled();
for (InjectedElement element : elementsToIterate) {
if (debug) {
logger.debug("Processing injected element of bean '" + beanName + "': " + element);
}
element.inject(target, beanName, pvs);
}
}
}
AutowiredAnnotationBeanPostProcessor 文件
protected void inject(Object bean, String beanName, PropertyValues pvs)
throws Throwable {
Field field = (Field) this.member;
Object value;
if (this.cached) {
value = resolvedCachedArgument(beanName, this.cachedFieldValue);
}
else {
DependencyDescriptor desc = new DependencyDescriptor(field, this.required);
desc.setContainingClass(bean.getClass());
Set<String> autowiredBeanNames = new LinkedHashSet<String>(1);
TypeConverter typeConverter = beanFactory.getTypeConverter();
try {
value = beanFactory.resolveDependency(desc, beanName, autowiredBeanNames, typeConverter);
// 调用bean工厂DefaultListableBeanFactory 的解决依赖功能
// 得到其真实的值
// TODO 目前也没看懂具体的细节，(／_＼)
}
catch (BeansException ex) {
throw new UnsatisfiedDependencyException(null, beanName, new InjectionPoint(field), ex);
}
synchronized (this) {
if (!this.cached) {
if (value != null || this.required) {
this.cachedFieldValue = desc;
registerDependentBeans(beanName, autowiredBeanNames);
if (autowiredBeanNames.size() == 1) {
String autowiredBeanName = autowiredBeanNames.iterator().next();
if (beanFactory.containsBean(autowiredBeanName)) {
if (beanFactory.isTypeMatch(autowiredBeanName, field.getType())) {
this.cachedFieldValue = new ShortcutDependencyDescriptor(
desc, autowiredBeanName, field.getType());
}
}
}
}
else {
this.cachedFieldValue = null;
}
this.cached = true;
}
}
}
if (value != null) {
ReflectionUtils.makeAccessible(field);
// 最后直接修改这个field的属性值
field.set(bean, value);
}
}
}
总结：其实没有非常理解其在赋值的操作细节，跨度太长，不过也清楚了如果需要使用依赖注入的功能更，则一定需要在xml中加入<context:component-scan base-package="com.demo"/>这样类似的话。
对外提供各种接口，便于用户可以自定义操作bean（例如BeanPostProcessor）
在spring中确实发现了很多的继承自BeanPostProcessor的类，beanfactory通过getBeanPostProcessor方法获得所有的BeanPostProcessor，然后通过类型筛选取得需要的对象，依次处理被管理的bean。如我们之前说的Spring 钩子之BeanFactoryPostProcessor和BeanPostProcessor的源码学习 同样是BeanPostProcessor的一种。基本上所有的使用的套路都是这样的，如下图中还存在自定义的CustomBeanPostProcessor
PS:在idea中可以通过Ctrl+H查看该类继承图
相互引用的情况，A引用B，B引用A该如何解决
这里存在两种依赖情况
- 构造器依赖
构造器依赖意味着引用的对象必须实例化，可是这样就导致了A等着B的实例化，B又等着A的实例化，造成了死锁一般的情况，会提示错误
- set依赖
set依赖原则上来说是没问题的，只需要选择一个先实例化即可，但是官方并不推荐这样做，而是推荐修改业务逻辑，使用其他方法实现
这一节基本上就到此结束了，大概的说了一些之前忽略的点，其实还有几个点可以细说，限于精力，后续会继续介绍同名Bean的处理情况以及BeanPostProcessor等
