java中redis缓存自动失效依赖其原生ttl机制，通过setex/expire设置过期时间，结合惰性删除（读时检查）和定期删除（每100ms抽样清理）实现轻量可靠失效，避免定时删除性能问题。

Java 中通过 Redis 实现缓存自动失效，核心是为键设置过期时间（TTL），让 Redis 在指定时间后自动清理数据。这不是靠 Java 主动轮询或定时删除，而是利用 Redis 原生的过期机制——设置 + 惰性/定期删除组合，既轻量又可靠。

常用设置方式：推荐用 setex 或 expire 配合 Jedis/Lettuce

实际开发中，最简洁、最常用的是 setex（设置值+秒级过期）和 expire（单独设置过期）。两者都由 Redis 服务端执行，一次命令完成，无竞态风险。

• setex：适合新写入即带过期的场景（如验证码、临时 token）
  jedis.setex("code:123", 300, "abcde"); // 5分钟过期
• expire / pexpire：适合先存值、后补过期，或需毫秒精度（如高频缓存）
  jedis.set("order:789", "pending");
  jedis.pexpire("order:789", 30000); // 30秒
• Spring Data Redis 封装更友好：
  redisTemplate.opsForValue().set("user:1001", user, 10, TimeUnit.MINUTES);

底层生效逻辑：不是“到点就删”，而是“访问时检查 + 后台抽样清理”

Redis 不会在精确时刻删除键，而是采用混合策略保障性能：

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 惰性删除：每次 get、hget 等读操作前，Redis 自动检查该 key 是否已过期；若过期，立即删除并返回 null —— 这保证了业务读不到脏数据。
• 定期删除：Redis 每 100ms 随机抽查一批设置了 TTL 的 key，删除其中过期的；若这批里超 25% 过期，会多抽几轮 —— 这避免内存长期被无效键占用。
• 注意：没有“定时删除”（即不为每个 key 开定时器），否则百万 key 就产生百万定时任务，CPU 直接打满。

关键注意事项：避免踩坑的实操细节

很多缓存失效问题其实源于设置阶段的疏忽：

• key 不存在时 expire 返回 0：务必检查返回值，或先用 exists 判断，否则过期没设上却以为成功了。
• TTL 返回值含义要记清：
  -2 = key 不存在；-1 = key 存在但没设过期；≥0 = 剩余秒数
• 持久化与重启不影响过期逻辑：RDB 快照只保存未过期的 key；AOF 重写时会自动过滤已过期 key；重启后，所有未过期 key 继续计时，过期时间按原始设定延续。
• 慎用永不过期 + 手动清理：除非业务强要求，否则别依赖 Java 定时任务扫描删除 —— 延迟高、易漏、增加应用负担，违背 Redis 设计初衷。

兜底方案：内存不足时靠淘汰策略保服务稳定

即使有 TTL，如果大量 key 还没被惰性或定期删除，内存仍可能吃紧。这时 Redis 会触发 maxmemory-policy（如 volatile-lru 或 allkeys-lru）来释放空间。

• 在 redis.conf 中配置：
  maxmemory 2gb
  maxmemory-policy volatile-ttl（优先淘汰快过期的 key）
• Java 应用无需干预，但需监控 evicted_keys 指标 —— 若该值持续上涨，说明过期设计不合理或流量突增，需优化 TTL 或扩容。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南