Spring源码深度解析(郝佳)-学习-Spring Boot体系原理

  Spring Boot是由Pivotal团队提供的全新框架，其设计目的用来简化新Spring应用初始化搭建以及开发过程，该框架使用了我写的方式进行配置，从而开发人员不再需要定义样板化的配置，通过这种方式，Spring Boot将致力于在蓬勃发展的快速应用开发领域（Rapid Application Developoment）成为领导者。
Spring Boot 的特点如下：

• 创建独立的Spring 应用程序。
• 嵌入的Tomcat ，无须部署WAR文件。
• 简化Maven配置
• 提供生产就绪型功能，如指标，健康检查和外部配置。
• 绝对没有代码生成，以及对XML没有配置要求。

  当然，这样的介绍似乎太过于官方化，好像没有什么帮助我们理解 Spring Boot 到底做了什么，我们不妨通过一个小小的例子来快速的了解Spring Boot .
  首先我们搭建一个Maven工程，pom如下：

    4.0.0
    
        org.springframework.boot
        spring-boot-starter-parent
        2.4.5
         
    
    com.example
    spring-boot-study
    0.0.1-SNAPSHOT
    spring-boot-study
    Demo project for Spring Boot
    
        1.8
    
    
        
            org.springframework.boot
            spring-boot-starter-web
        

        
            org.springframework.boot
            spring-boot-starter-test
            test
        
    

    
        
            
                org.springframework.boot
                spring-boot-maven-plugin
            
        
    

然后我们创建一个Controller类

@RestController
public class TestController {

    @RequestMapping("/home")
    public String home(){
        return "hello world";
    }
}

@SpringBootApplication
public class SpringBootStudyApplication {

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

  以上就是我们要准备的示例的所有内容，最后我们尝试启动main函数并在浏览器中输入localhost:8080 ，发现浏览器显示如下图所示：

测试结果：

  这一切都似乎完全超出我们的预料，按照之前的经验，如果要构建这样一套MVC体系，似乎是非常麻烦的，至少要引入一大堆的pom依赖，同时，最为神奇的是整个过程是我们似乎根本没有启动过Tomcat，但是当我们运行函数的时候Tomcat居然自动起起来了，而且还能通过浏览器访问，这一切都是那样的顺其自然，这里留下悬念，后面我们再来探索。
  当然，如果你认为Spring Boot仅仅是封装了Tomcat那就大错特错了，一个流行的框架一定是有他的理念和创新，它绝对不是一个简简单单的封装就能搞定的。

  可以认为 它是当前独立业务开发模块对外暴露可以直接调用的接口。

public interface HelloService {

    String sayHello();
}

  我们对这个接口做一个简单的实现，返回hello 字符串。

@Service
public class HelloServiceImpl implements HelloService {
    @Override
    public String sayHello() {
        return "hello !!";
    }
}

  以上的实现为了尽量屏蔽Spring Boot基础理论以外的东西，把演示设计处尽量简单，如果是真实业务，这个接口以及接口实现可能会非常复杂，甚至还会间接的依赖于非常多的其他bean，它基本上就是一个独立的业务模块，当然这个模块并不是自己部署的，而是运行在依赖它的主函数中，如果我们开发到这种程度，想要主函数感知的话，也并不是不可以，但是至少要让主工程知道当前业务的bean路径并加入到scan列表中，否则在Spring启动的过程中没有办法反cLient中所有的bean载入Spring容器，逻辑也就没法生效了，但是，随着业务的增长，模块也会越来越多，越来越分散，大量的配置在主函数中维护，这会造成主函数非常的臃肿及冲突严重，而且根据职责划分原则，以上的例子中主模块只关心自己是否使用外部依赖的模块以及对应的接口就好了，再让主模块感知对应的路径等细节信息显然是不合适的，于是，在Spring出来之前我们会尝试把Scan等配置项写入到XML里面。然后让主函数直接引用配置项，这样，主函数知道的事情就进一步减少了，但是还有没有有更好的解决方式呢？或者，还有没有更好的办法能让主函数做更少的事情呢？Spring Boot 做到这一点，继续追加代码，添加自动配置项。
  读者会发现，我们刚开发的功能使用起来非常的方便，除了pom中引入了依赖，什么都没有做就直接使用模块内部的接口注入了。
  @Autowired
  private HelloService helloService;
  这给模块给开发带来非常大的方便，同时也会后续的模块拆分提供了便利，因为当业务逐渐复杂的时候我们会引入大量的中间件，而这些中间件的配置，依赖，以及初始化是非常麻烦的，现在有了这种模式，它帮我们做了只关注逻辑的本身，那么Spring Boot是如何做到的呢？

探索SpringApplication启动Spring

  我们找到主函数入口SpringBootDemoApplication，发现这个入口的启动还是比较奇怪的，这也是Spring Boot启动的必要做法，那么，这也可以作为我们分析Spring Boot 的入口。

@SpringBootApplication
public class SpringBootStudyApplication {

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

   当顺着SpringApplication.run方法进入的时候我们己经找到了SpringApplication的一个看似核心逻辑的方法。

public ConfigurableApplicationContext run(String... args) {
    StopWatch stopWatch = new StopWatch();
    stopWatch.start();
    
    DefaultBootstrapContext bootstrapContext = createBootstrapContext();
    ConfigurableApplicationContext context = null;
    configureHeadlessProperty();
    SpringApplicationRunListeners listeners = getRunListeners(args);
    listeners.starting(bootstrapContext, this.mainApplicationClass);
    try {
        ApplicationArguments applicationArguments = new DefaultApplicationArguments(args);
        //为Spring boot项目准备环境
        ConfigurableEnvironment environment = prepareEnvironment(listeners, bootstrapContext, applicationArguments);
        configureIgnoreBeanInfo(environment);
        //Spring boot启动banner打印
        Banner printedBanner = printBanner(environment);
        context = createApplicationContext();
        context.setApplicationStartup(this.applicationStartup);
        prepareContext(bootstrapContext, context, environment, listeners, applicationArguments, printedBanner);
        refreshContext(context);
        afterRefresh(context, applicationArguments);
        
        stopWatch.stop();
        if (this.logStartupInfo) {
            new StartupInfoLogger(this.mainApplicationClass).logStarted(getApplicationLog(), stopWatch);
        }
        listeners.started(context);
        callRunners(context, applicationArguments);
    }
    catch (Throwable ex) {
        handleRunFailure(context, ex, listeners);
        throw new IllegalStateException(ex);
    }

    try {
        listeners.running(context);
    }
    catch (Throwable ex) {
        handleRunFailure(context, ex, null);
        throw new IllegalStateException(ex);
    }
    return context;
}

  首先我们来看看环境配置这一块。

private ConfigurableEnvironment prepareEnvironment(
		SpringApplicationRunListeners listeners,
		ApplicationArguments applicationArguments) {
	//获取或者创建环境变量，如果没有则创建，有则获取
	ConfigurableEnvironment environment = getOrCreateEnvironment();
	//配制环境变量
	configureEnvironment(environment, applicationArguments.getSourceArgs());
	//这一行代码很重要，我们的application.yml就是在这行代码中解析的
	listeners.environmentPrepared(environment);
	if (!this.webEnvironment) {
		environment = new EnvironmentConverter(getClassLoader())
				.convertToStandardEnvironmentIfNecessary(environment);
	}
	return environment;
}

  准备环境这一块，我们先来看最简单的方法getOrCreateEnvironment。

private ConfigurableEnvironment getOrCreateEnvironment() {
	//如果环境存在，则直接返回，不存在则创建
	if (this.environment != null) {
		return this.environment;
	}
	//如果是web环境，就创建StandardServletEnvironment，否则创建普通的StandardEnvironment
	if (this.webEnvironment) {
		return new StandardServletEnvironment();
	}
	return new StandardEnvironment();
}

  那什么环境下是web环境呢？我们来看看源码。在SpringApplication类中有一个initialize()方法，方法中有一行代码this.webEnvironment = deduceWebEnvironment();，对webEnvironment赋值。

private boolean deduceWebEnvironment() {
	for (String className : " { "javax.servlet.Servlet",
			"org.springframework.web.context.ConfigurableWebApplicationContext" }") {
		if (!ClassUtils.isPresent(className, null)) {
			return false;
		}
	}
	return true;
}

  最终得出结论。如果存在ConfigurableWebApplicationContext类，则使用StandardServletEnvironment环境，如果不存在，则使用StandardEnvironment环境。显然在web应用中肯定存在ConfigurableWebApplicationContext类，所以使用StandardServletEnvironment环境，其实在以前的博客中分析Spring 源码时也分析过StandardServletEnvironment这个类，但是为了大家不要那么麻烦，这里就再来分析一遍。我们进入StandardServletEnvironment类。

public class StandardServletEnvironment extends StandardEnvironment implements ConfigurableWebEnvironment {

	@Override
	protected void customizePropertySources(MutablePropertySources propertySources) {
		propertySources.addLast(new StubPropertySource("servletConfigInitParams"));
		propertySources.addLast(new StubPropertySource("servletContextInitParams"));
		if (JndiLocatorDelegate.isDefaultJndiEnvironmentAvailable()) {
			propertySources.addLast(new JndiPropertySource("jndiProperties"));
		}
		super.customizePropertySources(propertySources);
	}
	@Override
	public void initPropertySources(ServletContext servletContext, ServletConfig servletConfig) {
		WebApplicationContextUtils.initServletPropertySources(getPropertySources(), servletContext, servletConfig);
	}
}

  好像有点可惜，因为new StandardServletEnvironment()好像没有做任何事情嘛？真的吗？那先来看一下类结构。

  从类结构中，发现他继承了StandardEnvironment，实际上是对StandardEnvironment功能的扩展，扩展的内容就是为Spring环境中加入更多的环境参数，例如servletConfigInitParams，servletContextInitParams，和jndiProperties。我们到父类StandardEnvironment中去看看。

public class StandardEnvironment extends AbstractEnvironment {

	@Override
	protected void customizePropertySources(MutablePropertySources propertySources) {
		propertySources.addLast(new MapPropertySource("systemProperties", getSystemProperties()));
		propertySources.addLast(new SystemEnvironmentPropertySource("systemEnvironment", getSystemEnvironment()));
	}
}

  好像也没有什么发现，也就是标准环境参数中设置了系统环境属性及变量，不到黄河心不死，我们继续看父类。

public abstract class AbstractEnvironment implements ConfigurableEnvironment {
	private final MutablePropertySources propertySources = new MutablePropertySources(this.logger);

	public AbstractEnvironment() {
		customizePropertySources(this.propertySources);
		if (logger.isDebugEnabled()) {
			logger.debug("Initialized " + getClass().getSimpleName() + " with PropertySources " + this.propertySources);
		}
	}
	省略...
}

  终于功夫不负有心人，我们找到我们想要看到的结果了，在构造函数中，调用了customizePropertySources方法。也就是说StandardServletEnvironment在new的时候会调用其customizePropertySources方法。在这个方法中会初始化servletConfigInitParams及servletContextInitParams，以及System.getProperties()及 System.getenv()加入到环境中，那这有什么应用场景呢？有一定开发经验的小伙伴肯定知道，线上的配置文件和开发测试的配置文件肯定不是一样的，我们在服务器上一般使用【nohup /usr/local/jdk1.8.0_74/bin/java -jar -Dspring.profiles.active=test api-web.jar >/dev/null 2>&1 & 】命令来启动Spring boot项目，其中spring.profiles.active参数就是来区分不同的环境（dev 为开发环境，test为测试环境，online为线上环境），而spring.profiles.active参数的获取就是在System.getProperties()方法中。先来举个例子，在idea 中配置环境变量test。

  在系统属性中，我们看到了spring.profiles.active=test，那么只需要启动时配置active就能决定读取哪个配置文件中的配置了吗？细心的读者可能会想，如果我们在application.yml配置了spring.profiles.active=dev，同时又在项目启动时设置了参数-Dspring.profiles.active=test，那么Spring boot会使用哪个active呢？疑问先留在这里，我们继续来跟进源码。

protected void configureEnvironment(ConfigurableEnvironment environment,
		String[] args) {
	configurePropertySources(environment, args);
	//设置active文件
	configureProfiles(environment, args);
}

  configurePropertySources上述两个方法，第一个方法主要是将SpringApplication中配置的默认defaultProperties加入到环境中，同时将args也加入到环境中。代码如下

protected void configurePropertySources(ConfigurableEnvironment environment,
		String[] args) {
	MutablePropertySources sources = environment.getPropertySources();
	//如果配置了defaultProperties
	if (this.defaultProperties != null && !this.defaultProperties.isEmpty()) {
		//默认的配置添加到sources的最后，起到兜底r的作用，因为getProperty方法获取属性，
		//先遍历sources，取到了，则直接返回了，当最终都没有找到属性，就只能到默认的defaultProperties中获取属性了
		sources.addLast(
				new MapPropertySource("defaultProperties", this.defaultProperties));
	}
	if (this.addCommandLineProperties && args.length > 0) {
		String name = "commandLineArgs";
		if (sources.contains(name)) {
			//如果环境中己经存在名字为commandLineArgs的对象，则创建一个新的包装类CompositePropertySource，
			//替换掉原来的SimpleCommandLinePropertySource对象
			//而CompositePropertySource中propertySources属性中存储多个SimpleCommandLinePropertySource对象
			PropertySource source = sources.get(name);
			CompositePropertySource composite = new CompositePropertySource(name);
			composite.addPropertySource(new SimpleCommandLinePropertySource(
					name + "-" + args.hashCode(), args));
			composite.addPropertySource(source);
			sources.replace(name, composite);
		}
		else {
			//如果环境中没有commandLineArgs，则创建SimpleCommandLinePropertySource对象存储到环境中
			//命令行配置的参数放到sources第一位，在获取属性时优先被获取到
			sources.addFirst(new SimpleCommandLinePropertySource(args));
		}
	}
}

  SimpleCommandLinePropertySource也是一个数据源PropertySource ;但是它主要是存放命令行属性;例如启动参数Args;中的属性就会保存在这个对象中; 并且SimpleCommandLinePropertySource会被放入到Environment中; 所以也就可以通过{@link Environment#getProperty(String)}来获取命令行的值了

  可能有人感觉上面的代码commandLineArgs这一块难以理解。那我们继续跟进代码。

public SimpleCommandLinePropertySource(String... args) {
	super(new SimpleCommandLineArgsParser().parse(args));
}

  看到了parse()方法，我们进入这个方法看看

class SimpleCommandLineArgsParser {
	//创建CommandLineArgs对象
	public CommandLineArgs parse(String... args) {
		CommandLineArgs commandLineArgs = new CommandLineArgs();
		for (String arg : args) {
			//进循环，判断是否以--开头
			if (arg.startsWith("--")) {
				//如果是就截取，截取长度是参数长度，如果命令是--spring，那么就从s开始截取，包括s
				String optionText = arg.substring(2, arg.length());
				String optionName;
				String optionValue = null;
				//如果匹配到了=号，截取=号左边做optionName，右边做optionValue
				if (optionText.contains("=")) {
					optionName = optionText.substring(0, optionText.indexOf('='));
					optionValue = optionText.substring(optionText.indexOf('=')+1, optionText.length());
				}
				else {
					//如果没有=号，optionName 直接就是截取的optionText
					optionName = optionText;
				}
				if (optionName.isEmpty() || (optionValue != null && optionValue.isEmpty())) {
					throw new IllegalArgumentException("Invalid argument syntax: " + arg);
				}
				//这里将解析的参数添加到上面创建的CommandLineArgs对象中，该对象中有一个Map来存放
				commandLineArgs.addOptionArg(optionName, optionValue);
			}
			else {
				//不是--开头就是直接添加到非选项参数
				commandLineArgs.addNonOptionArg(arg);
			}
		}
		//最后返回对象
		return commandLineArgs;
	}

}

  那我们来看看网上怎么说，Spring对应用程序运行的命令行参数进行了抽象，这个抽象是类CommandLineArgs。
CommandLineArgs类将命令行参数分为两类：

1. option 参数

• 以 --开头
• 可以认为是name/value对参数
• 例子 : --foo, --foo=bar

2. 非 option 参数

• 不以 --开头
• 可以认为是只提供了value的参数(具体怎么理解这个值，看业务逻辑的需求)

  从代码中得知，以–开头的参数设置到了CommandLineArgs对象的optionArgs参数中，将不以–开头的参数添加到CommandLineArgs的nonOptionArgs参数中。说了这么多，我们先来看一个例子，假如我们要在项目启动时设置分页默认参数，默认为第一页，每页10行。

测试结果，我们看到pageNum和pageSize设置到CommandLineArgs的optionArgs参数中。

  我们说了那么多，关于CommandLineArgs和defaultProperties的设置，我们分析了那么久，那么使用场景是什么呢？我们在做后台管理系统时，经常遇到的问题是分页问题，分页最关键的两个参数就是pageNum和pageSize，如果前端传了分页参数，则使用前端的分页参数，如果不传，则使用我们默认的分页参数，比如产品经理有需求变动时，需要将原来每页10条变成每页20条，一种办法，就是在代码中写死，直接修改代码提交，合并，发布，还有另一种更加灵活的方法，就是直接将默认的分页参数以命令行的形式配置，当产品需要调整参数时，只需要重新启动项目，修改启动配置参数即可，为了避免运维在启动项目时，忘记加分页参数了，我们设置一个兜底的参数，这样即使运维忘记配置启动参数，程序也不会报错了。来看下面示例。

1. 编写业务测试类

@RequestMapping("/query")
public String home(Integer pageNum, Integer pageSize) {
    if (pageNum == null) {
        ApplicationContext applicationContext = SpringContextUtils.getApplicationContext();
        Environment environment = applicationContext.getEnvironment();
        pageNum = Integer.parseInt(environment.getProperty("pageNum"));
        pageSize = Integer.parseInt(environment.getProperty("pageSize"));
        System.out.println("前端没有设置pageNum,pageSize ，使用系统默认的配置参数");
    }
    System.out.println("====pageNum==" + pageNum + ", pageSize = " + pageSize);
    return "SUCESS";

}

2. 设置兜底参数

@SpringBootApplication
public class SpringBootStudyApplication {
	public static void main(String[] args) {
		SpringApplication springApplication = new SpringApplication(SpringBootStudyApplication.class);
		Map defaultProperties = new HashMap<>();

		defaultProperties.put("pageNum",1);
		defaultProperties.put("pageSize",20);
		//设置兜底参数
		springApplication.setDefaultProperties(defaultProperties);

		springApplication.setBannerMode(Banner.Mode.CONSOLE);
		springApplication.run(args);
		//SpringApplication.run(SpringBootStudyApplication.class, args);
	}
}

  测试1: 运维设置了pageNum=1和pageSize=18，但是前端没有传pageNum和pageSize

  测试结果：

  测试2：运维运维忘记配置pageNum和pageSize，但是前端没有传pageNum和pageSize，使用默认的兜底参数

  再来看一下getProperty()方法的源码。

protected  T getProperty(String key, Class targetValueType, boolean resolveNestedPlaceholders) {
	if (this.propertySources != null) {
		//遍历所有的propertySources
		for (PropertySource propertySource : this.propertySources) {
			if (logger.isTraceEnabled()) {
				logger.trace("Searching for key '" + key + "' in PropertySource '" +
						propertySource.getName() + "'");
			}
			//调用每个propertySource的Property方法
			Object value = propertySource.getProperty(key);
			//如果value不为空，转化为泛型类型
			if (value != null) {
				if (resolveNestedPlaceholders && value instanceof String) {
					value = resolveNestedPlaceholders((String) value);
				}
				logKeyFound(key, propertySource, value);
				return convertValueIfNecessary(value, targetValueType);
			}
		}
	}
	if (logger.isDebugEnabled()) {
		logger.debug("Could not find key '" + key + "' in any property source");
	}
	return null;
}

  从上述代码中可以看到，越在前的propertySource，优先获取到，因此defaultProperties只有做为兜底参数。
  我想我们分析了那么多环境为一块，感觉还是少了点东西，那是什么呢？

  我们继续来分析configureProfiles()方法，在这个方法中，设置了active区分线上，开发环境。

protected void configureProfiles(ConfigurableEnvironment environment, String[] args) {
	environment.getActiveProfiles();
	Set profiles = new LinkedHashSet(this.additionalProfiles);
	profiles.addAll(Arrays.asList(environment.getActiveProfiles()));
	environment.setActiveProfiles(profiles.toArray(new String[profiles.size()]));
}

  在这一行代码中environment.getActiveProfiles();确保了spring.profiles.active的存在。那是如何确保的呢？我们来看代码。

public String[] getActiveProfiles() {
	return StringUtils.toStringArray(doGetActiveProfiles());
}
protected Set doGetActiveProfiles() {
	synchronized (this.activeProfiles) {
		if (this.activeProfiles.isEmpty()) {
			String profiles = getProperty("spring.profiles.active");
			if (StringUtils.hasText(profiles)) {
				//profiles以逗号隔开
				setActiveProfiles(StringUtils.commaDelimitedListToStringArray(
						StringUtils.trimAllWhitespace(profiles)));
			}
		}
		return this.activeProfiles;
	}
}

  我们一般情况下指定一个配置文件，但是有个时候，我们需要每个环境指定多个配置文件，不同的配置文件中配制相关的业务。先来举个例子吧。在开发环境中配置两个配置文件application-dev.yml，application-dev1.yml，需要同时使用两个配置文件中的内容。

//test1.profile配置在application-dev1.yml并且配置了yyy
@Value("${test1.profile}")
private String profile1;
//test.profile配置在application-dev.yml并且配置了xxx
@Value("${test.profile}")
private String profile;

@RequestMapping("/home")
public String home() {
    System.out.println("profile1 " + profile1 + ",profile " + profile);
    return helloService.sayHello();
}

  配置了两个配置文件。
测试结果

  从上述测试结果来看，Spring Boot读取了两个配置文件application-dev.yml，application-dev1.yml 并且将test1.profile和test.profile设置到环境中。
  那又有读者会问了，application.yml文件又是在何时被解析的呢？又和propertySources有什么关系呢？在茫茫代码中，不知道何处去寻，那就等吧，我们在setActiveProfiles()方法中打一个断点。


  发现竟然是在监听器中解析的。超出我的意料。
  这里是一个关键点，就是在初始化MutablePropertySources的时候依赖的一个变量environment，Environment是Spring所有配置文件转换KV的基础，而后续的一系列操作都是在environment基础上做的进一步封装，那么我们就再来探索一下environment的实例路径。如下图所示

  可知，environment初始化过程并不是之前通过在PostProcessor类型的扩展口上做扩展的，而是通过ConfigFileApplicationListener监听机制完成的，当然这里面的重点步骤load方法，它是整个流程的核心点：

public void load() {
    this.propertiesLoader = new PropertySourcesLoader();
    this.activatedProfiles = false;
    this.profiles = Collections.asLifoQueue(new LinkedList());
    this.processedProfiles = new LinkedList();
	//通过profile标识不同的环境，可以通过设置spring.profile.active和spring.profiles.default，
	//如果设置了active，default就失去了作用，如果这两个设置都没有，那么带profiles的bean都不会生成
    Set initialActiveProfiles = initializeActiveProfiles();
    this.profiles.addAll(getUnprocessedActiveProfiles(initialActiveProfiles));
    if (this.profiles.isEmpty()) {
        for (String defaultProfileName : this.environment.getDefaultProfiles()) {
            Profile defaultProfile = new Profile(defaultProfileName, true);
            if (!this.profiles.contains(defaultProfile)) {
                this.profiles.add(defaultProfile);
            }
        }
    }
    //支持不添加任何profile注解的bean的加载
    this.profiles.add(null);
    while (!this.profiles.isEmpty()) {
        Profile profile = this.profiles.poll();
        //Spring Boot默认从4个位置查的application.properties文件就是从getSearchLocations()
        //方法中返回的，
        //1.当前目录下的/config
        //2.当前目录
        //3.类路径下的/config目录
        //4.类路径的根目录
        for (String location : getSearchLocations()) {
            if (!location.endsWith("/")) {
            	//如果目录不以/结尾，则表示路径本身就是一个文件，如路径为/Users/quyixiao/Desktop，
            	//则Spring boot 就会去解析Desktop文件，而不会到/Users/quyixiao/Desktop/目录下寻找了。
            	//如果路径为/Users/quyixiao/Desktop/，则会到目录下寻找相应的文件
                load(location, null, profile);
            }
            else {
				//如果没有配置则默认从application.properties中加载，约定大于配置
                for (String name : getSearchNames()) {
                    load(location, name, profile);
                }
            }
        }
        this.processedProfiles.add(profile);
    }
	addConfigurationProperties(this.propertiesLoader.getPropertySources());
}

  我们之前不是愁怎样找到application文件吗？看到getSearchLocations()方法后，我们就知道了在哪个路径下找文件了。我们进入getSearchLocations方法。

private Set getSearchLocations() {
	//项目启动时是否配置了spring.config.location参数，如果配置该参数，则到该目录下寻找
	Set locations = new LinkedHashSet();
	if (this.environment.containsProperty("spring.config.location")) {
		for (String path : asResolvedSet(
				this.environment.getProperty("spring.config.location"), null)) {
			if (!path.contains("$")) {
				path = StringUtils.cleanPath(path);
				if (!ResourceUtils.isUrl(path)) {
					path = "file:"+ path;
				}
			}
			locations.add(path);
		}
	}
	//默认到classpath:/,classpath:/config/,file:./,file:./config/下寻找
	locations.addAll(
			asResolvedSet(ConfigFileApplicationListener.this.searchLocations,
					"classpath:/,classpath:/config/,file:./,file:./config/"));
	return locations;
}

  getSearchLocations()方法的原理也很简单，看环境中是否配置了spring.config.location参数，如果配置了，则到spring.config.location下寻找配置文件，如果没有配置，则默认到classpath:/,classpath:/config/,file:./,file:./config/目录下寻找配置文件，
  文件路径确定了，那文件名又该如何确定呢？我们进入getSearchNames()方法中看看。

private Set getSearchNames() {
	if (this.environment.containsProperty("spring.config.name")) {
		return asResolvedSet(this.environment.getProperty("spring.config.name"),
				null);
	}
	return asResolvedSet(ConfigFileApplicationListener.this.names, "application");
}

  getSearchNames()方法和getSearchLocations()原理一样，如果环境中配置了spring.config.name属性，则找spring.config.name文件名作解析，如果没有则，使用系统默认的文件名application。
  可能会有读者问了，Spring Boot 这么意图是什么呢？我猜想，一方面Spring为了提供配置的灵活性，你想用什么路径，什么文件名，就用什么，提供配置的灵活性，同时也是有应用场景的，一般为了安全我们不会将线上的数据库配置文件也写到项目中，有一种办法就是在项目打包的时候，写一个脚本，先将配置文件考呗到项目中再进行打包，显然不是那样的优雅，那该如何使用呢？在项目启动时nohup /usr/local/jdk1.8.0_74/bin/java -jar -Dspring.profiles.active=test spring.config.location=/home/admin/web/ spring.config.name=application api-web.jar >/dev/null 2>&1 &
  这样，我们只需要在项目启动时指定配置文件的路径和文件名，而不需要在打包之前，将配置文件拷呗到项目中再进行打包了。接下来，我们模似线上环境发布，测试一下效果。

1. 在idea中模似线上环境
   

2. 修改config-name
   

3. 在我的桌面添加线上配置文件
   

4. 在配置文件中添加配置
   

5. 创建测试方法，并测试
   
     上述过程中我们需要注意的一点是，因为默认的配置路径是classpath:/,classpath:/config/,file:./,file:./config/，因此，为了配置文件统一存放在一个目录下，我们也可以创建一个config目录，将配置文件放在config目录下，更加好统一管理。如：
   

  那我们找到了配置文件的路径和文件名，那我们怎样来解析yml或properties文件呢？我们接着之前的代码继续分析。

private void load(String location, String name, Profile profile) {
	String group = "profile=" + (profile == null ? "" : profile);
	if (!StringUtils.hasText(name)) {
		//如果配置的路径没有后缀 / 的情况
		loadIntoGroup(group, location, profile);
	}
	else {
		//遍历所有的PropertySourceLoader 文件后缀名
		//PropertiesPropertySourceLoader支持properties和xml的解析
		//YamlPropertySourceLoader支持"yml", "yaml"的解析
		for (String ext : this.propertiesLoader.getAllFileExtensions()) {
			if (profile != null) {
				loadIntoGroup(group, location + name + "-" + profile + "." + ext,
						null);
				for (Profile processedProfile : this.processedProfiles) {
					if (processedProfile != null) {
						loadIntoGroup(group, location + name + "-"
								+ processedProfile + "." + ext, profile);
					}
				}
				//对application-dev.yml文件解析
				loadIntoGroup(group, location + name + "-" + profile + "." + ext,
						profile);
			}
			//对application.yml配置文件解析
			loadIntoGroup(group, location + name + "." + ext, profile);
		}
	}
}

  从配置文件的解析顺序，我们得出一个结论，如果相同的配置，application-dev.yml中也配置了，application.yml中也配置了，如启动端口，则以application-dev.yml中的配置为准。因为其先被解析。而getProperty的逻辑是，遍历propertySources，越早被解析的配置文件，配置的属性优先被使用。举个例子，在application-dev.yml中配置了server.port=8888,在application中配置了server.port=8502，那最终项目启动占用的端口是8888。
  我们接着继续分析配置文件又是如何解析的呢？进入loadIntoGroup方法。

private PropertySource loadIntoGroup(String identifier, String location,
		Profile profile) {
	try {
		return doLoadIntoGroup(identifier, location, profile);
	}
	catch (Exception ex) {
		throw new IllegalStateException(
				"Failed to load property source from location '" + location + "'",
				ex);
	}
}


private PropertySource doLoadIntoGroup(String identifier, String location,
		Profile profile) throws IOException {
	Resource resource = this.resourceLoader.getResource(location);
	PropertySource propertySource = null;
	StringBuilder msg = new StringBuilder();
	if (resource != null && resource.exists()) {
		String name = "applicationConfig: [" + location + "]";
		String group = "applicationConfig: [" + identifier + "]";
		propertySource = this.propertiesLoader.load(resource, group, name,
				(profile == null ? null : profile.getName()));
		if (propertySource != null) {
			msg.append("Loaded ");
			handleProfileProperties(propertySource);
		}
		else {
			msg.append("Skipped (empty) ");
		}
	}
	else {
		msg.append("Skipped ");
	}
	msg.append("config file ");
	msg.append(getResourceDescription(location, resource));
	if (profile != null) {
		msg.append(" for profile ").append(profile);
	}
	if (resource == null || !resource.exists()) {
		msg.append(" resource not found");
		this.logger.trace(msg);
	}
	else {
		this.logger.debug(msg);
	}
	return propertySource;
}

  上述方法中最重要的就是load方法了。我们继续跟进load方法。

public PropertySource load(Resource resource, String group, String name,
		String profile) throws IOException {
	if (isFile(resource)) {
		String sourceName = generatePropertySourceName(name, profile);
		for (PropertySourceLoader loader : this.loaders) {
			if (canLoadFileExtension(loader, resource)) {
				PropertySource specific = loader.load(sourceName, resource,
						profile);
				addPropertySource(group, specific, profile);
				return specific;
			}
		}
	}
	return null;
}

  上述代码选资源加载器PropertySourceLoader就像我们人一样，老板拿了一个活过来，问大家，谁有能力去做这个事情，每个人都问一遍，始终有人会做，就让这个会做的人，将结果给老板即可。
  对于后缀的文件，会使用YamlPropertySourceLoader来解析。接下来，我们来看其load方法的实现。

public PropertySource load(String name, Resource resource, String profile)
		throws IOException {
	if (ClassUtils.isPresent("org.yaml.snakeyaml.Yaml", null)) {
		Processor processor = new Processor(resource, profile);
		Map source = processor.process();
		if (!source.isEmpty()) {
			return new MapPropertySource(name, source);
		}
	}
	return null;
}

  上述需要注意的是，当前类环境下必需有org.yaml.snakeyaml.Yaml类，才能解析yml文件，解析结果得到一个map。为了方便理解，我们自己来手写一个yml文件用例看看。

public class YmlTest {

    public static void main(String[] args)  throws Exception{
        ResourceLoader resourceLoader = new DefaultResourceLoader();
        Resource resource = resourceLoader.getResource("application.yml");
        Processor processor = new Processor(resource, null);
        Map source = processor.process();
        System.out.println(source);

    }

    private static class Processor extends YamlProcessor {
        Processor(Resource resource, String profile) {
            if (profile == null) {
                setMatchDefault(true);
                setDocumentMatchers(new SpringProfileDocumentMatcher());
            }
            else {
                setMatchDefault(false);
                setDocumentMatchers(new SpringProfileDocumentMatcher(profile));
            }
            setResources(resource);
        }

        @Override
        protected Yaml createYaml() {
            return new Yaml(new StrictMapAppenderConstructor(), new Representer(),
                    new DumperOptions(), new Resolver() {
                @Override
                public void addImplicitResolver(Tag tag, Pattern regexp,
                                                String first) {
                    if (tag == Tag.TIMESTAMP) {
                        return;
                    }
                    super.addImplicitResolver(tag, regexp, first);
                }
            });
        }
        public Map process() {
            final Map result = new LinkedHashMap();
            process(new MatchCallback() {
                @Override
                public void process(Properties properties, Map map) {
                    result.putAll(getFlattenedMap(map));
                }
            });
            return result;
        }
    }
}

【测试结果】

  我相信很多人都不知道yml是怎样解析的，一般都要到百度上找找，其实，我们直接在Spring Boot源码中也能找到解析代码。就是上面的测试用例。
  关于整个环境的配置文件解析，我觉得己经很清楚了，就告一段落。

  这里面涉及我们经常使用的profile机制的实现，profile机制是Spring提供的一个用来标明当前运行环境的注解，我们正常开发过程中经常遇到这样的问题，开发环境是一套环境，QA测试是一套环境，线上部署又是另外一套环境，从开发到测试再到部署，会对程序中的配置修改多次，特别是QA到上线这个环节，经过QA测试的也不敢保证改了哪个配置后能不能在线上运行。
  为了解决上面的这个问题，我们一般会用一种方法，配置文件，然后通过不同的环境读取不同的配置文件，从而在不同的场景中运行我们的程序。
  Spring中的profile机制作用就体现这里，在Spring使用DI来注入的时候，能够根据当前制定的运行环境来注入相应的bean，最常见的就是使用不同的环境对应不同的数据源。
  这个机制的实现就是load(location,name,profile)这段代码中来控制，这里只会加载当前设置的profile对应的配置文件。

  我们花了大量的篇幅来分析Spring Boot环境变量这一块，下面来看看源码中的小技巧。
  StopWatch stopWatch = new StopWatch();
  stopWatch.start();
  省略…
  stopWatch.stop();
  Spring这样做的目的是什么呢？我们发现stopWatch最终传入了logStarted()方法中，我们跟进代码。

public void logStarted(Log log, StopWatch stopWatch) {
    if (log.isInfoEnabled()) {
        log.info(getStartedMessage(stopWatch));
    }
}
private StringBuilder getStartedMessage(StopWatch stopWatch) {
    StringBuilder message = new StringBuilder();
    message.append("Started ");
    message.append(getApplicationName());
    message.append(" in ");
    message.append(stopWatch.getTotalTimeSeconds());
    try {
        double uptime = ManagementFactory.getRuntimeMXBean().getUptime() / 1000.0;
        message.append(" seconds (JVM running for " + uptime + ")");
    }
    catch (Throwable ex) {
    }
    return message;
}

  当看到getTotalTimeSeconds()方法，我相信读者恍然大悟。原来是统计Spring启动的时间的，是否是我们猜想的那样呢？那我们来看一个例子吧。

public static void main(String[] args) throws Exception{
    StopWatch stopWatch = new StopWatch();
    stopWatch.start();

    Thread.sleep(2300);

    stopWatch.stop();
    double time = stopWatch.getTotalTimeSeconds();
    System.out.println(time);
}

【测试结果】

  根据结果我可以得知，StopWatch就是用来统计容器加载启动时间的，并且获得所花的秒值。按我们一般人来写，直接在加载之前start = System.currentTimeMillis(); 加载完之后，end = System.currentTimeMillis();
启动时间是 end - start 即可。我们不得不感叹Spring 团队写代码就是优雅。
  接下来，我们继续来看一些好玩的事情。

  那上面的图案是哪里打印的呢？从字面意思理解就是printBanner()方法打印的，那真是这样吗？我们进入方法看看。

private Banner printBanner(ConfigurableEnvironment environment) {
	//如果banner的模式是 Banner.Mode.OFF，则不打印banner
	if (this.bannerMode == Banner.Mode.OFF) {
		return null;
	}
	ResourceLoader resourceLoader = this.resourceLoader != null ? this.resourceLoader
			: new DefaultResourceLoader(getClassLoader());
	SpringApplicationBannerPrinter bannerPrinter = new SpringApplicationBannerPrinter(
			resourceLoader, this.banner);
	//bannerMode是Mode.LOG则会在服务器上打印banner，
	//如果不是，则只有在本地开发时打印，在服务器上不会打印
	if (this.bannerMode == Mode.LOG) {
		return bannerPrinter.print(environment, this.mainApplicationClass, logger);
	}
	//默认情况下bannerMode是Banner.Mode.CONSOLE，因此只有在本地打印启动banner，服务器上不打印banner
	return bannerPrinter.print(environment, this.mainApplicationClass, System.out);
}

  从上述方法中，我们可以看到，banner是否打印，以及打印方式和bannerMode有关系，那bannerMode又该如何设置呢？在代码中寻寻觅觅，没有找到合适的地方进行设置，没有办法，只能以不太优雅的操作来修改banner的打印方式。如下：

public static void main(String[] args) {
	SpringApplication springApplication = new SpringApplication(SpringBootStudyApplication.class);
	//当设置bannerMode为Banner.Mode.OFF，关闭banner打印，设置bannerMode为Banner.Mode.LOG，则服务器上也能打印banner
	springApplication.setBannerMode(Banner.Mode.LOG);
	springApplication.run(args);
	//SpringApplication.run(SpringBootStudyApplication.class, args);
}

  接下来，我们继续来看，既然能修改打印方式，那打印的内容是否能修改呢？想想Spring的灵活性，不可能不给我们考虑到，因此肯定能修改，那该怎样修改呢？我们继续跟进源码。

public Banner print(Environment environment, Class sourceClass, PrintStream out) {
	Banner banner = getBanner(environment, this.fallbackBanner);
	banner.printBanner(environment, sourceClass, out);
	return new PrintedBanner(banner, sourceClass);
}

private Banner getBanner(Environment environment, Banner definedBanner) {
	Banners banners = new Banners();
	banners.addIfNotNull(getImageBanner(environment));
	banners.addIfNotNull(getTextBanner(environment));
	if (banners.hasAtLeastOneBanner()) {
		return banners;
	}
	if (this.fallbackBanner != null) {
		return this.fallbackBanner;
	}
	return new SpringBootBanner();
}

private Banner getImageBanner(Environment environment) {
	//如果环境变量中配置了banner.image.location，
	//则取该位置的图片做为打印的banner
	String location = environment.getProperty("banner.image.location");
	if (StringUtils.hasLength(location)) {
		Resource resource = this.resourceLoader.getResource(location);
		return (resource.exists() ? new ImageBanner(resource) : null);
	}
	// 如果当前resource下有banner.gif或banner.jpg,或banner.png，则作为打印的banner
	for (String ext : { "gif", "jpg", "png" }) {
		Resource resource = this.resourceLoader.getResource("banner." + ext);
		if (resource.exists()) {
			return new ImageBanner(resource);
		}
	}
	return null;
}

private Banner getTextBanner(Environment environment) {
	//如果环境中配置了banner.location，则取之文本作为banner打印，
	//如果没有则取当前resource下的banner.txt作为默认的banner
	String location = environment.getProperty("banner.location",
			"banner.txt");
	Resource resource = this.resourceLoader.getResource(location);
	if (resource.exists()) {
		return new ResourceBanner(resource);
	}
	return null;
}

  既然源码都写得这么清楚了，那就按源码的意思测试一把。

1. 在resources下添加banner.txt
   
   【开始测试】
   
   如果想自定义自己文本图案，下面地址就是绘制字符图案。
   http://patorjk.com/software/taag/#p=display&f=Graffiti&t=XXXQ

2. 我们将banner.txt换成banner.jpg试试，那我就用我的女神刘亦菲来测试一把

  很遗憾，测试结果失败，Spring Boot 不让女神陪我们开发 ，那我到网上找了一张其他次一点的图片。

  测试结果出来了，显然可以个性化指定一些图片来作为项目启动的banner。但是需要注意的一点是SpringBoot的版本。

  刚刚开始，使用1.5.12.RELEASE版本时，无论哪张图片都不支持，后面使用了2.1.5.RELEASE版本，才打印出2020的图案，因此，图片banner的设置还和Spring Boot的版本有关系，所以在设置时当发现设置图片banner无效时，可以看一下你的版本是否过低。不过为了方便起见，我还是用1.5.12.RELEASE来做源码分析，越高版本的代码，可能封装程度越高，但是对于阅读源码者来说，不一定是好事，反而早期的代码原理理解起来更加方便一点。

  在这里，我们发现其他几个关键的字眼。
context = createApplicationContext();
refreshContext(context);
afterRefresh(context, applicationArguments);
  如果读者看过之前的内容，就会知道，我们曾经介绍过Spring的初始化方案，其中最核心的就是SpringContext的创建，初始化，刷新等，那么我们可以直接进入查看其中的逻辑，同时Spring作为一个全球都使用的主流框架，会有非常多的需要考虑的问题，我们在阅读源码的过程中只需要关系核心的主流程，了解其工作原理，并阅读的过程中感受它的代码风格以及设计理念就好了，如果真的追求理解每一行代码真是非常耗时一个件事情。

SpringContext创建

ApplicationContextFactory DEFAULT = (webApplicationType) -> {
    try {
        switch (webApplicationType) {
        case SERVLET:
            return new AnnotationConfigServletWebServerApplicationContext();
        case REACTIVE:
            return new AnnotationConfigReactiveWebServerApplicationContext();
        default:
            return new AnnotationConfigApplicationContext();
        }
    }
    catch (Exception ex) {
        throw new IllegalStateException("Unable create a default ApplicationContext instance, "
                + "you may need a custom ApplicationContextFactory", ex);
    }
};

  这个函数似乎没有什么特别的地方，无非就是实例化一个ApplicationContext，因为ApplicationContext昌Spring存在的基础，而对应的SpringContext候选类如下；
SERVLET = new AnnotationConfigServletWebServerApplicationContext();
REACTIVE = new AnnotationConfigReactiveWebServerApplicationContext();
default = new AnnotationConfigApplicationContext();
  这里有个关键的判断webApplicationType，如果读者没有看过代码很容易忽略，但是这里将成为在前面提到过的Spring如何自动化启动Tomcat的关键，我们将在后面继续研究。

private void prepareContext(DefaultBootstrapContext bootstrapContext, ConfigurableApplicationContext context,
        ConfigurableEnvironment environment, SpringApplicationRunListeners listeners,
        ApplicationArguments applicationArguments, Banner printedBanner) {
    context.setEnvironment(environment);
    postProcessApplicationContext(context);
    applyInitializers(context);
    listeners.contextPrepared(context);
    bootstrapContext.close(context);
    if (this.logStartupInfo) {
        logStartupInfo(context.getParent() == null);
        logStartupProfileInfo(context);
    }
    // Add boot specific singleton beans
    ConfigurableListableBeanFactory beanFactory = context.getBeanFactory();
    beanFactory.registerSingleton("springApplicationArguments", applicationArguments);
    if (printedBanner != null) {
        beanFactory.registerSingleton("springBootBanner", printedBanner);
    }
    if (beanFactory instanceof DefaultListableBeanFactory) {
        ((DefaultListableBeanFactory) beanFactory)
                .setAllowBeanDefinitionOverriding(this.allowBeanDefinitionOverriding);
    }
    if (this.lazyInitialization) {
        context.addBeanFactoryPostProcessor(new LazyInitializationBeanFactoryPostProcessor());
    }
    // Load the sources
    Set