1. 先把三件事串成一条线工厂类、Bean生命周期与注解配置的内在关系做Spring开发这么多年我发现一个特别有意思的现象很多同学能熟练用Component、Autowired、Configuration项目也能正常跑起来但一旦遇到循环依赖报错、Bean被创建了两次、Value注入不生效这类问题就完全没了排查思路。原因很简单——你只学会了注解怎么写没搞懂注解背后的执行引擎。Spring的整个IoC容器本质上就干三件事解析配置、按规则造对象、管理对象的全过程。这三件事正好对应标题里的三个关键词注解配置负责描述规则工厂类负责按规则造对象Bean生命周期负责对象从出生到消亡的全程管理。它们不是三个独立的知识点而是一条流水线上的三个环节。拿一个最普通的Autowired注入举例容器启动时Spring先扫描你标了注解的类把它们的信息封装成BeanDefinition配置环节接着通过BeanFactory这个工厂去创建对象但在创建过程中会经过一系列扩展点工厂环节对象创建完成后Spring还要负责属性填充、初始化回调、代理包装甚至当容器关闭时还要触发销毁方法生命周期环节。任何一环出了问题整个应用就起不来。这篇文章我不打算写成一章一节的教科书式讲解而是按照流水线的顺序往下走先讲工厂类为什么是容器的心脏再顺着Bean的完整生命周期把每个钩子过一遍最后解释注解配置是怎么变成实实在在的BeanDefinition的。每一部分都会配代码和踩坑记录希望能帮你在脑海里建立起Spring的完整执行模型——有了这个模型面试和排故障都会轻松很多。2. 工厂类不只是newBeanFactory与FactoryBean的职责边界2.1 BeanFactory是容器而非工厂很多初学者会把BeanFactory理解成创建Bean的工厂类这个理解不能说错但容易把后面的机制绕晕。准确地说BeanFactory是容器的最顶层接口它的核心职责是管理Bean包括获取、查找、判断类型、判断是否单例这些操作。真正负责创建动作的是它内部实现的getBean方法——但这个方法背后调用的又是由一系列策略组件比如InstantiationStrategy、BeanPostProcessor协作完成的。从这个角度理解BeanFactory更像是一个对象托管中心而不是一个简单的new工厂。举个例子ApplicationContext context new AnnotationConfigApplicationContext(AppConfig.class); UserService userService context.getBean(UserService.class);这里的contextApplicationContext底层就持有一个DefaultListableBeanFactory。你调用getBean它先去单例池里找有没有现成的没有才会走创建流程。这种设计最大的好处是调用方完全不需要关心对象是怎么创建出来的只需要知道我给它一个类型/名字它给我一个可用的实例。这也正是控制反转的本质——创建对象的控制权从业务代码转移到了容器。2.2 FactoryBean当Bean本身就是一个工厂时BeanFactory是容器FactoryBean是容器里可以被管理的一个特殊Bean。这个区别很绕但特别重要。FactoryBean的定位是当某个对象的创建逻辑过于复杂不适合用普通的构造器属性填充来表达时你给它做一个专门的工厂。我记得自己第一次真正理解FactoryBean是在看MyBatis的源码时。MyBatis-Spring里的SqlSessionFactoryBean就是一个典型的FactoryBean实现。正常情况下你写一个Bean需要指定class然后容器负责实例化但SqlSessionFactoryBean需要读取数据源、解析XML映射文件、配置插件等一系列复杂步骤这些逻辑如果全塞给容器去猜容器根本做不到。于是MyBatis框架提供SqlSessionFactoryBean实现FactoryBean接口容器只负责创建SqlSessionFactoryBean本身这个很简单就是new一下然后调用它的getObject()方法返回真正的SqlSessionFactory对象。用代码来体现一下FactoryBean的定义方式Component public class MySpecialBeanFactory implements FactoryBeanSpecialBean { Override public SpecialBean getObject() throws Exception { // 这里可以做复杂的构造逻辑比如读取远程配置 SpecialBean bean new SpecialBean(); bean.setConfig(loadRemoteConfig()); bean.init(); return bean; } Override public Class? getObjectType() { return SpecialBean.class; } Override public boolean isSingleton() { return true; } }需要注意一个容易混淆的点当你通过容器getBean(mySpecialBeanFactory)时拿到的不是SpecialBeanFactory实例而是它getObject()返回的SpecialBean。要想拿到工厂本身必须用前缀getBean(mySpecialBeanFactory)。这个细节我在实际项目里见过不止一次有人在这上面翻车——注入半天发现类型对不上就是因为没搞清楚容器里注册的到底是工厂还是工厂的产品。2.3 三种实例化方式的对比与取舍在Spring里Bean的实例化方式大致可以归纳为三类构造器实例化、静态工厂方法实例化、实例工厂方法实例化。加上FactoryBean常被拿来对比的就有四种。我整理了一张对比表实例化方式配置写法使用场景注意事项构造器实例化bean classcom.example.User/或直接Component大多数常规业务Bean私有构造器会导致实例化失败静态工厂方法bean classExampleFactory factory-methodcreateInstance/工具类、历史遗留的静态工厂代码工厂方法必须为static且返回类型匹配实例工厂方法bean factory-beanfactory factory-methodgetInstance/需要先有工厂对象再产出产品工厂本身也得注册为BeanFactoryBean实现FactoryBean接口复杂对象、第三方集成、代理生成注意前缀取工厂本身从实践角度来看现在用纯注解开发时90%的Bean都是构造器实例化——Spring会自动推断构造函数如果有多个构造函数需要配合Autowired指定。静态工厂和实例工厂在SpringBoot的自动配置里偶尔会出现比如一些第三方Starter会用工厂方法模式注册组件但业务代码里基本用不上。我个人的观点是FactoryBean是这几个方案中最值得花时间去学的因为它代表了一种延迟复杂创建逻辑的封装思想。框架层的很多魔法都是基于它实现的比如Ribbon的LoadBalancer、Feign的FeignClientFactoryBean。理解透FactoryBean后面看SpringCloud的源码会顺畅很多。3. Bean生命周期全链路从BeanDefinition到销毁钩子3.1 实例化Instantiation与初始化Initialization不是一回事说到生命周期我最常纠正新人的一个误解是实例化和初始化是两个阶段之间还隔着一个极其重要的属性填充阶段。实例化只是调用构造函数把对象new出来此时对象里的依赖字段全是null处于还没准备好的状态属性填充Populate才会把Autowired、Resource、Value这些依赖注入进去初始化才是执行InitializingBean回调、PostConstruct、init-method这些定制逻辑。顺序大概是这样的BeanDefinition解析 - 实例化前回调InstantiationAwareBeanPostProcessor.postProcessBeforeInstantiation - 构造器实例化 - 实例化后回调postProcessAfterInstantiation - 属性填充Autowired、Resource、Value等 - Aware回调BeanNameAware、BeanFactoryAware等 - BeanPostProcessor.postProcessBeforeInitialization - InitializingBean.afterPropertiesSet / PostConstruct / init-method - BeanPostProcessor.postProcessAfterInitialization - 放入单例池Bean已就绪这里有几个细节很关键。第一个是Aware回调的位置它在属性填充之后、初始化之前执行。也就是说你写了一个BeanNameAware接口重写setBeanName()时这个Bean的依赖已经注入完成了你可以在setBeanName里放心使用这些依赖。第二个是init-method的执行顺序它和InitializingBean、PostConstruct的先后关系PostConstruct最先、InitializingBean其次、init-method最后。如果在同一个Bean里同时用了这三种初始化方式执行顺序就是这个顺序。3.2 三级缓存与循环依赖生命周期中最烧脑的一环谈到Bean生命周期绕不开循环依赖和三级缓存。很多面试题喜欢问Spring怎么解决循环依赖但实际工作中更重要的是理解为什么三级缓存能解决循环依赖以及哪些情况下解决不了。三级缓存指的是三个Map// 一级缓存存放完整可用的单例Bean MapString, Object singletonObjects new HashMap(); // 二级缓存存放早期暴露的原始对象引用还没完成属性填充或初始化 MapString, Object earlySingletonObjects new HashMap(); // 三级缓存存放ObjectFactory用于在需要时生成代理对象 MapString, ObjectFactory? singletonFactories new HashMap();循环依赖的场景是A依赖BB依赖A。单例模式下Spring先创建A发现A需要注入B于是去创建BB创建时发现它需要注入A但A还没创建完——这时候如果直接报错就完蛋了。Spring的做法是A在实例化之后、属性填充之前就把自己的一个ObjectFactory放进三级缓存。这个ObjectFactory的能力是返回A的早期引用必要时生成代理。B注入A时从三级缓存拿到早期引用完成自己的创建A接着从B那里拿到完整对象最终完成创建。但这里有一个大坑构造器注入的循环依赖无法解决。原因很好理解三级缓存暴露的是实例化之后的对象引用如果A是通过构造器注入B的那么A在构造阶段就需要B而此时A还没有完成实例化根本没机会放入三级缓存。同理Async注解创建的代理对象也有类似的问题因为代理生成被延后了。我记得之前线上出过一次故障:两个Service通过构造器互相依赖SpringBoot 2.6直接把循环依赖禁止了项目启动直接报错。当时排查半天才反应过来——SpringBoot 2.6版本开始默认禁止循环依赖spring.main.allow-circular-referencesfalse如果你的代码里历史遗留下了循环依赖升级SpringBoot后必须显式开启这个配置或者赶紧重构掉。3.3 一个能打印全过程的演示Bean理论讲多了容易飘我写了一个简单的胖Bean把生命周期里的所有阶段全打印出来照着跑一遍就能对生命周期有直观感受Component public class LifecycleDemoBean implements InitializingBean, BeanNameAware, BeanFactoryAware { private String name; Autowired private AnotherBean anotherBean; public LifecycleDemoBean() { System.out.println(1. 构造函数执行实例化); } Autowired public void setName(String name) { System.out.println(2. 属性填充-方法注入setName); this.name name; } PostConstruct public void postConstruct() { System.out.println(4. PostConstruct执行); } Override public void setBeanFactory(BeanFactory beanFactory) throws BeansException { System.out.println(3. Aware回调BeanFactoryAware); } Override public void setBeanName(String name) { System.out.println(3. Aware回调BeanNameAware); } Override public void afterPropertiesSet() throws Exception { System.out.println(5. InitializingBean.afterPropertiesSet执行); } PreDestroy public void preDestroy() { System.out.println(销毁阶段PreDestroy执行); } }同时注册一个BeanPostProcessor来观察前后置处理Component public class MyBeanPostProcessor implements BeanPostProcessor { Override public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException { System.out.println(BeanPostProcessor.beforeInitialization beanName); return bean; } Override public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException { System.out.println(BeanPostProcessor.afterInitialization beanName); return bean; } }跑这个Demo时你会发现打印顺序中构造函数和属性填充并不是紧挨着的中间可能有其他Bean的创建过程穿插。这种穿插正是容器管理复杂性的体现——Spring不是一个个Bean单独走完流程而是按依赖关系递归创建因此日志顺序一片混乱很正常。真正想看单个Bean的生命周期建议给目标Bean单独打断点看调用栈。4. 注解配置的底层逻辑Configuration与ComponentScan只是入口4.1 ConfigurationClassPostProcessor注解配置的总开关你有没有想过这样一个问题Configuration作用于类上的时候Spring是怎么知道要去解析它的我用一个例子来说明——ComponentScan里配置了扫描包路径但Spring为什么要去解析ComponentScan这个注解本身答案是ConfigurationClassPostProcessor一个BeanDefinitionRegistryPostProcessor。它的优先级在所有BeanPostProcessor之前容器启动时最先执行。它会扫描容器里所有的配置类包括用Configuration标注的类然后做两件事解析ComponentScan、解析Bean方法。我这里有一个实际调试经历某次项目里所有Autowired注入全部失败报错说找不到Bean。查了半天发现是配置类写成了Component而不是Configuration而且没有显式加ComponentScan。因为Component标注的类虽然也能被扫描到但它的子类不会经过ConfigurationClassPostProcessor的完整链路处理很多针对配置类的增强逻辑就丢失了。换句话说Configuration不只是个语义标记它决定了你的配置类能不能被CGLIB代理增强。4.2 Bean方法之间的调用为什么同一个实例会被拦截在Configuration类里你可能会这样写Configuration public class AppConfig { Bean public ServiceA serviceA() { return new ServiceA(serviceB()); } Bean public ServiceB serviceB() { return new ServiceB(); } }你想当然地以为serviceA()内部调用serviceB()会直接调用方法new一个ServiceB出来如果这样每次调用serviceB()都会创建新实例但Spring容器里serviceB这个Bean是单例。那serviceA里到底注入了哪个实例答案藏在CGLIB代理里。Configuration类默认会被CGLIB动态代理当你调用serviceB()方法时代理会拦截这个方法检查容器里是否已经有serviceB这个Bean有就直接从单例池返回不会再执行方法体。这就是为什么Configuration下的Bean方法互相调用能保证拿到同一实例。但如果你把Configuration替换成Component或Configuration(proxyBeanMethods false)CGLIB代理就失效了serviceB()会真正执行方法体产生一个spring容器之外的全新实例。这种模式叫Lite模式。SpringBoot自动配置里大量使用lite模式提升启动速度但代价就是Bean方法之间的依赖不能靠方法调用维护。遇到这种情况最稳的写法是方法参数里声明依赖Bean public ServiceA serviceA(ServiceB serviceB) { return new ServiceA(serviceB); }这样的写法无论配置类是Full模式还是Lite模式都能正确拿到容器里注册的ServiceB实例。这个经验是我在优化项目启动时间时积累下来的——把大配置类全部改成proxyBeanMethodsfalse之后启动快了不少但顺带引入了好几个方法调用级别的Bug。4.3 Import、Conditional与自动配置的联动注解配置除了ComponentScan和Bean还有几个隐藏入口值得注意。比如Import可以在配置类里快速引入其他配置类或普通类到容器Conditional系列可以按条件判断要不要注入某个Bean。在SpringBoot生态里自动配置起始就是AutoConfigurationImportSelector通过Import方式引入的它根据classpath里有没有对应的类来决定创建哪些Bean。这正是工厂类和注解配置联动的高光时刻——配置类负责声明什么样的条件成立时创建什么样的Bean工厂负责按声明去生产。我建议有时间可以把SpringBoot的spring.factories机制和ConditionalOnClass、ConditionalOnMissingBean这些注解逐一过一遍。这些东西初看只是条件开关本质上是把工厂策略模式搬到了注解层面让创建谁、不创建谁可以由外部条件动态决定。理解了这层看那些第三方Starter的源码就很有条理了。5. 实战视角怎么用生命周期钩子做正经事5.1 根据生命周期阶段修改Bean属性网上搜根据Bean的生命周期修改属性值这个需求的人不少其实Spring提供了非常清晰的切入点。如果你需要在初始化之前修改Bean的某个属性那就实现BeanPostProcessor在postProcessBeforeInitialization里做修改。举一个我在项目里的真实案例微服务里每个服务都要往Redis写一个注册信息注册信息的key包含当前应用名和实例ID。代码里不想让每个Service都自己去拿实例ID所以我搞了一个统一的BeanPostProcessor凡是实现了某个自定义接口的Bean自动注入实例ID属性public interface InstanceAware { void setInstanceId(String instanceId); } Component public class InstanceIdInjector implements BeanPostProcessor { Override public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException { if (bean instanceof InstanceAware) { String instanceId generateInstanceId(); ((InstanceAware) bean).setInstanceId(instanceId); } return bean; } }这样的好处是业务代码完全不用感知实例ID从哪来只负责实现InstanceAware接口接收值。而且这个修改发生在属性填充之后、业务初始化之前所以在PostConstruct里就能直接用注入好的实例ID。需要注意的一点是在postProcessBeforeInitialization里修改属性前提是这个属性在属性填充阶段没有被覆盖。如果你同时用了Value给这个字段赋值那么赋值发生在属性填充阶段早于BeanPostProcessor此时后者的修改会覆盖Value的值这个先后顺序要心里有数。5.2 用BeanPostProcessor做AOP的入口理解Spring的AOP实现核心其实就藏在BeanPostProcessor里。AnnotationAwareAspectJAutoProxyCreator就是一个BeanPostProcessor它的postProcessAfterInitialization阶段检查这个Bean需不需要被代理如果需要就生成一个代理对象替换原来的Bean。顺着这个逻辑回头看为什么Transactional事务注解有时候失效原因之一是你的Bean被代理了但你调用事务方法时是通过this调用而不是通过代理调用——事务切面压根没机会拦截。这和循环依赖里三级缓存为什么要暴露ObjectFactory也有关系如果Bean已经被代理了早期暴露的引用Earl要是不经过三级缓存适配所有依赖它的Bean拿到的都是普通原始对象代理就白做了。我的体会是当你理解BeanPostProcessor是所有自动增强机制的共同底座后Spring里大量为什么这里要这样设计的疑问都会消散。它就像一个流水线上的固定工位每个经过的Bean都得在这个工位安检一遍然后决定是放行、篡改、还是换个替身。5.3 自定义一个生命周期日志切面工程上还有一种非常常见的需求监控Bean初始化耗时。在Bean密集、启动时间敏感的场景下排查哪个Bean创建最慢可以自己挂一个BeanPostProcessor来计时Component public class BeanInitTimeMonitor implements BeanPostProcessor { private final MapString, Long initTimeMap new ConcurrentHashMap(); Override public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException { initTimeMap.put(beanName, System.currentTimeMillis()); return bean; } Override public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException { Long start initTimeMap.get(beanName); if (start ! null) { long cost System.currentTimeMillis() - start; if (cost 200) { System.out.println(慢初始化Bean: beanName 耗时 cost ms); } } return bean; } }这个监控实现非常简单但实际使用起来效果很好。我第一次用在生产环境里立刻就揪出了一个初始化耗时超过2秒的Bean——它在一个PostConstruct里同步拉取远程配置导致整个应用启动时间被拉长。虽然直接用Actuator也能看到部分信息但这么搞非常直观可以精确到每个Bean。6. 后置处理器和Bean工厂共同构建的扩展基石6.1 手写一段简化版BeanFactory感受Spring的设计我一直认为学Spring源码最有效的路径之一是手写一个简化版。下面这段代码实现了最基本的按名字获取单例Bean的流程虽然只有三十来行但已经把三级缓存的核心思想体现了一部分public class MySimplifiedBeanFactory { private final MapString, Object singletonObjects new ConcurrentHashMap(); private final MapString, BeanDefinition beanDefinitionMap new ConcurrentHashMap(); private final ListBeanPostProcessor postProcessors new ArrayList(); public void registerBeanDefinition(String beanName, BeanDefinition definition) { beanDefinitionMap.put(beanName, definition); } public void registerPostProcessor(BeanPostProcessor processor) { postProcessors.add(processor); } public Object getBean(String beanName) { Object singleton singletonObjects.get(beanName); if (singleton ! null) { return singleton; } BeanDefinition definition beanDefinitionMap.get(beanName); if (definition null) { throw new RuntimeException(No bean named beanName); } singleton createBean(beanName, definition); singletonObjects.put(beanName, singleton); return singleton; } private Object createBean(String beanName, BeanDefinition definition) { // 1. 实例化这里简化成通过反射创建 Object bean instantiate(definition); // 2. 属性填充这里简化成按属性名赋值 populate(bean, definition); // 3. 初始化前后置处理 for (BeanPostProcessor processor : postProcessors) { bean processor.postProcessBeforeInitialization(bean, beanName); } // 4. 初始化回调这里省略具体实现 for (BeanPostProcessor processor : postProcessors) { bean processor.postProcessAfterInitialization(bean, beanName); } return bean; } }不考虑代理、循环依赖、作用域这些复杂情况这个简易工厂把最核心的模板方法流程做出来了。Spring真正的DefaultSingletonBeanRegistry里getSingleton的代码复杂得多但主干就是这么几件事。我自己在写这个简化版的过程中对这个模板的理解比看十篇源码解析都深。6.2 为什么建议多看几个BeanPostProcessor的实现Spring内置了大量的BeanPostProcessor实现每一类背后都对应一个功能点BeanPostProcessor实现类负责的功能触发的时机AutowiredAnnotationBeanPostProcessorAutowired、Value注入解析属性填充阶段CommonAnnotationBeanPostProcessorResource、PostConstruct、PreDestroy属性填充/初始化/销毁AnnotationAwareAspectJAutoProxyCreatorAOP代理生成初始化后阶段ScheduledAnnotationBeanPostProcessorScheduled定时任务注册初始化后阶段ApplicationListenerDetector识别ApplicationListener并注册初始化后阶段带着这张表去看Spring源码你会发现所有功能都被安装到了生命周期流水线的特定工位上。比如定时任务为什么在Bean初始化完成后才能生效因为ScheduledAnnotationBeanPostProcessor在postProcessAfterInitialization里拿到的是已经完成所有准备工作的Bean这时候解析Scheduled才安全。这种设计思路对普通人做架构也是很有启发的。我们做自己的框架时同样可以预留几个工位——定义一系列类似BeanPostProcessor的Spare接口让用户可以在对象创建的各个阶段插入自定义逻辑这是Spring扩展性的核心魔法也是它能统治Java生态这么多年的重要原因之一。7. 容易被忽略的Bean生命周期细节与排错经验7.1 各种初始化方式的优先级与混用实际项目中一个Bean里同时出现PostConstruct、InitializingBean和init-method的情况不算少见。执行顺序前面提过PostConstruct - afterPropertiesSet - init-method。这个顺序有一个现实影响如果你想在Bean初始化最早期放一些标记或统计逻辑PostConstruct是最合适的如果想确保它发生在所有自定义初始化之后init-method最靠后。我遇到过的一个真实问题某个Bean在PostConstruct里去查数据库结果报出空指针。排查半天发现数据源实例是在afterPropertiesSet里初始化的而afterPropertiesSet晚于PostConstruct所以查数据库时连接池还没建好。后来把数据库初始化移到了PostConstruct之前问题才解决。这提醒我们多阶段初始化虽然灵活但也意味着你必须清楚每段逻辑应该放在哪一层否则很容易出现初始化顺序导致的依赖失败。7.2 单例与原型作用域下生命周期执行的差异Bean实际创建次数和生命周期钩子的执行次数取决于scope。默认singleton模式下每个Bean只创建一次所有钩子也只执行一次prototype模式下每次getBean都会创建新实例并且容器关闭时不会调用销毁回调。这个差异的实际影响是如果你在单例Bean里注入了一个prototype Bean比如直接Autowired那注入的实际是一个固定实例那个Bean的生命周期已经被冻结在单例宿主里了。要做成每次获取都是新实例通常要使用ObjectProvider、Lookup或者ScopedProxyMode。我之前的文章里详细写过这块这里简单提一句核心还是别把prototype当每次new用它必须配合正确的获取方式才是真正的每次新建。7.3 排查Bean创建异常的通用套路最后分享一个排错方法。遇到BeanCreationException这类问题时我的排查路径大概是这样第一看异常栈里是否有循环依赖提示。Spring的报错信息很明确如果是The dependencies of some of the beans in the application context form a cycle直接看循环链路在哪个类。第二看是不是构造器注入导致的循环依赖无法解决。如上文所述构造器循环依赖是死结必须重构。第三排查是否有PostConstruct抛出异常。initializeBean阶段任何异常都会被包装成BeanCreationException里层cause会告诉你具体是哪一步炸的。第四检查BeanDefinition是否注册成功。有时候你在配置类里定义Bean时写错了方法签名比如Bean方法方法名写错导致返回类型不匹配容器根本注册不了这个Bean但报错信息可能不如你想的那么直观。这套排查链路我几乎每次都能用上。说白了Spring的运行时诊断信息已经很完善了剩下的就是你脑子里有没有完整的生命周期模型去解读这些信息。希望这篇文章能帮你把这条链路建立起来——下次再看到异常不要再停留在网上去搜中文翻译这一步了。
