缓存预热需结合启动节奏、数据热度与资源约束策略化加载，核心是让关键数据在首请求前就绪以避免冷启动问题；包括启动阶段主动加载热点数据、定时任务补充更新、jvm级代码预热及利于预热的缓存设计。
缓存预热不是“加个注解就完事”，而是要结合系统启动节奏、数据热度特征和运行时资源约束，做有策略的加载。核心目标是让关键数据在第一个真实请求到来前，已经稳稳躺在缓存里——避免冷启动时的数据库洪峰和用户首屏等待。
启动阶段主动加载热点数据
这是最常用也最可控的方式，适合数据量适中、变更频率低的业务主数据（如城市列表、商品类目、配置项）。关键是选对触发时机和加载范围：
- 用 ApplicationRunner 或 @PostConstruct 执行预热逻辑，确保 Spring 容器已就绪、缓存组件（如 RedisTemplate 或 Caffeine 实例）可安全调用
- 避免全量加载：只预热 QPS ≥ 50 或响应耗时 > 20ms 的接口所依赖的数据，可通过压测日志或 APM 工具（如 SkyWalking）导出高频 key
- 加载过程加超时与降级：比如设置 30 秒总超时，若某批数据加载失败，记录 warn 日志但不中断启动，防止因缓存服务临时异常导致应用起不来
定时任务补充更新缓存
适用于有明确更新周期的缓存项，比如每日凌晨更新的运营活动榜单、每小时刷新的实时销量 TOP100。它不替代启动预热，而是持续保鲜：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 用 @Scheduled(fixedDelay = 3600000) 配合条件判断（如只在主节点执行），避免集群多实例重复加载
- 更新前先查旧值是否仍有效：比如对比数据库最新更新时间戳，若无变化则跳过写缓存，减少无效 IO
- 采用“双写+原子切换”：先写新 key（如 rank:today:new），再用 RENAME 或 SET key new_value NX 原子替换旧 key，避免中间态不一致
JVM 级别热点代码预热（常被忽略）
接口快不只是数据快，更是执行路径快。刚启动时 JIT 还没编译核心方法，所有调用都走解释器，CPU 利用率低但延迟高。这时需主动“喂”几次调用：
- 在 ApplicationRunner 中对订单创建、用户鉴权等主干方法，用模拟参数调用 3–5 次（不关心返回值，只触发计数器）
- 配合 JVM 参数优化：-XX:+TieredCompilation -XX:CompileThreshold=1500，加快 C1 编译；-XX:ReservedCodeCacheSize=384m 防止编译缓存挤爆
- 验证是否生效：启动后执行 jstat -compiler pid，观察 Compiled 数稳定增长，且 Invalid 接近 0
缓存设计本身要利于预热落地
再好的预热逻辑，遇上不合理的设计也会打折。几个关键点：
- Key 命名规范统一：比如用户维度用 user:info:{id}，订单维度用 order:detail:{sn}，方便预热脚本批量生成 key 范围
- 过期时间分级设置：配置类缓存设为永不过期（靠主动刷新），排行榜类设 5 分钟，用户会话类设 30 分钟，避免预热后几分钟就失效
- 本地缓存 + 分布式缓存组合：Caffeine 做一级缓存（毫秒级响应），Redis 做二级（保障一致性），预热时两级同步写入，降低穿透风险
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
