Java应用中配置Redis的maxmemory和淘汰策略关键在于Redis服务端配置而非Java代码，需结合部署环境设maxmemory为总内存40%–60%，并根据业务选allkeys-lfu、volatile-lru等策略，通过redis.conf静态配置或CONFIG SET动态生效。
Java 应用中配置 Redis 的 maxmemory 和淘汰策略，关键不在 Java 代码本身，而在于 Redis 服务端的配置与业务场景匹配。Java 客户端（如 Lettuce 或 Jedis）不直接控制内存策略，它只负责连接和发命令；真正起作用的是 Redis 实例启动时或运行中生效的 maxmemory 和 maxmemory-policy 设置。
明确 maxmemory 的合理取值
不能凭空设一个“看起来安全”的值，需结合实际部署环境和数据特征：
-
预留系统内存：Redis 进程本身、AOF 重写、RDB 快照、主从复制缓冲区等都会额外占用内存。建议将
maxmemory设为机器总内存的 40%–60%，避免触发系统 OOM Killer。 -
估算键值平均开销：一个简单字符串键值对通常占 100–200 字节（含元数据），带嵌套结构（如 Hash、ZSet）会更高。可用
INFO memory中的used_memory_human和total_keys粗略反推。 -
留出缓冲余量：比如预估缓存常驻数据约 800MB，建议设
maxmemory 1gb，而非刚好卡在 800MB，防止突发写入或内存碎片导致立即触发淘汰。
根据业务类型选淘汰策略
策略不是越“智能”越好，要匹配数据访问规律和语义约束：
-
缓存场景（推荐 allkeys-lru / allkeys-lfu）：
所有键都可被替换，无强保留需求。若请求有明显热点（如商品详情页），allkeys-lfu比allkeys-lru更稳；若访问时间局部性更强（如用户会话短期集中活跃），allkeys-lru更合适。 -
混合存储场景（推荐 volatile-lru / volatile-ttl）：
仅对加了EXPIRE的键淘汰，保留永久键（如配置项、白名单）。例如会话 ID 带 TTL，用户资料缓存也设 TTL，但系统参数键不设过期 —— 此时用volatile-lru可保核心配置不被误删。 -
短时任务/队列类数据（推荐 volatile-ttl）：
键的 TTL 差异大（如任务 5 分钟超时、通知 2 小时过期），优先淘汰即将到期的，避免堆积大量“僵尸”键。 -
绝对不允许丢失数据（noeviction）：
仅用于非缓存用途，如 Redis 作消息队列或持久化状态存储。此时必须配合监控告警+自动扩容，否则写操作会直接失败。
Java 项目中如何生效配置
配置不是写在 Java 里，而是通过运维或初始化脚本注入 Redis 实例：
立即学习“Java免费学习笔记（深入）”；
-
静态配置（推荐生产环境）：修改
redis.conf，重启前验证：maxmemory 2gbmaxmemory-policy allkeys-lfu -
动态配置（适合测试或灰度）：用 Java 调用 Redis 命令设置（需权限）：
jedis.configSet("maxmemory", "2gb");jedis.configSet("maxmemory-policy", "allkeys-lfu"); -
容器化部署（如 Docker）：通过
redis-server --maxmemory 2gb --maxmemory-policy allkeys-lfu启动，或挂载自定义 conf 文件。
验证与调优要点
配完不是一劳永逸，得看真实行为：
- 用
INFO stats查evicted_keys是否持续增长 —— 若每秒淘汰数百键，说明maxmemory过小或策略不匹配热点。 - 用
INFO memory观察mem_fragmentation_ratio：若 > 1.5，可能内存碎片高，考虑开启activedefrag yes（Redis 4.0+）。 - LFU 策略需注意：Redis 默认 LFU 计数器衰减周期是 1 分钟，高频低频混杂时可能滞后，可通过
lfu-log-factor调整灵敏度（值越大，衰减越慢，越倾向保留长期热点）。
