目录
[1. 实例化时序问题](#1. 实例化时序问题)
[2. 延迟获取解决空指针](#2. 延迟获取解决空指针)
[3. 设计模式与 Spring 的权衡](#3. 设计模式与 Spring 的权衡)
[代码对比：错误 vs 正确](#代码对比：错误 vs 正确)
优势
在单例模式中通过SpringUtil.getBean获取Bean有以下几个关键优势：
解决依赖注入失效问题：
-
- AsyncManager是饿汉式单例，实例化时机早于Spring容器初始化
- 使用@Autowired等注入方式会导致NullPointerException
- getBean()延迟获取保证了Spring容器完成初始化后才获取Bean
- 保持单例控制权：
- 该类自己维护单例实例（非Spring管理）
- 避免与Spring容器管理的单例产生冲突
- 可以自主控制初始化和销毁时机
- 获取复杂依赖的灵活性：
- 当需要动态获取不同profile配置的Bean时更灵活
- 特别适用于需要根据条件获取不同实现类的场景
- 避免循环依赖陷阱：
- 传统注入方式在复杂依赖链中可能引发循环依赖问题
- 按需主动获取的方式打破了这种潜在的循环依赖链
- 与工具类整合更自然：
- 结合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();
// 延迟获取 Bean
private final ScheduledExecutorService executor =
SpringUtil.getBean("scheduledExecutorService");
public void execute(TimerTask task) {
executor.schedule(task, 10, TimeUnit.MILLISECONDS); // 安全执行
}
}总结
- 核心目标 ：确保在 Spring 容器初始化完成后再获取 Bean，避免
NullPointerException - 设计权衡：牺牲一定的 "纯粹性"（依赖注入的理想模式），换取代码的健壮性和框架整合的灵活性
- 适用场景：自主管理的单例类、工具类、需要早期初始化的组件等
这种模式在需要严格掌控初始化时序的场景中非常实用，是解决框架整合时序问题的经典方案。