谈谈单例模式中通过Htools包的SpringUtil.getBean获取Bean的好处
目录
优势
解决依赖注入失效问题：
典型应用场景：
好处
1. 实例化时序问题
2. 延迟获取解决空指针
3. 设计模式与 Spring 的权衡
代码对比：错误 vs 正确
错误示例（空指针）：
正确实现（延迟获取）：
总结
优势
在单例模式中通过SpringUtil.getBean获取Bean有以下几个关键优势：
解决依赖注入失效问题：
-
- AsyncManager是饿汉式单例，实例化时机早于Spring容器初始化
- 使用@Autowired等注入方式会导致NullPointerException
- getBean()延迟获取保证了Spring容器完成初始化后才获取Bean
1. 保持单例控制权：
- 该类自己维护单例实例（非Spring管理）
- 避免与Spring容器管理的单例产生冲突
- 可以自主控制初始化和销毁时机
2. 获取复杂依赖的灵活性：
- 当需要动态获取不同profile配置的Bean时更灵活
- 特别适用于需要根据条件获取不同实现类的场景
3. 避免循环依赖陷阱：
- 传统注入方式在复杂依赖链中可能引发循环依赖问题
- 按需主动获取的方式打破了这种潜在的循环依赖链
4. 与工具类整合更自然：
- 结合Hutool等工具库的使用风格
- 保持代码简洁性，避免大量注解污染
典型应用场景：
- 框架基础组件
- 需要严格生命周期控制的类
- 早于Spring容器初始化的核心组件
- 需要避免被Spring代理的场合
这种模式在中间件开发、基础框架开发中较为常见，体现了对Spring容器的主动控制，而非被动依赖。
好处
1. 实例化时序问题
- 根本矛盾：
AsyncManager是饿汉式单例，其静态实例INSTANCE在类加载时（通常是应用启动早期）立即初始化。而此时 Spring 容器可能尚未完成 Bean 的初始化。 - 传统注入的陷阱：如果用
@Autowired注入ScheduledExecutorService：
@Autowired
private ScheduledExecutorService executor; // 此时Spring容器未就绪，注入会失败！由于单例的初始化早于 Spring 容器的初始化，executor 会保持 null，后续使用时必然抛出 NullPointerException。
2. 延迟获取解决空指针
- 按需获取：通过
SpringUtil.getBean("scheduledExecutorService")延迟加载 Bean：
-
- 第一次调用
execute()方法时才会实际获取 Bean - 此时 Spring 容器已经初始化完成，可以安全获取到 Bean
- 第一次调用
- 避免静态代码块陷阱：即使你在静态代码块中调用
SpringUtil.getBean()，仍然可能因容器未就绪而失败，而延迟加载彻底规避了时序问题。
3. 设计模式与 Spring 的权衡
- 单例控制权：
AsyncManager是一个自主管理的单例（非 Spring 托管），因此：
-
- 它不参与 Spring 的生命周期管理
- 不能直接享受 Spring 的依赖注入特性
- 需要主动从容器中获取依赖，而非被动注入
- 框架整合技巧：通过
SpringUtil工具类（Hutool 提供）打破单例模式与 Spring 容器的耦合，是常见的企业级解决方案。
代码对比：错误 vs 正确
错误示例（空指针）：
public class AsyncManager {private static final AsyncManager INSTANCE = new AsyncManager();@Autowired // 注入时机不对！private ScheduledExecutorService executor;public void execute(TimerTask task) {executor.schedule(task, 10, TimeUnit.MILLISECONDS); // executor 为 null！}
}正确实现（延迟获取）：
public class AsyncManager {private static final AsyncManager INSTANCE = new AsyncManager();// 延迟获取 Beanprivate final ScheduledExecutorService executor = SpringUtil.getBean("scheduledExecutorService"); public void execute(TimerTask task) {executor.schedule(task, 10, TimeUnit.MILLISECONDS); // 安全执行}
}总结
- 核心目标：确保在 Spring 容器初始化完成后再获取 Bean，避免
NullPointerException - 设计权衡：牺牲一定的 "纯粹性"（依赖注入的理想模式），换取代码的健壮性和框架整合的灵活性
- 适用场景：自主管理的单例类、工具类、需要早期初始化的组件等
这种模式在需要严格掌控初始化时序的场景中非常实用，是解决框架整合时序问题的经典方案。