生命太短暂，不要去做一些根本没有人想要的东西。本文已被 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环境下到底能够迸出怎么样的火花呢？比如静态内部类~

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哥举例领你一探究竟...

static静态配置类提升配置优先级

自己先构造一个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哥会放到本专栏的总结篇里统一供以你白嫖，关注我公众号吧~

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

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

说明：beanName的生成其实和你注册Bean的方式有关，比如@Import、Scan方式是不一样的，这里就不展开讨论了，知道有这个差异就成。

进阶：Spring下普通内部类表现如何？

我们知道，从内聚性上来说，普通内部类似乎也可以达到目的。但是相较于静态内部类在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注入的分析，下篇见~

关注A哥

Author	A哥(YourBatman)
个人站点	www.yourbatman.cn
E-mail	yourbatman@qq.com
微信	fsx641385712
`活跃平台`
公众号	BAT的乌托邦（ID：BAT-utopia）
知识星球	BAT的乌托邦
每日文章推荐	每日文章推荐

BAT的乌托邦

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

前言

版本约定

正文

Spring下的静态内部类

认识静态/普通内部类

static静态配置类提升配置优先级

源码分析

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

进阶：Spring下普通内部类表现如何？

思考题：

总结

关注A哥

热门文章

最新文章

相关课程

相关电子书

相关实验场景

热门

活动广场

任务中心

开发者评测

高校计划

乘风者计划

训练营

阿里云MVP

话题

直播

下载

镜像站

技术资料

插件

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

前言

版本约定

正文

Spring下的静态内部类

认识静态/普通内部类

static静态配置类提升配置优先级

源码分析

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

进阶：Spring下普通内部类表现如何？

思考题：

总结

关注A哥

热门文章

最新文章

相关课程

相关电子书

相关实验场景