static关键字有何魔法竟让Spring-Boot搞出那么多静态内部类

生命太短暂，不要去做一些基本没有人想要的货色。本文已被 https://www.yourbatman.cn 收录，外面一并有 Spring 技术栈、MyBatis、JVM、中间件等小而美的专栏供以收费学习。关注公众号【BAT 的乌托邦】一一击破，深刻把握，回绝浅尝辄止。

各位小伙伴大家好，我是 A 哥。上篇文章理解了 static 关键字 + @Bean 办法 的应用，通晓了它可能晋升 Bean 的优先级，在 @Bean 办法前标注 static 关键字，特定状况下能够防止一些烦人的“正告”日志的输入，排除隐患让工程变得更加平安。咱们晓得 static 关键字它不仅可应用在办法上，那么本文将持续开掘 static 在 Spring 环境下的用途。

依据所学的 JavaSE 根底，static 关键字除了可能润饰办法外，还能应用在这两个中央：

润饰类。确切的说，应该叫润饰 外部类，所以它叫动态外部类
润饰成员变量

其实 static 还能够润饰代码块、static 动态导包等，但很显著，这些与本文无关

接下来就以这为两条主线，别离钻研 static 在对应场景下的作用，本文将聚焦在动态外部类上。

本文内容若没做非凡阐明，均基于以下版本：

JDK：1.8
Spring Framework：5.2.2.RELEASE

说到 Java 里的 static 关键字，这当属最根底的入门常识，是 Java 中罕用的关键字之一。你平时用它来润饰变量和办法了，然而对它的理解，即便放在 JavaSE 情景下晓得这些还是 不够的，问题虽小但这往往反映了你对 Java 根底的理解水平。

当然喽，本文并不探讨它在 JavaSE 下应用，毕竟咱们还是 有肯定逼格的 专栏，须要进阶一把，玩玩它在 Spring 环境下到底可能迸出怎么样的火花呢？比方动态外部类~

static 润饰类 只有一种状况 ：那就是这个类属于外部类，这就是咱们津津有味的 动态外部类，形如这样：

public class Outer {

    private String name;
    private static Integer age;

    // 动态外部类
    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) {
        // 动态外部类的实例化并不需要依赖于外部类的实例
        Inner inner = new Inner();}
}

在理论开发中，动态外部类的应用场景是十分之多的。

因为一些小伙伴对一般外部类 vs 动态外部类傻傻分不清，为了不便后续解说，本处把 要害因素 做简要比照阐明：

动态外部类能够申明动态 or 实例成员 (属性和办法)；而一般外部类则 不能够 申明动态成员(属性和办法)
动态外部类实例的创立 不依赖于 外部类；而一般外部类实例创立必须先有外部类实例才行（绑定关系拿捏得死死的，不信你问郑凯）
动态外部类不能拜访外部类的实例成员；而一般外部类能够随便拜访(不论动态 or 非动态) –> 我了解这是一般外部类能 “存活” 下来的最大理由了吧????

总之，一般外部类和外部类的关系属于 强绑定 ，而动态外部类简直不会受到外部类的限度，能够游离 独自应用。既然如此，那为何还须要 static 动态外部类呢，间接独自写个 Class 类岂不就好了吗？存在即正当，这么应用的起因我集体感觉有如下两方面思考，供以你参考：

动态外部类是弱关系并不是没关系，比方它还是能够拜访外部类的 static 的变量的不是（即使它是 private 的）
高内聚的体现

在传统 Spirng Framework 的配置类场景下，你可能鲜有接触到 static 关键字应用在类上的场景，但这在 Spring Boot 下应用十分频繁，比方属性配置类的典型利用：

@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 内的 log 配置
        public static class Accesslog {
            
            // server.tomcat.accesslog.enabled = xxx
            private boolean enabled = false;
            ...
        }
    }    
}

这种嵌套 case 使得代码（配置）的 key 内聚性十分强 ，应用起来更加不便。试想一下，如果你 不应用 动态外部类去集中管理这些配置，每个配置都独自书写的话，像这样：

@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 {}

这代码，就问你，如果是你共事写的，你骂不骂吧！用臃肿来形容还是个中意词，层次结构体现得也十分的不直观嘛。因而，对于这种属性类里应用动态外部类是非常适合，内聚性一下子高很多~

除了在内聚性上的作用，在 Spring Boot 中的 @Configuration 配置类下（特地常见于主动配置类）也能常常看到它的身影：

@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 {...}

}

利用动态外部类把类似配置类归并在一个 .java 文件 内，这样多个 static 类还可专用外部类的属性、办法，也是一种高内聚的体现。同时 static 关键字晋升了初始化的优先级，比方本例中的 EnableWebMvcConfiguration 它会优先于外部类加载~

对于 static 动态外部类优先级相干是重点，动态外部类的优先级会更高吗？应用一般外部能达到同样成果吗？拍脑袋间接答复是没用的，带着这两个问题，接下来 A 哥举例领你一探到底 …

本人先结构一个 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);
    }
}

启动程序，后果输入：

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

后果细节：仿佛都是依照字母表的程序来执行的。I 在前 O 在后；D 在前 P 在后；

看到这个后果，如果你就过早的得出结论：动态外部类优先级高于外部类，那么就太随便了，图样图森破啊。大胆猜测，小心求证 应该是程序员应有的态度，那么持续往下看，在此基础上我新减少一个动态外部类：

@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();
        }
    }
}

我先解释下我这么做的用意：

减少一个字母 P 结尾的外部类，天然程序 P 在 O（外部类）前面，打消影响
P 结尾的外部类在源码摆放程序上成心放在了 I 结尾的外部类的下面，同样为了打消字母表程序带来的影响
1. 目标：看看是依照字节码程序，还是字母表程序呢？
PInnerConfig 外面的 @Bean 实例为 Son，字母表程序是三者中最为靠后的，但字节码却在两头，这样也可能打消影响

运行程序，后果输入：

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

后果细节：外部类貌似总是滞后于外部类初始化；同一类的多个外部类之间程序是依照字母表程序（天然排序）初始化而非字节码程序；@Bean 办法的程序按照了类的程序

请注意本后果和下面后果是否有区别，你应该若有所思。

这是单.java 文件的 case（所有 static 类都在同一个.java 文件内），接下来我在同目录下减少 2 个.java 文件（请自行注意类名第一个字母，我将不再赘述我的设计用意）：

// 文件一：@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();}
    }
}

运行程序，后果输入：

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...

这个后果大而全，是有说服力的，通过这几个示例能够总结出如下论断：

垮.java 文件（垮配置类）之间的程序，是由天然程序来保障的（字母表程序）
1. 如上：下加载 A 打头的配置类（含动态外部类），再是 O 打头的，再是 Z 打头的
同一.java 文件外部 ，static 动态外部类 优先于 外部类初始化。若有多个动态外部类，那么依照类名天然排序初始化（并非依照定义程序哦，请务必留神）
1. 阐明：个别外部类只可能与外部类“产生关系”，与兄弟之间不倡议有任何分割，否则顺序控制上你就得当心了。毕竟靠天然程序去保障是一种弱保障，容错性太低
同一.java 文件内，不同类内的 @Bean 办法之间的执行程序，放弃同 2 统一（也就说你的 @Bean 所在的 @Configuration 配置类先加载，那你就优先被初始化喽）
1. 同一 Class 内多个 @Bean 办法的执行程序，上篇文章 static 关键字真能进步 Bean 的优先级吗？答：真能就曾经说过了哈，请移步参见

总的来说，当 static 标注在 class 类上时，在 同.java 文件内 它是可能晋升优先级的，这对于 Spring Boot 的主动配置十分有意义，次要体现在如下两个办法：

static 动态外部类配置优先于外部类加载，从而动态外部类外面的 @Bean 也 优先于 外部类的 @Bean 先加载
既然这样，那么 Spring Boot 主动配置就能够联合此个性，就能够进行具备优先级的 @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() 它属于动态外部类，所以这个 @Bean 必定是优先于内部的 Feign.builder() 先加载的。所以这段逻辑可解释为：优先应用 HystrixFeign.builder()（若条件满足），否则应用Feign.builder().retryer(retryer) 作为兜底。通过此例你应该再一次感触到Bean 的加载程序之于 Spring 利用的重要性，特地在 Spring Boot/Cloud 下此个性尤为凸显。

你认为记住这几个论断就完事了？不，这显著不合乎 A 哥的逼格嘛，上面咱们就来持续挖一挖吧。

对于 @Configuration 配置类的程序问题，事先需强调两点：

不同 .java 文件 之间的加载程序是不重要的，Spring 官网也强烈建议使用者不要去依赖这种程序
1. 因为无状态性，因而你在应用过程中能够认为垮 @Configuration 文件之前的初始化程序 是不确定的
同一.javaw 文件 内也可能存在多个 @Configuration 配置类（比方动态外部类、一般外部类等），它们之间的程序是咱们 须要关怀 的，并且须要强依赖于这个程序编程（比方 Spring Boot）

@Configuration配置类只有是被 @ComponentScan 扫描进来（或者被 Spring Boot 主动配置加载进来）才须要探讨程序（假使是构建上下文时本人手动指好的，那程序就曾经定死了嘛），理论开发中的配置类也的确是酱紫的，个别都是通过扫描被加载。接下来咱们看看 @ComponentScan 是如何扫描的，把此注解的解析步骤（伪代码）展现如下：

阐明：本文并不会着重剖析 @ComponentScan 它的解析原理，只关注本文“感兴趣”局部

1、解析配置类上的 @ComponentScan 注解 (们)：本例中TestSpring 作为扫描入口，会扫描到 A_OuterConfig/OuterConfig 等配置类们

ConfigurationClassParser#doProcessConfigurationClass：// ** 最先判断 ** 该配置类是否有成员类（一般外部类）// 若存在一般外部类，最先把一般外部类给解析喽（留神，不是动态外部类）if (configClass.getMetadata().isAnnotated(Component.class.getName())) {processMemberClasses(configClass, sourceClass);
    }
    
    ...

    // 遍历该配置类上所有的 @ComponentScan 注解
    // 应用 ComponentScanAnnotationParser 一个个解析
    for (AnnotationAttributes componentScan : componentScans) {Set<BeanDefinitionHolder> scannedBeanDefinitions = this.componentScanParser.parse(componentScan,...);
        
        // 持续判断扫描到的 bd 是否是配置类，递归调用
        ... 
    }

细节阐明：对于最先解析外部类时须要特地留神，Spring 通过 sourceClass.getMemberClasses() 来获取外部类们：只有一般外部类属于这个，static 动态外部类 并不属于 它，这点很重要哦

2、解析该注解上的 basePackages/basePackageClasses 等属性值得到一些扫描的基包，委托给 ClassPathBeanDefinitionScanner 去实现扫描

ComponentScanAnnotationParser#parse

    // 应用 ClassPathBeanDefinitionScanner 扫描，基于类门路哦
    scanner.doScan(StringUtils.toStringArray(basePackages));

3、遍历 每个基包，从文件系统中定位到资源，把符合条件的Spring 组件（强调：这里只指内部 @Configuration 配置类，还没波及到外面的 @Bean 这些）注册到 BeanDefinitionRegistry 注册核心

ComponentScanAnnotationParser#doScan

    for (String basePackage : basePackages) {
        // 这个办法是本文最须要关注的办法
        Set<BeanDefinition> candidates = findCandidateComponents(basePackage);
        for (BeanDefinition candidate : candidates) {
            ...
            // 把该配置 ** 类 **(并非 @Bean 办法)注册到注册核心
            registerBeanDefinition(definitionHolder, this.registry);
        }
    }

到这一步就实现了 Bean 定义的注册，此处能够验证一个论断：多个配置类之间，谁先被扫描到，就先注册谁，对应的就是谁最先被初始化 。那么这个程序到底是咋样界定的呢？那么就要来到这两头 最为重要（本文最关怀）的一步喽：findCandidateComponents(basePackage)。

阐明：Spring 5.0 开始减少了 @Indexed 注解为云原生做了筹备，能够让 scan 扫描动作在编译期就实现，但这项技术还不成熟，临时简直无人应用，因而本文仍旧只关注经典模式的实现

ClassPathScanningCandidateComponentProvider#scanCandidateComponents

    // 最终返回的候选组件们
    Set<BeanDefinition> candidates = new LinkedHashSet<>();


    // 失去文件系统的门路，比方本例为 classpath*:com/yourbatman/**/*.class
    String packageSearchPath = ResourcePatternResolver.CLASSPATH_ALL_URL_PREFIX +
                    resolveBasePackage(basePackage) + '/' + this.resourcePattern;
    // 从文件系统去加载 Resource 资源文件进来
    // 这里 Resource 代表的是一个本地资源：存在你硬盘上的.class 文件
    Resource[] resources = getResourcePatternResolver().getResources(packageSearchPath);
    for (Resource resource : resources) {if (isCandidateComponent(metadataReader)) {if (isCandidateComponent(sbd)) {candidates.add(sbd);
            }
        }
    }

这段代码的信息量是很大的，合成为如下两大步：

通过 ResourcePatternResolver 从磁盘里加载到 所有的 .class 资源 Resource[]。这外面 程序信息 就呈现了，加载磁盘 Resource 资源的过程很简单，总而言之它依赖于你 os 文件系统。所以对于资源的程序可简略了解为：你磁盘文件里是啥程序它就按啥程序加载进来

留神：不是看.java 源代码程序，也不是看你 target 目录下的文件程序（该目录是通过了 IDEA 反编译的后果，无奈反馈实在程序），而是编译后看你的 磁盘上的.class 文件的文件程序

遍历每一个 Resource 资源，并不是每个资源都会成为 candidates 候选，它有个 双重过滤 （对应两个 isCandidateComponent() 办法）：
1. 过滤一：应用 TypeFilter 执行过滤，看看是否被排除；再看看是否满足 @Conditional 条件
2. 过滤二：它有两种 case 能满足条件（任意满足一个 case 即可）
  1. isIndependent()是独立类（top-level 类 or 动态外部类属于独立类）并且 isConcrete() 是具体的（非接口非抽象类）
  2. isAbstract()是抽象类并且类内存在标注有@Lookup 注解的办法

基于以上例子，磁盘中的.class 文件状况如下：

看着这个程序，再联合下面的打印后果，是不是感觉得到了解释呢？既然 @Configuration 类（外部类和外部类）的程序确定了，那么 @Bean 就跟着定了喽，因为毕竟配置类也得遍历一个一个去执行嘛（有依赖关系的 case 除外）。

特地阐明：实践上不同的操作系统（如 windows 和 Linux）它们的文件系统是有差别的，对文件寄存的程序是可能不同的（比方 $xxx 外部类可能放在前面），但 现实状况 它们是一样的，因而各位同学对此无需放心跨平台问题哈，这由 JVM 底层来给你保障。

什么，对于此解析步骤你想要张流程图？好吧，你晓得的，这个 A 哥会放到本专栏的 总结篇 里对立供以你白嫖，关注我公众号吧~

看到这个截图你就懂了：在不同.java 文件内，动态外部类是不必放心重名问题的，这不也就是内聚性的一种体现麽。

阐明：beanName 的生成其实和你注册 Bean 的形式无关，比方 @Import、Scan 形式是不一样的，这里就不展开讨论了，晓得有这个差别就成。

咱们晓得，从内聚性上来说，一般外部类仿佛也能够达到目标。然而相较于动态外部类在 Spring 容器内对优先级的问题，它的体现可就没这么好喽。基于以上例子，把所有的 static 关键字去掉，就是本处须要的 case。

reRun 测试程序，后果输入：

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...

对于这个后果 A 哥不必再做详尽剖析了，看似比较复杂其实有了下面的剖析还是比拟容易了解的。次要有如下两点须要留神：

一般外部类它不是一个独立的类（也就是说 isIndependent() = false），所以它并不能像动态外部类那样事后就被 扫描进去，如图后果展现：

一般外部类初始化之前，肯定得先初始化外部类，所以类自身的优先级是低于外部类的（不蕴含 @Bean 办法哦）
一般外部类属于外部类的 memberClasses，因而它会在解析 以后外部类 的第一步 processMemberClasses() 时被解析
一般外部类的 beanName 和动态外部类是有差别的，如下截图：

请思考：为何应用一般外部类失去的是这个后果呢？倡议 copy 我的 demo，自行走一遍流程，多入手总是好的

本文判若两人的很干哈。写本文的 原动力 是因为真的太多小伙伴在看 Spring Boot 主动配置类的时候，无奈了解为毛它有些 @Bean 配置要独自写在一个 static 动态类 外面，感觉挺麻烦；办法前间接价格 static 不香吗？通过 这篇文章 + 上篇文章 的解读，置信 A 哥曾经给了你答案了。

static 关键字在 Spring 中应用的这个专栏，下篇将进入到可能是你 更关怀 的一个话题：为毛 static 字段不能应用 @Autowired 注入的剖析，下篇见~

Author	A 哥(YourBatman)
集体站点	www.yourbatman.cn
E-mail	yourbatman@qq.com
微信	fsx641385712
`沉闷平台`
公众号	BAT 的乌托邦（ID：BAT-utopia）
常识星球	BAT 的乌托邦
每日文章举荐	每日文章举荐

static关键字有何魔法竟让Spring-Boot搞出那么多静态内部类

前言

版本约定

注释

Spring 下的动态外部类

意识动态 / 一般外部类

static 动态配置类晋升配置优先级

源码剖析

动态外部类在容器内的 beanName 是什么？

进阶：Spring 下一般外部类体现如何？

思考题：

总结

关注 A 哥