不能用@PostConstruct做缓存预热，因其在Bean初始化阶段执行，此时Spring上下文未刷新完成，RedisConnectionFactory等依赖组件可能未就绪，易导致NPE或连接失败；且不保证依赖服务已初始化，存在循环依赖风险，也无法控制执行顺序。
缓存预热必须在 Spring 容器完全就绪、Redis 连接可用之后执行，否则 RedisTemplate 或 StringRedisTemplate 会为 null，导致 NPE 或连接超时失败。
为什么不能用 @PostConstruct 做缓存预热
@PostConstruct 方法在 Bean 初始化阶段调用，此时 Spring 上下文尚未刷新完成，RedisConnectionFactory 可能还没完成初始化，尤其在启用 SSL、Lettuce 连接池或自定义序列化器时更易出错。常见现象是日志里反复打印 Cannot get Jedis connection 或抛出 RedisConnectionFailureException。
- 该注解不保证依赖的 Redis 组件已 ready，只保证当前 Bean 的字段注入完成
- 若预热逻辑依赖其他服务（如
UserRepository），而这些服务又依赖未就绪的缓存组件，会触发循环依赖警告甚至启动失败 - 无法控制执行顺序：多个
@PostConstruct方法之间无明确先后关系
CommandLineRunner 是最稳妥的启动后执行点
CommandLineRunner 的 run() 方法会在整个 ApplicationContext 刷新完毕、所有单例 Bean 加载完成后才被调用，此时 RedisTemplate、数据库连接、业务 Service 全部可用。
- 推荐加
@Order(1)显式指定优先级，避免与其他 Runner 冲突 - 预热逻辑应包裹在 try-catch 中，并记录关键日志，例如“预热完成共加载 247 条热点数据”
- 若预热耗时较长（如 >5s），建议异步执行（用
new Thread(...).start()或@Async），防止阻塞主线程影响健康检查探针响应
示例：
@Component
@Order(1)
public class RedisCacheWarmer implements CommandLineRunner {
@Autowired private RedisTemplate<String, Object> redisTemplate;
@Autowired private ProductService productService;
@Override
public void run(String... args) {
try {
List<Product> hotProducts = productService.listHotProducts();
for (Product p : hotProducts) {
redisTemplate.opsForValue().set("product:" + p.getId(), p, 30, TimeUnit.MINUTES);
}
System.out.println("✅ Redis cache warmed with " + hotProducts.size() + " items");
} catch (Exception e) {
System.err.println("❌ Cache warmup failed: " + e.getMessage());
}
}
}
ApplicationReadyEvent 更适合需要监听服务真正对外可用的场景
ApplicationReadyEvent 在 Spring Boot Actuator 的 /actuator/health 返回 UP 后才发布，比 CommandLineRunner 稍晚一点，但语义上更准确——它代表应用已就绪、可接收外部请求。
- 适合预热逻辑强依赖其他微服务已注册（如 Eureka/Nacos）、或需等待配置中心配置拉取完成的场景
- 注意：若项目未引入
spring-boot-starter-actuator，该事件不会触发 - 监听时务必检查
event.getApplicationContext().isActive()，避免重复触发（例如在测试上下文中）
示例监听器：
@Component
public class ApplicationReadyCacheWarmer implements ApplicationListener<ApplicationReadyEvent> {
@Autowired private RedisUtils redisUtils;
@Override
public void onApplicationEvent(ApplicationReadyEvent event) {
if (event.getApplicationContext().isActive()) {
redisUtils.warmupAllHotKeys(); // 封装好的预热方法
}
}
}
预热失败后不要静默吞掉异常
缓存预热失败本身不会导致 Spring Boot 启动失败，但会让后续请求直接打到数据库，可能瞬间引发雪崩。最容易被忽略的是 Redis 连接池满、序列化器不匹配、或 key 过长被截断这三类问题。
- 检查
redisTemplate.setKeySerializer(new StringRedisSerializer())是否设置正确；默认JdkSerializationRedisSerializer会导致 key 出现乱码，GET命令查不到 - 批量写入时避免单条
SET，改用redisTemplate.opsForValue().multiSet(...)或管道（redisTemplate.executePipelined(...)）提升性能 - 预热数据量大时，记得确认 Redis 的
maxmemory和淘汰策略（如allkeys-lru），否则刚预热完就被踢出
真正关键的不是“能不能跑起来”，而是“预热失败时有没有人知道”。上线前至少要在日志中 grep 一次 CacheWarmup 关键字，确认它确实执行了、没报错、且数量对得上。
