如何解决Spring Boot集成Redis出现的OOM异常_排查大对象存储与过期Key清理不及时-Redis-PHP中文网

spring boot集成redis出现oom，主因是jvm堆内存被反序列化的大对象持续占用：getobject频繁加载未设ttl的过期key对应的大json，jackson全量解析后生成的java对象长期驻留堆中，叠加静态引用或本地缓存缺失导致gc无法回收。

如何解决spring boot集成redis出现的oom异常_排查大对象存储与过期key清理不及时

Spring Boot 集成 Redis 出现 OOM，大概率不是 Redis 本身内存爆了，而是应用进程（JVM）堆内存被大量未释放的 Redis 缓存对象撑爆 —— 尤其是反复用 getObject 加载大对象、或 set 时没设 TTL 导致过期 Key 滞留，再叠加序列化器误配，会直接把反序列化后的 Java 对象塞进 JVM 堆里长期驻留。

为什么 getObject 会引发 JVM OOM 而不是 Redis 内存溢出

Redis 的内存上限由 maxmemory 控制，触发淘汰策略后会删 key；但 Spring 的 RedisTemplate 默认用 Jackson2JsonRedisSerializer 反序列化时，会把整个 JSON 字符串解析成完整的 Java 对象（比如一个含 10 万条记录的 List<user></user>），这个对象就留在 JVM 堆里了。如果业务频繁调用 getObject("user:all", List.class)，又没做本地缓存或引用管理，GC 就可能收不走。

每次 getObject 都新建对象实例，旧对象若被静态 Map 或单例 Bean 持有，就成内存泄漏点
Jackson2JsonRedisSerializer 不支持流式解析，无法对超大 JSON 做分页/懒加载
Redis 中 key 已过期，但客户端没访问它，惰性删除不触发 → Redis 里没占内存，但应用里早加载过的对象还活着

set 方法没设 timeout 是 OOM 的隐形推手

看知识库里的 set 方法实现：if(timeout != null) { this.redisTemplate.expire(...); } —— 这意味着传入 null 或不传 timeout，key 就永久存在。而生产环境常因逻辑分支漏掉 timeout 参数，或配置项读取失败返回 null，结果就是：Redis 里堆积大量“逻辑上该过期”的 key，虽不占 Redis 内存（集群可能已淘汰），但应用侧仍通过定时任务/监听反复 getObject 加载它们，不断 new 大对象。

Redis Skill - 高性能缓存管理

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

下载

检查所有 set 调用点，确认 timeout 是否为必填参数，避免默认值为 null
在工具类中强制 fallback：Long actualTimeout = Optional.ofNullable(timeout).orElse(3600L);
禁用无过期时间的写入：可在 RedisTemplate 上添加拦截器，对未设 TTL 的 set 操作打日志甚至抛异常

大 Key 存储 + 错误的序列化方式 = 双重内存炸弹

String 类型超过 10KB、Hash 元素超 5000 个，就属于 Redis 大 Key。但更危险的是：你用 Jackson2JsonRedisSerializer 存了一个 5MB 的 JSON 字符串，Redis 里它就是一个 key，可一旦 getObject 执行，Jackson 会把它全量解析成 Java 对象——这个对象在 JVM 堆里可能膨胀到 20MB（因对象头、引用、字符串编码等开销）。

禁止对已知大结构（如报表数据、导出文件内容）使用 getObject，改用 get 拿 byte[] 或 String 后流式处理
对必须反序列化的场景，改用 GenericJackson2JsonRedisSerializer（它不绑定具体 Class，减少泛型擦除带来的反射开销）
用 redis-cli --bigkeys 定期扫描，发现大 Key 后立刻拆分或转为分页存储，而不是在应用层硬扛

过期 Key 清理不及时的真相：不是 Redis 懒，是你的访问模式太“佛系”

Redis 的惰性删除只在你 get 或 getObject 时才检查过期。如果你的代码只写不读（比如纯写日志类 key）、或读操作被缓存/开关屏蔽，那些过期 key 就永远沉在 Redis 里，直到定期删除线程扫到——而它每 100ms 最多花 25ms，且只随机抽 20 个 key，根本赶不上写入速度。

不要依赖 Redis 自动清理，关键业务 key 必须主动控制生命周期，例如用 expire 单独设置，或用 Lua 脚本 SET key value EX 3600 原子写入
对时效敏感的数据（如登录态），加一层本地缓存（Caffeine）并设置 expireAfterWrite，让 JVM 主动丢弃，而不是等 Redis 过期
监控 expired_keys 和 evicted_keys 指标，如果前者长期为 0，说明惰性删除几乎没生效，得查访问路径是否绕过了 Redis 读取

最易被忽略的点：OOM 往往发生在低峰期。因为高峰期 GC 频繁反而能及时回收，而凌晨批量任务把一堆大对象 load 进来，又没及时释放引用，等到早上流量上来，老年代直接打满。别只盯着 Redis info memory，先用 jmap -histo 看 JVM 里谁占堆最多 —— 八成是某个反序列化出来的 List 或 Map 实例。