SmartInitializingSingleton 是在所有非懒加载单例 Bean 初始化完成后触发的全局回调，用于执行一次性收尾逻辑。它不监听依赖注入过程，而是在 finishBeanFactoryInitialization 末尾调用，此时依赖已就绪但 ApplicationRunner 尚未执行。
SmartInitializingSingleton 不是用来“监听”依赖注入过程的，它是在整个 Spring 容器中所有非懒加载单例 Bean 都完成实例化和初始化之后，统一触发的一次回调。它不介入依赖注入阶段，也不感知某个 Bean 是何时被注入的，而是站在容器全局视角，在所有单例就绪后执行自定义逻辑。
SmartInitializingSingleton 的触发时机
它在 finishBeanFactoryInitialization 流程末尾、preInstantiateSingletons 执行完毕后被调用。此时：
- 所有非 lazy-init 的单例 Bean 已完成实例化、属性填充、依赖注入、初始化方法（@PostConstruct / InitializingBean）执行；
- BeanPostProcessor 已全部注册并完成对 Bean 的后置处理；
- 但 ApplicationRunner / CommandLineRunner 尚未执行，应用还未真正“就绪”（ApplicationReadyEvent 未发布）。
如何配合依赖注入使用
你可以在实现类中安全地注入其他 Bean，并在 afterSingletonsInstantiated() 中使用它们——因为此时所有依赖都已就绪。关键点是：注入本身由 Spring 完成，你只需声明依赖，无需手动获取。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 用 @Autowired 或构造器注入需要的 service、repository、配置类等；
- 避免在该方法中调用尚未初始化完成的懒加载（@Lazy）或原型（prototype）Bean 的初始化逻辑；
- 不要在此方法里再触发新的 Bean 创建或复杂耗时操作（如连接远程服务、消费大量 MQ 消息），否则会阻塞容器启动（例如 RocketMQ 监听器积压导致就绪失败）。
典型使用示例
比如预热缓存、注册全局任务处理器、初始化 Netty 服务端：
@Component
public class CachePreloader implements SmartInitializingSingleton {
@Autowired
private RedisTemplate redisTemplate;
@Autowired
private UserService userService;
@Override
public void afterSingletonsInstantiated() {
// 此时 redisTemplate 和 userService 都已完全可用
List<User> hotUsers = userService.findTop100ByScore();
redisTemplate.opsForValue().set("hot_users", hotUsers);
System.out.println("✅ 缓存预热完成");
}
}
和其它初始化方式的区别
对比常见方案，可更清楚它的定位：
- @PostConstruct / InitializingBean：每个 Bean 自己的初始化钩子，依赖注入刚完成即执行，无法跨 Bean 协作；
- ApplicationListener<ContextRefreshedEvent>：时机略晚于 SmartInitializingSingleton（在 refresh 完全结束时），且可能被多次触发（子上下文刷新）；
- SmartLifecycle：支持控制启动/停止顺序和生命周期阶段，适合需异步启动或有 phase 依赖的组件；
- SmartInitializingSingleton：轻量、单次、全局、无 phase、无异步支持，适合“所有 Bean 齐备后一次性收尾动作”。
它不是监听器，而是一个“全局就绪确认点”。用好它的前提，是理解 Spring 容器的初始化阶段划分，而不是把它当作依赖注入的观察者。
