@

目錄

• 前言
• 正文
  • 啟動原理
  • 事件驅動
  • 自動配置原理
  • Condition註解原理
• 總結

前言

SpringBoot是Spring的包裝，通過自動配置使得SpringBoot可以做到開箱即用，上手成本非常低，但是學習其實現原理的成本大大增加，需要先了解熟悉Spring原理。如果還不清楚Spring原理的，可以先查看博主之前的文章，本篇主要分析SpringBoot的啟動、自動配置、Condition、事件驅動原理。

正文

啟動原理

SpringBoot啟動非常簡單，因其內置了Tomcat，所以只需要通過下面幾種方式啟動即可：

@SpringBootApplication(scanBasePackages = {"cn.dark"})
public class SpringbootDemo {

    public static void main(String[] args) {
    	// 第一種
        SpringApplication.run(SpringbootDemo .class, args);

		// 第二種
        new SpringApplicationBuilder(SpringbootDemo .class)).run(args);

		// 第三種
        SpringApplication springApplication = new SpringApplication(SpringbootDemo.class);
        springApplication.run();		
    }
}

可以看到第一種是最簡單的，也是最常用的方式，需要注意類上面需要標註@SpringBootApplication註解，這是自動配置的核心實現，稍後分析，先來看看SpringBoot啟動做了些什麼？
在往下之前，不妨先猜測一下，run方法中需要做什麼？對比Spring源碼，我們知道，Spring的啟動都會創建一個ApplicationContext的應用上下文對象，並調用其refresh方法啟動容器，SpringBoot只是Spring的一層殼，肯定也避免不了這樣的操作。另一方面，以前通過Spring搭建的項目，都需要打成War包發布到Tomcat才行，而現在SpringBoot已經內置了Tomcat，只需要打成Jar包啟動即可，所以在run方法中肯定也會創建對應的Tomcat對象並啟動。以上只是我們的猜想，下面就來驗證，進入run方法：

	public ConfigurableApplicationContext run(String... args) {
		// 統計時間用的工具類
		StopWatch stopWatch = new StopWatch();
		stopWatch.start();
		ConfigurableApplicationContext context = null;
		Collection<SpringBootExceptionReporter> exceptionReporters = new ArrayList<>();
		configureHeadlessProperty();
		// 獲取實現了SpringApplicationRunListener接口的實現類，通過SPI機制加載
		// META-INF/spring.factories文件下的類
		SpringApplicationRunListeners listeners = getRunListeners(args);

		// 首先調用SpringApplicationRunListener的starting方法
		listeners.starting();
		try {
			ApplicationArguments applicationArguments = new DefaultApplicationArguments(args);

			// 處理配置數據
			ConfigurableEnvironment environment = prepareEnvironment(listeners, applicationArguments);
			configureIgnoreBeanInfo(environment);

			// 啟動時打印banner
			Banner printedBanner = printBanner(environment);

			// 創建上下文對象
			context = createApplicationContext();

			// 獲取SpringBootExceptionReporter接口的類，異常報告
			exceptionReporters = getSpringFactoriesInstances(SpringBootExceptionReporter.class,
					new Class[] { ConfigurableApplicationContext.class }, context);

			prepareContext(context, environment, listeners, applicationArguments, printedBanner);

			// 核心方法，啟動spring容器
			refreshContext(context);
			afterRefresh(context, applicationArguments);

			// 統計結束
			stopWatch.stop();
			if (this.logStartupInfo) {
				new StartupInfoLogger(this.mainApplicationClass).logStarted(getApplicationLog(), stopWatch);
			}
			// 調用started
			listeners.started(context);

			// ApplicationRunner
			// CommandLineRunner
			// 獲取這兩個接口的實現類，並調用其run方法
			callRunners(context, applicationArguments);
		}
		catch (Throwable ex) {
			handleRunFailure(context, ex, exceptionReporters, listeners);
			throw new IllegalStateException(ex);
		}

		try {
			// 最後調用running方法
			listeners.running(context);
		}
		catch (Throwable ex) {
			handleRunFailure(context, ex, exceptionReporters, null);
			throw new IllegalStateException(ex);
		}
		return context;
	}

SpringBoot的啟動流程就是這個方法，先看getRunListeners方法，這個方法就是去拿到所有的SpringApplicationRunListener實現類，這些類是用於SpringBoot事件發布的，關於事件驅動稍後分析，這裏主要看這個方法的實現原理：

	private SpringApplicationRunListeners getRunListeners(String[] args) {
		Class<?>[] types = new Class<?>[] { SpringApplication.class, String[].class };
		return new SpringApplicationRunListeners(logger,
				getSpringFactoriesInstances(SpringApplicationRunListener.class, types, this, args));
	}

	private <T> Collection<T> getSpringFactoriesInstances(Class<T> type, Class<?>[] parameterTypes, Object... args) {
		ClassLoader classLoader = getClassLoader();
		// Use names and ensure unique to protect against duplicates
		Set<String> names = new LinkedHashSet<>(SpringFactoriesLoader.loadFactoryNames(type, classLoader));
		// 加載上來后反射實例化
		List<T> instances = createSpringFactoriesInstances(type, parameterTypes, classLoader, args, names);
		AnnotationAwareOrderComparator.sort(instances);
		return instances;
	}

	public static List<String> loadFactoryNames(Class<?> factoryType, @Nullable ClassLoader classLoader) {
		String factoryTypeName = factoryType.getName();
		return loadSpringFactories(classLoader).getOrDefault(factoryTypeName, Collections.emptyList());
	}

	public static final String FACTORIES_RESOURCE_LOCATION = "META-INF/spring.factories";

	private static Map<String, List<String>> loadSpringFactories(@Nullable ClassLoader classLoader) {
		MultiValueMap<String, String> result = cache.get(classLoader);
		if (result != null) {
			return result;
		}

		try {
			Enumeration<URL> urls = (classLoader != null ?
					classLoader.getResources(FACTORIES_RESOURCE_LOCATION) :
					ClassLoader.getSystemResources(FACTORIES_RESOURCE_LOCATION));
			result = new LinkedMultiValueMap<>();
			while (urls.hasMoreElements()) {
				URL url = urls.nextElement();
				UrlResource resource = new UrlResource(url);
				Properties properties = PropertiesLoaderUtils.loadProperties(resource);
				for (Map.Entry<?, ?> entry : properties.entrySet()) {
					String factoryTypeName = ((String) entry.getKey()).trim();
					for (String factoryImplementationName : StringUtils.commaDelimitedListToStringArray((String) entry.getValue())) {
						result.add(factoryTypeName, factoryImplementationName.trim());
					}
				}
			}
			cache.put(classLoader, result);
			return result;
		}
	}

一步步追蹤下去可以看到最終就是通過SPI機制根據接口類型從META-INF/spring.factories文件中加載對應的實現類並實例化，SpringBoot的自動配置也是這樣實現的。為什麼要這樣實現呢？通過註解掃描不可以么？當然不行，這些類都在第三方jar包中，註解掃描實現是很麻煩的，當然你也可以通過@Import註解導入，但是這種方式不適合擴展類特別多的情況，所以這裏採用SPI的優點就顯而易見了。
回到run方法中，可以看到調用了createApplicationContext方法，見名知意，這個就是去創建應用上下文對象：

	public static final String DEFAULT_SERVLET_WEB_CONTEXT_CLASS = "org.springframework.boot."
			+ "web.servlet.context.AnnotationConfigServletWebServerApplicationContext";

	protected ConfigurableApplicationContext createApplicationContext() {
		Class<?> contextClass = this.applicationContextClass;
		if (contextClass == null) {
			try {
				switch (this.webApplicationType) {
				case SERVLET:
					contextClass = Class.forName(DEFAULT_SERVLET_WEB_CONTEXT_CLASS);
					break;
				case REACTIVE:
					contextClass = Class.forName(DEFAULT_REACTIVE_WEB_CONTEXT_CLASS);
					break;
				default:
					contextClass = Class.forName(DEFAULT_CONTEXT_CLASS);
				}
			}
			catch (ClassNotFoundException ex) {
				throw new IllegalStateException(
						"Unable create a default ApplicationContext, please specify an ApplicationContextClass", ex);
			}
		}
		return (ConfigurableApplicationContext) BeanUtils.instantiateClass(contextClass);
	}

注意這裏通過反射實例化了一個新的沒見過的上下文對象AnnotationConfigServletWebServerApplicationContext，這個是SpringBoot擴展的，看看其構造方法：

	public AnnotationConfigServletWebServerApplicationContext() {
		this.reader = new AnnotatedBeanDefinitionReader(this);
		this.scanner = new ClassPathBeanDefinitionScanner(this);
	}

如果你有看過Spring註解驅動的實現原理，這兩個對象肯定不會陌生，一個實支持註解解析的，另外一個是掃描包用的。
上下文創建好了，下一步自然就是調用refresh方法啟動容器：

	private void refreshContext(ConfigurableApplicationContext context) {
		refresh(context);
		if (this.registerShutdownHook) {
			try {
				context.registerShutdownHook();
			}
			catch (AccessControlException ex) {
				// Not allowed in some environments.
			}
		}
	}

	protected void refresh(ApplicationContext applicationContext) {
		Assert.isInstanceOf(AbstractApplicationContext.class, applicationContext);
		((AbstractApplicationContext) applicationContext).refresh();
	}

這裏首先會調用到其父類中ServletWebServerApplicationContext：

	public final void refresh() throws BeansException, IllegalStateException {
		try {
			super.refresh();
		}
		catch (RuntimeException ex) {
			stopAndReleaseWebServer();
			throw ex;
		}
	}

可以看到是直接委託給了父類：

	public void refresh() throws BeansException, IllegalStateException {
		synchronized (this.startupShutdownMonitor) {
			// Prepare this context for refreshing.
			prepareRefresh();

			// Tell the subclass to refresh the internal bean factory.
			ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory();

			// Prepare the bean factory for use in this context.
			prepareBeanFactory(beanFactory);

			try {
				// Allows post-processing of the bean factory in context subclasses.
				postProcessBeanFactory(beanFactory);

				// Invoke factory processors registered as beans in the context.
				invokeBeanFactoryPostProcessors(beanFactory);

				// Register bean processors that intercept bean creation.
				registerBeanPostProcessors(beanFactory);

				// Initialize message source for this context.
				initMessageSource();

				// Initialize event multicaster for this context.
				initApplicationEventMulticaster();

				// Initialize other special beans in specific context subclasses.
				onRefresh();

				// Check for listener beans and register them.
				registerListeners();

				// Instantiate all remaining (non-lazy-init) singletons.
				finishBeanFactoryInitialization(beanFactory);

				// Last step: publish corresponding event.
				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();
			}
		}
	}

這個方法不會陌生吧，之前已經分析過了，這裏不再贅述，至此SpringBoot的容器就啟動了，但是Tomcat啟動是在哪裡呢？run方法中也沒有看到。實際上Tomcat的啟動也是在refresh流程中，這個方法其中一步是調用了onRefresh方法，在Spring中這是一個沒有實現的模板方法，而SpringBoot就通過這個方法完成了Tomcat的啟動：

	protected void onRefresh() {
		super.onRefresh();
		try {
			createWebServer();
		}
		catch (Throwable ex) {
			throw new ApplicationContextException("Unable to start web server", ex);
		}
	}

	private void createWebServer() {
		WebServer webServer = this.webServer;
		ServletContext servletContext = getServletContext();
		if (webServer == null && servletContext == null) {
			ServletWebServerFactory factory = getWebServerFactory();
			// 主要看這個方法
			this.webServer = factory.getWebServer(getSelfInitializer());
		}
		else if (servletContext != null) {
			try {
				getSelfInitializer().onStartup(servletContext);
			}
			catch (ServletException ex) {
				throw new ApplicationContextException("Cannot initialize servlet context", ex);
			}
		}
		initPropertySources();
	}

這裏首先拿到TomcatServletWebServerFactory對象，通過該對象再去創建和啟動Tomcat：

	public WebServer getWebServer(ServletContextInitializer... initializers) {
		if (this.disableMBeanRegistry) {
			Registry.disableRegistry();
		}
		Tomcat tomcat = new Tomcat();
		File baseDir = (this.baseDirectory != null) ? this.baseDirectory : createTempDir("tomcat");
		tomcat.setBaseDir(baseDir.getAbsolutePath());
		Connector connector = new Connector(this.protocol);
		connector.setThrowOnFailure(true);
		tomcat.getService().addConnector(connector);
		customizeConnector(connector);
		tomcat.setConnector(connector);
		tomcat.getHost().setAutoDeploy(false);
		configureEngine(tomcat.getEngine());
		for (Connector additionalConnector : this.additionalTomcatConnectors) {
			tomcat.getService().addConnector(additionalConnector);
		}
		prepareContext(tomcat.getHost(), initializers);
		return getTomcatWebServer(tomcat);
	}

上面的每一步都可以對比Tomcat的配置文件，需要注意默認只支持了http協議：

	Connector connector = new Connector(this.protocol);

	private String protocol = DEFAULT_PROTOCOL;
	public static final String DEFAULT_PROTOCOL = "org.apache.coyote.http11.Http11NioProtocol";

如果想要擴展的話則可以對additionalTomcatConnectors屬性設置值，需要注意這個屬性沒有對應的setter方法，只有addAdditionalTomcatConnectors方法，也就是說我們只能通過實現BeanFactoryPostProcessor接口的postProcessBeanFactory方法，而不能通過BeanDefinitionRegistryPostProcessor的postProcessBeanDefinitionRegistry方法，因為前者可以通過傳入的BeanFactory對象提前獲取到TomcatServletWebServerFactory對象調用addAdditionalTomcatConnectors即可；而後者只能拿到BeanDefinition對象，該對象只能通過setter方法設置值。

事件驅動

Spring原本就提供了事件機制，而在SpringBoot中又對其進行擴展，通過發布訂閱事件在容器的整個生命周期的不同階段進行不同的操作。我們先來看看SpringBoot啟動關閉的過程中默認會發布哪些事件，使用下面的代碼即可：

@SpringBootApplication
public class SpringEventDemo {

    public static void main(String[] args) {
        new SpringApplicationBuilder(SpringEventDemo.class)
                .listeners(event -> {
                    System.err.println("接收到事件：" + event.getClass().getSimpleName());
                })
                .run()
                .close();
    }

}

這段代碼會在控制台打印所有的事件名稱，按照順序如下：

• ApplicationStartingEvent：容器啟動
• ApplicationEnvironmentPreparedEvent：環境準備好
• ApplicationContextInitializedEvent：上下文初始化完成
• ApplicationPreparedEvent：上下文準備好
• ContextRefreshedEvent：上下文刷新完
• ServletWebServerInitializedEvent：webServer初始化完成
• ApplicationStartedEvent：容器啟動完成
• ApplicationReadyEvent：容器就緒
• ContextClosedEvent：容器關閉

以上是正常啟動關閉，如果發生異常還有發布ApplicationFailedEvent事件。事件的發布遍布在整個容器的啟動關閉周期中，事件發布對象剛剛我們也看到了是通過SPI加載的SpringApplicationRunListener實現類EventPublishingRunListener，同樣事件監聽器也是在spring.factories文件中配置的，默認實現了以下監聽器：

org.springframework.context.ApplicationListener=\
org.springframework.boot.ClearCachesApplicationListener,\
org.springframework.boot.builder.ParentContextCloserApplicationListener,\
org.springframework.boot.cloud.CloudFoundryVcapEnvironmentPostProcessor,\
org.springframework.boot.context.FileEncodingApplicationListener,\
org.springframework.boot.context.config.AnsiOutputApplicationListener,\
org.springframework.boot.context.config.ConfigFileApplicationListener,\
org.springframework.boot.context.config.DelegatingApplicationListener,\
org.springframework.boot.context.logging.ClasspathLoggingApplicationListener,\
org.springframework.boot.context.logging.LoggingApplicationListener,\
org.springframework.boot.liquibase.LiquibaseServiceLocatorApplicationListener

可以看到有用於文件編碼的（FileEncodingApplicationListener），有加載日誌框架的（LoggingApplicationListener），還有加載配置的（ConfigFileApplicationListener）等等一系列監聽器，SpringBoot也就是通過這系列監聽器將必要的配置和組件加載到容器中來，這裏不再詳細分析，感興趣的讀者可以通過其實現的onApplicationEvent方法看到每個監聽器究竟是監聽的哪一個事件，當然事件發布和監聽我們自己也是可以擴展的。

自動配置原理

SpringBoot最核心的還是自動配置，為什麼它能做到開箱即用，不再需要我們手動使用@EnableXXX等註解來開啟？這一切的答案就在@SpringBootApplication註解中：

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
@SpringBootConfiguration
@EnableAutoConfiguration
@ComponentScan(excludeFilters = { @Filter(type = FilterType.CUSTOM, classes = TypeExcludeFilter.class),
		@Filter(type = FilterType.CUSTOM, classes = AutoConfigurationExcludeFilter.class) })
public @interface SpringBootApplication {}

這裏重要的註解有三個：@SpringBootConfiguration、@EnableAutoConfiguration、@ComponentScan。@ComponentScan就不用再說了，@SpringBootConfiguration等同於@Configuration，而@EnableAutoConfiguration就是開啟自動配置：

@AutoConfigurationPackage
@Import(AutoConfigurationImportSelector.class)
public @interface EnableAutoConfiguration {

}

@Import(AutoConfigurationPackages.Registrar.class)
public @interface AutoConfigurationPackage {

}

@AutoConfigurationPackage註解的作用就是將該註解所標記類所在的包作為自動配置的包，簡單看看就行，主要看AutoConfigurationImportSelector，這個就是實現自動配置的核心類，注意這個類是實現的DeferredImportSelector接口。
在這個類中有一個selectImports方法。這個方法在我之前的文章這一次搞懂Spring事務註解的解析也有分析過，只是實現類不同，它同樣會被ConfigurationClassPostProcessor類調用，先來看這個方法做了些什麼：

	public String[] selectImports(AnnotationMetadata annotationMetadata) {
		if (!isEnabled(annotationMetadata)) {
			return NO_IMPORTS;
		}
		AutoConfigurationMetadata autoConfigurationMetadata = AutoConfigurationMetadataLoader
				.loadMetadata(this.beanClassLoader);
		// 獲取所有的自動配置類
		AutoConfigurationEntry autoConfigurationEntry = getAutoConfigurationEntry(autoConfigurationMetadata,
				annotationMetadata);
		return StringUtils.toStringArray(autoConfigurationEntry.getConfigurations());
	}

	protected AutoConfigurationEntry getAutoConfigurationEntry(AutoConfigurationMetadata autoConfigurationMetadata,
			AnnotationMetadata annotationMetadata) {
		if (!isEnabled(annotationMetadata)) {
			return EMPTY_ENTRY;
		}
		AnnotationAttributes attributes = getAttributes(annotationMetadata);
		// SPI獲取EnableAutoConfiguration為key的所有實現類
		List<String> configurations = getCandidateConfigurations(annotationMetadata, attributes);
		configurations = removeDuplicates(configurations);
		Set<String> exclusions = getExclusions(annotationMetadata, attributes);
		checkExcludedClasses(configurations, exclusions);
		configurations.removeAll(exclusions);
		// 把某些自動配置類過濾掉
		configurations = filter(configurations, autoConfigurationMetadata);
		fireAutoConfigurationImportEvents(configurations, exclusions);
		// 包裝成自動配置實體類
		return new AutoConfigurationEntry(configurations, exclusions);
	}

	protected List<String> getCandidateConfigurations(AnnotationMetadata metadata, AnnotationAttributes attributes) {
		// SPI獲取EnableAutoConfiguration為key的所有實現類
		List<String> configurations = SpringFactoriesLoader.loadFactoryNames(getSpringFactoriesLoaderFactoryClass(),
				getBeanClassLoader());
		Assert.notEmpty(configurations, "No auto configuration classes found in META-INF/spring.factories. If you "
				+ "are using a custom packaging, make sure that file is correct.");
		return configurations;
	}

追蹤源碼最終可以看到也是從META-INF/spring.factories文件中拿到所有EnableAutoConfiguration對應的值（在spring-boot-autoconfigure中）並通過反射實例化，過濾后包裝成AutoConfigurationEntry對象返回。
看到這裏你應該會覺得自動配置的實現就是通過這個selectImports方法，但實際上這個方法通常並不會被調用到，而是會調用該類的內部類AutoConfigurationGroup的process和selectImports方法，前者同樣是通過getAutoConfigurationEntry拿到所有的自動配置類，而後者這是過濾排序並包裝后返回。
下面就來分析ConfigurationClassPostProcessor是怎麼調用到這裏的，直接進入processConfigBeanDefinitions方法：

	public void processConfigBeanDefinitions(BeanDefinitionRegistry registry) {
		List<BeanDefinitionHolder> configCandidates = new ArrayList<>();
		String[] candidateNames = registry.getBeanDefinitionNames();

		for (String beanName : candidateNames) {
			BeanDefinition beanDef = registry.getBeanDefinition(beanName);
			if (beanDef.getAttribute(ConfigurationClassUtils.CONFIGURATION_CLASS_ATTRIBUTE) != null) {
				if (logger.isDebugEnabled()) {
					logger.debug("Bean definition has already been processed as a configuration class: " + beanDef);
				}
			}
			else if (ConfigurationClassUtils.checkConfigurationClassCandidate(beanDef, this.metadataReaderFactory)) {
				configCandidates.add(new BeanDefinitionHolder(beanDef, beanName));
			}
		}

		// Return immediately if no @Configuration classes were found
		if (configCandidates.isEmpty()) {
			return;
		}

		// Sort by previously determined @Order value, if applicable
		configCandidates.sort((bd1, bd2) -> {
			int i1 = ConfigurationClassUtils.getOrder(bd1.getBeanDefinition());
			int i2 = ConfigurationClassUtils.getOrder(bd2.getBeanDefinition());
			return Integer.compare(i1, i2);
		});

		// Detect any custom bean name generation strategy supplied through the enclosing application context
		SingletonBeanRegistry sbr = null;
		if (registry instanceof SingletonBeanRegistry) {
			sbr = (SingletonBeanRegistry) registry;
			if (!this.localBeanNameGeneratorSet) {
				BeanNameGenerator generator = (BeanNameGenerator) sbr.getSingleton(
						AnnotationConfigUtils.CONFIGURATION_BEAN_NAME_GENERATOR);
				if (generator != null) {
					this.componentScanBeanNameGenerator = generator;
					this.importBeanNameGenerator = generator;
				}
			}
		}

		if (this.environment == null) {
			this.environment = new StandardEnvironment();
		}

		// Parse each @Configuration class
		ConfigurationClassParser parser = new ConfigurationClassParser(
				this.metadataReaderFactory, this.problemReporter, this.environment,
				this.resourceLoader, this.componentScanBeanNameGenerator, registry);

		Set<BeanDefinitionHolder> candidates = new LinkedHashSet<>(configCandidates);
		Set<ConfigurationClass> alreadyParsed = new HashSet<>(configCandidates.size());
		do {
			parser.parse(candidates);
			parser.validate();

			Set<ConfigurationClass> configClasses = new LinkedHashSet<>(parser.getConfigurationClasses());
			configClasses.removeAll(alreadyParsed);

			// Read the model and create bean definitions based on its content
			if (this.reader == null) {
				this.reader = new ConfigurationClassBeanDefinitionReader(
						registry, this.sourceExtractor, this.resourceLoader, this.environment,
						this.importBeanNameGenerator, parser.getImportRegistry());
			}
			this.reader.loadBeanDefinitions(configClasses);
			alreadyParsed.addAll(configClasses);

			// 省略。。。。
	}

前面一大段主要是拿到合格的Configuration配置類，主要邏輯是在ConfigurationClassParser.parse方法中，該方法完成了對@Component、@Bean、@Import、@ComponentScans等註解的解析，這裏主要看對@Import的解析，其它的讀者可自行分析。一步步追蹤，最終會進入到processConfigurationClass方法：

	protected void processConfigurationClass(ConfigurationClass configClass) throws IOException {
		if (this.conditionEvaluator.shouldSkip(configClass.getMetadata(), ConfigurationPhase.PARSE_CONFIGURATION)) {
			return;
		}

		ConfigurationClass existingClass = this.configurationClasses.get(configClass);
		if (existingClass != null) {
			if (configClass.isImported()) {
				if (existingClass.isImported()) {
					existingClass.mergeImportedBy(configClass);
				}
				// Otherwise ignore new imported config class; existing non-imported class overrides it.
				return;
			}
			else {
				// Explicit bean definition found, probably replacing an import.
				// Let's remove the old one and go with the new one.
				this.configurationClasses.remove(configClass);
				this.knownSuperclasses.values().removeIf(configClass::equals);
			}
		}

		// Recursively process the configuration class and its superclass hierarchy.
		SourceClass sourceClass = asSourceClass(configClass);
		do {
			sourceClass = doProcessConfigurationClass(configClass, sourceClass);
		}
		while (sourceClass != null);

		this.configurationClasses.put(configClass, configClass);
	}

這裏需要注意this.conditionEvaluator.shouldSkip方法的調用，這個方法就是進行Bean加載過濾的，即根據@Condition註解的匹配值判斷是否加載該Bean，具體實現稍後分析，繼續跟蹤主流程doProcessConfigurationClass：

	protected final SourceClass doProcessConfigurationClass(ConfigurationClass configClass, SourceClass sourceClass)
			throws IOException {
		省略....

		// Process any @Import annotations
		processImports(configClass, sourceClass, getImports(sourceClass), true);

		省略....
		return null;
	}

這裏就是完成對一系列註解的支撐，我省略掉了，主要看processImports方法，這個方法就是處理@Import註解的：

	private void processImports(ConfigurationClass configClass, SourceClass currentSourceClass,
			Collection<SourceClass> importCandidates, boolean checkForCircularImports) {

		if (importCandidates.isEmpty()) {
			return;
		}

		if (checkForCircularImports && isChainedImportOnStack(configClass)) {
			this.problemReporter.error(new CircularImportProblem(configClass, this.importStack));
		}
		else {
			this.importStack.push(configClass);
			try {
				for (SourceClass candidate : importCandidates) {
					if (candidate.isAssignable(ImportSelector.class)) {
						// Candidate class is an ImportSelector -> delegate to it to determine imports
						Class<?> candidateClass = candidate.loadClass();
						ImportSelector selector = ParserStrategyUtils.instantiateClass(candidateClass, ImportSelector.class,
								this.environment, this.resourceLoader, this.registry);
						if (selector instanceof DeferredImportSelector) {
							this.deferredImportSelectorHandler.handle(configClass, (DeferredImportSelector) selector);
						}
						else {
							String[] importClassNames = selector.selectImports(currentSourceClass.getMetadata());
							Collection<SourceClass> importSourceClasses = asSourceClasses(importClassNames);
							processImports(configClass, currentSourceClass, importSourceClasses, false);
						}
					}
					else if (candidate.isAssignable(ImportBeanDefinitionRegistrar.class)) {
						Class<?> candidateClass = candidate.loadClass();
						ImportBeanDefinitionRegistrar registrar =
								ParserStrategyUtils.instantiateClass(candidateClass, ImportBeanDefinitionRegistrar.class,
										this.environment, this.resourceLoader, this.registry);
						configClass.addImportBeanDefinitionRegistrar(registrar, currentSourceClass.getMetadata());
					}
					else {
						this.importStack.registerImport(
								currentSourceClass.getMetadata(), candidate.getMetadata().getClassName());
						processConfigurationClass(candidate.asConfigClass(configClass));
					}
				}
			}
		}
	}

剛剛我提醒過AutoConfigurationImportSelector是實現DeferredImportSelector接口的，如果不是該接口的實現類則是直接調用selectImports方法，反之則是調用DeferredImportSelectorHandler.handle方法：

		private List<DeferredImportSelectorHolder> deferredImportSelectors = new ArrayList<>();
		
		public void handle(ConfigurationClass configClass, DeferredImportSelector importSelector) {
			DeferredImportSelectorHolder holder = new DeferredImportSelectorHolder(
					configClass, importSelector);
			if (this.deferredImportSelectors == null) {
				DeferredImportSelectorGroupingHandler handler = new DeferredImportSelectorGroupingHandler();
				handler.register(holder);
				handler.processGroupImports();
			}
			else {
				this.deferredImportSelectors.add(holder);
			}
		}

首先創建了一個DeferredImportSelectorHolder對象，如果是第一次執行則是添加到deferredImportSelectors屬性中，等到ConfigurationClassParser.parse的最後調用process方法：

	public void parse(Set<BeanDefinitionHolder> configCandidates) {
		省略.....

		this.deferredImportSelectorHandler.process();
	}

	public void process() {
		List<DeferredImportSelectorHolder> deferredImports = this.deferredImportSelectors;
		this.deferredImportSelectors = null;
		try {
			if (deferredImports != null) {
				DeferredImportSelectorGroupingHandler handler = new DeferredImportSelectorGroupingHandler();
				deferredImports.sort(DEFERRED_IMPORT_COMPARATOR);
				deferredImports.forEach(handler::register);
				handler.processGroupImports();
			}
		}
		finally {
			this.deferredImportSelectors = new ArrayList<>();
		}
	}

反之則是直接執行，首先通過register拿到AutoConfigurationGroup對象：

	public void register(DeferredImportSelectorHolder deferredImport) {
		Class<? extends Group> group = deferredImport.getImportSelector()
				.getImportGroup();
		DeferredImportSelectorGrouping grouping = this.groupings.computeIfAbsent(
				(group != null ? group : deferredImport),
				key -> new DeferredImportSelectorGrouping(createGroup(group)));
		grouping.add(deferredImport);
		this.configurationClasses.put(deferredImport.getConfigurationClass().getMetadata(),
				deferredImport.getConfigurationClass());
	}

	public Class<? extends Group> getImportGroup() {
		return AutoConfigurationGroup.class;
	}

然後在processGroupImports方法中進行真正的處理：

		public void processGroupImports() {
			for (DeferredImportSelectorGrouping grouping : this.groupings.values()) {
				grouping.getImports().forEach(entry -> {
					ConfigurationClass configurationClass = this.configurationClasses.get(
							entry.getMetadata());
					try {
						processImports(configurationClass, asSourceClass(configurationClass),
								asSourceClasses(entry.getImportClassName()), false);
					}
					catch (BeanDefinitionStoreException ex) {
						throw ex;
					}
					catch (Throwable ex) {
						throw new BeanDefinitionStoreException(
								"Failed to process import candidates for configuration class [" +
										configurationClass.getMetadata().getClassName() + "]", ex);
					}
				});
			}
		}

		public Iterable<Group.Entry> getImports() {
			for (DeferredImportSelectorHolder deferredImport : this.deferredImports) {
				this.group.process(deferredImport.getConfigurationClass().getMetadata(),
						deferredImport.getImportSelector());
			}
			return this.group.selectImports();
		}

在getImports方法中就完成了對process和selectImports方法的調用，拿到自動配置類后再遞歸調用調用processImports方法完成對自動配置類的加載。至此，自動配置的加載過程就分析完了，下面是時序圖：

Condition註解原理

在自動配置類中有很多Condition相關的註解，以AOP為例：

Configuration(proxyBeanMethods = false)
@ConditionalOnProperty(prefix = "spring.aop", name = "auto", havingValue = "true", matchIfMissing = true)
public class AopAutoConfiguration {

	@Configuration(proxyBeanMethods = false)
	@ConditionalOnClass(Advice.class)
	static class AspectJAutoProxyingConfiguration {

		@Configuration(proxyBeanMethods = false)
		@EnableAspectJAutoProxy(proxyTargetClass = false)
		@ConditionalOnProperty(prefix = "spring.aop", name = "proxy-target-class", havingValue = "false",
				matchIfMissing = false)
		static class JdkDynamicAutoProxyConfiguration {

		}

		@Configuration(proxyBeanMethods = false)
		@EnableAspectJAutoProxy(proxyTargetClass = true)
		@ConditionalOnProperty(prefix = "spring.aop", name = "proxy-target-class", havingValue = "true",
				matchIfMissing = true)
		static class CglibAutoProxyConfiguration {

		}

	}

	@Configuration(proxyBeanMethods = false)
	@ConditionalOnMissingClass("org.aspectj.weaver.Advice")
	@ConditionalOnProperty(prefix = "spring.aop", name = "proxy-target-class", havingValue = "true",
			matchIfMissing = true)
	static class ClassProxyingConfiguration {

		ClassProxyingConfiguration(BeanFactory beanFactory) {
			if (beanFactory instanceof BeanDefinitionRegistry) {
				BeanDefinitionRegistry registry = (BeanDefinitionRegistry) beanFactory;
				AopConfigUtils.registerAutoProxyCreatorIfNecessary(registry);
				AopConfigUtils.forceAutoProxyCreatorToUseClassProxying(registry);
			}
		}

	}

}

這裏就能看到@ConditionalOnProperty、@ConditionalOnClass、@ConditionalOnMissingClass，另外還有@ConditionalOnBean、@ConditionalOnMissingBean等等很多條件匹配註解。這些註解表示條件匹配才會加載該Bean，以@ConditionalOnProperty為例，表明配置文件中符合條件才會加載對應的Bean，prefix表示在配置文件中的前綴，name表示配置的名稱，havingValue表示配置為該值時才匹配，matchIfMissing則是表示沒有該配置是否默認加載對應的Bean。其它註解可類比理解記憶，下面主要來分析該註解的實現原理。
這裏註解點進去看會發現每個註解上都標註了@Conditional註解，並且value值都對應一個類，比如OnBeanCondition，而這些類都實現了Condition接口，看看其繼承體系：

上面只展示了幾個實現類，但實際上Condition的實現類是非常多的，我們還可以自己實現該接口來擴展@Condition註解。
Condition接口中有一個matches方法，這個方法返回true則表示匹配。該方法在ConfigurationClassParser中多處都有調用，也就是剛剛我提醒過的shouldSkip方法，具體實現是在ConditionEvaluator類中：

	public boolean shouldSkip(@Nullable AnnotatedTypeMetadata metadata, @Nullable ConfigurationPhase phase) {
		if (metadata == null || !metadata.isAnnotated(Conditional.class.getName())) {
			return false;
		}

		if (phase == null) {
			if (metadata instanceof AnnotationMetadata &&
					ConfigurationClassUtils.isConfigurationCandidate((AnnotationMetadata) metadata)) {
				return shouldSkip(metadata, ConfigurationPhase.PARSE_CONFIGURATION);
			}
			return shouldSkip(metadata, ConfigurationPhase.REGISTER_BEAN);
		}

		List<Condition> conditions = new ArrayList<>();
		for (String[] conditionClasses : getConditionClasses(metadata)) {
			for (String conditionClass : conditionClasses) {
				Condition condition = getCondition(conditionClass, this.context.getClassLoader());
				conditions.add(condition);
			}
		}

		AnnotationAwareOrderComparator.sort(conditions);

		for (Condition condition : conditions) {
			ConfigurationPhase requiredPhase = null;
			if (condition instanceof ConfigurationCondition) {
				requiredPhase = ((ConfigurationCondition) condition).getConfigurationPhase();
			}
			if ((requiredPhase == null || requiredPhase == phase) && !condition.matches(this.context, metadata)) {
				return true;
			}
		}

		return false;
	}

再來看看matches的實現，但OnBeanCondition類中沒有實現該方法，而是在其父類SpringBootCondition中：

	public final boolean matches(ConditionContext context, AnnotatedTypeMetadata metadata) {
		String classOrMethodName = getClassOrMethodName(metadata);
		try {
			ConditionOutcome outcome = getMatchOutcome(context, metadata);
			logOutcome(classOrMethodName, outcome);
			recordEvaluation(context, classOrMethodName, outcome);
			return outcome.isMatch();
		}

getMatchOutcome方法也是一個模板方法，具體的匹配邏輯就在這個方法中實現，該方法返回的ConditionOutcome對象就包含了是否匹配和日誌消息兩個字段。進入到OnBeanCondition類中：

	public ConditionOutcome getMatchOutcome(ConditionContext context, AnnotatedTypeMetadata metadata) {
		ConditionMessage matchMessage = ConditionMessage.empty();
		MergedAnnotations annotations = metadata.getAnnotations();
		if (annotations.isPresent(ConditionalOnBean.class)) {
			Spec<ConditionalOnBean> spec = new Spec<>(context, metadata, annotations, ConditionalOnBean.class);
			MatchResult matchResult = getMatchingBeans(context, spec);
			if (!matchResult.isAllMatched()) {
				String reason = createOnBeanNoMatchReason(matchResult);
				return ConditionOutcome.noMatch(spec.message().because(reason));
			}
			matchMessage = spec.message(matchMessage).found("bean", "beans").items(Style.QUOTE,
					matchResult.getNamesOfAllMatches());
		}
		if (metadata.isAnnotated(ConditionalOnSingleCandidate.class.getName())) {
			Spec<ConditionalOnSingleCandidate> spec = new SingleCandidateSpec(context, metadata, annotations);
			MatchResult matchResult = getMatchingBeans(context, spec);
			if (!matchResult.isAllMatched()) {
				return ConditionOutcome.noMatch(spec.message().didNotFind("any beans").atAll());
			}
			else if (!hasSingleAutowireCandidate(context.getBeanFactory(), matchResult.getNamesOfAllMatches(),
					spec.getStrategy() == SearchStrategy.ALL)) {
				return ConditionOutcome.noMatch(spec.message().didNotFind("a primary bean from beans")
						.items(Style.QUOTE, matchResult.getNamesOfAllMatches()));
			}
			matchMessage = spec.message(matchMessage).found("a primary bean from beans").items(Style.QUOTE,
					matchResult.getNamesOfAllMatches());
		}
		if (metadata.isAnnotated(ConditionalOnMissingBean.class.getName())) {
			Spec<ConditionalOnMissingBean> spec = new Spec<>(context, metadata, annotations,
					ConditionalOnMissingBean.class);
			MatchResult matchResult = getMatchingBeans(context, spec);
			if (matchResult.isAnyMatched()) {
				String reason = createOnMissingBeanNoMatchReason(matchResult);
				return ConditionOutcome.noMatch(spec.message().because(reason));
			}
			matchMessage = spec.message(matchMessage).didNotFind("any beans").atAll();
		}
		return ConditionOutcome.match(matchMessage);
	}

可以看到該類支持了@ConditionalOnBean、@ConditionalOnSingleCandidate、@ConditionalOnMissingBean註解，主要的匹配邏輯在getMatchingBeans方法中：

	protected final MatchResult getMatchingBeans(ConditionContext context, Spec<?> spec) {
		ClassLoader classLoader = context.getClassLoader();
		ConfigurableListableBeanFactory beanFactory = context.getBeanFactory();
		boolean considerHierarchy = spec.getStrategy() != SearchStrategy.CURRENT;
		Set<Class<?>> parameterizedContainers = spec.getParameterizedContainers();
		if (spec.getStrategy() == SearchStrategy.ANCESTORS) {
			BeanFactory parent = beanFactory.getParentBeanFactory();
			Assert.isInstanceOf(ConfigurableListableBeanFactory.class, parent,
					"Unable to use SearchStrategy.ANCESTORS");
			beanFactory = (ConfigurableListableBeanFactory) parent;
		}
		MatchResult result = new MatchResult();
		Set<String> beansIgnoredByType = getNamesOfBeansIgnoredByType(classLoader, beanFactory, considerHierarchy,
				spec.getIgnoredTypes(), parameterizedContainers);
		for (String type : spec.getTypes()) {
			Collection<String> typeMatches = getBeanNamesForType(classLoader, considerHierarchy, beanFactory, type,
					parameterizedContainers);
			typeMatches.removeAll(beansIgnoredByType);
			if (typeMatches.isEmpty()) {
				result.recordUnmatchedType(type);
			}
			else {
				result.recordMatchedType(type, typeMatches);
			}
		}
		for (String annotation : spec.getAnnotations()) {
			Set<String> annotationMatches = getBeanNamesForAnnotation(classLoader, beanFactory, annotation,
					considerHierarchy);
			annotationMatches.removeAll(beansIgnoredByType);
			if (annotationMatches.isEmpty()) {
				result.recordUnmatchedAnnotation(annotation);
			}
			else {
				result.recordMatchedAnnotation(annotation, annotationMatches);
			}
		}
		for (String beanName : spec.getNames()) {
			if (!beansIgnoredByType.contains(beanName) && containsBean(beanFactory, beanName, considerHierarchy)) {
				result.recordMatchedName(beanName);
			}
			else {
				result.recordUnmatchedName(beanName);
			}
		}
		return result;
	}

這裏邏輯看起來比較複雜，但實際上就做了兩件事，首先通過getNamesOfBeansIgnoredByType方法調用beanFactory.getBeanNamesForType拿到容器中對應的Bean實例，然後根據返回的結果判斷哪些Bean存在，哪些Bean不存在（Condition註解中是可以配置多個值的）並返回MatchResult對象，而MatchResult中只要有一個Bean沒有匹配上就返回false，也就決定了當前Bean是否需要實例化。

總結

本篇分析了SpringBoot核心原理的實現，通過本篇相信讀者也將能更加熟練地使用和擴展SpringBoot。另外還有一些常用的組件我沒有展開分析，如事務、MVC、監聽器的自動配置，這些我們有了Spring源碼基礎的話下來看一下就明白了，這裏就不贅述了。最後讀者可以思考一下我們應該如何自定義starter啟動器，相信看完本篇應該難不倒你。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※新北清潔公司,居家、辦公、裝潢細清專業服務

※別再煩惱如何寫文案,掌握八大原則!

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※超省錢租車方案

  2月12日，媒體報導，樂視網資訊技術（北京）股份有限公司稱計畫投資數十億美元開發電動汽車，將美國定為首要目標市場。   此前的1月19日，樂視網正式確認「SEE計畫」即樂視超級汽車計畫。公司表示，這是由控股股東樂視控股所開展的一項旨在打造一個全球獨有的垂直整合汽車互聯網生態系統的重要戰略。   受超級汽車計畫等一系列利好影響，2月11日，樂視網以584億元人民幣（下同）的市值躍升創業板首位。自去年12月23日起，其股價從28.2元的底部漲至11日的69.43元，大漲146%。  
動態：正就專案資金與投資方磋商   上任伊始的樂視汽車業務中國負責人呂征宇接受電話採訪時表示，樂視計畫招聘更多人才以加強現有大約260人的電動汽車專案團隊。他說，樂視將這個專案視為一項長期投資，正在就專案資金與投資方進行磋商。樂視計畫投資數十億美元，將美國定為首要目標市場。他沒有透露更多細節。   樂視董事長賈躍亭誓言「顛覆」傳統汽車行業，宣佈要打造一款智慧化和互聯化程度更高的汽車。其目標是比亞迪和長城汽車等更成熟的中國車企未能實現的目標：把汽車賣給美國消費者。   呂征宇曾在日產汽車旗下英菲尼迪供職。他確信，就像賈躍亭所說的那樣，對於每件新生事物，當人們第一次看到的時候，首先會忽視你，然後會笑話你，再然後會反對你，然後你就贏了；利用自己在設計、製造和分銷方面的優勢，樂視有機會顛覆傳統汽車行業。  
回顧：北汽曾表示願意代工   2014年7月21日，國務院公佈《關於加快新能源汽車推廣應用的指導意見》，阿里巴巴與樂視網分別傳出要進軍汽車領域，一個牽手上汽，一個牽手北汽。   2014年4月份，北汽董事長徐和誼在一次公開場合就提出，「汽車企業未來可能會成為互聯網企業的貼牌製造商」這一觀點，甚至點名「樂視網」，表示願意「代工生產樂視汽車」。   在徐和誼看來，新能源汽車按照傳統汽車模式肯定不行。新能源汽車產業與傳統汽車產業不只是在燒油與用電方面的區別，「新能源汽車是一個全新的行業，必須要用全新的模式與之相適應」，而這個新模式的合作物件目前來看首選樂視的可能很大。   知名產業評論家信海光在微信中披露，樂視CEO賈躍亭在美期間，除了佈局海外市場，在美國創立兩家子公司，推動樂視生態業務全球化全面啟動外，另一高度保密專案，就是樂視汽車專案。據悉，賈躍亭在美國和徐和誼密會，初步達成合作汽車的意向，至於細節不得而知。   2014年4月9日，賓士CLA與樂視強強聯合上演了一場時尚行銷秀。賓士發言人表示其品牌看中了樂視網中極具潛力、並願為生活品質買單的高端用戶，而這批用戶對於北汽開拓新能源汽車市場十分關鍵。此外，寶馬、英菲尼迪等高端車企品牌也都上過樂視超級電視廣告。樂視一直強調的「生態」建設，是樂視進軍汽車業的驅動力，也是樂視推出互聯網汽車的良好土壤。   按照目前的樂視產品思路，互聯網行銷方式與產品價格將是撒手鐧，評論人士認為，樂視汽車一旦推向市場，會很大程度推動新能源車或者互聯網汽車的市場普及，而樂視網本身也會很快走向年營收千億元這一量級。  
影響：超級計畫引爆股價   2015年2月11日，樂視網收穫本週第2個、今年第5個漲停板。憑藉密集發力榮登創業板老大的樂視網，以市值584億元遠遠甩開第二名東方財富，後者總市值為498億元。   樂視網市值躍升首位，用了35個交易日。自去年12月23日起，其股價從28.2元的底部漲至11日的69.43元，大漲146%。   市場人士認為，樂視網已經與京東、小米、360一起，組成繼百度、阿里巴巴和騰訊之後的中國互聯網第二梯隊。樂視的總市值已經超越奇虎360，資料顯示，在納斯達克上市的360市值為78億美元，約合人民幣488億元。   樂視網股價任性飆升的背後，是電動超級汽車等計畫獲得了市場認同。   1月14日，美國影響力最大的商業科技媒體Business Insider刊發文章，認為中國互聯網公司樂視CEO賈躍亭將憑藉電動超級汽車，與推出特斯拉電動汽車的埃隆•馬斯克一樣，成為全球矚目的明星企業家。Business Insider文中稱：賈躍亭將是中國的「埃隆•馬斯克」。   1月19日，樂視網正式確認「SEE計畫」即樂視超級汽車計畫。公司表示，這是由控股股東樂視控股所開展的一項旨在打造一個全球獨有的垂直整合汽車互聯網生態系統的重要戰略，樂視網與其運營主體並無股權關係，短期內也不會對公司業績構成影響。   連結：特斯拉跌落神壇敲響警鐘   2月11日，特斯拉中國1月銷量僅為120輛的消息幾乎佔據了各大財經和科技媒體的頭條。這家曾經令中國媒體不惜溢美之詞、引得自主品牌車企紛紛一探究竟的電動車製造企業，在一年後跌落神壇。   特斯拉的失敗不可避免地讓一大批揮師進軍汽車行業的互聯網公司坐立難安。通過「電腦+四個輪子」的品牌形象和打破4S經銷體系、主打直營的銷售模式，特斯拉吸引了不少中國擁躉，其中不乏小米和樂視這樣靠垂直整合起家的手機和電視廠商。   從目前已經公佈的樂視超級汽車等方案來看，特斯拉的這批中國學徒們均給自己貼上了「智慧汽車」、「互聯網汽車」的標籤，但在電動車最核心的電池、電機、電控及底盤技術上卻諱莫如深。   特斯拉希望通過推出廉價版的Model X來緩解單產品線的窘境，而電池成本的下降是實現低價版車型量產的基礎。馬斯克曾樂觀預計10年內特斯拉能夠將電池成本降到100美元/千瓦時，但包括電池專家在內紛紛對馬斯克的預期予以駁斥：不僅在2025年之前，電池成本不可能降低至167美元/千瓦時，而且特斯拉Model X價格將從原本的3萬美元定價提高到5-8萬美元。   特斯拉在中國市場陷入泥潭戳破了電動車的泡沫，當樂視小米們在造車的道路上越走越遠時，不得不回頭看看特斯拉的警示。   （文章來源：長江商報）

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※新北清潔公司,居家、辦公、裝潢細清專業服務

※別再煩惱如何寫文案,掌握八大原則!

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※超省錢租車方案

我是風箏，公眾號「古時的風箏」，一個兼具深度與廣度的程序員鼓勵師，一個本打算寫詩卻寫起了代碼的田園碼農！
文章會收錄在 JavaNewBee 中，更有 Java 後端知識圖譜，從小白到大牛要走的路都在裏面。

程序員上班戴耳機聽歌難道不是正常的嗎，真的還有公司不允許程序員戴耳機的嗎？不戴耳機能寫代碼？

那程序員的耳機里聽的是什麼呢？我採訪了一眾程序員朋友。

鋼鐵程序員王二麻子同學

聽的什麼？我根本就不知道，我只是不想讓別人打擾我

有時候開發確實是比較費腦子的，尤其是遇到複雜邏輯的時候。正當思如泉涌、靈感迸發的時候，旁人看着我坐在那裡一動不動，好像什麼都沒有做，其實我腦子里正在構思一個複雜的流程。

這時候，突然有個人走過來打斷我，前面的思考都白費了，你說傷心不，你說氣人不。

所以，為了防止上面的情況出現，不得不戴上耳機。至於聽什麼，不重要，我只是告訴別人，別過來，我現在沒時間。

生活需要儀式感的劉精神同學

聽什麼不重要，關鍵是儀式感

生活需要儀式感，寫代碼也需要儀式感啊。當我戴上耳機的那一刻，我感覺精神抖擻，彷彿遊離的三魂六魄都回來了，寫代碼更有動力。

要是不戴耳機，感覺渾身無力，只想摸魚，寫代碼什麼的，根本想都想不起來。

心疼自己的高愛己同學

其實我就是不想聽我的机械鍵盤聲音，實在太吵了

你也知道，筆記本自帶的鍵盤總感覺軟綿綿的，敲起來實在不給力，嚴重影響我的工作效率。那必須得買個鍵盤啊，在多個朋友的推薦下，我就買了一個青軸鍵盤。你別說，觸感真不錯，每按一下，都感覺指尖有一股電流滑過，同時伴隨着啪啪啪的聲音，感覺寫代碼效率明顯變高了，更神奇的是 bug 都比以前少了，你說神奇不。

但是呢，有個缺點，就是時間久了吧，感覺稍微有那麼一點點吵，所以我就配了個耳機，從此之後，既得到了直達靈魂的觸感，又不會感覺吵了。更神奇的一點是，以前罵我的同事好像都不罵我了。

真的在聽東西的同學

雖然存在以上幾位同學說的情況，但大多數情況下， 我們是真的在聽東西。比如我，為了聽高品質的，還專門買了網易雲音樂的 VIP 。

為什麼是東西，而不是音樂呢，因為有的人不是在聽音樂。

我聽說有人在寫代碼的時候聽評書，更有厲害的，竟然聽相聲。那我想只有三種可能。

1. 根本沒在寫代碼，可能是在摸魚。
2. 評書一點都不精彩，相聲一點都不好笑，僅僅是一門語言的藝術而已。
3. 這是個大佬，已經進入忘我的境界，聽到的不是語言，而是聲音解析成比特位時產生的白噪音，一般人聽不到，只有某些段位的大佬可以。

當然畢竟大佬不常有，而普通群眾常用。大部分人聽的確實是音樂。比如我吧，我戴耳機真的是在聽音樂，為了降噪、減少干擾，提高專註力，提升效率。

什麼類型的音樂更受程序員歡迎呢

英文歌

英文歌是大多數程序員的最愛。請看網易雲音樂給我的每日歌曲推薦，除了伍佰的一首中文歌亂入，剩下的都是英文歌。

你真的認為我英語很好嗎，正好相反，之所以英文歌那麼受歡迎，就是因為聽不懂歌詞是什麼意思，這樣才不會被歌詞帶跑偏，沒錯，我們聽的就是這個節奏。

那要是中文歌就不一樣了，比如說當我聽到「你的酒館對我打了烊，子彈在我心頭上了膛」的時候，我就以為真的要打烊了，子彈真的要上膛了，從而引發一系列思考，酒館為什麼對我打烊，子彈為什麼要上膛，生意不做了嗎，刑法基本法則不懂嗎。

為了證明這一點，我到網易雲音樂上搜了「程序員」相關的歌單，點進去一看，大部分也都是英文歌，看來大家英文都不太好。

然後我又搜了「產品狗」相關的歌單，同樣也是英文歌為主，可見我們雖然不太對付，請參考歌單『產品狗如何說服程序猿』和『程序員如何回應產品狗』，但是方法論還是差不多的。

純音樂

純音樂也是很受歡迎的，我有個同事最喜歡聽貝多芬的命運交響曲，我就沒那麼文藝了。我一般都是聽那種激昂的小提琴或者聽完感覺自己馬上要登基了的那種，不容易犯困。

白噪音

小提琴太勁爆，不能常聽，犯困的下午聽聽可以提神，bug 太多又不想改的時候可以聽聽。大多數時候，不需要那麼亢奮，保持內心的平靜就是寫代碼最好的狀態。那就聽聽白噪音好了，比如雨聲、風聲、溪水聲、鳥唱蟬鳴。

我最喜歡的就是雨聲，嘩啦啦的大雨，再配上驚雷，簡直不要太平靜，innerpeace。

比如下面這個，一聽就是一個小時。

保留曲目

每個人都有自己家私藏的歌單，百聽不厭的那種，當然每個人的品位不一樣、口味兒不一樣，比如當年有個哥們兒異常興奮的把他的珍藏歌單分享給我，我當即表示很感動，一定要認真聽一聽。可當我硬着頭皮聽完第二首的時候，我內心是拒絕的，只能委婉的跟哥們兒說：這 TM 什麼玩意兒。當然是不會破壞友誼的小船的，如果是不熟的朋友，那肯定會豎起大拇指，並且連連點頭稱讚：真不錯，品位棒棒噠。

我沒有薦歌啊，向別人推薦歌曲犹如喂別人食物，你覺得好吃別人並一定覺得好吃。下面是我的 2018 年年度聽歌報告，Sophie Zelmani（蘇菲.珊曼妮）的熱門50單曲就是我的保留曲目，白聽不厭，而且更重要的不仔細聽，還是聽不出歌詞的意思，正好適合寫代碼用。

另外，作為一個程序員鼓勵師，為了鼓勵我自己，我也創建了一個「程序員鼓勵師」的歌單，經常拿出來聽聽接收鼓勵。

作為程序員的你，耳機里有什麼特殊的內容嗎？

壯士且慢，先給點個贊吧，總是被白嫖，身體吃不消！

我是風箏，公眾號「古時的風箏」。一個兼具深度與廣度的程序員鼓勵師，一個本打算寫詩卻寫起了代碼的田園碼農！你可選擇現在就關注我，或者看看歷史文章再關注也不遲。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※網頁設計公司推薦不同的風格，搶佔消費者視覺第一線

※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

※南投搬家公司費用,距離,噸數怎麼算?達人教你簡易估價知識!

※教你寫出一流的銷售文案?

※超省錢租車方案