生命太短暂，不要去做一些根本没有人想要的东西。本文已被 https://ponent()方法）：

过滤一：使用TypeFilter执行过滤，看看是否被排除；再看看是否满足@Conditional条件

过滤二：它有两种case能满足条件（任意满足一个case即可）

• isIndependent()是独立类（top-level类 or 静态内部类属于独立类） 并且 isConcrete()是具体的（非接口非抽象类）
• 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 Boot搞出那么多静态内部类(推荐)的文章就介绍到这了,更多相关Spring Boot静态内部类内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持！