缓存雪崩时Redis内存不一定涨，因其本质是缓存集体失效导致请求洪峰涌向下游，Redis自身used_memory往往下降或持平；真正暴涨的是数据库连接池、JVM堆内存和线程栈。
会，但不是 Redis 自身内存突增，而是数据库和应用层内存压力陡升 —— Redis 内存反而可能短暂下降（比如全量 @CacheEvict(allEntries = true) 后），真正暴涨的是数据库连接池、JVM 堆内存（大量 SQL 查询对象、结果集）、线程栈（阻塞等待 DB 响应）。
缓存雪崩时 Redis 内存为什么不一定涨？
缓存雪崩的本质是“缓存集体失效 + 请求洪峰”，Redis 本身只是丢了数据或变为空，INFO memory 显示的 used_memory 往往下降或持平；真正吃内存的是下游：
- 数据库瞬间涌入数倍于平时的查询，连接池满、SQL 执行堆栈膨胀、临时结果集驻留内存
- 应用层大量线程卡在 DB 查询上，每个线程占用栈空间（默认 1MB/线程），并发 2000 就可能吃掉 2GB JVM 堆外内存
- 若用了同步锁（如
synchronized或RedisLock）重建缓存，线程排队导致大量 WAITING 状态对象堆积
哪些操作会让 Redis 内存真的飙升？
真正触发 Redis 内存暴涨的，往往是雪崩后的“补救动作”而非雪崩本身：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
DEL+SET批量写入：旧缓存清空后，大量请求同时重建缓存，写入未压缩的 JSON 字符串、重复 key、未设 TTL 的数据 - 误用
@CacheEvict(allEntries = true)后又立刻@Cacheable全量回写，且新数据结构更臃肿（比如从 Hash 改成 String 存整个对象） - 客户端缓冲区积压：Jedis/Lettuce 连接未配置
client-output-buffer-limit，雪崩期间慢响应导致输出缓冲区持续堆积（尤其 pub/sub 或 bigkey 场景）
如何快速判断是不是 Redis 内存真在涨？
别只看 redis-cli info memory | grep used_memory，要交叉验证：
- 查
used_memory_peak和mem_fragmentation_ratio：如果后者 > 1.5 且used_memory持续爬升，说明内存碎片+真实增长 - 用
redis-cli --bigkeys或MEMORY USAGE定位具体 key：是否突然出现大量user:10000001类似无规律 key（可能是穿透攻击或日志误写） - 对比
instantaneous_ops_per_sec和rejected_connections：如果 ops 暴跌但 rejected 上升，大概率是客户端缓冲区满或 OOM killer 干预
雪崩本身不直接烧 Redis 内存，但它是系统性压力的导火索；真正危险的是后续重建逻辑失控、客户端配置失当、以及对“缓存空了就赶紧塞回去”这种直觉式修复的盲目执行。
