生命太短暫，不要去做一些根本沒有人想要的東西。本文已被 https://www.yourbatman.cn 收錄，里面一并有Spring技術(shù)棧、MyBatis、JVM、中間件等小而美的專欄供以免費學習。

前言

各位小伙伴大家好，我是A哥。上篇文章了解了static關(guān)鍵字 + @Bean方法的使用，知曉了它能夠提升Bean的優(yōu)先級，在@Bean方法前標注static關(guān)鍵字，特定情況下可以避免一些煩人的“警告”日志的輸出，排除隱患讓工程變得更加安全。我們知道static關(guān)鍵字它不僅可使用在方法上，那么本文將繼續(xù)挖掘static在Spring環(huán)境下的用處。

根據(jù)所學的JavaSE基礎(chǔ)，static關(guān)鍵字除了能夠修飾方法外，還能使用在這兩個地方：

修飾類。確切的說，應(yīng)該叫修飾內(nèi)部類，所以它叫靜態(tài)內(nèi)部類修飾成員變量

其實static還可以修飾代碼塊、static靜態(tài)導包等，但很明顯，這些與本文無關(guān)

接下來就以這為兩條主線，分別研究static在對應(yīng)場景下的作用，本文將聚焦在靜態(tài)內(nèi)部類上。

版本約定

本文內(nèi)容若沒做特殊說明，均基于以下版本：

• JDK：1.8
• Spring Framework：5.2.2.RELEASE

正文

說到Java里的static關(guān)鍵字，這當屬最基礎(chǔ)的入門知識，是Java中常用的關(guān)鍵字之一。你平時用它來修飾變量和方法了，但是對它的了解，即使放在JavaSE情景下知道這些還是不夠的，問題雖小但這往往反映了你對Java基礎(chǔ)的了解程度。

當然嘍，本文并不討論它在JavaSE下使用，畢竟咱們還是有一定逼格的專欄，需要進階一把，玩玩它在Spring環(huán)境下到底能夠迸出怎么樣的火花呢？比如靜態(tài)內(nèi)部類~

Spring下的靜態(tài)內(nèi)部類

static修飾類只有一種情況：那就是這個類屬于內(nèi)部類，這就是我們津津樂道的靜態(tài)內(nèi)部類，形如這樣：

public class Outer {

 private String name;
 private static Integer age;

 // 靜態(tài)內(nèi)部類
 private static class Inner {

 private String innerName;
 private static Integer innerAge;

 public void fun1() {
 // 無法訪問外部類的成員變量
 //System.out.println(name);
 System.out.println(age);

 System.out.println(innerName);
 System.out.println(innerAge);
 }

 }

 public static void main(String[] args) {
 // 靜態(tài)內(nèi)部類的實例化并不需要依賴于外部類的實例
 Inner inner = new Inner();
 }
}

在實際開發(fā)中，靜態(tài)內(nèi)部類的使用場景是非常之多的。

認識靜態(tài)/普通內(nèi)部類

由于一些小伙伴對普通內(nèi)部類 vs 靜態(tài)內(nèi)部類傻傻分不清，為了方便后續(xù)講解，本處把關(guān)鍵要素做簡要對比說明：

• 靜態(tài)內(nèi)部類可以聲明靜態(tài)or實例成員(屬性和方法)；而普通內(nèi)部類則不可以聲明靜態(tài)成員(屬性和方法)
• 靜態(tài)內(nèi)部類實例的創(chuàng)建不依賴于外部類；而普通外部類實例創(chuàng)建必須先有外部類實例才行（綁定關(guān)系拿捏得死死的，不信你問鄭凱）
• 靜態(tài)內(nèi)部類不能訪問外部類的實例成員；而普通內(nèi)部類可以隨意訪問(不管靜態(tài)or非靜態(tài)) --> 我理解這是普通內(nèi)部類能 “存活” 下來的最大理由了吧😄

總之，普通內(nèi)部類和外部類的關(guān)系屬于強綁定，而靜態(tài)內(nèi)部類幾乎不會受到外部類的限制，可以游離單獨使用。既然如此，那為何還需要static靜態(tài)內(nèi)部類呢，直接單獨寫個Class類豈不就好了嗎？存在即合理，這么使用的原因我個人覺得有如下兩方面思考，供以你參考：

• 靜態(tài)內(nèi)部類是弱關(guān)系并不是沒關(guān)系，比如它還是可以訪問外部類的static的變量的不是（即便它是private的）
• 高內(nèi)聚的體現(xiàn)

在傳統(tǒng)Spirng Framework的配置類場景下，你可能鮮有接觸到static關(guān)鍵字使用在類上的場景，但這在Spring Boot下使用非常頻繁，比如屬性配置類的典型應(yīng)用：

@ConfigurationProperties(prefix = "server", ignoreUnknownFields = true)
public class ServerProperties {
	
	// server.port = xxx 
	// server.address = xxx
	private Integer port;
	private InetAddress address;
	...
	
	// tomcat配置
	public static class Tomcat {
		
		// server.tomcat.protocol-header = xxx
		private String protocolHeader;
		...
		
		// tomcat內(nèi)的log配置
		public static class Accesslog {
			
			// server.tomcat.accesslog.enabled = xxx
			private boolean enabled = false;
			...
		}
	}	
}

這種嵌套case使得代碼（配置）的key 內(nèi)聚性非常強，使用起來更加方便。試想一下，如果你不使用靜態(tài)內(nèi)部類去集中管理這些配置，每個配置都單獨書寫的話，像這樣：

@ConfigurationProperties(prefix = "server", ignoreUnknownFields = true)
public class ServerProperties {
}

@ConfigurationProperties(prefix = "server.tomcat", ignoreUnknownFields = true)
public class TomcatProperties {
}

@ConfigurationProperties(prefix = "server.tomcat.accesslog", ignoreUnknownFields = true)
public class AccesslogProperties {
}

這代碼，就問你，如果是你同事寫的，你罵不罵吧！用臃腫來形容還是個中意詞，層次結(jié)構(gòu)體現(xiàn)得也非常的不直觀嘛。因此，對于這種屬性類里使用靜態(tài)內(nèi)部類是非常適合，內(nèi)聚性一下子高很多~

除了在內(nèi)聚性上的作用，在Spring Boot中的@Configuration配置類下（特別常見于自動配置類）也能經(jīng)?？吹剿纳碛埃?/p>

@Configuration(proxyBeanMethods = false)
public class WebMvcAutoConfiguration {

	// web MVC個性化定制配置
	@Configuration(proxyBeanMethods = false)
	@Import(EnableWebMvcConfiguration.class)
	@EnableConfigurationProperties({ WebMvcProperties.class, ResourceProperties.class })
	@Order(0)
	public static class WebMvcAutoConfigurationAdapter implements WebMvcConfigurer {
		...
	}

	@Configuration(proxyBeanMethods = false)
	public static class EnableWebMvcConfiguration extends DelegatingWebMvcConfiguration implements ResourceLoaderAware {
		...
	}

}

利用靜態(tài)內(nèi)部類把相似配置類歸并在一個 .java文件 內(nèi)，這樣多個static類還可公用外部類的屬性、方法，也是一種高內(nèi)聚的體現(xiàn)。同時static關(guān)鍵字提升了初始化的優(yōu)先級，比如本例中的EnableWebMvcConfiguration它會優(yōu)先于外部類加載~

關(guān)于static靜態(tài)內(nèi)部類優(yōu)先級相關(guān)是重點，靜態(tài)內(nèi)部類的優(yōu)先級會更高嗎？使用普通內(nèi)部能達到同樣效果嗎？拍腦袋直接回答是沒用的，帶著這兩個問題，接下來A哥舉例領(lǐng)你一探究竟...

static靜態(tài)配置類提升配置優(yōu)先級

自己先構(gòu)造一個Demo，場景如下：

@Configuration
class OuterConfig {

 OuterConfig() {
 System.out.println("OuterConfig init...");
 }
 @Bean
 static Parent parent() {
 return new Parent();
 }

 @Configuration
 private static class InnerConfig {
 InnerConfig() {
 System.out.println("InnerConfig init...");
 }
 @Bean
 Daughter daughter() {
 return new Daughter();
 }
 }
}

測試程序：

@ComponentScan
public class TestSpring {

 public static void main(String[] args) {
 new AnnotationConfigApplicationContext(TestSpring.class);
 }
}

啟動程序，結(jié)果輸出：

InnerConfig init...
OuterConfig init...
Daughter init...
Parent init...

結(jié)果細節(jié)：似乎都是按照字母表的順序來執(zhí)行的。I在前O在后；D在前P在后；

看到這個結(jié)果，如果你就過早的得出結(jié)論：靜態(tài)內(nèi)部類優(yōu)先級高于外部類，那么就太隨意了，圖樣圖森破啊。大膽猜想，小心求證 應(yīng)該是程序員應(yīng)有的態(tài)度，那么繼續(xù)往下看，在此基礎(chǔ)上我新增加一個靜態(tài)內(nèi)部類：

@Configuration
class OuterConfig {

 OuterConfig() {
 System.out.println("OuterConfig init...");
 }
 @Bean
 static Parent parent() {
 return new Parent();
 }


 @Configuration
 private static class PInnerConfig {
 PInnerConfig() {
 System.out.println("PInnerConfig init...");
 }
 @Bean
 Son son() {
 return new Son();
 }
 }

 @Configuration
 private static class InnerConfig {
 InnerConfig() {
 System.out.println("InnerConfig init...");
 }
 @Bean
 Daughter daughter() {
 return new Daughter();
 }
 }
}

我先解釋下我這么做的意圖：

1. 增加一個字母P開頭的內(nèi)部類，自然順序P在O（外部類）后面，消除影響
2. P開頭的內(nèi)部類在源碼擺放順序上故意放在了I開頭的內(nèi)部類的上面，同樣為了消除字母表順序帶來的影響
3. 目的：看看是按照字節(jié)碼順序，還是字母表順序呢？
4. PInnerConfig里面的@Bean實例為Son，字母表順序是三者中最為靠后的，但字節(jié)碼卻在中間，這樣也能夠消除影響

運行程序，結(jié)果輸出：

InnerConfig init...
PInnerConfig init...
OuterConfig init...
Daughter init...
son init...
Parent init...

結(jié)果細節(jié)：外部類貌似總是滯后于內(nèi)部類初始化；同一類的多個內(nèi)部類之間順序是按照字母表順序（自然排序）初始化而非字節(jié)碼順序；@Bean方法的順序依照了類的順序

請留意本結(jié)果和上面結(jié)果是否有區(qū)別，你應(yīng)該若有所思。

這是單.java文件的case（所有static類都在同一個.java文件內(nèi)），接下來我在同目錄下增加 2個.java文件（請自行留意類名第一個字母，我將不再贅述我的設(shè)計意圖）：

// 文件一：
@Configuration
class A_OuterConfig {

 A_OuterConfig() {
 System.out.println("A_OuterConfig init...");
 }
 @Bean
 String a_o_bean(){
 System.out.println("A_OuterConfig a_o_bean init...");
 return new String();
 }


 @Configuration
 private static class PInnerConfig {
 PInnerConfig() {
 System.out.println("A_OuterConfig PInnerConfig init...");
 }
 @Bean
 String a_p_bean(){
 System.out.println("A_OuterConfig a_p_bean init...");
 return new String();
 }
 }

 @Configuration
 private static class InnerConfig {
 InnerConfig() {
 System.out.println("A_OuterConfig InnerConfig init...");
 }
 @Bean
 String a_i_bean(){
 System.out.println("A_OuterConfig a_i_bean init...");
 return new String();
 }
 }
}

// 文件二：
@Configuration
class Z_OuterConfig {

 Z_OuterConfig() {
 System.out.println("Z_OuterConfig init...");
 }
 @Bean
 String z_o_bean(){
 System.out.println("Z_OuterConfig z_o_bean init...");
 return new String();
 }


 @Configuration
 private static class PInnerConfig {
 PInnerConfig() {
 System.out.println("Z_OuterConfig PInnerConfig init...");
 }
 @Bean
 String z_p_bean(){
 System.out.println("Z_OuterConfig z_p_bean init...");
 return new String();
 }
 }

 @Configuration
 private static class InnerConfig {
 InnerConfig() {
 System.out.println("Z_OuterConfig InnerConfig init...");
 }
 @Bean
 String z_i_bean(){
 System.out.println("Z_OuterConfig z_i_bean init...");
 return new String();
 }
 }
}

運行程序，結(jié)果輸出：

A_OuterConfig InnerConfig init...
A_OuterConfig PInnerConfig init...
A_OuterConfig init...
InnerConfig init...
PInnerConfig init...
OuterConfig init...
Z_OuterConfig InnerConfig init...
Z_OuterConfig PInnerConfig init...
Z_OuterConfig init...

A_OuterConfig a_i_bean init...
A_OuterConfig a_p_bean init...
A_OuterConfig a_o_bean init...
Daughter init...
son init...
Parent init...
Z_OuterConfig z_i_bean init...
Z_OuterConfig z_p_bean init...
Z_OuterConfig z_o_bean init...

這個結(jié)果大而全，是有說服力的，通過這幾個示例可以總結(jié)出如下結(jié)論：

垮.java文件 （垮配置類）之間的順序，是由自然順序來保證的（字母表順序）如上：下加載A打頭的配置類（含靜態(tài)內(nèi)部類），再是O打頭的，再是Z打頭的

同一.java文件內(nèi)部，static靜態(tài)內(nèi)部類優(yōu)先于外部類初始化。若有多個靜態(tài)內(nèi)部類，那么按照類名自然排序初始化（并非按照定義順序哦，請務(wù)必注意）說明：一般內(nèi)部類只可能與外部類“發(fā)生關(guān)系”，與兄弟之間不建議有任何聯(lián)系，否則順序控制上你就得當心了。畢竟靠自然順序去保證是一種弱保證，容錯性太低

同一.java文件內(nèi)，不同類內(nèi)的@Bean方法之間的執(zhí)行順序，保持同2一致（也就說你的@Bean所在的@Configuration配置類先加載，那你就優(yōu)先被初始化嘍）同一Class內(nèi)多個@Bean方法的執(zhí)行順序，上篇文章static關(guān)鍵字真能提高Bean的優(yōu)先級嗎？答：真能 就已經(jīng)說過了哈，請移步參見

總的來說，當static標注在class類上時，在同.java文件內(nèi)它是能夠提升優(yōu)先級的，這對于Spring Boot的自動配置非常有意義，主要體現(xiàn)在如下兩個方法：

• static靜態(tài)內(nèi)部類配置優(yōu)先于外部類加載，從而靜態(tài)內(nèi)部類里面的@Bean也優(yōu)先于外部類的@Bean先加載
• 既然這樣，那么Spring Boot自動配置就可以結(jié)合此特性，就可以進行具有優(yōu)先級的@Conditional條件判斷了。

這里我舉個官方的例子，你便能感受到它的魅力所在：

@Configuration
public class FeignClientsConfiguration {
	...
	@Bean
	@Scope("prototype")
	@ConditionalOnMissingBean
	public Feign.Builder feignBuilder(Retryer retryer) {
		return Feign.builder().retryer(retryer);
	}

	@Configuration
	@ConditionalOnClass({ HystrixCommand.class, HystrixFeign.class })
	protected static class HystrixFeignConfiguration {
		@Bean
		@Scope("prototype")
		@ConditionalOnMissingBean
		@ConditionalOnProperty(name = "feign.hystrix.enabled")
		public Feign.Builder feignHystrixBuilder() {
			return HystrixFeign.builder();
		}
	}
}

因為HystrixFeign.builder()它屬于靜態(tài)內(nèi)部類，所以這個@Bean肯定是優(yōu)先于外部的Feign.builder()先加載的。所以這段邏輯可解釋為：優(yōu)先使用HystrixFeign.builder()（若條件滿足），否則使用Feign.builder().retryer(retryer)作為兜底。通過此例你應(yīng)該再一次感受到Bean的加載順序之于Spring應(yīng)用的重要性，特別在Spring Boot/Cloud下此特性尤為凸顯。

你以為記住這幾個結(jié)論就完事了？不，這明顯不符合A哥的逼格嘛，下面我們就來繼續(xù)挖一挖吧。

源碼分析

關(guān)于@Configuration配置類的順序問題，事前需強調(diào)兩點：

• 不同 .java文件 之間的加載順序是不重要的，Spring官方也強烈建議使用者不要去依賴這種順序因為無狀態(tài)性，因此你在使用過程中可以認為垮@Configuration文件之前的初始化順序是不確定的
• 同一.javaw文件內(nèi)也可能存在多個@Configuration配置類（比如靜態(tài)內(nèi)部類、普通內(nèi)部類等），它們之間的順序是我們需要關(guān)心的，并且需要強依賴于這個順序編程（比如Spring Boot）

@Configuration配置類只有是被@ComponentScan掃描進來（或者被Spring Boot自動配置加載進來）才需要討論順序（倘若是構(gòu)建上下文時自己手動指好的，那順序就已經(jīng)定死了嘛），實際開發(fā)中的配置類也確實是醬紫的，一般都是通過掃描被加載。接下來我們看看@ComponentScan是如何掃描的，把此注解的解析步驟（偽代碼）展示如下：

說明：本文并不會著重分析@ComponentScan它的解析原理，只關(guān)注本文“感興趣”部分

1、解析配置類上的@ComponentScan注解(們)：本例中TestSpring作為掃描入口，會掃描到A_OuterConfig/OuterConfig等配置類們

ConfigurationClassParser#doProcessConfigurationClass：

	// **最先判斷** 該配置類是否有成員類（普通內(nèi)部類）
	// 若存在普通內(nèi)部類，最先把普通內(nèi)部類給解析嘍（注意，不是靜態(tài)內(nèi)部類）
	if (configClass.getMetadata().isAnnotated(Component.class.getName())) {
		processMemberClasses(configClass, sourceClass);
	}
	
	...

	// 遍歷該配置類上所有的@ComponentScan注解
	// 使用ComponentScanAnnotationParser一個個解析
	for (AnnotationAttributes componentScan : componentScans) {
		Set<BeanDefinitionHolder> scannedBeanDefinitions = this.componentScanParser.parse(componentScan,...);
		
		// 繼續(xù)判斷掃描到的bd是否是配置類，遞歸調(diào)用
		... 
	}

細節(jié)說明：關(guān)于最先解析內(nèi)部類時需要特別注意，Spring通過sourceClass.getMemberClasses()來獲取內(nèi)部類們：只有普通內(nèi)部類屬于這個，static靜態(tài)內(nèi)部類并不屬于它，這點很重要哦

2、解析該注解上的basePackages/basePackageClasses等屬性值得到一些掃描的基包，委托給ClassPathBeanDefinitionScanner去完成掃描

ComponentScanAnnotationParser#parse

	// 使用ClassPathBeanDefinitionScanner掃描，基于類路徑哦
	scanner.doScan(StringUtils.toStringArray(basePackages));

3、遍歷每個基包，從文件系統(tǒng)中定位到資源，把符合條件的Spring組件（強調(diào)：這里只指外部@Configuration配置類，還沒涉及到里面的@Bean這些）注冊到BeanDefinitionRegistry注冊中心

ComponentScanAnnotationParser#doScan

	for (String basePackage : basePackages) {
		// 這個方法是本文最需要關(guān)注的方法
		Set<BeanDefinition> candidates = findCandidateComponents(basePackage);
		for (BeanDefinition candidate : candidates) {
			...
			// 把該配置**類**(并非@Bean方法)注冊到注冊中心
			registerBeanDefinition(definitionHolder, this.registry);
		}
	}

到這一步就完成了Bean定義的注冊，此處可以驗證一個結(jié)論：多個配置類之間，誰先被掃描到，就先注冊誰，對應(yīng)的就是誰最先被初始化。那么這個順序到底是咋樣界定的呢？那么就要來到這中間最為重要（本文最關(guān)心）的一步嘍：findCandidateComponents(basePackage)。

說明：Spring 5.0開始增加了@Indexed注解為云原生做了準備，可以讓scan掃描動作在編譯期就完成，但這項技術(shù)還不成熟，暫時幾乎無人使用，因此本文仍舊只關(guān)注經(jīng)典模式的實現(xiàn)

ClassPathScanningCandidateComponentProvider#scanCandidateComponents

	// 最終返回的候選組件們
	Set<BeanDefinition> candidates = new LinkedHashSet<>();


	// 得到文件系統(tǒng)的路徑，比如本例為classpath*:com/yourbatman/**/*.class
	String packageSearchPath = ResourcePatternResolver.CLASSPATH_ALL_URL_PREFIX +
					resolveBasePackage(basePackage) + '/' + this.resourcePattern;
	// 從文件系統(tǒng)去加載Resource資源文件進來
	// 這里Resource代表的是一個本地資源：存在你硬盤上的.class文件
	Resource[] resources = getResourcePatternResolver().getResources(packageSearchPath);
	for (Resource resource : resources) {
		if (isCandidateComponent(metadataReader)) {
			if (isCandidateComponent(sbd)) {
				candidates.add(sbd);
			}
		}
	}

這段代碼的信息量是很大的，分解為如下兩大步：

1.通過ResourcePatternResolver從磁盤里加載到所有的 .class資源Resource[]。這里面順序信息就出現(xiàn)了，加載磁盤Resource資源的過程很復(fù)雜，總而言之它依賴于你os文件系統(tǒng)。所以關(guān)于資源的順序可簡單理解為：你磁盤文件里是啥順序它就按啥順序加載進來

注意：不是看.java源代碼順序，也不是看你target目錄下的文件順序（該目錄是經(jīng)過了IDEA反編譯的結(jié)果，無法反應(yīng)真實順序），而是編譯后看你的磁盤上的.class文件的文件順序

2.遍歷每一個Resource資源，并不是每個資源都會成為candidates候選，它有個雙重過濾（對應(yīng)兩個isCandidateComponent()方法）：

過濾一：使用TypeFilter執(zhí)行過濾，看看是否被排除；再看看是否滿足@Conditional條件

過濾二：它有兩種case能滿足條件（任意滿足一個case即可）

• isIndependent()是獨立類（top-level類 or 靜態(tài)內(nèi)部類屬于獨立類） 并且 isConcrete()是具體的（非接口非抽象類）
• isAbstract()是抽象類 并且 類內(nèi)存在標注有@Lookup注解的方法

基于以上例子，磁盤中的.class文件情況如下：

看著這個順序，再結(jié)合上面的打印結(jié)果，是不是感覺得到了解釋呢？既然@Configuration類（外部類和內(nèi)部類）的順序確定了，那么@Bean就跟著定了嘍，因為畢竟配置類也得遍歷一個一個去執(zhí)行嘛（有依賴關(guān)系的case除外）。

特別說明：理論上不同的操作系統(tǒng)（如windows和Linux）它們的文件系統(tǒng)是有差異的，對文件存放的順序是可能不同的（比如$xxx內(nèi)部類可能放在后面），但現(xiàn)實狀況它們是一樣的，因此各位同學對此無需擔心跨平臺問題哈，這由JVM底層來給你保證。

什么，關(guān)于此解析步驟你想要張流程圖？好吧，你知道的，這個A哥會放到本專欄的總結(jié)篇里統(tǒng)一供以你白嫖，關(guān)注我公眾號吧~

靜態(tài)內(nèi)部類在容器內(nèi)的beanName是什么？

看到這個截圖你就懂了：在不同.java文件內(nèi)，靜態(tài)內(nèi)部類是不用擔心重名問題的，這不也就是內(nèi)聚性的一種體現(xiàn)麼。

說明：beanName的生成其實和你注冊Bean的方式有關(guān)，比如@Import、Scan方式是不一樣的，這里就不展開討論了，知道有這個差異就成。

進階：Spring下普通內(nèi)部類表現(xiàn)如何？

我們知道，從內(nèi)聚性上來說，普通內(nèi)部類似乎也可以達到目的。但是相較于靜態(tài)內(nèi)部類在Spring容器內(nèi)對優(yōu)先級的問題，它的表現(xiàn)可就沒這么好嘍?；谝陨侠?，把所有的static關(guān)鍵字去掉，就是本處需要的case。

reRun測試程序，結(jié)果輸出：

A_OuterConfig init...
OuterConfig init...
Z_OuterConfig init...

A_OuterConfig InnerConfig init...
A_OuterConfig a_i_bean init...
A_OuterConfig PInnerConfig init...
A_OuterConfig a_p_bean init...
A_OuterConfig a_o_bean init...

InnerConfig init...
Daughter init...
PInnerConfig init...
son init...
Parent init...

Z_OuterConfig InnerConfig init...
Z_OuterConfig z_i_bean init...
Z_OuterConfig PInnerConfig init...
Z_OuterConfig z_p_bean init...
Z_OuterConfig z_o_bean init...

對于這個結(jié)果A哥不用再做詳盡分析了，看似比較復(fù)雜其實有了上面的分析還是比較容易理解的。主要有如下兩點需要注意：

普通內(nèi)部類它不是一個獨立的類（也就是說isIndependent() = false），所以它并不能像靜態(tài)內(nèi)部類那樣預(yù)先就被掃描進去，如圖結(jié)果展示：

普通內(nèi)部類初始化之前，一定得先初始化外部類，所以類本身的優(yōu)先級是低于外部類的（不包含@Bean方法哦）普通內(nèi)部類屬于外部類的memberClasses，因此它會在解析當前外部類的第一步processMemberClasses()時被解析普通內(nèi)部類的beanName和靜態(tài)內(nèi)部類是有差異的，如下截圖：

思考題：

請思考：為何使用普通內(nèi)部類得到的是這個結(jié)果呢？建議copy我的demo，自行走一遍流程，多動手總是好的

總結(jié)

本文一如既往的很干哈。寫本文的原動力是因為真的太多小伙伴在看Spring Boot自動配置類的時候，無法理解為毛它有些@Bean配置要單獨寫在一個static靜態(tài)類里面，感覺挺費事；方法前直接價格static不香嗎？通過這篇文章 + 上篇文章的解讀，相信A哥已經(jīng)給了你答案了。

到此這篇關(guān)于static關(guān)鍵字有何魔法？竟讓Spring Boot搞出那么多靜態(tài)內(nèi)部類(推薦)的文章就介紹到這了,更多相關(guān)Spring Boot靜態(tài)內(nèi)部類內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！