秒级交易系统要求本地缓存毫秒级响应且冷启不拖慢服务，需通过延迟500ms的异步惰性加载预热可预测、低变更、高命中的元数据，配合future占位实现首请求零等待，并用write-through和refreshAfterWrite持续保鲜。
秒级交易系统对本地缓存的要求很明确：既要毫秒级响应，又不能在启动或冷启时拖慢服务。惰性加载不是“等用才加”，而是利用延迟执行的天然窗口，在请求真正抵达前，把高频、确定性高的数据“悄悄”预热进来——不阻塞主线程，也不浪费空闲资源。
识别真正适合惰性加载的数据
不是所有热点数据都适合惰性加载。关键看三点：是否可预测、是否低变更、是否高命中。比如秒杀商品的基础信息（标题、原价、活动时间）、风控白名单规则、固定汇率表，这些在活动开始前就已确定，且访问频次极高，但首次访问又不能容忍毫秒级延迟。
- 避免加载全量库存：库存是动态变化的，应走分布式缓存+原子扣减，本地只缓存“是否可售”这类轻量状态
- 优先加载元数据：商品ID→SKU映射、类目树快照、用户等级配置等结构稳定、读多写少的数据
- 排除会触发远程调用链的数据：如用户实时画像，若加载需查多个服务，反而放大延迟风险
用延迟任务触发加载，而非启动即拉
传统预热是在应用启动完成时立刻加载，容易造成启动卡顿和资源争抢。惰性加载应绑定一个可控的延迟窗口，例如在JVM启动后500ms内提交一个ScheduledFuture任务，此时应用上下文已就绪，但真实流量尚未涌入。
- 使用轻量调度器（如ScheduledThreadPoolExecutor），避免引入Quartz等重型框架
- 设置最大重试1次+超时3秒，失败则记录告警但不中断主流程
- 加载过程异步非阻塞：用CompletableFuture.supplyAsync()封装加载逻辑，结果写入Caffeine Cache的LoadingCache中
与请求路径联动，实现“首请求零等待”
真正的惰性不是放任首次请求变慢，而是让第一次查询能“撞上”正在加载中的数据。可通过双重检查+future占位实现：
- 首次get(key)时，若缓存未命中，不直接去远端查，而是尝试putIfAbsent一个CompletableFuture<Value>
- 该future由延迟任务统一触发加载；后续同key请求直接join这个future，共享同一加载结果
- 若延迟任务已结束，则直接返回；若仍在运行，最多等待200ms，超时则退化为单次远程调用（带熔断）
加载后持续保鲜，避免“惰性变失效”
惰性加载只解决冷启问题，不代表一劳永逸。必须配合合理的保鲜策略，否则刚加载完就过期，等于白做。
- 设置write-through刷新：当上游（如Redis）发生变更时，通过消息通知本地缓存主动reload对应key
- 对静态配置类数据，启用refreshAfterWrite（如10分钟），确保长期运行中不因长时间无访问而丢失
- 监控loadedCount与hitRate，若hitRate持续低于95%，说明加载范围或时机需调整
