// 1.RandomLoadBalancer: 就是随机数呗, 0-size, 简单!!
// 在 RandomLoadBalancer#getInstanceResponse() 中
// 觉得这个方法可以做出 protected, 这样有些实现只需要重写这个方法就行了 
private Response<ServiceInstance> getInstanceResponse(List<ServiceInstance> instances) {
  if (instances.isEmpty()) {
    if (log.isWarnEnabled()) {
      log.warn("No servers available for service: " + serviceId);
    }
    return new EmptyResponse();
  }
  int index = ThreadLocalRandom.current().nextInt(instances.size());

  ServiceInstance instance = instances.get(index);

  return new DefaultResponse(instance);
}

// 2.RoundRobinLoadBalancer
// 在 RoundRobinLoadBalancer#getInstanceResponse() 中
// 用一个 position 保存位置, 这个主意高啊, 即保证了数据的正确性, 还.... 编不下去了!!
private Response<ServiceInstance> getInstanceResponse(List<ServiceInstance> instances) {
  if (instances.isEmpty()) {
    if (log.isWarnEnabled()) {
      log.warn("No servers available for service: " + serviceId);
    }
    return new EmptyResponse();
  }
  // TODO: enforce order?
  int pos = Math.abs(this.position.incrementAndGet());

  ServiceInstance instance = instances.get(pos % instances.size());

  return new DefaultResponse(instance);
}

// org.springframework.cloud.loadbalancer.blocking.client.BlockingLoadBalancerClient
// 先进入这个方法, 然后会调用第二个方法.
// 这两个方法其实就是从工厂获取对象执行 choose 后再让其完成请求的执行, 大部分代码都是 LoadBalancerLifecycle 的触发.
@Override
public <T> T execute(String serviceId, LoadBalancerRequest<T> request) throws IOException {
  // 遍历 LoadBalancerLifecycle 触发 onStart 钩子
  // 调用 choose 方法选取一个 IP:PORT 得到包装类 ServiceInstance
  // 遍历 LoadBalancerLifecycle 触发 onComplete 钩子
  // 执行请求
  String hint = getHint(serviceId);
  LoadBalancerRequestAdapter<T, DefaultRequestContext> lbRequest = new LoadBalancerRequestAdapter<>(request,
                                                                                                    new DefaultRequestContext(request, hint));
  Set<LoadBalancerLifecycle> supportedLifecycleProcessors = LoadBalancerLifecycleValidator
    .getSupportedLifecycleProcessors(
    loadBalancerClientFactory.getInstances(serviceId, LoadBalancerLifecycle.class),
    DefaultRequestContext.class, Object.class, ServiceInstance.class);
  supportedLifecycleProcessors.forEach(lifecycle -> lifecycle.onStart(lbRequest));

  // 从 serviceId 对应的容器中获取一个负载均衡算法实现类对象, 即 ReactorServiceInstanceLoadBalancer.
  // 调用其 choose 方法. 从响应中获取 ServiceInstance 并返回.
  ServiceInstance serviceInstance = choose(serviceId, lbRequest);
  if (serviceInstance == null) {
    supportedLifecycleProcessors.forEach(lifecycle -> lifecycle.onComplete(
      new CompletionContext<>(CompletionContext.Status.DISCARD, lbRequest, new EmptyResponse())));
    throw new IllegalStateException("No instances available for " + serviceId);
  }
  // 可以执行了
  return execute(serviceId, serviceInstance, lbRequest);
}

@Override
public <T> T execute(String serviceId, ServiceInstance serviceInstance, LoadBalancerRequest<T> request)
  throws IOException {
  // 遍历 LoadBalancerLifecycle 触发 onStartRequest 钩子
  // 调用 request.apply 方法执行请求(即进入之前 LoadBalancerRequestFactory 中的代码)
  // 遍历 LoadBalancerLifecycle 触发 onComplete 钩子

  DefaultResponse defaultResponse = new DefaultResponse(serviceInstance);
  Set<LoadBalancerLifecycle> supportedLifecycleProcessors = LoadBalancerLifecycleValidator
    .getSupportedLifecycleProcessors(
    loadBalancerClientFactory.getInstances(serviceId, LoadBalancerLifecycle.class),
    DefaultRequestContext.class, Object.class, ServiceInstance.class);
  Request lbRequest = request instanceof Request ? (Request) request : new DefaultRequest<>();
  supportedLifecycleProcessors
    .forEach(lifecycle -> lifecycle.onStartRequest(lbRequest, new DefaultResponse(serviceInstance)));
  try {
    // 请求调用前先使用 transformers 对原始请求对象进行一些改变处理后再执行请求
    T response = request.apply(serviceInstance);
    Object clientResponse = getClientResponse(response);
    supportedLifecycleProcessors
      .forEach(lifecycle -> lifecycle.onComplete(new CompletionContext<>(CompletionContext.Status.SUCCESS,
                                                                         lbRequest, defaultResponse, clientResponse)));
    return response;
  }
  catch (IOException iOException) {
    supportedLifecycleProcessors.forEach(lifecycle -> lifecycle.onComplete(
      new CompletionContext<>(CompletionContext.Status.FAILED, iOException, lbRequest, defaultResponse)));
    throw iOException;
  }
  catch (Exception exception) {
    supportedLifecycleProcessors.forEach(lifecycle -> lifecycle.onComplete(
      new CompletionContext<>(CompletionContext.Status.FAILED, exception, lbRequest, defaultResponse)));
    ReflectionUtils.rethrowRuntimeException(exception);
  }
  return null;
}

// 先看其如何获取对象的 LoadBalancerClientFactory#getInstance()
@Override
public ReactiveLoadBalancer<ServiceInstance> getInstance(String serviceId) {
  // 从 serviceId 对应的容器中获取一个负载均衡算法实现类对象, 即 ReactorServiceInstanceLoadBalancer.
  return getInstance(serviceId, ReactorServiceInstanceLoadBalancer.class);
}
// getInstance(serviceId, ReactorServiceInstanceLoadBalancer.class):
public <T> T getInstance(String name, Class<T> type) {
  AnnotationConfigApplicationContext context = getContext(name);
  try {
    return context.getBean(type);
  }
  catch (NoSuchBeanDefinitionException e) {
    // ignore
  }
  return null;
}
// getContext(name):
protected AnnotationConfigApplicationContext getContext(String name) {
  if (!this.contexts.containsKey(name)) {
    synchronized (this.contexts) {
      if (!this.contexts.containsKey(name)) {
        // 结论: 容器里有点东西, 但不多...  主要是于父容器打通... 所以又啥都有了.
        this.contexts.put(name, createContext(name));
      }
    }
  }
  return this.contexts.get(name);
}

// createContext(name):
protected AnnotationConfigApplicationContext createContext(String name) {
  // 0.结合实现类 LoadBalancerClientFactory 做出如下注释
  // 1.将 LoadBalancerAutoConfiguration 扫描到 configurations 注册到 name 对应的容器中.
  //     这里的 name 其实就是 serviceId, 也就是说, 若我们想给某个容器加入一些东西, 则实现 LoadBalancerClientSpecification 时, name 需要与 serviceId 对应起来(相同)
  // 2.当我上面那句没说啊... 原来 name 为 default. 开头是可以加入任意 serviceId 对应的容器的.........................(qiao)
  // 3.为容器加入一个占位符解析器, 和一个 defaultConfigType(=LoadBalancerClientConfiguration.class, 作用配置一些 bean)
  //     LoadBalancerClientConfiguration 会加入一个 RoundRobinLoadBalancer, 看来就是默认的负载均衡类了.
  // 4.默认为加了一个名为 loadbalancer 的 PropertySource, 里面有一个 loadbalancer.client.name=serviceId 的配置....
  // 5.设定父容器, 父容器通过 ApplicationContextAware 获得, 这样刚才那么辛苦的注册方式, 就仅适合于特性, 而非通用了.
  // 6.设置名称(啥意义呢?), 然后调用容器的 refresh() 完成容器加载


  AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext();
  if (this.configurations.containsKey(name)) {
    for (Class<?> configuration : this.configurations.get(name).getConfiguration()) {
      context.register(configuration);
    }
  }
  for (Map.Entry<String, C> entry : this.configurations.entrySet()) {
    if (entry.getKey().startsWith("default.")) {
      for (Class<?> configuration : entry.getValue().getConfiguration()) {
        context.register(configuration);
      }
    }
  }
  context.register(PropertyPlaceholderAutoConfiguration.class, this.defaultConfigType);
  // 默认为加了一个名为 loadbalancer 的 PropertySource, 里面有一个 loadbalancer.client.name=serviceId 的配置....
  context.getEnvironment().getPropertySources().addFirst(new MapPropertySource(this.propertySourceName,
                                                                               Collections.<String, Object>singletonMap(this.propertyName, name)));
  if (this.parent != null) {
    // Uses Environment from parent as well as beans
    context.setParent(this.parent);
    // jdk11 issue
    // https://github.com/spring-cloud/spring-cloud-netflix/issues/3101
    context.setClassLoader(this.parent.getClassLoader());
  }
  context.setDisplayName(generateDisplayName(name));
  context.refresh();
  return context;
}

// 根据这句 context.register(PropertyPlaceholderAutoConfiguration.class, this.defaultConfigType);
// 而 defaultConfigType 在 LoadBalancerClientFactory 定义为 LoadBalancerClientConfiguration.class, 其配置了一个 bean, 代码如下
@Bean
@ConditionalOnMissingBean
public ReactorLoadBalancer<ServiceInstance> reactorServiceInstanceLoadBalancer(Environment environment,
                                                                               LoadBalancerClientFactory loadBalancerClientFactory) {
  String name = environment.getProperty(LoadBalancerClientFactory.PROPERTY_NAME);
  return new RoundRobinLoadBalancer(
    loadBalancerClientFactory.getLazyProvider(name, ServiceInstanceListSupplier.class), name);
}
// 这里会与服务发现结合起来, 即 loadBalancerClientFactory.getLazyProvider(name, ServiceInstanceListSupplier.class)
// 此方法从容器中获取能提供 ServiceInstanceListSupplier.class 类型的 BeanProvider, 其实就是能获取这种类型的 bean 呗, 然后用这个类来获取 url 列表...  具体实现要看 Nacos / Consul 了.

// 所以默认获取的负载均衡策略就是它了:  RoundRobinLoadBalancer

// AQS 的 acquire： AbstractQueuedSynchronizer#acquire()
public final void acquire(int arg) {
  if (
    !tryAcquire(arg) 
    && acquireQueued(addWaiter(Node.EXCLUSIVE), arg)
  ) {
    selfInterrupt();
  }
}
// 1.tryAcquire：判断 state 状态，无线程持有则 CAS 加持 state，并返回 true，加锁结束。
// 2.addWaiter：已被持有则先加入队列
// 3.acquireQueued：两件事，第一，循环尝试持有锁，失败则休眠；第二，持有成功则更新队列头为自己（队列向前移动）
//    加入队列后，不能立刻睡，防止没人唤醒自己（比如还没加入等待队列，上个持有锁的线程就结束了然后触发解锁代码，而解锁代码的唤醒依赖于等待队列）
//    确定得不到锁（需要等待）则进入睡眠，醒来后再尝试 tryAcquire 持有锁，失败则睡眠（循环尝试）
//    醒来尝试持有锁成功后，维护队列（即队列头部设为自己，宏观上队列往前移动了）

// AQS 的 release：AbstractQueuedSynchronizer#release()
public final boolean release(int arg) {
  if (tryRelease(arg)) {
    Node h = head;
    if (h != null && h.waitStatus != 0)
      unparkSuccessor(h);
    return true;
  }
  return false;
}
// 1.tryRelease：减持 state 数量，减到 0 代表线程彻底释放了这个锁
// 2.unparkSuccessor：唤醒下一个节点的线程（若下一个节点为空，则从队列尾往前查找队列中状态不是 CANCELLED 的且最靠前的节点来唤醒）
// 3.唤醒后处于 acquireQueued 的循环中。

// new CountDownLatch(n)：设置 state 的初始值为 n，使得需要调用 n 次 countDown 才会唤醒调用 await 的线程
// countDown：state - 1，若 state 减到 0，则唤醒所有队列中的节点
// await：加入到 AQS 队列休眠，节点标记为 SHARED

// new Semaphore(n)：设置 state 的初始值为 n，当想唤醒调用 acquire(x) 的线程，则需要调用 release(x-n)
// acquire(x)：加入到 AQS 队列休眠（前提 state < x) 
// release(x)：state + x，总是尝试唤醒队列

理解方式：acquire 多少个数，则代表需要等待多少个 release，若有初始值，则需要的 release 再减去初始值；满足则唤醒，为满足则进入队列休眠

// java.util.concurrent.ThreadPoolExecutor#execute
public void execute(Runnable command) {
  if (command == null)
    throw new NullPointerException();
  int c = ctl.get();
  if (workerCountOf(c) < corePoolSize) {
    if (addWorker(command, true))
      return;
    c = ctl.get();
  }
  if (isRunning(c) && workQueue.offer(command)) {
    int recheck = ctl.get();
    if (! isRunning(recheck) && remove(command))
      reject(command);
    else if (workerCountOf(recheck) == 0)
      addWorker(null, false);
  }
  else if (!addWorker(command, false))
    reject(command);
}

org.springframework.web.servlet.HttpServletBean#init
    // 1.把 servletConfig 的 initParameters 都加入 PropertySource, 根据 requiredProperties 判断所需配置项是否齐全
		// 2.将配置项绑定到 Servlet 对象(this) 上(子类的字段也算).
		// 3.调用子类初始化方法
  
org.springframework.web.servlet.FrameworkServlet#initServletBean
    // 0.父类的 init 执行完, 此时 contextConfigLocation 已经有值了
		// 1.记录日志和开始时间
		// 2.创建子容器, 与父容器绑定, 做一些配置, 调用 refresh() 完成加载.
		// 3.打印日志, 打印耗时

  
org.springframework.web.servlet.FrameworkServlet#initWebApplicationContext
    // 1.从 ServletContext 中获取 Spring 容器.(那么谁放进去的呢? 没错, 就是 ContextLoader,监听了 ServletContext 事件)
		// 2.若容器在构造方法处被注入(可能是注解开发 Spring MVC 的方式会触发), 先忽视  -- 来自 web.xml 形式启动分析
		// 3.根据绑定得到的配置的 contextClass 创建一个子容器, 进行一些配置和初始化, 调用 refresh() 完成容器加载
		// 4.防止子容器不支持 refresh, 或子容器不是刚刚创建的, 因此手动触发 onRefresh(), 这个方法会加载一些默认的 bean(用处很大的那种)
		// 5.将容器设置到 ServletContext 中(根据配置, 默认允许)
		// 6.返回创建的子容器对象

  
org.springframework.web.servlet.FrameworkServlet#configureAndRefreshWebApplicationContext
    // 1.根据绑定得到的配置设置容器 id, 若无则生成默认的
		// 2.设置 ServletContext/ServletConfig 对象
		// 3.为子容器添加一个监听只监听子容器刷新事件的监听器, 用于容器加载完毕后调用 FrameworkServlet.onApplicationEvent()
		// 4.将 ServletConfig/ServletContext 加入到 environment 中.
		// 5.执行 web.xml 中配置的 Initializers, 为子容器做的初始化
		// 6.调用子容器的 refresh(), 完成容器的加载

  
org.springframework.web.servlet.DispatcherServlet#initStrategies
    // 加载文件上传处理 bean
		// 加载国际化处理 bean
		// 加载主题切换处理 bean
		// 加载 HandlerMapping bean
		// 加载 HandlerAdapter bean
		// 加载异常处理 bean
		// 加载 HttpServletRequest 转视图名称处理策略 bean
		// 加载视图解析器
		// 加载 FlashMap 管理 bean

		// 每一个加载的逻辑都是类似的, 先从容器中根据 Xxx.class getBean
		// 若无, 则调用 getDefaultStrategy() 从 DispatcherServlet.properties 配置文件中读取

// 入口 HttpServlet.service
@Override
protected void service(HttpServletRequest request, HttpServletResponse response)
  throws ServletException, IOException {

  HttpMethod httpMethod = HttpMethod.resolve(request.getMethod());
  if (httpMethod == HttpMethod.PATCH || httpMethod == null) {
    processRequest(request, response);
  }
  else {
    super.service(request, response);
  }
}

org.springframework.web.servlet.FrameworkServlet#processRequest
    // 1.记录启动时间
		// 2.准备国际化处理上下文
		// 3.准备属性管理上下文
		// 4.获取并缓存一个 asyncManager(异步)
		// 5.初始化两个 ContextHolder
		// 6.处理文件上传, 根据不同策略查找可执行的 controller 方法, 查到后加入拦截器, 再通过适配器来执行 controller 方法, 然后把得到的 ModelAndView 解析成视图对象, 并渲染到前端.
		// 7.重置两个 ContextHolder
		// 8.打印日志, 发布事件

  
org.springframework.web.servlet.DispatcherServlet#doService
    // 1.打印日志, 记录请求信息
		// 2.保存一份请求上下文的快照, 这样嵌套的请求在回归时可以恢复数据
		// 3.将容器中的一些 bean 配置到请求上下文中
		// 4.处理文件上传, 根据不同策略查找可执行的 controller 方法, 查到后加入拦截器, 再通过适配器来执行 controller 方法, 然后把得到的 ModelAndView 解析成视图对象, 并渲染到前端.
		// 5.若需要, 将快照恢复到请求上下文

  
org.springframework.web.servlet.DispatcherServlet#doDispatch
    // 1.准备一些变量
		// 2.判断并处理文件上传请求, 若是, processedRequest 则变为 MultipartHttpServletRequest 类型的对象.
		// 3.遍历之前加载的 handlerMappings, 调用 getHandler 接口获取执行链对象并返回. 找不到则返回 null
		// 4.根据 handler 获取合适的适配器
		// 5.遍历执行拦截器的 preHandle(), 若遇到 renturn false, 则结束 doDispatch
		// 6.执行实际的 controller 的方法得到 ModelAndView 对象.
		// 7.处理默认的 viewName
		// 8.遍历执行拦截器的 postHandle()
		// 9.若有异常则处理异常: 遍历之前加载的异常处理器策略类, 调用 resolveException()
		//10.若无异常则根据需要根据 ModelAndView的对象的视图名配合之前加载的视图解析器获取 View 对象, 再调用 render() 渲染视图.
		//11.最后执行拦截器的 triggerAfterCompletion

  
org.springframework.web.servlet.DispatcherServlet#getHandler
    // 遍历之前加载的 handlerMappings, 调用其 getHandler 接口获取 handler 和拦截器封装成 chain 对象并返回. 找不到则返回 null
  

org.springframework.web.servlet.DispatcherServlet#getHandlerAdapter
    // 遍历之前加载的 handlerAdapters, 调用 supports 判断是否支持 handler, 支持则返回 adapter
  
  
org.springframework.web.servlet.HandlerExecutionChain#applyPreHandle
    // 从头到尾遍历拦截器, 执行 preHandle(), 若拦截器返回 false, 则立刻 triggerAfterCompletion, 然后 return false
  
  
org.springframework.web.servlet.DispatcherServlet#processDispatchResult
    // 若有异常则处理异常: 遍历之前加载的异常处理器策略类, 调用 resolveException()
		// 若无异常则根据需要根据视图名和视图解析器渲染视图
		// 最后执行拦截器的 triggerAfterCompletion

  
org.springframework.web.servlet.DispatcherServlet#processHandlerException
    // 遍历之前加载的异常处理器策略类, 调用 resolveException()
  
  
org.springframework.web.servlet.DispatcherServlet#render
    // 先遍历视图解析器, 根据视图名获取实际视图对象
		// 最后调用实际视图对象的 render (渲染方法)

  
org.springframework.web.servlet.DispatcherServlet#resolveViewName
    // 遍历视图解析器, 根据视图名获取实际视图对象

org.springframework.web.servlet.DispatcherServlet#initStrategies
protected void initStrategies(ApplicationContext context) {
  // 加载文件上传处理 bean
  // 加载国际化处理 bean
  // 加载主题切换处理 bean
  // 加载 HandlerMapping bean
  // 加载 HandlerAdapter bean
  // 加载异常处理 bean
  // 加载 HttpServletRequest 转视图名称处理策略 bean
  // 加载视图解析器
  // 加载 FlashMap 管理 bean

  // 每一个 init 的逻辑都是类似的, 先从容器中根据 Xxx.class getBean
  // 若无, 则调用 getDefaultStrategy() 从 DispatcherServlet.properties 配置文件中读取
  initMultipartResolver(context);
  initLocaleResolver(context);
  initThemeResolver(context);
  initHandlerMappings(context);
  initHandlerAdapters(context);
  initHandlerExceptionResolvers(context);
  initRequestToViewNameTranslator(context);
  initViewResolvers(context);
  initFlashMapManager(context);
}

@Override
public Object resolveArgument(MethodParameter parameter, @Nullable ModelAndViewContainer mavContainer,
                              NativeWebRequest webRequest, @Nullable WebDataBinderFactory binderFactory) throws Exception {
  // 调用 readWithMessageConverters 读取 body 的数据, 再序列化 json 成相应的 Java Bean
  // 使用 binder 检查 arg 的值是否与 @Valid 的那些注解相关的规则相符, 若有错误, 则抛异常.

  parameter = parameter.nestedIfOptional();
  Object arg = readWithMessageConverters(webRequest, parameter, parameter.getNestedGenericParameterType());
  String name = Conventions.getVariableNameForParameter(parameter);

  if (binderFactory != null) {
    WebDataBinder binder = binderFactory.createBinder(webRequest, arg, name);
    if (arg != null) {
      validateIfApplicable(binder, parameter);
      if (binder.getBindingResult().hasErrors() && isBindExceptionRequired(binder, parameter)) {
        throw new MethodArgumentNotValidException(parameter, binder.getBindingResult());
      }
    }
    if (mavContainer != null) {
      mavContainer.addAttribute(BindingResult.MODEL_KEY_PREFIX + name, binder.getBindingResult());
    }
  }

  return adaptArgumentIfNecessary(arg, parameter);
}

// 参考上面的代码
if (binderFactory != null) {
  WebDataBinder binder = binderFactory.createBinder(webRequest, arg, name);
  if (arg != null) {
    validateIfApplicable(binder, parameter);
    if (binder.getBindingResult().hasErrors() && isBindExceptionRequired(binder, parameter)) {
      throw new MethodArgumentNotValidException(parameter, binder.getBindingResult());
    }
  }
  if (mavContainer != null) {
    mavContainer.addAttribute(BindingResult.MODEL_KEY_PREFIX + name, binder.getBindingResult());
  }
}
// 这段代码 validateIfApplicable() 就进行了参数校验, 代码如下:
// 逻辑是: 遍历参数所有的注解, 包含 validatedAnn 或以 Valid 开头的注解都进行校验
protected void validateIfApplicable(WebDataBinder binder, MethodParameter parameter) {
  Annotation[] annotations = parameter.getParameterAnnotations();
  for (Annotation ann : annotations) {
    Validated validatedAnn = AnnotationUtils.getAnnotation(ann, Validated.class);
    if (validatedAnn != null || ann.annotationType().getSimpleName().startsWith("Valid")) {
      Object hints = (validatedAnn != null ? validatedAnn.value() : AnnotationUtils.getValue(ann));
      Object[] validationHints = (hints instanceof Object[] ? (Object[]) hints : new Object[] {hints});
      binder.validate(validationHints);
      break;
    }
  }
}

// 然后是 validate 具体的对象.
// 逻辑是: 遍历所有的 validators, 挨个调用 validate 校验
public void validate(Object... validationHints) {
  Object target = getTarget();
  Assert.state(target != null, "No target to validate");
  BindingResult bindingResult = getBindingResult();
  // Call each validator with the same binding result
  for (Validator validator : getValidators()) {
    if (!ObjectUtils.isEmpty(validationHints) && validator instanceof SmartValidator) {
      ((SmartValidator) validator).validate(target, bindingResult, validationHints);
    }
    else if (validator != null) {
      validator.validate(target, bindingResult);
    }
  }
}
// 再往下就没啦... Spring 没有具体的实现, 所以要导入 Hibernate 的啥啥啥包, 这是有原因的.

// 参考 RequestMappingHandlerAdapter#afterPropertiesSet()
public void afterPropertiesSet() {
  // Do this first, it may add ResponseBody advice beans
  initControllerAdviceCache();

  if (this.argumentResolvers == null) {
    List<HandlerMethodArgumentResolver> resolvers = getDefaultArgumentResolvers();
    this.argumentResolvers = new HandlerMethodArgumentResolverComposite().addResolvers(resolvers);
  }
  if (this.initBinderArgumentResolvers == null) {
    List<HandlerMethodArgumentResolver> resolvers = getDefaultInitBinderArgumentResolvers();
    this.initBinderArgumentResolvers = new HandlerMethodArgumentResolverComposite().addResolvers(resolvers);
  }
  if (this.returnValueHandlers == null) {
    List<HandlerMethodReturnValueHandler> handlers = getDefaultReturnValueHandlers();
    this.returnValueHandlers = new HandlerMethodReturnValueHandlerComposite().addHandlers(handlers);
  }
}

// 寻找字段的引用发现
WebMvcConfigurationSupport#addReturnValueHandlers
WebMvcConfigurationSupport#addArgumentResolvers
// 这两个方法可以继承后加入加入自己的 ArgumentResolvers/ReturnValueHandlers, 也就是项目里面继承 WebMvcConfiguration 的那个类, 重写这两个方法, 加入自己的类即可实现对参数/返回值的干预; 常用于统一加密/解密, 记录日志等.

// 参考 AbstractMessageConverterMethodArgumentResolver#readWithMessageConverters
for (HttpMessageConverter<?> converter : this.messageConverters) {
  Class<HttpMessageConverter<?>> converterType = (Class<HttpMessageConverter<?>>) converter.getClass();
  GenericHttpMessageConverter<?> genericConverter =
    (converter instanceof GenericHttpMessageConverter ? (GenericHttpMessageConverter<?>) converter : null);
  if (genericConverter != null ? genericConverter.canRead(targetType, contextClass, contentType) :
      (targetClass != null && converter.canRead(targetClass, contentType))) {
    if (message.hasBody()) {
      HttpInputMessage msgToUse =
        getAdvice().beforeBodyRead(message, parameter, targetType, converterType);
      body = (genericConverter != null ? genericConverter.read(targetType, contextClass, msgToUse) :
              ((HttpMessageConverter<T>) converter).read(targetClass, msgToUse));
      body = getAdvice().afterBodyRead(body, msgToUse, parameter, targetType, converterType);
    }
    else {
      body = getAdvice().handleEmptyBody(null, message, parameter, targetType, converterType);
    }
    break;
  }
}

// 参考 RequestMappingHandlerAdapter#getDefaultArgumentResolvers
private List<HandlerMethodArgumentResolver> getDefaultArgumentResolvers() {
  List<HandlerMethodArgumentResolver> resolvers = new ArrayList<>();

  // Annotation-based argument resolution
  resolvers.add(new RequestParamMethodArgumentResolver(getBeanFactory(), false));
  resolvers.add(new RequestParamMapMethodArgumentResolver());
  resolvers.add(new PathVariableMethodArgumentResolver());
  resolvers.add(new PathVariableMapMethodArgumentResolver());
  resolvers.add(new MatrixVariableMethodArgumentResolver());
  resolvers.add(new MatrixVariableMapMethodArgumentResolver());
  resolvers.add(new ServletModelAttributeMethodProcessor(false));
  resolvers.add(new RequestResponseBodyMethodProcessor(getMessageConverters(), this.requestResponseBodyAdvice));
  resolvers.add(new RequestPartMethodArgumentResolver(getMessageConverters(), this.requestResponseBodyAdvice));
  resolvers.add(new RequestHeaderMethodArgumentResolver(getBeanFactory()));
  resolvers.add(new RequestHeaderMapMethodArgumentResolver());
  resolvers.add(new ServletCookieValueMethodArgumentResolver(getBeanFactory()));
  resolvers.add(new ExpressionValueMethodArgumentResolver(getBeanFactory()));
  resolvers.add(new SessionAttributeMethodArgumentResolver());
  resolvers.add(new RequestAttributeMethodArgumentResolver());

  // Type-based argument resolution
  resolvers.add(new ServletRequestMethodArgumentResolver());
  resolvers.add(new ServletResponseMethodArgumentResolver());
  resolvers.add(new HttpEntityMethodProcessor(getMessageConverters(), this.requestResponseBodyAdvice));
  resolvers.add(new RedirectAttributesMethodArgumentResolver());
  resolvers.add(new ModelMethodProcessor());
  resolvers.add(new MapMethodProcessor());
  resolvers.add(new ErrorsMethodArgumentResolver());
  resolvers.add(new SessionStatusMethodArgumentResolver());
  resolvers.add(new UriComponentsBuilderMethodArgumentResolver());

  // Custom arguments
  if (getCustomArgumentResolvers() != null) {
    resolvers.addAll(getCustomArgumentResolvers());
  }

  // Catch-all
  resolvers.add(new RequestParamMethodArgumentResolver(getBeanFactory(), true));
  resolvers.add(new ServletModelAttributeMethodProcessor(true));

  return resolvers;
}

// 我们从源码的 spring-boot/spring-boot-tests/spring-boot-smoke-tests/spring-boot-smoke-test-tomcat 下, 找到 SampleTomcatApplication.java 类, 直接看它的 main 方法.

public static void main(String[] args) {
  SpringApplication.run(SampleTomcatApplication.class, args);
}

// 看起来不多嘛......(看前如是写道, 看完已是凌晨四点)
public ConfigurableApplicationContext run(String... args) {
  // 1.StopWatch 提供的计算耗时的功能, 创建一个后立即开始计时.
  // 2.创建一个引导容器, 并在此时(容器未使用前)把 spring.factories 找到 Bootstrapper 接口的类对应的方法触发, 来给引导容器里注册一些东西(如果有需要)
  // 3.从 spring.factories 找 SpringApplicationRunListener 的类, 实例化后存到 SpringApplicationRunListeners 中.
  // 4.触发所有存入的 SpringApplicationRunListener 的 starting 事件.
  // 5.将 args 内容中的参数们(类似 --spring.port=9999)解析成键值对存到 applicationArguments 对象中.
  // 6.创建了一个 environment 对象, 添加了好几个功能各异的 PropertySource, 触发所有存入的 SpringApplicationRunListener 的 environmentPrepared 事件
  // 7.根据 this.bannerMode 判断是否打印 Banner, 以及打印在哪里, 根据 this.banner 判断打印什么样的 Banner (佛祖保佑.png)
  // 8.根据 web 类型创建不同的 ApplicationContext, 这里的创建, 仅实例化而已, 没有从构造方法调用 loadBeanDefinitions 和 refresh 的逻辑
  // 9.将 applicationStartup (步骤记录器)赋值给 context.
  //10.对容器做些配置, 然后发布 contextPrepared 事件, 接着关闭引导容器; 然后根据 primarySource 使用 BeanDefinitionLoader 加载 BeanDefinition 到容器, 最后发布 contextLoaded 事件
  //11.注册一个钩子, 当 JVM 关闭时, 相应的关闭 context, 然后调用容器的 refresh 方法(然后进入到 Spring 源码分析那段, 自行脑补)
  //12.计时器停止计时, 接着打印计时数据
  //13.发布 started 事件
  //14.从容器中取出 ApplicationRunner/CommandLineRunner 两类 bean, 并调用它们的 run 方法.
  //15.catch 到异常则发布 failed 事件
  //16.发布 running 事件

  StopWatch stopWatch = new StopWatch();
  stopWatch.start();

  // 创建一个引导容器, 并在此时(容器未使用前)从 spring.factories 扫描一些实现了 Bootstrapper 接口的类, 来给引导容器里注册一些东西(如果有需要)
  DefaultBootstrapContext bootstrapContext = createBootstrapContext();
  ConfigurableApplicationContext context = null;

  // 往系统变量里设置一个变量 headless, 看上去和 AWT 有关, 暂且忽略之
  configureHeadlessProperty();

  // 扫描 spring.factories 中配置的实现了 SpringApplicationRunListener 的类们
  //   实例化后放到 SpringApplicationRunListeners (其就是个容器管理类) 存起来.
  SpringApplicationRunListeners listeners = getRunListeners(args);

  // 触发所有存入的 SpringApplicationRunListener 的 starting 事件.
  listeners.starting(bootstrapContext, this.mainApplicationClass);
  try {
    // 将 args 内容中的参数(类似 --spring.port=9999)解析成键值对存到 applicationArguments 对象中.
    ApplicationArguments applicationArguments = new DefaultApplicationArguments(args);

    // 创建了一个 environment 对象, 添加了好几个功能各异的 PropertySource,
    //   触发所有存入的 SpringApplicationRunListener 的 environmentPrepared 事件
    //   将 environment 中 spring.main 开头的配置数据, 一一对应绑定到 SpringApplication(即this)的字段上去
    ConfigurableEnvironment environment = prepareEnvironment(listeners, bootstrapContext, applicationArguments);

    // 将 environment 的 spring.beaninfo.ignore 配置复制到 System.Property 去(若不存在)
    configureIgnoreBeanInfo(environment);

    // 根据 this.bannerMode 判断是否打印 Banner, 以及打印在哪里, 根据 this.banner 判断打印什么样的 Banner (佛祖保佑.png)
    Banner printedBanner = printBanner(environment);

    // 根据 web 类型创建不同的 ApplicationContext, 但其实差别不大, 就时多了 web 容器的特征(如启动 tomcat)
    // 另外与 Spring 源码分析时不同, 这里的创建, 仅实例化而已, 没有从构造方法调用 loadBeanDefinitions 和 refresh 的逻辑
    context = createApplicationContext();

    // 将 applicationStartup (步骤记录器)赋值给 context.
    context.setApplicationStartup(this.applicationStartup);

    // 对 context 做一些配置, 执行 initializers 的 initialize()
    // 发布 contextPrepared 事件
    // 关闭引导容器, 即发布 BootstrapContextClosedEvent 事件给之前加的 closeListener (监听者)
    // 使用 BeanDefinitionLoader 根据 sources 和 run 方法参数 primarySource 加载 BeanDefinition 到容器中.
    // 发布 contextLoaded 事件
    prepareContext(bootstrapContext, context, environment, listeners, applicationArguments, printedBanner);

    // 注册一个钩子, 当 JVM 关闭时, 相应的关闭 context, 然后调用容器的 refresh 方法(然后进入到 Spring 源码分析那段, 自行脑补)
    refreshContext(context);

    // 留给子类扩展吧
    afterRefresh(context, applicationArguments);

    // 计时器停止计时, 接着打印计时数据
    stopWatch.stop();
    if (this.logStartupInfo) {
      new StartupInfoLogger(this.mainApplicationClass).logStarted(getApplicationLog(), stopWatch);
    }

    // 发布 started 事件
    listeners.started(context);

    // 从容器中取出 ApplicationRunner/CommandLineRunner 两类 bean, 并调用它们的 run 方法.
    callRunners(context, applicationArguments);
  }
  catch (Throwable ex) {
    // 发布 failed 事件
    handleRunFailure(context, ex, listeners);
    throw new IllegalStateException(ex);
  }

  try {
    // 发布 running 事件
    listeners.running(context);
  }
  catch (Throwable ex) {
    // 发布 failed 事件
    handleRunFailure(context, ex, null);
    throw new IllegalStateException(ex);
  }
  return context;
}

// 来看看所有过程涉及方法的注释(大多数)
org.springframework.boot.SpringApplication#createBootstrapContext
    // 1.创建一个引导容器(这个容器作用和 BeanFactory 类似, 但更简单得多, 仅有获取/注册 bean 对象等的功能)
		//   触发存于 this.bootstrappers 的对象的 intitialize 方法来对引导容器进行初始化(即可以在引导容器未使用前往里面注册 bean 对象)
		//   然后 this.bootstrappers 的数据有一部分是从 spring.factories 找 Bootstrapper 的类实例化后得到的, 然后也可以代码手动添加
		
  
org.springframework.boot.SpringApplication#getRunListeners
    // 扫描 spring.factories 中配置的实现了 SpringApplicationRunListener 的类, 并调用形如 types 的参数的构造函数来实例化得到对象集合
		//   再将这些对象集合放到 SpringApplicationRunListeners(其就是个容器管理类)中.
		// 并绑定 applicationStartup (步骤记录器)
  

org.springframework.boot.SpringApplicationRunListeners#doWithListeners(java.lang.String, java.util.function.Consumer<org.springframework.boot.SpringApplicationRunListener>, java.util.function.Consumer<org.springframework.core.metrics.StartupStep>)
    // 遍历持有的所有 SpringApplicationRunListener, 触发对应事件
		// 在触发监听事件前后加入 StartupStep 监听所耗时间
		// 步骤监听器的 accept 处理
  
  
org.springframework.boot.SpringApplication#prepareEnvironment
    // 1.根据 web 类型创建一个 environment 对象
		// 2.配置 environment
		//     通过 ConversionService 类添加一些类型转换支持(如文件大小1024k=1M等)
		//     将用户设置的 defaultProperties 添加到 environment 的 sources 中, 将 args 解析成一个 PropertySource 后加入到 environment 中
		// 3.为 environment 添加一个名为 configurationProperties 的源, 其作用是将每一个 PropertySource 适配成 ConfigurationPropertySource.
		// 4.触发所有存入的 SpringApplicationRunListener 的 environmentPrepared 事件.
		// 5.将名为 defaultProperties 的 Property 源移最后(降低优先级), 另此 defaultProperties 不是 this.defaultProperties
		// 6.将用户通过代码设置的要附加的 profile 设置到 activeProfiles 中去 (若存在且 environment 中不存在)
		// 7.将 environment 中 spring.main 开头的配置数据, 一一对应绑定到 SpringApplication(即this)的字段上去
		// 8.若不开启自定义 environment, 则将 environment 转换成 StandardEnvironment(默认行为)
		// 9.由于上一步可能做了转换, 所以需要重新 attach 一次.

  
org.springframework.boot.SpringApplication#getOrCreateEnvironment
    // 1.若存在一个 environment, 则直接返回
		// 2.若不存在, 则根据之前推断得出的 webApplicationType 来创建对应的 Environment 对象.
		// 3.这几个不同的类型区别也不大, 就 StandardServletEnvironment 多了3个 propertySources(其中一个是 JDNI, 比较重要)
		
  
org.springframework.boot.SpringApplication#configureEnvironment
    // 1.通过 ConversionService 类添加一些类型转换支持(如文件大小1024k=1M等)
		// 2.将用户设置的 defaultProperties 添加到 environment 的 sources 中, 将 args 解析成一个 PropertySource 后加入到 environment 中.
		// 3. configureProfiles 是一个空方法, 看来是留给我们实现子类时扩展的.
		
  
org.springframework.boot.context.properties.source.ConfigurationPropertySources#attach
    // 为 environment 添加一个名为 configurationProperties 的源, 其作用是将每一个 PropertySource 适配成 ConfigurationPropertySource.
		
  
org.springframework.boot.SpringApplication#configureAdditionalProfiles
    // 将用户通过代码设置的要附加的 profile 设置到 activeProfiles 中去 (若存在且 environment 中不存在)
		
  
org.springframework.boot.SpringApplication#bindToSpringApplication
    // 将 environment 中的配置数据, 绑定到 SpringApplication(即this)的一些字段上去
		// 绑定规则是 spring.main 开头的配置数据与 SpringApplication 一一对应, 如若存在 spring.main.banner-mode=OFF, 则 this.bannerMode=OFF
		
  

  
org.springframework.boot.SpringApplication#printBanner
    // 根据 this.bannerMode 判断是否打印 Banner, 以及打印在哪里
		//   this.banner 为文件路径, 若为空, 则打印 Spring Boot 默认准备的文本(这不换个佛祖保佑?)
		
  
org.springframework.boot.SpringApplication#createApplicationContext
  
    // 根据 web 类型创建不同的 ApplicationContext, 但其实差别不大, 就几个细节不同罢了
		// 以 AnnotationConfigServletWebServerApplicationContext 为例, 与 AnnotationConfigApplicationContext 的区别大致为
		//   多加了一个 BeanPostProcessor 用于给 ServletContextAware/ServletConfigAware 接口注入 servletContext/servletConfig 对象
		//   onRefresh() 时, 调用 createWebServer() 启动 tomcat/jetty/undertow
		
  
org.springframework.boot.SpringApplication#prepareContext
    // 1.设置 environment 对象
		// 2.将 beanNameGenerator 注册到容器中 (若存在), 配置容器的 resourceLoader 和 conversionService (从 SpringApplication 获取)
		// 3.将 initializers 根据 @Order 配置排序后, 遍历执行其 initialize 方法.
		// 4.发布 contextPrepared 事件
		// 5.关闭销毁引导容器(毕竟真正的容器已经准备好了, 这玩意就没用了)
		// 6.为容器添加一些特殊的 bean, 对 beanFactory 做点小设置; 然后添加一个懒加载功能的 BeanFactoryPostProcessor, 作用是将所有的 BeanDefinition 的 lazyInit 设置为 true
		// 7.创建一个 BeanDefinitionLoader, 解析 sources 得到 BeanDefinition 再注册到容器中. 和 Spring 的 new 容器时的 load 过程类似.
		// 8.发布 contextLoaded 事件

  
org.springframework.boot.SpringApplication#postProcessApplicationContext
    // 1.将 beanNameGenerator 注册到容器中 (若存在)
		// 2.将 SpringApplication 的 resourceLoader 赋值给容器 (若存在)
		// 3.为容器设置 ConversionService(类型转换工具)对象 (若配置了允许)
		
  
org.springframework.boot.SpringApplication#load
    // 创建一个 BeanDefinitionLoader, 解析 sources 得到 BeanDefinition 再注册到容器中. 和 Spring 的 new 容器时的 load 过程类似.
		

org.springframework.boot.SpringApplication#refreshContext
    // 1.注册一个钩子, 当 JVM 关闭时, 相应的关闭 context
		// 2.调用容器的 refresh 方法
		
  
org.springframework.boot.SpringApplication#callRunners
    // 从容器中取出 ApplicationRunner/CommandLineRunner 两类 bean, 并调用它们的 run 方法.
		// 这里有两个不同点
		//    1. XxxRunner 和 ApplicationListener 有何不同?
		//       答案是 XxxRunner 的 run 方法可以直接取到程序启动的 args 参数, 而监听器要取则还需借助 environment
		//    2.ApplicationRunner 和 CommandLineRunner 有何不同?
		//       答案是 run 方法接受的参数形式不同, 一个是 字符串数组(原始的), 一个是解析好的 key:value 方便直接取用.