// 先随便写个 main 方法, 如我写的, 可测试依赖循环问题和事件监听:
// 包名: cn.gudqs7.spring.tests, 改动则需同步修改xml哦
// 进入对应类代码: 快捷键 Cmd+Option+鼠标点击 (或 Ctrl+Alt+鼠标左键 ); 如果是接口松开 Option(或Alt)键

Test.java
public class Test {

	public static void main(String[] args) {
		ApplicationContext xmlContext = new ClassPathXmlApplicationContext("application-wq.xml");
		UserServiceImpl userService = xmlContext.getBean(UserServiceImpl.class);
		userService.sayHi();
	}

}


application-wq.xml
<?xml version="1.0" encoding="UTF-8" ?>
<beans xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns="http://www.springframework.org/schema/beans"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd" default-autowire="byName">

	<bean name="userService" class="cn.gudqs7.spring.tests.UserServiceImpl">
		<property name="starter"><ref bean="serverStarter"/></property>
	</bean>
	<bean name="serverStarter" class="cn.gudqs7.spring.tests.ServerStarter">
		<property name="userService"><ref bean="userService"/></property>
	</bean>

</beans>

    
UserServiceImpl.java
@Service
public class UserServiceImpl {

	@Resource
	private ServerStarter starter;

	public void sayHi() {
		System.out.println(starter);
		System.out.println("Hello Spring!");
	}

	public void setStarter(ServerStarter starter) {
		this.starter = starter;
	}
}


ServerStarter.java
@Service
public class ServerStarter implements ApplicationListener<ContextRefreshedEvent> {

	@Inject
	private UserServiceImpl userService;

	@Override
	public void onApplicationEvent(ContextRefreshedEvent event) {
		String applicationName = event.getApplicationContext().getApplicationName();
		System.out.println(applicationName);
		System.out.println(userService);
		System.out.println("========== started by gudqs7 ==============");
		System.out.println("========== started by gudqs7 ==============");
		System.out.println("========== started by gudqs7 ==============");
	}

	public void setUserService(UserServiceImpl userService) {
		this.userService = userService;
	}
}

// 接下来, 进入ClassPathXmlApplicationContext#ClassPathXmlApplicationContext(java.lang.String) 方法中

// 其跳转到了
  public ClassPathXmlApplicationContext(
			String[] configLocations, boolean refresh, @Nullable ApplicationContext parent)
			throws BeansException {

		// 为容器的 parent 字段赋值, 若 parent 不为空, 且有 ConfigurableEnvironment, 则合并数据(将父容器有的加到子容器中)
		// 即执行了 org.springframework.context.support.AbstractApplicationContext.setParent()
		super(parent);

		// 为 configLocations 字段赋值(告知配置文件位置), 赋值前会根据环境变量解析(此时环境变量中只有系统环境变量: 如JAVA_HOME).
		setConfigLocations(configLocations);
		if (refresh) {
			// 注释在下面
      refresh();
		}
	}

// 然后具体的看 refresh 方法
public void refresh() throws BeansException, IllegalStateException {
		// 1.设置容器初始的一些属性(时间,状态)，初始化占位符数据源并校验所有 bean 所使用的占位符是否存在, 清空事件和监听
		// 2.清空重置旧的 beanFactory, 再创建新的 beanFactory 并通过解析 xml或注解 加载 beanDefinitions
		// 3.设置了一些 beanFactory 的属性, 添加了几个有用的 BeanPostProcessor, 还添加了几个 bean 到容器中(都是环境相关的 bean)
		// 4.子类对beanFactory 添加自己的特殊的 BeanPostProcessor (如servletContxt/servletConfig注入)
		// 5.扫描容器中实现了 BeanFactoryPostProcessor 接口的 bean 将其注册到 beanFactory 中并执行
		// 6.扫描容器中实现了 BeanPostProcessor 接口的 bean 将其注册到 beanFactory 但不执行(实例化 bean 对象那会有几个执行时机)
		// 7.创建一个国际化资源解析器并注册到 beanFactory; 创建一个事件广播器并注册到 beanFactory.
		// 8.调用子类的其他刷新时需要做的事情(模板方法)
		// 9.扫描容器中实现了 ApplicationListener 接口的 bean, 将其预存到广播器中但不执行
		//10.完成 beanFactory 的一些配置(包括终结一些东西, 如 setTempClassLoader(null) ); 将单例的 bean 创建出来放入容器中(未设置lazy-init=true)的 bean
		//11.广播 ContextRefreshedEvent 事件， 初始化LifeCycleProcessor及调用其 onRefresh 方法.

		synchronized (this.startupShutdownMonitor) {
			// Prepare this context for refreshing.
			// 设置容器初始的一些属性(时间,状态)，初始化占位符数据源并校验所有 bean 所使用的占位符是否存在, 清空事件和监听
			prepareRefresh();

			// Tell the subclass to refresh the internal bean factory.
			// 清空重置旧的 beanFactory, 再创建新的 beanFactory 并解析 xml或注解 加载 beanDefinitions
			ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory();

			// Prepare the bean factory for use in this context.
			// 设置了一些 beanFactory 的属性, 添加了几个有用的 BeanPostProcessor, 还添加了几个 bean 到容器中(都是环境相关的 bean)
			prepareBeanFactory(beanFactory);

			try {
				// Allows post-processing of the bean factory in context subclasses.
				// 子类对beanFactory 添加自己的特殊的 BeanPostProcessor (如servletContxt/servletConfig注入)
				postProcessBeanFactory(beanFactory);

				// Invoke factory processors registered as beans in the context.
				// 扫描容器中实现了 BeanFactoryPostProcessor 接口的 bean 将其注册到 beanFactory 中并执行
				//   扫描6次, 2(BeanDefinitionRegistry/BeanFactory) x 3(优先级:高/中/其他)
				invokeBeanFactoryPostProcessors(beanFactory);

				// Register bean processors that intercept bean creation.
				// 扫描容器中实现了 BeanPostProcessor 接口的 bean 将其注册到 beanFactory 但不执行; 扫描6次: 2(MergedBeanDefinitionPostProcessor/其他) x 3(优先级: 高/中/其他)
				registerBeanPostProcessors(beanFactory);

				// Initialize message source for this context.
				// 创建一个国际化资源解析器并注册到 beanFactory.
				initMessageSource();

				// Initialize event multicaster for this context.
				// 创建一个事件广播器并注册到 beanFactory.
				initApplicationEventMulticaster();

				// Initialize other special beans in specific context subclasses.
				// 调用子类的其他刷新时需要做的事情(模板方法)
				onRefresh();

				// Check for listener beans and register them.
				// 将可能存在的 applicationListeners 注册到事件广播器中(新建时是不存在的),
				// 然后扫描容器中实现了 ApplicationListener 接口的 bean, 将其预存到广播器中但不执行
				// 将之前 publishEvent() 想广播的事件广播出去, 然后字段 earlyApplicationEvents 赋值为空(代表之后可立即广播)
				registerListeners();

				// Instantiate all remaining (non-lazy-init) singletons.
				// 完成 beanFactory 的一些配置(包括终结一些东西, 如 setTempClassLoader(null) )
				// 注册默认的表达式解析器(若无相应的bean存在)
				// 扫描容器中实现了 LoadTimeWeaverAware 接口的 bean, 并触发(getBean)之前注册过的 BeanPostProcessor
				// 将单例的 bean 创建出来放入容器中(未设置lazy-init=true)的 bean
				finishBeanFactoryInitialization(beanFactory);

				// Last step: publish corresponding event.
				// 广播 ContextRefreshedEvent 事件， 初始化LifeCycleProcessor及调用其 onRefresh 方法.
				finishRefresh();
			}

			catch (BeansException ex) {
				if (logger.isWarnEnabled()) {
					logger.warn("Exception encountered during context initialization - " +
							"cancelling refresh attempt: " + ex);
				}

				// Destroy already created singletons to avoid dangling resources.
				// 销毁缓存的单例对象
				destroyBeans();

				// Reset 'active' flag.
				// 变更状态
				cancelRefresh(ex);

				// Propagate exception to caller.
				throw ex;
			}

			finally {
				// Reset common introspection caches in Spring's core, since we
				// might not ever need metadata for singleton beans anymore...
				// 清空公共工具产生的缓存(内存松一口气).
				resetCommonCaches();
			}
		}
	}

// 挨个看里面的方法
org.springframework.context.support.AbstractApplicationContext#prepareRefresh
    // 1.设置容器初始的一些属性, 如启动时间, 当前状态
		// 2.打印开始日志
		// 3.初始化占位符数据源
		// 4.校验所有 bean 所使用的占位符是否存在
		// 5.清空事件和监听
		// Switch to active.
  
org.springframework.context.support.AbstractRefreshableApplicationContext#refreshBeanFactory
    // 1.存在旧的则先摧毁 bean 对象实例及缓存数据, 再将旧的置为 null
		// 2.创建一个新的 beanFactory 对象, 再设置 id及一些配置
		// 3.扫描并加载 beanDefinations
		// 4.设置这个新的 beanFactory 对象为 applicationContext 的 beanFactory 字段值.
  
org.springframework.context.support.AbstractApplicationContext#prepareBeanFactory
    // 1.设置 beanFactory 的类加载器
		// 2.设置 beanFactory 的表达式解析器
		// 3.1:注册一个 BeanPostProcessor 用于将实现了ApplicationContext能力相关的Aware接口的 bean, 触发赋值setter 注入 applicationContext 对象
		// 3.2:设置 beanFactory 处理 bean 时要忽略的接口(主要是setter注入时忽视一些也是setter的方法, 因为这些方法会由 PostProcessor 来触发)
		// 4.注册一些特殊的 bean(注入这些bean时会注入 this 对象: 多功能工具人 ApplicationContext, 可见其和普通 bean 的注册方式不一样)
		// 5.注册一个 BeanPostProcessor 用于检测加载的 bean 是否实现了 ApplicationListener 接口, 若是, 则注册到事件广播器中(不是,是暂存在applicationListeners字段中, 等事件广播器创建后才注册)
		// 6.注册一个 BeanPostProcessor 用于触发实现了 LoadTimeWeaverAware 接口的 bean 的 setLoadTimeWeaver() 社会 LTW 实例.
		// 7.注册几个环境相关 bean 到容器中(Spring的环境对象, 以及系统环境变量和系统配置文件)

org.springframework.context.support.PostProcessorRegistrationDelegate#invokeBeanFactoryPostProcessors(org.springframework.beans.factory.config.ConfigurableListableBeanFactory, java.util.List<org.springframework.beans.factory.config.BeanFactoryPostProcessor>)
    // 1.若 beanFactory 实现了 BeanDefinitionRegistry 接口(new AnnotationConfigApplicationContext 就实现了)
		//    则扫描所有实现了 BeanDefinitionRegistryPostProcessor 接口的 bean, 根据优先级分三类(高/中/其他)依次执行
		// 2.然后扫描所有实现了 BeanFactoryPostProcessor 接口的 bean, 依旧是根据优先级分三类依次执行.
		// 3.每次执行前都会根据 Order 信息排序, 再遍历执行
  
org.springframework.context.support.PostProcessorRegistrationDelegate#registerBeanPostProcessors(org.springframework.beans.factory.config.ConfigurableListableBeanFactory, org.springframework.context.support.AbstractApplicationContext)
    // 1.扫描6次: 2(MergedBeanDefinitionPostProcessor/其他) x 3(优先级: 高/中/其他)
		//    将其加入到 beanFactory 的 beanPostProcessors 集合中
		// 2.再次加入 ApplicationListenerDetector (用于处理实现 ApplicationListener 的 bean 注册到事件广播器), 主要是使其在链末尾, 可以最后执行.

org.springframework.context.support.AbstractApplicationContext#registerListeners
    // 1.将可能存在的 applicationListeners 注册到事件广播器中(新建时是不存在的)
		// 2.扫描容器中实现了 ApplicationListener 接口的 bean, 将其预存到广播器中但不执行
		// 3.将之前 publishEvent() 想广播的事件广播出去, 然后字段 earlyApplicationEvents 赋值为空
		//    (因为 publishEvent() 中根据是否为空判断立刻执行或先存着) (另这也解释了 prepareRefresh() 中为何要赋值一个空集合)

  
org.springframework.context.support.AbstractApplicationContext#finishBeanFactoryInitialization
    // 1.完成 beanFactory 的一些配置
		// 2.注册默认的表达式解析器(若无相应的bean存在)
		// 3.扫描容器中实现了 LoadTimeWeaverAware 接口的 bean, 并触发(getBean)之前注册过的 BeanPostProcessor
		// 4.将单例的 bean 创建出来放入容器中(未设置lazy-init=true)的 bean

org.springframework.context.support.AbstractApplicationContext#finishRefresh
    // 1.清空资源缓存
		// 2.创建一个生命周期管理器(start, refresh, stop等)并注册到 beanFactory
		// 3.触发生命周期管理器的 onRefresh()
		// 4.广播容器刷新完成的事件
		// 5.为 Spring Tool Suite 提供某些便捷(没用过, 不知道...)

// 从这个方法进入
@Override
public <T> T getBean(Class<T> requiredType) throws BeansException {
  // 判断容器的状态, 确保 beanFactory 可用.(主要是若不可用, 提示的错误信息会比getBeanFacgtory()中更准确)
  // 使用 beanFactory 的 getBean 方法获取对象并返回.
  assertBeanFactoryActive();
  return getBeanFactory().getBean(requiredType);
}

// 然后其他所有涉及的核心方法的注释
org.springframework.beans.factory.support.DefaultListableBeanFactory#resolveBean
    // 调用 resolveNamedBean, 如存在 bean 则直接返回. (核心)
		// 若不存在则从父容器中寻找, 父容器实现了 DefaultListableBeanFactory 则调与同子容器相同的方法
		// 若没实现则 通过 getBeanProvider 获取.
  
org.springframework.beans.factory.support.DefaultListableBeanFactory#resolveNamedBean(org.springframework.core.ResolvableType, java.lang.Object[], boolean)
    // 1.调用 getBeanNamesForType 获取所有与 type 相匹配的 beanName 集合.
		// 2.遍历判断每个 beanName 是否可用
		// 3.若可用的 beanName 只有一个, 则调用 getBean(beanName) 获取对象实例并返回
		//   若可用数超过一个, 则试着根据是否主要以及高优先级来确定一个 beanName 实例, 若能确定则返回, 不能则报错.

org.springframework.beans.factory.support.AbstractBeanFactory#doGetBean
    // 1.获取完整的 beanName
		// 2.调用 getSingleton1() 检查是否存在缓存, 这层检查可防止依赖循环.
		//     若存在, 则通过 getObjectForBeanInstance() 判断缓存的是 bean 还是 FactoryBean 并返回相应的对象实例.
		// 3.若不存在, 先试着从父容器获取(子容器不存在这个 beanDefinition 且父容器不为空)
		//     没有父容器则 调用 markBeanAsCreated() 标记这个 bean已经创建了 (先标记, 再创建)
		//     获取 beanDefinition, 判断其 dependsOn 属性是否存在, 存在则 先获取依赖的 bean
		//     调用 getSingleton2() 处理单例缓存
		// 4.而 getSingleton2() 中的闭包中 执行的 createBean() 方法中则才是创建实例并调用 BeanPostProcessor

org.springframework.beans.factory.support.DefaultSingletonBeanRegistry#getSingleton(java.lang.String, boolean)
    // 1.判断是否存在于 singletonObjects 中
		// 2.若不存在则判断 bean 是否处于创建中(未创建完成, 如循环依赖时)
		// 3.若处于创建中, 则同步后判断是否存在于 earlySingletonObjects (也就是 singletonFactories 移除后存入的地方)
		//      (因为FactoryBean占用空间大, 获取对象麻烦且速度更慢, 这是为了防止如果循环依赖链条很长 多次获取浪费CPU的问题)
		// 4.不存于 earlySingletonObjects 则代表第一次(也只会有一次)取 singletonFactories
		//    取出后调用 getObject() 并将其存入到 earlySingletonObjects, 然后从 singletonFactories 中移除. 以后就少走几行代码了.
  
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry#getSingleton(java.lang.String, org.springframework.beans.factory.ObjectFactory<?>)
    // 1.先确保是第一次创建单例对象, 防止重复创建
		// 2.进行一些异常处理
		// 3.调用 singletonFactory.getObject() 创建对象
		// 4.创建对象结束添加单例缓存和清空 singletonFactories / earlySingletonObjects 缓存.
  
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory#createBean(java.lang.String, org.springframework.beans.factory.support.RootBeanDefinition, java.lang.Object[])
    // 1.调用 resolveBeanClass 解析得到真正的 bean class, 若解析不为空且处于某些情况下, 则复制一份 beanDefinition 并设置 beanClass 为解析所得
		// 2.执行 BeanPostProcessor 的 postProcessorsBeforeInstantiation() 方法
		// 3.调用 doCreateBean() 创建对象 并返回

org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory#doCreateBean
    // 1.调用 createBeanInstance() 获得一个 对象实例的 包装类
		// 2.同步锁下执行 BeanFactoryPostProcessor 的 postProcessMergedBeanDefinition().
		// 3.添加 singletonFactories 缓存, 移除 earlySingletonObjects; 解决循环依赖问题.
		// 4.调用 populateBean() 检查字段是否需要注入对象实例, 是则获取对应的 bean 注入. (可能引起循环依赖)
		// 5.调用 initializeBean() 执行对象的一些 Aware 和 init 方法和 BeanPostProcessor 的 postProcessBeforeInitialization.
		// 6.最后返回对象实例.

  // 1.1: InstantiationAwareBeanPostProcessor 的 postProcessAfterInstantiation()
//   在 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean 第一段
// 1.2: InstantiationAwareBeanPostProcessor 的 postProcessProperties()
//   在 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean 第二段
// 1.3: InstantiationAwareBeanPostProcessor 的 postProcessPropertyValues
//   在 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean 第三段
// 1.4: InstantiationAwareBeanPostProcessor 的 postProcessBeforeInstantiation()
//   在 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsBeforeInstantiation 中

// 2.1: SmartInstantiationAwareBeanPostProcessor 的 predictBeanType()
//   在 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.predictBeanType 中
// 2.2: SmartInstantiationAwareBeanPostProcessor 的 getEarlyBeanReference()
//   在 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.getEarlyBeanReference 中
// 2.3: SmartInstantiationAwareBeanPostProcessor 的 determineCandidateConstructors()
//   在 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.determineConstructorsFromBeanPostProcessors 中

// 3.1: MergedBeanDefinitionPostProcessor 的 postProcessMergedBeanDefinition()
//   在 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyMergedBeanDefinitionPostProcessors 中
// 3.2: MergedBeanDefinitionPostProcessor 的 resetBeanDefinition()
//   在 org.springframework.beans.factory.support.DefaultListableBeanFactory.resetBeanDefinition 中

// 4.1: DestructionAwareBeanPostProcessor 的 postProcessBeforeDestruction()
//   在 org.springframework.beans.factory.support.DisposableBeanAdapter.destroy 中
// 4.2: DestructionAwareBeanPostProcessor 的 requiresDestruction()
//   在 org.springframework.beans.factory.support.DisposableBeanAdapter.filterPostProcessors 和 org.springframework.beans.factory.support.DisposableBeanAdapter.hasApplicableProcessors 中

1) acquire(): 尝试获取一个许可证, 获取成功则直接返回(lock结束), 获取失败则需要排队
2) tryAcquire(): 判断当前许可证数量(state), 若为0则尝试获取
     分公平和非公平, 公平锁会判断 hasQueuedPredecessors, 非公平则直接抢 compareAndSetState
     若不为0, 则判断持有锁的人是否为我本身, 是则增加当前许可证数量, 返回true获取成功
     不是则 返回 false, 获取失败(将排队).
3) addWaiter(): AQS 队列尾部添加一个 Node(waiter=X[独占锁]), 若 tail 不存在, 则先初始化一个 空head[空指不代表任何线程] 后再加入队列
4) acquireQueued: 进入队列的节点, 尝试获取许可证, 失败则 park()
     先判断node的上一个节点是否为 head 节点, 若是, 则要尝试获取一次许可证(因为这说明上一个线程已经在执行过程中了, 也许已经走完了unlock() 方法(即已经运行过唤醒队列下一位的代码了,而因为你那时还不在队列中或没进入睡眠中, 唤醒代码是无意义的), 而你则刚加入队列, 如果你此时直接park()去等待唤醒, 则根本无人唤醒你, 同理你的下一个节点也就等不到你去唤醒它.)
     如果不是, 设置了上一个节点的 waitStatus 为 SINGLE 后, 自己睡眠 park(), 等待唤醒

唤醒后:  
5) 判断上一个节点是不是 head, 一般来说是(因为unkock唤醒的一般就是head.next)
     如果不是则进入 shouldParkAfterFailedAcquire: 将队列中一些已取消的节点从队列中删除, 重新设置节点的prev
     因为是for循环, 所以又会再回来判断, 这时应该是head了, 尝试获取许可证, 2种可能, 非公平时被刚lock的人抢了(概率较小吧), 另一种就是获取成功
     获取成功后, 把原head节点删掉, 自己设为head节点(head象征一个拿到许可证的节点,除队列第一次初始化), 然后返回到acquire(), 中途没有线程被打断就正常出方法, lock结束

总结:
得到方式1: acquire 时 state = 0, 且抢到了.
得到方式2: 没抢到或不让抢(公平锁), 进入队列等上一个来唤醒我, 上一个等上上个来唤醒他, 上上个等上上上个唤醒....
    unlock 唤醒队列第二个非取消的线程并删除队列第一个元素 [其他元素移位]
    这样第二个线程就可以唤醒非取消的第三个线程[相对而言的第三个,实际上唤醒时还是第二个, 只是唤醒后会删除第一个, 所以第三变第二]

读锁
	获取锁 tryAcquireShared(), 若当前没有写锁存在, 则 state + 1个读单位, 然后返回获取成功. 防止返回获取失败, 进入队列休眠.
	释放锁 tryReleaseShared(), state - 1个读单位, 然后根据 state = 0 判断返回是否可以唤醒队列.
	
写锁
	获取锁 tryAcquire(), 若存在读锁, 则失败, 若存在写锁, 判断是否重入获取, 是则返回获取成功. 否则失败; 失败就意味着加队列,休眠.
    释放锁 tryRelease(), state - 1, 判断 state 中写锁数量是否为0, 是则可以唤醒队列. 否则代表这时一个可重入锁的释放逻辑.
   
总结: 读写锁也好, 可重入锁也好, CountDownLatch 等工具类也好, 都是对 state 操作为多, 或者说, 实现了 AQS的它们, 只负责操作 state, 而队列, 唤醒, 都交给 AQS 来处理.

1) 首先 AbstractApplicationContext#prepareBeanFactory 会添加一个ApplicationContextAwareProcessor
2) 这个 beanPostProcessor 负责在bean初始化之前注入context对象.
3) 这个 beanPostProcessor 的执行时机是在 doCreateBean 中的 postProcessBeforeInitialization()

1) 在 AbstractApplicationContext#registerListeners() 中扫描容器内所有相关实现类加入到事件监听者集合中
2) 然后在publishEvent时，遍历事件监听者集合调用bean的方法即可。观察者模式！
3) 另外也用了BeanPostProcessor去实现, 叫 ApplicationListenerDetector, 加入时机同1, 执行时机同1.
4) 至于为何使用2种机制，与多例有关吧！(scope="prototype")

1) 首先 getBeanPostProcessorCache 获取一些特殊的BeanPostProcessor
2) 如 InstantiationAwareBeanPostProcessor/SmartInstantiationAwareBeanPostProcessor
3) 然后 createBean时, 会在正确的时机使用到这些特殊的 PostProcessor, 取出来, 然后执行对应方法
4) 具体何时可以查看 getBeanPostProcessorCache() 的调用位置一一查看.

1) 首先是指定包名或指定类名
	如指定包名则scan时会执行, 如指定类名则在构造方法初始化 reader 时执行
2) 无论哪种, 最终都会走一段代码 AnnotationConfigUtils#registerAnnotationConfigProcessors()
3) 这段代码会添加一些 BeanFactoryPostProcessor
	如 ConfigurationClassPostProcessor 负责解析 @Configuration/@Import/@Bean 注解
    	postProcessBeanDefinitionRegistry() 中 parse 所有的带以上注解的 beanDefinitions
    	ConfigurationClassParser 将注解信息解析保存，
    	然后由 ConfigurationClassBeanDefinitionReader 负责注册到容器。
	如 AutowiredAnnotationBeanPostProcessor 负责解析 @Autowired/@Value 注解
    如 CommonAnnotationBeanPostProcessor 负责解析 @Resource 注解
    解析放在 postProcessProperties() 方法中， 先扫描bean的字段和方法， 然后一一调用方法和为字段注入值
4) 之后, 他会将扫描的类放到 beanDefinitions 中(或指定的类注册进去)
5) BeanFactory加载完毕后, 回到AbstractApplicationContext的refresh逻辑
	如会执行 postProcessBeanFactory(), 调用前面加入的ConfigurationClassPostProcessor
	然后会添加更多的类到容器中.
    
注意事项：
    @Configuration 和 @Component的区别？
    观察发现，即使使用@Component 其下带 @Bean 的方法依然可以注入到容器中。所以似乎两者没有区别？
    仔细查看源码和资料后，发现 postProcessBeanFactory() 方法在 processConfigBeanDefinitions() 后还会调用 enhanceConfigurationClasses()
    而在这个方法中, 对前面解析了class 是 CONFIGURATION_CLASS_FULL (即代表@Configuration)的类
    会生成一个 cglib 的代理, 这样获取@Bean注解的方法的bean时,不会每次调用方法new 一个, 而是有缓存.

1) 使用 @EnableAspectJAutoProxy
2) @EnableAspectJAutoProxy 中使用了 @Import(AspectJAutoProxyRegistrar.class)
3) ConfigurationClassPostProcessor 会解析@Import, 进入 registerBeanDefinitions() 中
4) registerBeanDefinitions() 中添加了 AnnotationAwareAspectJAutoProxyCreator 到容器中
5) AnnotationAwareAspectJAutoProxyCreator 本质上时一个 BeanPostProcessor
6) 因此在 createBean 时, 会被自动调用. 其中 postProcessAfterInitialization() 负责创建代理对象
7) 而 getAdvicesAndAdvisorsForBean() 则负责查找对应的增强. 然后会调用子类的findCandidateAdvisors
8) 如 AnnotationAwareAspectJAutoProxyCreator#findCandidateAdvisors() 负责注解编写增强@Before/@After等
9) 简单说下逻辑, 就是查找容器所有类, 判断这个类有没有 @Aspect 注解, 然后先找出所有Pointcut
	再遍历所有方法, 找出方法上带有@Before等注解且有关联的Pointcut的方法,
    然后使用这个方法和关联的Pointcut 来new 一个Advisor, 加入到Advisor集合中, 遍历结束后返回即可.
10) 查找到所有的增强后, 再比较Pointcut表达式是否匹配当前的bean, 如可以则加入.
11) 根据找到的Advisor集合, 创建一个带配置(advisor集合等)的代理对象, 代理对象执行方法前
12) 会先根据配置中的advisor集合生成一个执行链, 然后在拦截代理方法处调用. 执行链会负责执行通知.
13) 不同的通知由不同的适配器执行.

0) 事务是由AOP实现的, 所以需要找到对应的Pointcut 和 Advisor
1) 打开了 @EnableTransactionManagement 注解
2) 然后@Import 了 TransactionManagementConfigurationSelector
3) 之后导入了 ProxyTransactionManagementConfiguration 到容器中
4) ProxyTransactionManagementConfiguration 带有 @Configuration
5) @Bean 注入了一个通用的Advisor: BeanFactoryTransactionAttributeSourceAdvisor
6) 这个Advisor的 Pointcut 是由 TransactionAttributeSourcePointcut 实现的
	实现逻辑是 TransactionAttributeSourcePointcut 的 matches()
    这个方法调用了 getTransactionAttributeSource() 获取 AnnotationTransactionAttributeSource
    然后通过 getTransactionAttribute() 调用了 findTransactionAttribute()
    最终使用SpringTransactionAnnotationParser 类判断方法是否有@Transactional注解
    并解析注解信息然后返回. 另外这个方法还可以获取@Transactional注解的信息, 而这里只用于判断是否需要拦截这个方法.
7) TransactionInterceptor 是一个Advisor
    也可以通过AnnotationTransactionAttributeSource获取@Transactional注解上的信息
    然后在invoke中, 拦截方法, 打开事务, 在执行完方法后, 提交事务, 报错时回滚事务
    这个 Advisor 不同于传统的前置/后置, 而是更具体的 MethodInterceptor.

1.MultipartAutoConfiguration
	添加了一个bean StandardServletMultipartResolver, 并设置上传文件大小等属性
	使得Spring MVC中的 DispatcherServlet 可以获取 multipartResolver, 处理文件上传.
    若不是Spring Boot, 需要在xml或注解中手动添加一个 这样的bean才能处理文件上传, 而且配置文件还要自己读取.

2.MailSenderAutoConfiguration
    添加了一个 JavaMailSenderImpl 的bean到容器中, 并设置邮箱服务器/账号/密码等属性
    若不是Spring Boot, 需要在xml中配置一个bean即配置他的属性(邮箱配置)

3.TransactionAutoConfiguration
    在内部类添加 @EnableTransactionManagement，剩下的参考上面的 Spring 事务实现
    
4.WebMvcAutoConfiguration
    添加了 RequestMappingHandlerAdapter/RequestMappingHandlerMapping
    添加了 ContentNegotiatingViewResolver

1) 创建 SpringApplicationRunListeners 管理 run 过程的事件, 监听者取自 spring.factories
2) 触发 run 的开始(starting)事件
3) 初始化 environment 对象, 并利用 run 的 environmentPrepared 事件将application.yml的数据注入
4) 打印 Banner, 可自定义 Banner 通过 banner.txt 文件
5) 根据webApplicationType创建一个ApplicationContext 容器
    默认使用 AnnotationConfigApplicationContext
6) 为 context 做一些初始化和设置
    设置环境变量， 使得 context 可以获取 application.yml 中的配置
    调用子类扩展的设置
    加载 容器的 initializers
    触发 run 的 contextPrepared 事件
    打印日志
    添加spring boot 启动参数信息到 bean 容器中
    设置beanFactory的 allowBeanDefinitionOverriding 属性
    设置 懒加载策略， 添加 postProcessor 则会将每个 beanDefinition 的 lazyInit 设置为 true
    把启动类class封装成 BeanDefinition 放到容器中, 使得@Configuration之类的注解生效
    触发 run 的 contextLoaded 事件
7) 调用 context 的 refresh()
    执行 BeanFactoryPostProcessor, 如 ConfigurationClassPostProcessor 解析 @Import 注解
    @Import 会实现 @EnableAutoConfiguration, 总之都是熟悉的 spring 套路. boot的东西就少了.
8) 调用留给子类的 afterRefresh() 方法, 默认空实现
9) 打印启动完毕信息
10) 触发 run 的 started 事件
11) 调用 容器内所有的 ApplicationRunner 和 CommandLineRunner 实现类, 类似事件监听.
12) 使用 spring.factories 中的 exceptionReporters 处理可能出现的异常.
13) 触发 run 的 running 事件

1) 首先加了 @EnableConfigurationProperties 也会解析里面的 @Import 
2) @Import 则引入了 EnableConfigurationPropertiesRegistrar.class
3) 这是一个 ImportBeanDefinitionRegistrar 的实现类, 会在解析 @Configuration 注解时调用指定方法
4) 指定方法 registerBeanDefinitions() 获取 @EnableConfigurationPropertiesRegistrar 的数据
    如 @EnableConfigurationProperties(RabbitProperties.class) 加载 RabbitProperties.class
    然后, 将这些 class 都注册到容器中
5) 指定方法还注册了一些工具bean和一个重要的 BeanPostProcessor 在 registerInfrastructureBeans()中
6) registerInfrastructureBeans() 加载了 ConfigurationPropertiesBindingPostProcessor.class
7) 在 postProcessorBeforeInitialization() 中 调用 ConfigurationPropertiesBinder
8) 调用链很长, 最后 property.setValue(beanSupplier, bound);设置了值 -- JavaBeanBinder

总结: 就是先将 XxxProperties 类定义注入到容器中, 这样可以getBean, 然后通过 BeanPostProcessor
    再实例化后将属性值一一绑定.

1) 在类上加上注解 @Conditional 或 带有 @Conditional 的其他注解:其他扩展实现
2) 在所有的扫描类和注解的地方,如解析@Configuration, AnotatedBeanDefinitionReader等reader
    会使用 ConditionEvaluator 的 shouldSkip() 判断是否可以加载, 时机点如下
    AnnotatedBeanDefinitionReader#doRegisterBean() 的第二行代码
    ConfigurationClassBeanDefinitionReader#loadBeanDefinitionsForBeanMethod() 第四行
    ConfigurationClassBeanDefinitionReader#loadBeanDefinitionsForConfigurationClass()
    ConfigurationClassParser#doProcessConfigurationClass() 处理 ComponentScan 那段
3) 然后再 shouldSkip 中判断， 判断逻辑大致如下：
    先遍历所有注解取得所有的 @Conditional 下的 所有 value, 这个 value 是具体的Condition实现, 如OnClassCondition
    实例化 Condition 然后添加到 conditions中
    排序并遍历调用 matches(), 一个不匹配则返回true, 代表应该跳过.

TIPS:
ConditionOutcome 封装了是否匹配和匹配日志信息[为啥成功/为啥失败]
SpringBootCondition 提供了通用的根据 ConditionOutcome 判断是否匹配并记录日志信息的抽象类.
    子类只需实现 getMatchOutcome(): 根据 metadata[注解信息] 返回 ConditionOutcome 对象.
    因此, 如果我们要实现自己的 Condition, 可以继承它.

1) 首先 AutoConfigurationImportSelector 是一个 DeferredImportSelector  
2) 这种 DeferredImportSelector 会延迟加载, 原理是 parse 后再加载, 而非parse执行过程中就加载.
3) 延迟加载机制 会先调用 process 方法, 将要加载的class保存起来, 然后再调用 selectImports 返回.
4) 此时 AutoConfigurationImportSelector.AutoConfigurationGroup 的 selectImports() 会调用 sortAutoConfigurations(), 也就是调用了 AutoConfigurationSorter.getInPriorityOrder()
5) getInPriorityOrder() 调用了 sortByAnnotation() 这个方法根据2个注解 @AutoConfigureBefore @AutoConfigureAfter 排序.
6) 最后返回的就是有序的了. 另外, 这两个注解只能作用再 AutoConfiguration 上.

总结:
所有的 AutoConfiguration 所引入的class文件解析完毕后, 再准备加载之前, 进行排序, 然后一一加载.

1) run方法中创建了Environment对象, 当初始化好一些东西后会触发事件
2) 通过 SpringApplicationRunListeners 的 environmentPrepared() 告知监听者
3) 默认存在 spring.factories 中的 EventPublishingRunListener 监听者负责转发事件
4) 事件被转发到 ApplicationListener 下的监听者来处理
5) 监听者配置在 spring.factories 中, 其中 ConfigFileApplicationListener 监听了此事件
6) 此监听者接受 ApplicationEnvironmentPreparedEvent 事件后
7) 加载一些 postProcessor 专门用于处理 environment 对象的 postProcessor
8) 其他的 postProcessor 暂时不管, 真正做了加载的是 postProcessors.add(this); 自己的实现
9) 自己的处理方法是: addPropertySources(), 此方法将会扫描指定的路径下指定的某些文件
10) 然后使用 spring.factories 下的 PropertySourceLoader 一一尝试解析
11) 文件存在且解析正确则加入到 environment 的 propertySources.
	某些路径: getSearchLocations() ,默认: classpath:/,classpath:/config/ ...
	某些文件: getSearchNames() ,默认: application

TIPS: 
PropertySourceLoader 有 PropertiesPropertySourceLoader/YamlPropertySourceLoader
一个尝试后缀有 xml/properties, 另一个是 yml/yaml, 所以所有可能性有:
    classpath:/application.xml; classpath:/application.properties
	classpath:/application.yml; classpath:/application.yaml
    ......

1) boot 的 run 里面会创建 applicationContext, 如是 webApplicationType = SERVLET, 则实现类为 AnnotationConfigServletWebServerApplicationContext
    另外一提, webApplicationType 是根据 classpath 下是否有哪些类来推断的.
2) 这个类继承了 ServletWebServerApplicationContext
3) ServletWebServerApplicationContext 实现了 onRefresh()
4) onRefresh() 调用了 createWebServer()
5) createWebServer() 使用 ServletWebServerFactory.getWebServer() 获取 webServer 对象
6) ServletWebServerFactory 会被 ServletWebServerFactoryAutoConfiguration 引入
    详细见 ServletWebServerFactoryConfiguration.EmbeddedTomcat.class
7) 引入后调用 getWebServer(), 大概为 new Tomcat(), 设置属性, 然后启动.
8) 至此, run() 启动了 tomcat 或 jetty/undertow.
 
TIPS:
spring 使用工厂模式获取webServer, 然后工厂又通过AutoConfiguration自动注入(还会判断Condition).
    这样如果新增一种 webServer, 只需要在写一个 AutoConfiguration 注入一个 工厂即可. 非常灵活.

/**
 * 新增一个用户
 *
 * @param userEntity 用户信息
 * @return 操作是否成功
 * #code 1 用户名已存在 建议换个用户名再试
 * #code 2 手机号已存在 同上
 * #hiddenRequest userId,lastLoginTime
 * #hiddenResponse totalCount
 */
@PostMapping("/addUser")
public BaseResponse<Boolean> addUser(@RequestBody UserEntity userEntity) {
    // todo 新增用户
    log.info("addUser--> " + JsonUtils.getJsonString(userEntity));

    return BaseResponse.success(true);
}

/**
 * 新增一个用户
 *
 * @param userEntity 用户信息
 * @return 操作是否成功
 * #code 1 用户名已存在 建议换个用户名再试
 * #code 2 手机号已存在 同上
 * #hiddenRequest userId,lastLoginTime
 * #hiddenResponse totalCount
 */
@PostMapping("/addUser")
public BaseResponse<Boolean> addUser(@RequestBody UserEntity userEntity) {
    // todo 新增用户
    log.info("addUser--> " + JsonUtils.getJsonString(userEntity));

    return BaseResponse.success(true);
}

/**
 * 修改用户信息
 *
 * @param userEntity 用户信息
 * @return 操作是否成功
 * #hiddenRequest lastLoginTime,userGender,userAge
 * #hiddenResponse totalCount
 */
@PostMapping("/updateUser")
public BaseResponse<Boolean> updateUser(@RequestBody UserEntity userEntity) {
    // todo 修改用户信息
    log.info("updateUser--> " + JsonUtils.getJsonString(userEntity));

    return BaseResponse.success(true);
}

/**
 * 测试字段上的注释有哪些 tag
 * 字段注释说明是可以换行的
 * 当然有个前提就是
 * 最终负责渲染Markdown的引擎需要支持 <br> 标签，也就是支持部分 HTML
 * #required
 * #hidden false
 * #important
 * #example 测试示例值 此处可带空格，方法上的 @param 后面不行
 * #notes 对应其他参考信息 同理，可带空格，方法上的 @param 后面不行
 * #notes 谁说我不能换行的，只是没那么优雅罢了
 * #notes 不过也还凑合，换行
 */
@ApiModelProperty(value = "这里是Swagger的字段说明\n试试换行", required = true, hidden = false,
        example = "测试示例值", notes = "对应其他参考信息\n试试换行")
private String testField;

/**
 * 查询用户信息(分页)
 * 试试换行
 * #notes 方法的更多信息需要换行展示，毕竟内容很多啊
 * #notes 这样看起来如何！
 *
 * @param listUserPage 过滤条件
 * @param userEntities 没用的参数 hidden
 * @return 用户列表数据-分页
 * #hiddenRequest userEntities
 * #hiddenResponse data.userAvatar
 */
@PostMapping("/listUser")
public BaseResponse<List<ListUserResponse>> listUserPage(ListUserRequest listUserPage, List<UserEntity> userEntities) {
    // todo 查询分页数据
    log.info("listUserPage--> " + JsonUtils.getJsonString(listUserPage));

    return BaseResponse.success(new ArrayList<>(), 0L);
}