必须设置maxmemory和淘汰策略:maxmemory限制内存上限(如2gb),maxmemory-policy选择allkeys-lru等8种策略之一,结合业务数据特性与访问模式精准选型,防止OOM。

Java项目中用Redis防止物理内存被撑满,关键不是“等快满了再处理”,而是提前配置好内存上限和淘汰策略,让Redis自己在内存接近阈值时主动清理旧数据。核心动作就两步:设上限、选策略。
必须设置 maxmemory 限制
Redis默认不限制内存,不设这个值等于没上保险。在 redis.conf 中明确指定:
- maxmemory 2gb(建议设为服务器总内存的60%~75%,避免挤占系统和其他进程)
- 不要写成
maxmemory 0或留空,否则 Redis 会持续占用直到 OOM - Spring Boot 项目可通过
spring.redis.jedis.pool.max-memory或配置类动态设置,但最终仍需落地到 Redis 实例的maxmemory
根据业务选对淘汰策略(LRU/LFU)
Java应用调用 Redis 时,数据是否带过期时间(EXPIRE)决定了该用哪类策略:
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis,支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
只做纯缓存(如接口结果、计算中间值) → 用
allkeys-lru或allkeys-lfu。
所有 key 都可淘汰,无需手动加过期时间,客户端更轻量。 -
混用缓存+持久数据(如用户配置、白名单) → 用
volatile-lru或volatile-lfu。
只淘汰设置了EXPIRE的 key,永久数据不受影响。 -
访问有明显热点(比如 Top100 商品被反复查) → 优先选
allkeys-lfu。
它比 LRU 更擅长保留高频 key,冷门数据哪怕刚写入也会被快速清理。 -
访问较均匀或周期性较强(如每小时刷新的报表缓存) →
allkeys-lru更稳。
避免 LFU 计数器把短期爆发访问误判为长期热点。
调优采样精度与衰减行为
Redis 的 LRU/LFU 都是近似算法,靠采样而非全量扫描,可通过配置微调效果:
立即学习“Java免费学习笔记(深入)”;
-
增大采样数:
maxmemory-samples 10(默认是 5),让 LRU 更接近真实最近访问顺序,代价是稍高 CPU 开销 -
调整 LFU 衰减:
lfu-decay-time 1(单位:分钟),控制计数器随时间自然下降的速度。
值越小,越快遗忘历史访问;适合访问模式变化快的场景(如促销期间流量突变) - 这些参数可在运行时用
CONFIG SET修改,无需重启 Redis
配合 Java 客户端做好兜底
策略生效的前提是 Redis 真的触发了淘汰,Java 层也要配合:
- 监控
evicted_keys指标(通过INFO memory或 Micrometer),持续上涨说明内存压力大或策略不合适 - 捕获
OOM command not allowed错误——这是noeviction策略下的典型报错,意味着你漏配了策略 - 避免在 Java 里大量写入超大 value(如 MB 级序列化对象),单个 key 过大会加速触达内存上限

















