SpringBoot配置的加載流程詳細(xì)分析

更新時(shí)間：2023年01月06日 11:48:21 作者：起風(fēng)哥

了解內(nèi)部原理是為了幫助我們做擴(kuò)展，同時(shí)也是驗(yàn)證了一個(gè)人的學(xué)習(xí)能力，如果你想讓自己的職業(yè)道路更上一層樓，這些底層的東西你是必須要會(huì)的，這篇文章主要介紹了SpringBoot配置的加載流程

在上一篇Springboot啟動(dòng)流程解析中我們沒(méi)有張開(kāi)對(duì)配置的解析，因?yàn)槠^(guò)大，需要單獨(dú)在起一篇文章來(lái)講。

且看一下兩行代碼：

ApplicationArguments applicationArguments = new DefaultApplicationArguments(
					args);
			ConfigurableEnvironment environment = prepareEnvironment(listeners,
					applicationArguments);

第一行代碼是對(duì)控制臺(tái)入?yún)⒆隽私馕鲰樦a跟進(jìn)去我們發(fā)現(xiàn)

先調(diào)用SimpleCommandLineArgsParser來(lái)解析對(duì)應(yīng)的控制臺(tái)入?yún)ⅲ馕鐾曛笤趤G給父類(lèi)進(jìn)行處理

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

所以接下來(lái)我們看這個(gè)parse方法：

public CommandLineArgs parse(String... args) {
		//構(gòu)建個(gè)緩存，將解析的參數(shù)分別放入兩個(gè)容器中，分為兩種類(lèi)型的熟悉選項(xiàng)參數(shù)和非選項(xiàng)參數(shù)，選項(xiàng)參數(shù)使用 --開(kāi)頭
		CommandLineArgs commandLineArgs = new CommandLineArgs();
		for (String arg : args) {
			if (arg.startsWith("--")) {
				String optionText = arg.substring(2, arg.length());
				String optionName;
				String optionValue = null;
				if (optionText.contains("=")) {
					optionName = optionText.substring(0, optionText.indexOf('='));
					optionValue = optionText.substring(optionText.indexOf('=')+1, optionText.length());
				}
				else {
					optionName = optionText;
				}
				if (optionName.isEmpty() || (optionValue != null && optionValue.isEmpty())) {
					throw new IllegalArgumentException("Invalid argument syntax: " + arg);
				}
				commandLineArgs.addOptionArg(optionName, optionValue);
			}
			else {
				commandLineArgs.addNonOptionArg(arg);
			}
		}
		return commandLineArgs;
	}

以上代碼就做了件很簡(jiǎn)單的事情，將遍歷所有的入?yún)?，然后判斷key是否包含"–“如果包含丟到OptionArg 中，不包含就丟到NonOptionArg中，并且將commandLineArgs返回。就做了個(gè)分類(lèi)動(dòng)作含”–"的寫(xiě)法標(biāo)準(zhǔn)注解也給出來(lái)了 ,必須按下面這種寫(xiě)法

--foo
--foo=bar
--foo="bar then baz"
--foo=bar,baz,biz

好此時(shí)我們已經(jīng)獲得了一個(gè)分好類(lèi)的參數(shù)對(duì)象，丟給父類(lèi)在加工，發(fā)現(xiàn)父類(lèi)又丟給了父類(lèi)，但是我們發(fā)現(xiàn) 父類(lèi)已經(jīng)是一個(gè)PropertySource的子類(lèi)，所以最后這里被封裝成了一個(gè)PropertySource對(duì)象，實(shí)際上就是把返回的commandLineArgs對(duì)象緩存起來(lái)，最終通過(guò)提供的抽象方法，可以獲取到對(duì)應(yīng)的屬性。

public CommandLinePropertySource(T source) {
		super(COMMAND_LINE_PROPERTY_SOURCE_NAME, source);
	}

所以我們回過(guò)頭看SimpleCommandLinePropertySource 和DefaultApplicationArguments即可。從簡(jiǎn)單的代碼上我們可以很容易看出來(lái)，無(wú)非最后就是從兩個(gè)集合當(dāng)中取key value,所以直接把它當(dāng)做一個(gè)map就好了，代碼也不貼了。

接著看第二行代碼，這個(gè)才是我們的主菜

發(fā)現(xiàn)沒(méi)有，寫(xiě)代碼的層次結(jié)構(gòu)，思維思想，都是一個(gè)模式

一個(gè)復(fù)雜的過(guò)程就是先prepare -->init -->createA–>creatB–>complete.優(yōu)秀的人寫(xiě)代碼就跟寫(xiě)文章一樣。一看就很好懂得那種。

private ConfigurableEnvironment prepareEnvironment(
			SpringApplicationRunListeners listeners,
			ApplicationArguments applicationArguments) {
		//進(jìn)來(lái)第一步先聲明一個(gè)可配置的環(huán)境變量容器
		ConfigurableEnvironment environment = getOrCreateEnvironment();
		//然后配置它
		configureEnvironment(environment, applicationArguments.getSourceArgs());
		//然后發(fā)布給事件出去告訴所有l(wèi)istener 環(huán)境配置完成
		listeners.environmentPrepared(environment);
		//把環(huán)境綁定給springboot
		bindToSpringApplication(environment);
		if (!this.isCustomEnvironment) {
			environment = new EnvironmentConverter(getClassLoader())
					.convertEnvironmentIfNecessary(environment, deduceEnvironmentClass());
		}
		ConfigurationPropertySources.attach(environment);
		return environment;
	}

針對(duì)以上代碼我們接著一行行展開(kāi)創(chuàng)建，這里就是根據(jù)不同容器創(chuàng)建不同的對(duì)象。

	private ConfigurableEnvironment getOrCreateEnvironment() {
		if (this.environment != null) {
			return this.environment;
		}
		switch (this.webApplicationType) {
		case SERVLET:
			return new StandardServletEnvironment();
		case REACTIVE:
			return new StandardReactiveWebEnvironment();
		default:
			return new StandardEnvironment();
		}
	}

根據(jù)Environment的繼承關(guān)系我們不難看出在對(duì)象創(chuàng)建時(shí)就調(diào)用了customizePropertySources(this.propertySources);方法

此時(shí)也就是往容器中初始化了兩個(gè)對(duì)象一個(gè)時(shí) system一個(gè)時(shí)env，這兩個(gè)變量的參數(shù)就是系統(tǒng)和jvm級(jí)別的變量對(duì)象

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

而傳入的MutablePropertySources 直接由父類(lèi)抽象類(lèi)直接new出來(lái)的，通過(guò)查看這個(gè)類(lèi)我們可很清楚的知道它也是一個(gè)數(shù)據(jù)存儲(chǔ)結(jié)構(gòu)，緩存了一個(gè)Propertysource的列表。剩下的就是對(duì)它的增刪改等處理操作。

所以我們來(lái)看這一行

configureEnvironment(environment,applicationArguments.getSourceArgs());

在這段代碼中放了個(gè)類(lèi)型轉(zhuǎn)換服務(wù)，這個(gè)類(lèi)型轉(zhuǎn)換服務(wù)，也是一整套的體系，內(nèi)置了各種各樣的類(lèi)型轉(zhuǎn)換，比如你在配置文件寫(xiě)了個(gè) 時(shí)間 100ms 它到底是怎么被識(shí)別成100毫秒的，都是通過(guò)這個(gè)類(lèi)型轉(zhuǎn)換服務(wù)轉(zhuǎn)換的。有興趣可以自行拓展開(kāi)

protected void configureEnvironment(ConfigurableEnvironment environment,
			String[] args) {
		if (this.addConversionService) {
			ConversionService conversionService = ApplicationConversionService
					.getSharedInstance();
			environment.setConversionService(
					(ConfigurableConversionService) conversionService);
		}
		configurePropertySources(environment, args);
		configureProfiles(environment, args);
	}

接著往里走

configurePropertySources(environment, args);

這里代碼還是將拿到上面配置的緩存往里面在塞propertysource對(duì)象

protected void configurePropertySources(ConfigurableEnvironment environment,
			String[] args) {
		MutablePropertySources sources = environment.getPropertySources();
		if (this.defaultProperties != null && !this.defaultProperties.isEmpty()) {
			sources.addLast(
					new MapPropertySource("defaultProperties", this.defaultProperties));
		}
		if (this.addCommandLineProperties && args.length > 0) {
			String name = CommandLinePropertySource.COMMAND_LINE_PROPERTY_SOURCE_NAME;
			if (sources.contains(name)) {
				PropertySource<?> source = sources.get(name);
				CompositePropertySource composite = new CompositePropertySource(name);
				composite.addPropertySource(new SimpleCommandLinePropertySource(
						"springApplicationCommandLineArgs", args));
				composite.addPropertySource(source);
				sources.replace(name, composite);
			}
			else {
				sources.addFirst(new SimpleCommandLinePropertySource(args));
			}
		}
	}

從代碼可以看出，獲取了一個(gè)defaultProperties 的map把它也加入到list中。而這個(gè)map也是在main函數(shù)進(jìn)行設(shè)置的,而這個(gè)屬性是出了系統(tǒng)屬性的之外最早加載的propertysource對(duì)象

public static void main(String[] args) {
        SpringApplicationBuilder builder = new SpringApplicationBuilder();
        builder.properties(map);
        builder.run(Application.class,args);
    }

然后我們回過(guò)頭來(lái)看configureProfiles方法，此方法等以上配置完成之后，先從配置中抽取出profiles 并將其作為單獨(dú)的屬性設(shè)置回去。抽取規(guī)則看如下代碼

	protected Set<String> doGetActiveProfiles() {
		synchronized (this.activeProfiles) {
			if (this.activeProfiles.isEmpty()) {
				String profiles = getProperty(ACTIVE_PROFILES_PROPERTY_NAME);
				if (StringUtils.hasText(profiles)) {
					setActiveProfiles(StringUtils.commaDelimitedListToStringArray(
							StringUtils.trimAllWhitespace(profiles)));
				}
			}
			return this.activeProfiles;
		}
	}

最終所有的getProperty都走到如下代碼，而這段代碼也很簡(jiǎn)單就是遍歷所有的propertysource ，如果取到則終止，也就給我們營(yíng)造了一個(gè)假象，就是同一個(gè)配置被覆蓋的假象。不是真真的被覆蓋，而是放在不同的propertysource中，并且propertysource有順序而已。

protected <T> T getProperty(String key, Class<T> targetValueType, boolean resolveNestedPlaceholders) {
		if (this.propertySources != null) {
			for (PropertySource<?> propertySource : this.propertySources) {
				if (logger.isTraceEnabled()) {
					logger.trace("Searching for key '" + key + "' in PropertySource '" +
							propertySource.getName() + "'");
				}
				Object value = propertySource.getProperty(key);
				if (value != null) {
					if (resolveNestedPlaceholders && value instanceof String) {
						value = resolveNestedPlaceholders((String) value);
					}
					logKeyFound(key, propertySource, value);
					return convertValueIfNecessary(value, targetValueType);
				}
			}
		}
		if (logger.isTraceEnabled()) {
			logger.trace("Could not find key '" + key + "' in any property source");
		}
		return null;
	}

通過(guò)以上的代碼分析我們可以知道一件事情放在越底層的propertysource 會(huì)被上層的覆蓋，通過(guò)巧妙的利用這一點(diǎn)，我們就以通過(guò)不同入?yún)⒎绞竭M(jìn)行不同環(huán)境的變量覆蓋，比如在項(xiàng)目中配置了配置中心為測(cè)試環(huán)境，發(fā)布到生產(chǎn)是不是可以使用環(huán)境變量放在它的上層，就達(dá)到覆蓋效果。而不用在打包的時(shí)候去改配置。

關(guān)于propertysource總體數(shù)據(jù)結(jié)構(gòu)體系設(shè)計(jì)下回分解。

到此這篇關(guān)于SpringBoot配置的加載流程詳細(xì)分析的文章就介紹到這了,更多相關(guān)SpringBoot配置加載過(guò)程內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

您可能感興趣的文章: