空值缓存更吃内存是因为每个空key仍占用100–200字节Redis内部结构开销，且因访问极少难以被LRU/LFU淘汰，若未设过期时间或统一设长TTL，易成“内存钉子户”导致OOM。
空值缓存为什么比正常缓存更吃内存
空值缓存本身不存业务数据，但每个 key 仍要占用 Redis 内部结构开销：dictEntry + SDS 字符串头 + 过期时间字段，实测约 100–200 字节/个。10 万个空 key 就是 10–20 MB，还不算哈希表扩容和内存碎片。更关键的是——这些 key 几乎不被访问（查一次返回 null，后续请求也命中它），导致 allkeys-lru 和 allkeys-lfu 都难以淘汰它们。
如果用了 volatile-lru 却漏设过期时间，或统一用 EX 3600 给空值，那它们就成了“内存钉子户”：既不会被访问触发惰性删除，又躲过了定期扫描的清理节奏（因为扫描只针对带过期时间的 key，且默认每轮只抽 20 个）。
别用 SET user:123 "" EX 60 填坑
这是最常见、最危险的操作。它表面防穿透，实际埋下三颗雷：
Redis 8.2.3
下载
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
-
""或"NULL"作为 value 没有语义区分，后续代码里满屏if (v == null || "".equals(v))，易错且难维护 - 所有空 key 共享同一 TTL，无法按业务敏感度分级（比如用户 ID 查无结果应比配置项更快过期）
- 一旦误配成
EX 3600，攻击脚本批量刷 10 万随机 ID，半小时就能把maxmemory打满，触发OOM command not allowed when used memory > 'maxmemory'
安全清理已堆积的空 key
别用 KEYS * —— 它会阻塞主线程。用 SCAN 分批 + 精准匹配更稳妥：
- 先采样确认模式：
redis-cli SCAN 0 MATCH user:* COUNT 100 | xargs -n 1 redis-cli GET，看哪些返回(nil)或空字符串 - 按命名规范批量删：如果空值都带
:null后缀，执行redis-cli --scan --pattern "user:*:null" | xargs -r redis-cli DEL - 若没统一后缀，可用
redis-cli --scan --pattern "user:*" | xargs -n 100 sh -c 'redis-cli MGET $@ | grep -q "^\$-1$\|^\$0$" && echo $@' | xargs -r redis-cli DEL（需配合 shell 判断）
真正要固化进代码层的防护点
清理只是救火，防复发靠设计：
- 布隆过滤器必须前置：在 DAO 层入口加
BloomFilter.mightContain(id)，仅对“可能存在的 ID”才走缓存 → DB 流程，拦截 99% 的无效查询 - 空值写入必须带短 TTL：推荐
redisTemplate.opsForValue().set(key, "NULL", 2, TimeUnit.SECONDS)，而非复用正常数据的 30 分钟 - 监控必须覆盖空值占比：用
INFO memory中的used_memory_human和DBSIZE，再结合SCAN抽样统计空 key 数量，超 30% 就告警
最难的不是写那行 set(..., 2, SECONDS)，而是让每个新上线的缓存逻辑都默认走布隆 + 短 TTL 路径——否则运维清完，发版五分钟，空 key 又回来了。
