防范缓存击穿的核心是控失效瞬间的并发冲击，而非防过期；常用方案包括加锁重建缓存（redis set nx ex实现分布式锁）、热点key永不过期+异步刷新、加随机过期时间+多级缓存、以及预热+过期错峰。
Java 中防范高并发秒杀场景下缓存过期引发的缓存击穿（Hotspot Invalid），核心不是“防过期”，而是“控失效瞬间的并发冲击”。秒杀商品详情、库存等热点 key 一旦过期，成千上万请求几乎同时发现缓存 miss，全部涌向数据库——这就是典型的缓存击穿。它虽不像雪崩那样波及大批 key，但单点压力可能更致命。
给热点 key 加锁重建缓存（最常用且有效）
让多个线程中仅一个去查库并回写缓存，其余等待结果，避免数据库被并发打爆。
- 用 Redis 的 SET key value NX EX seconds 命令实现分布式锁（原子性+自动过期），不依赖额外锁服务
- 锁 key 建议带业务前缀和唯一标识（如
"seckill:stock:1001:lock"），避免误删 - 锁过期时间要略大于数据库查询+写缓存耗时（建议设为 5–10 秒），防止死锁
- 获取锁失败后，不要立即重试，应短暂休眠（如 50ms）再查缓存，避免自旋竞争
让热点 key 永不过期 + 后台异步刷新
适用于读远多于写的强热点数据（如秒杀商品标题、规则文案），彻底规避过期瞬间问题。
- 初始化时设置永不过期：
jedis.set("seckill:item:1001", json, "PX", -1)（或不设 TTL） - 用定时任务或消息队列监听库存变更、活动状态等事件，主动更新缓存
- 配合版本号或时间戳字段，客户端可判断缓存是否需强制刷新（如
"seckill:item:1001:version"）
加随机过期时间 + 多级缓存兜底
即使针对秒杀 key，也别设固定 TTL；同时引入本地缓存作为第一道缓冲，降低 Redis 和 DB 压力。
- 设置基础过期时间（如 30 分钟），再叠加 1–5 分钟随机抖动：
ttl = 1800 + new Random().nextInt(300) - 使用 Caffeine 或 Guava Cache 在 JVM 内存中缓存热点 key，设置较短过期（如 1 分钟）和最大容量
- 本地缓存未命中才查 Redis；Redis 未命中再走加锁重建流程，形成“本地 → Redis → DB”三级防护
提前预热 + 过期时间错峰
秒杀开始前主动加载关键数据到缓存，并人为打散过期时间，从源头减少集中失效风险。
- 活动开始前 5 分钟，批量调用接口或脚本预热商品、库存、规则等核心 key
- 预热时对同一类 key（如所有秒杀 SKU）按 ID 取模或哈希分组，每组设置不同基础 TTL（如 group0=3600s，group1=3630s…）
- 避免在整点或半点等规律时刻统一设置过期时间，防止“整点雪崩”式击穿
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
