Spring Bean实例化双雄：从BeanDefinition.setInstanceSupplier()到FactoryBean的进阶之路

1. Spring Bean实例化的两种高阶玩法

刚接触Spring框架时，我们通常用@Component或@Bean注解来声明Bean，这就像用微波炉加热预制菜——简单快捷但缺乏定制空间。当遇到需要动态构造、条件化初始化的复杂对象时，就需要请出今天的主角：BeanDefinition.setInstanceSupplier()和FactoryBean。这就像从家常菜进阶到分子料理，虽然操作复杂，但能精准控制每个细节。

我在重构一个支付网关时深有体会。有的支付渠道需要运行时动态加载证书，有的需要代理对象实现AOP拦截。这时候传统的注解方式就力不从心了，而这两种方案就像瑞士军刀的不同组件：setInstanceSupplier()像精确的镊子，适合细粒度控制单个对象的构建过程；FactoryBean则像多功能钳子，适合封装整套对象生产流水线。下面我们通过真实项目场景，拆解它们的适用边界。

2. 解剖BeanDefinition.setInstanceSupplier()

2.1 底层原理与核心优势

setInstanceSupplier()是Spring 5.0引入的API，它允许我们直接干预Bean的实例化阶段。想象你正在组装乐高，默认情况Spring会按照说明书（BeanDefinition）自动拼装，而这个API相当于让你亲手捏住每一块积木。

它的核心价值在于：

• 延迟计算：直到真正需要时才执行Supplier逻辑
• 条件化构造：能根据运行时状态决定如何构建对象
• 规避反射：相比反射实例化，直接提供对象引用性能更高

去年优化一个配置中心时，我需要根据不同的环境变量创建数据源。传统做法要写一堆@Conditional注解，而用Supplier只需要三行代码：

java复制definition.setInstanceSupplier(() -> {
    return "prod".equals(env) ? new ProdDataSource() : new TestDataSource();
});

2.2 实战中的典型应用场景

在微服务架构中，这种模式特别适合：

1. 原型模式Bean：每次获取都返回新实例
2. 上下文感知对象：需要访问ApplicationContext再构造
3. 动态代理增强：在实例化阶段植入AOP逻辑

看个更复杂的例子——实现一个线程安全的随机数生成器：

java复制@Configuration
public class RandomConfig {
    @Bean
    public BeanDefinitionBuilder randomBuilder() {
        GenericBeanDefinition definition = new GenericBeanDefinition();
        definition.setInstanceSupplier(ThreadLocalRandom::current);
        return definition;
    }
}

这里直接把Java原生API包装成Spring Bean，避免了不必要的包装层。

3. 深入FactoryBean的工业级用法

3.1 为什么说它是Spring的"黑魔法"

如果说setInstanceSupplier是手术刀，那么FactoryBean就是整套手术设备。它不仅控制实例化，还能管理生命周期。我常把它比作汽车工厂：getObject()是生产线，getObjectType()是产品说明书，isSingleton()决定是量产还是定制。

一个经典的误区和真相：

• 误区：认为FactoryBean返回的是自身实例
• 真相：通过"&"前缀才能获取工厂本身

在实现分布式锁时，我用FactoryBean完美封装了Redis和ZooKeeper的差异：

java复制public class DistributedLockFactory implements FactoryBean<Lock> {
    @Override
    public Lock getObject() {
        return lockType == LockType.REDIS ? 
               new RedisLock(connection) : 
               new ZkLock(client);
    }
    
    @Override
    public Class<?> getObjectType() {
        return Lock.class;
    }
}

3.2 企业级开发中的组合拳

真正体现FactoryBean威力的场景是与其他Spring特性联动：

1. 结合AOP：在getObject()返回代理对象
2. 整合生命周期：实现InitializingBean做后置处理
3. 动态注册：通过BeanDefinitionRegistryPostProcessor批量注册

比如这个可观测的RPC客户端工厂：

java复制public class RpcClientFactory implements FactoryBean<RpcClient>, InitializingBean {
    private RpcClient client;
    
    @Override
    public void afterPropertiesSet() {
        this.client = new RpcClient();
        Metrics.register(client); // 注册监控
    }
    
    @Override
    public RpcClient getObject() {
        return client;
    }
}

4. 技术选型决策树

4.1 何时该用哪种方案

经过多个项目的实践，我总结出这样的决策路径：

1. 是否需要管理完整生命周期？→ 选FactoryBean
2. 是否要避免额外接口实现？→ 选setInstanceSupplier
3. 是否需要AOP集成？→ FactoryBean更自然
4. 是否要动态决定对象类型？→ 两者皆可

关键指标对比表：

4.2 那些年我踩过的坑

1. 循环依赖陷阱：FactoryBean如果依赖其他Bean，需要在getObjectType()准确返回类型
2. 过早初始化问题：Supplier中访问尚未初始化的Bean会导致异常
3. 代理对象识别：FactoryBean创建的代理对象可能影响@Autowired类型匹配

最难忘的是在一次性能优化中，误将高耗时的资源加载放在Supplier里，导致每次getBean都重新初始化。后来改用FactoryBean配合@Lazy才解决：

java复制public class HeavyResourceFactory implements FactoryBean<Resource> {
    private Resource resource;
    
    @Override
    public Resource getObject() {
        if(resource == null) {
            synchronized(this) {
                resource = loadFromRemote(); // 双重检查锁定
            }
        }
        return resource;
    }
}

5. 进阶技巧与模式创新

5.1 两种模式的杂交育种

真正的高手会混用两者。比如先用FactoryBean搭建框架，再用Supplier实现细节：

java复制public class HybridFactory implements FactoryBean<Service>, BeanClassLoaderAware {
    private Supplier<Service> supplier;
    
    public void setBeanClassLoader(ClassLoader classLoader) {
        this.supplier = () -> {
            return Proxy.newProxyInstance(classLoader, 
                new Class[]{Service.class}, new DebugInvoker());
        };
    }
    
    @Override
    public Service getObject() {
        return supplier.get();
    }
}

5.2 自动装配的魔法

结合Spring Boot自动配置，可以创建智能工厂：

java复制@AutoConfiguration
public class SmartFactoryAutoConfig {
    @Bean
    @ConditionalOnMissingBean
    public FactoryBean<Cache> cacheFactory(Environment env) {
        return new FactoryBean<>() {
            @Override
            public Cache getObject() {
                return env.acceptsProfiles("cloud") ? 
                       new RedisCache() : new LocalCache();
            }
            // 省略其他方法
        };
    }
}

这种模式在Starter开发中特别有用，能根据运行环境自动选择实现。

6. 性能优化实战录

6.1 对象池的两种实现

对于数据库连接等昂贵资源，对象池是常见需求。先用Supplier实现基础版：

java复制definition.setInstanceSupplier(() -> {
    return pool.borrowObject(); // 从Apache Commons Pool获取
});

再用FactoryBean实现增强版：

java复制public class PooledDataSourceFactory implements FactoryBean<DataSource>, DisposableBean {
    private final ObjectPool<Connection> pool;
    
    @Override
    public DataSource getObject() {
        return new PooledDataSource(pool);
    }
    
    @Override
    public void destroy() {
        pool.close(); // 优雅关闭
    }
}

6.2 编译时验证的妙用

通过注解处理器，可以在编译期检查FactoryBean的合法性：

java复制@AutoService(Processor.class)
public class FactoryBeanProcessor extends AbstractProcessor {
    @Override
    public boolean process(Set<? extends TypeElement> annotations, 
                          RoundEnvironment env) {
        // 检查getObjectType()返回值是否匹配实际类型
    }
}

这套机制在我司中间件团队已经防止了数十次类型不匹配的线上事故。