很多人学Spring都是从IoC容器开始的但等你打开一个真实的老项目看到XML里散落着一堆bean配置有时还是会犯迷糊同样是创建一个对象为什么有的直接写个class就完事有的要加factory-method有的还要配factory-bean甚至还有专门实现FactoryBean接口的类这些写法的背后其实就是Spring实例化对象的几种典型方式——构造器、静态工厂、实例工厂、FactoryBean。这篇文章我不打算讲多高深的源码就把这四种方式掰开揉碎用最小可运行的XML配置一个个列出来告诉你每种方式在什么场景下用、配置里的每个属性是干什么的、踩到坑怎么排查。不管你是刚看完Spring入门教程的新手还是被循环依赖和代理创建折磨过的中级开发这份梳理应该都能帮你把那层窗户纸捅破。1. XML配置实例化Bean的整体图景1.1 实例化不是全部创建对象是一条流水线先说一个很多人容易忽略的概念bean标签里的class属性并不只是告诉Spring你要new这个类而是告诉Spring这个Bean的BeanDefinition长什么样。容器启动后真正发生的事远比一个new关键字复杂。我自己习惯把Bean的创建过程分成四个阶段解析配置、实例化、填充属性、初始化。实例化只是中间一小步。你写下的bean会被解析成一个BeanDefinition对象里面记录了class名、作用域、构造参数、属性值、初始化方法名等元数据然后容器在合适的时机调用构造器或工厂方法把对象造出来此时对象还是半成品属性全是默认值接着Spring根据property和constructor-arg把依赖塞进去最后执行init-method或InitializingBean回调一个能用的Bean才算真正诞生。理解这条流水线特别重要。因为后面的几种实例化方式本质上都是在实例化这一环做文章而后面的属性填充和初始化逻辑对四种方式一视同仁。也就是说不管你是用构造器搭出来的对象还是从工厂方法里拿到的对象只要它进了容器Spring都会继续给它做依赖注入和初始化。很多同学疑惑为什么从FactoryBean里拿到的对象也能自动注入属性答案就在这里——注入动作发生在实例化之后而不是之前。1.2 BeanDefinition你写的每行XML都会变成什么为了让你对后续的配置不产生割裂感我建议你先建立这个映射关系bean iduserService classcom.example.UserService/表示一个BeanDefinitionclass指向最终实例化要用的类property namexxx valueyyy/最终会变成一个PropertyValue在填充属性阶段被反射写入constructor-arg则对应构造参数列表供实例化阶段选择匹配的构造器factory-bean和factory-method组合相当于把实例化动作委托给了另一个Bean的方法FactoryBean接口则是一种更高级的委托容器的getBean(xxx)会转发给getObject()。说白了XML配置只是BeanDefinition的一种外部表现。你写的每一种方式最终都会在AbstractAutowireCapableBeanFactory.createBean()里被分派到不同的创建策略。我在看Spring源码时最喜欢在AbstractAutowireCapableBeanFactory里打断点观察createBeanInstance()方法怎么走分支有factoryMethodName走工厂方法有FactoryBean类型则先创建工厂本身否则老老实实找构造器。理解了这条主线下面的各种配置就不会觉得是零散技巧了。2. 构造器实例化最朴素也最常用2.1 无参构造器配置先看最基础的一种Spring直接调用类的无参构造器创建对象。配置就一行bean iduserService classcom.example.UserService/如果你的UserService长这样public class UserService { private UserDao userDao; public UserService() { System.out.println(UserService 无参构造器被调用); } public void setUserDao(UserDao userDao) { this.userDao userDao; } }那么Spring在实例化时会通过反射找到UserService的无参构造器并执行。这里要提醒一个新手高频坑如果你的类写了带参构造器却没写无参构造器容器启动会直接报No default constructor found。因为反射调clazz.getDeclaredConstructor()找不到默认构造器Spring就束手无策了。所以用这种最朴素方式创建Bean的类要么保留无参构造器要么老老实实走带参构造的配置。无参构造器之所以是默认选项是因为它最简单、最不容易出错。Spring不需要猜测该调用哪个构造器也不需要准备参数直接BeanUtils.instantiateClass就完事。实际项目里Spring容器管理的类我几乎都默认设计成无参构造器配合setter注入这样既方便容器操作写单元测试时也可以手动new出来然后set依赖两条路都走得通。2.2 带参构造器与constructor-arg有些类就是为必须传参才能用设计的比如一个要求强制传入UserDao和一个初始化次数的服务。这种类直接用无参构造器并不合理Spring也提供了constructor-arg来匹配带参构造器bean iduserService classcom.example.UserService constructor-arg nameuserDao refuserDao/ constructor-arg namemaxRetry value3/ /bean对应的Java类public class UserService { private UserDao userDao; private int maxRetry; public UserService(UserDao userDao, int maxRetry) { this.userDao userDao; this.maxRetry maxRetry; } }这里有个匹配规则要说清楚Spring会根据constructor-arg的类型、顺序去匹配构造器。如果参数是引用类型用ref指向另一个Bean如果是基本类型或字符串用value直接给值。当你用name属性明确指定参数名时Spring还需要你的代码在编译时开启了-parameters参数否则参数名拿不到最好同时用index0来兜底或者保证类型组合足够唯一。带参构造器的一大好处是依赖不可变。对象一旦创建依赖关系就固定了不会因为后续有人调了setter而被改掉这对核心域对象特别友好。代价就是灵活性下降尤其是构造参数一多XML配置就变得很啰嗦。我的建议是超过三四个构造参数的对象优先考虑建造者模式或拆成多个小对象别让XML变成火车一样的长串参数。2.3 一个绕不开的话题构造函数循环依赖提到构造器方式就不得不顺带说一个Spring里最容易挂的场景——循环依赖。假设A的构造器需要BB的构造器需要A容器启动时会发生什么答案是直接抛BeanCurrentlyInCreationException。原因也好理解构造器方式意味着创建对象时必须拿到参数Spring为了拿到A就得先创建B为了创建B又得先创建A两边都在等待形成一个死结。Spring的三级缓存解决的是setter注入的循环依赖先提前暴露半成品对象再填充属性时互相引用而构造器阶段连半成品都还没造出来想暴露也没得暴露。所以遇到构造器循环依赖不需要研究什么高级配置直接把其中一边改成setter注入或者重新设计依赖方向就行。我自己排查这类问题时第一步就是看报错里的Bean名把它们画成一张依赖图然后果断改掉其中一条边。记住一句话构造器适合表达必需依赖但别用它表达互相依赖。3. 静态工厂实例化适合不让你new的类3.1 原理和适用场景有些类的构造器不是public的或者类本身设计成通过静态方法获取实例比如JDK里的Runtime.getRuntime()、Calendar.getInstance()。如果这样的类要交给Spring管理直接用bean class.../反射调构造器肯定会失败因为构造器压根不公开。这时候就可以用静态工厂方式配置里告诉Spring别调构造器了去调用这个类的某个静态方法由它把对象给你。原理并不复杂Spring在实例化阶段发现factory-method属性存在就不再走instantiateClass而是反射调用factory-method指定的静态方法拿到返回值作为Bean实例。方法必须是static的因为它不依赖任何对象实例本质上是一种类级别的对象提供器。适用场景也比较典型目标类构造器是private只能通过静态方法获取创建逻辑封装在静态方法里方法内部可能做了缓存、参数校验或者统一配置你不想让调用方直接new而是通过一个名字清晰的工厂方法体现创建意图。3.2 配置细节先看最简单的写法。public class UserServiceFactory { public static UserService getInstance() { return new UserService(created-by-factory); } }bean iduserService classcom.example.UserServiceFactory factory-methodgetInstance/注意这个配置里class指向的是工厂类不是最终要创建的目标类。Spring看到factory-method后会用class定位工厂类再找到对应的静态方法调完之后把方法返回值注册成userService这个Bean。如果静态方法需要参数就用constructor-arg传入——虽然名字叫constructor-arg但在工厂方法场景下它实际上对应的是工厂方法的参数public class DateFormatFactory { public static SimpleDateFormat create(String pattern) { return new SimpleDateFormat(pattern); } }bean iddateFormat classcom.example.DateFormatFactory factory-methodcreate constructor-arg namepattern valueyyyy-MM-dd/ /bean这里最容易犯的错就是把class写成目标类或者忘记加factory-method。如果两者同时出问题报错会是No default constructor found因为你把类写成了目标类Spring又开始傻傻地找构造器了。3.3 一个随手可试的示例你可以用一个很简单的例子试明白假设有个ConnectionManager构造器是private的对外只暴露静态工厂方法public class ConnectionManager { private final String url; private ConnectionManager(String url) { this.url url; } public static ConnectionManager createLocal() { return new ConnectionManager(jdbc:local://config); } }XML配置bean idconnectionManager classcom.example.ConnectionManager factory-methodcreateLocal/写个启动类验证ApplicationContext context new ClassPathXmlApplicationContext(applicationContext.xml); ConnectionManager cm context.getBean(connectionManager, ConnectionManager.class); System.out.println(cm);运行后你会发现容器成功拿到了ConnectionManager实例完全绕过了private构造器。静态工厂方式的最大优势就是让那些不情愿被new的类也能无缝融入容器同时把创建细节留在工厂方法内部XML这边干干净净。4. 实例工厂实例化工厂本身也是Bean4.1 与静态工厂的差别在哪里如果说静态工厂是类级别的方法调用那实例工厂就是把工厂本身变成一个Bean再通过这个Bean实例的普通方法去创建目标对象。差别非常关键静态工厂方法不能依赖任何Spring注入的依赖而实例工厂是容器管理的Bean可以注入属性、引用其他Bean。这一下就打开了更多可能性。比如某个工厂方法需要根据环境变量来决定创建什么类型的对象而环境变量是另一个配置Bean提供的静态工厂就做不到因为静态方法没有this拿不到被Spring注入的状态。实例工厂可以做到Spring先创建并配置好工厂Bean再把工厂Bean注入依赖最后调用它的实例方法产出目标对象。4.2 配置方法与示例先看Java端。我设计一个工厂它自己持有env属性用来决定返回什么配置的连接管理实例public class ServiceFactory { private String env; public void setEnv(String env) { this.env env; } public UserService createUserService() { return new UserService(env); } }XML配置分两步。第一步先配置工厂Bean本身第二步配置目标Bean时用factory-bean指向上一步的工厂bean idserviceFactory classcom.example.ServiceFactory property nameenv valuedev/ /bean bean iduserService factory-beanserviceFactory factory-methodcreateUserService/注意这里的目标Bean没有class属性因为类类型由工厂方法的返回值决定。Spring通过反射调用serviceFactory.createUserService()拿到返回值后注册为userService。factory-bean和factory-method必须成对出现只写一个就会启动报错。这种模式的实际价值在于工厂的复用和上下文感知。同一个工厂类可以在XML里配置成不同状态的多个工厂Bean比如一个envdev、一个envprod分别产出不同配置的对象工厂内部还能引用其他Bean比如引用一个PropertiesLoader来读取外部配置。Spring内部很多复杂组件的装配都用了类似的思路先配置一个持有大量依赖的工厂Bean再让它产出真正需要的客户端对象。如果你把实例工厂和前面的静态工厂对比一下会发现实例工厂的配置只多了factory-bean但灵活性提升了不止一个量级。我自己的习惯是当创建逻辑需要依赖其他Bean或需要状态时果断用实例工厂别硬塞静态方法。5. FactoryBeanSpring内部最常用的生产方式5.1 接口与约定FactoryBean是本章节的重头戏也是很多Spring开发者的困惑点。它听起来和工厂有关但和前面的普通工厂方式有一个本质区别FactoryBean是Spring容器认可的一等公民接口容器会对实现了FactoryBean接口的Bean做特殊处理。接口长这样public interface FactoryBeanT { T getObject() throws Exception; Class? getObjectType(); boolean isSingleton(); }约定是这样的你配置了一个classxxxFactoryBean的Bean容器在实例化阶段会正常创建这个工厂Bean本身但当有人调用context.getBean(xxx)时Spring发现这个Bean实现了FactoryBean接口就会返回getObject()的产物而不是工厂Bean本身。换句话说对外暴露的是getObject()的返回值工厂Bean本尊被藏了起来。这个设计精妙在哪里它把复杂的创建过程和统一的外部获取方式解耦了。调用方完全不需要知道对象是从哪来的只要通过Bean名拿就行。Spring内部大量使用这个机制比如MyBatis的SqlSessionFactoryBean、Ribbon的配置、以及AOP代理对象的创建都是靠它实现的。5.2 自定义FactoryBean示例我写一个尽量贴近实际的例子假设有个RpcClient创建时需要初始化连接池、加载协议配置、设置重试次数过程非常啰嗦你想把这些细节都封装起来。先看一下目标类public class RpcClient { private final String serverAddress; private final int retryTimes; public RpcClient(String serverAddress, int retryTimes) { this.serverAddress serverAddress; this.retryTimes retryTimes; // 模拟建立连接等耗时操作 System.out.println(RpcClient 初始化完成: serverAddress); } }然后实现FactoryBean把复杂的初始化流程放进去public class RpcClientFactoryBean implements FactoryBeanRpcClient { private String serverAddress; private int retryTimes; public void setServerAddress(String serverAddress) { this.serverAddress serverAddress; } public void setRetryTimes(int retryTimes) { this.retryTimes retryTimes; } Override public RpcClient getObject() { // 这里可以写一大段复杂初始化逻辑 return new RpcClient(serverAddress, retryTimes); } Override public Class? getObjectType() { return RpcClient.class; } Override public boolean isSingleton() { return true; } }XML配置bean idrpcClient classcom.example.RpcClientFactoryBean property nameserverAddress value127.0.0.1:8080/ property nameretryTimes value3/ /bean这时候Spring会对配置在class里的RpcClientFactoryBean做实例化和属性填充但调用方取的时候拿的是RpcClientRpcClient rpcClient context.getBean(rpcClient, RpcClient.class);你可能会想这不就和实例工厂差不多吗功能上确实有点像但FactoryBean的优势在于它是Spring的标准接口容器里的很多基础能力都认识它比如事务、AOP在自动代理时会对FactoryBean做特殊处理还会在ApplicationContext里额外持有前缀的Bean。你不实现这个接口就享受不到这些容器级待遇。5.3 前缀与内部使用场景FactoryBean还有一个很经典的细节如果你想获取工厂Bean本身而不是它的产物需要加前缀。RpcClientFactoryBean factory context.getBean(rpcClient, RpcClientFactoryBean.class);没有拿产物有拿工厂本身。这个规则我刚学的时候经常记反后来我用一个类比才记住FactoryBean像一个代购你下单getBean(xxx)拿到的是代购买回来的商品想去问代购本人问题就得喊找那个代购前缀。Spring内部为什么要大量用FactoryBean呢最主要的原因是AOP代理。当某个Bean需要被AOP增强时Spring会创建一个代理对象这个代理对象的创建逻辑复杂通常用一个FactoryBean把创建代理的细节封装起来。你配置一个普通Bean结果从容器里拿出来的是增强后的代理正是因为背后有FactoryBean在干活。理解了这一点再看那些XML里配了个beans但是getBean出来类型不对的问题就能猜到八成是FactoryBean在搞鬼了。如果你感兴趣还可以看看MyBatis-Spring的SqlSessionFactoryBean源码它实现了FactoryBeanSqlSessionFactory把MyBatis配置解析、环境构建、映射器注册全塞进了getObject()。一个SqlSessionFactory背后涉及那么多步骤外部调用却只是getBean(sqlSessionFactory)——这种封装力度才是FactoryBean真正的魅力。6. 四种方式横向对比与组合实践6.1 一张表看懂四种方式的配置差异做了这么多铺垫我把四种方式的区别整理成一张表方便你快速对比和回忆。实例化方式关键配置属性创建者是谁典型场景注意事项构造器classconstructor-argSpring容器大多数普通业务Bean类需要有对应构造器参数匹配要稳静态工厂classfactory-method静态方法JDK工具类、构造器私有类factory-method指向的方法必须是static实例工厂factory-beanfactory-method工厂Bean的实例方法创建逻辑依赖其他Bean或状态工厂Bean必须单独配置并先初始化FactoryBeanclassFactoryBean实现类getObject()方法复杂创建、代理对象、框架集成获取工厂本身需要前缀这张表的核心记忆点就一句话构造器方式靠Spring自己去new另外三种方式本质上是把创建动作委托出去委托给静态方法、或者委托给另一个Bean的方法、或者委托给FactoryBean的getObject()。6.2 一个贴近真实的综合示例光看碎片配置不够我带你走一个稍微完整点的场景假设系统里有多种环境的数据源连接管理器需要根据env配置创建连接管理器。手动new太啰嗦我们用实例工厂来实现public class ConnectionManager { private final String env; private final int maxConnections; public ConnectionManager(String env, int maxConnections) { this.env env; this.maxConnections maxConnections; } }工厂类public class ConnectionManagerFactory { private AppConfig appConfig; public void setAppConfig(AppConfig appConfig) { this.appConfig appConfig; } public ConnectionManager createLocal() { return new ConnectionManager(appConfig.getEnv(), appConfig.getLocalMaxConnections()); } public ConnectionManager createRemote() { return new ConnectionManager(appConfig.getEnv(), appConfig.getRemoteMaxConnections()); } }XML配置bean idappConfig classcom.example.AppConfig property nameenv valuedev/ property namelocalMaxConnections value10/ property nameremoteMaxConnections value5/ /bean bean idconnectionFactory classcom.example.ConnectionManagerFactory property nameappConfig refappConfig/ /bean bean idlocalConn factory-beanconnectionFactory factory-methodcreateLocal/ bean idremoteConn factory-beanconnectionFactory factory-methodcreateRemote/这样我们不但在XML里复用了同一个工厂Bean还让工厂从AppConfig里读取配置。如果用静态工厂这个AppConfig根本传不进去如果用构造器硬拼每个Bean都要重复写一堆参数。实例工厂在这个场景下的优势就很明显了。如果这里要创建的对象初始化逻辑特别重比如要读取多个配置文件、要构建子组件我就直接把工厂类改成实现FactoryBean把这个工厂Bean 工厂方法两步封装成一步。毕竟FactoryBean对调用方更友好外部只用getBean(localConn)连谁是工厂都不用知道。6.3 实例化时机scope、lazy-init和init-method聊实例化方式还绕不开一个实际问题这些Bean到底什么时候被创建四个字取决于scope和lazy-init。默认情况下scopesingleton的Bean容器启动时就会完成实例化和初始化这被称为饿汉式创建。如果你不想启动阶段就创建可以设置lazy-inittrue容器会推迟到第一次getBean时才实例化。要注意这个懒加载对scopeprototype其实是没有意义的因为prototype本来就是每次getBean才新建。scope和实例化时机的对应关系直接在XML里体验最直观。bean idheavyService classcom.example.HeavyService lazy-inittrue/ bean idprototypeBean classcom.example.PrototypeBean scopeprototype/实例化完成之后Spring还会执行初始化钩子。XML里最直观的就是init-method和destroy-methodbean idrpcClient classcom.example.RpcClient init-methodconnect destroy-methodclose/如果你在这篇文章前面理解了实例化、填充属性、初始化三段式的节奏那init-method出现的位置就很好猜了它一定在属性填充完成之后执行因为一个没有依赖注入完的对象去连网、起线程纯属找死。这也是为什么我强调实例化只是第一步你看到init-method要意识到它已经是容器为你准备的上桌菜了。7. 常见问题与排查技巧7.1 高频报错速查四种方式都讲完了我把实战里最容易踩的坑整理成一个速查表遇到报错直接对着看。报错现象常见原因解决建议No default constructor found类没有无参构造器但XML没配constructor-arg补无参构造器或用index/name明确配置构造参数factory-method ... non-static配置的factory-method指向了非静态方法把方法改成static或用实例工厂方式factory-bean与factory-method缺失其一实例工厂方式缺配置两个属性必须成对出现Bean property xxx is not writable...property的name和setter对不上检查setter命名、检查name拼写ClassCastException: cannot cast ... FactoryBean想拿工厂本身却直接用了Bean名用beanName获取工厂本身BeanCurrentlyInCreationException构造器注入循环依赖改成setter注入或重新设计依赖关系7.2 我的几条排查经验最后再分享几条我在真实项目里的排障心得这些在文档里都不容易看到。第一先确认BeanDefinition长啥样再猜问题。你可以临时写个ApplicationContext启动类遍历所有BeanDefinition打印factoryMethodName、beanClassName、scope一眼就能看出来你写的XML有没有被正确解析。很多为什么我配置了实例工厂但没生效的问题排查来排查去最后发现是factory-bean的名字写错了。第二遇到FactoryBean相关异常先找前缀。有时候日志里出现No qualifying bean of type xxxFactoryBean是因为你一直以为getBean(xxx)返回的是工厂本身结果类型对不上。想清楚你拿的是产物还是工厂问题就解决了一大半。第三XML配置优先用IDEA的Spring面板看依赖图。在IDEA里右键XML文件选择Diagram - Show dependencies所有Bean之间的引用关系会以图形展示循环依赖、指向错误几乎一眼可见。这个功能在我处理老项目时帮了我大忙比盯着报错日志猜有效多了。第四别在XML里堆十来个constructor-arg。配置越复杂出错的概率越高。如果你的一个Bean需要四五个依赖才能创建请重新审视设计是不是对象拆得太粗了如果能拆拆出来的小对象用无参构造加setter大对象用工厂组装整体可维护性会好很多。我自己在项目里长期遵循一个默认策略普通业务Bean优先无参构造加setter注入需要不可变依赖、参数较少时用带参构造接入框架或创建过程重时用FactoryBeanJDK或第三方库不给new的类才考虑静态工厂。这不是说其他方式不行而是这个组合踩坑最少、读起来最直观。如果你正准备改造一段老代码或者在为团队制定Spring Bean创建规范我建议你把这篇文章里的四种方式当成一个检查清单遇到一个新Bean先问一句它属于哪种方式配置里对应的属性是什么该配class还是factory-bean把基础概念理清楚之后你会发现很多看似玄乎的Spring问题其实都能落到这几个简单选择上。