必须用unlink替代del删除大key，因其主线程仅解引用并交由bio线程异步释放内存，避免阻塞；同时需redis≥4.0、开启lazyfree-lazy-user-del和activedefrag机制，并配合key拆分与分批处理。
Java 应用连接 Redis 时，遇到大 Key（如 String >10KB、Hash 元素超 5000 个）会显著拖慢主线程：删除耗 CPU、读取占带宽、网络传输延时高，还会加剧内存碎片。优化核心不是“怎么删得快”，而是“怎么让删和读不卡主线程 + 降低单次操作压力”。
用 UNLINK 替代 DEL 做异步删除
DEL 是同步阻塞操作，主线程要等内存真正释放完才返回；UNLINK 则把释放内存任务交给后台线程，主线程立刻返回。Jedis 和 Lettuce 都支持：
- Jedis：
jedis.unlink("big:key") - Lettuce：
redisClient.connect().sync().unlink("big:key") - 注意：Redis 服务端需 ≥4.0，且建议配合开启 lazy-free 机制（
lazyfree-lazy-user-del yes），双重保障释放不阻塞
拆分大 Key，从源头避免单点压力
比如一个存用户订单列表的 List，含 5 万条记录，不要用 LPUSH big:list ... 累加，改用时间或 ID 分片：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 按天分：key 命名为
user:123:orders:20260820、user:123:orders:20260819 - 按哈希槽分：对订单 ID 取模，生成
user:123:orders:0~user:123:orders:9共 10 个 key - 客户端读取时并行拉多个 key，再合并结果 —— 把单次 O(N) 拆成多个小 O(n)
批量清理时控制节奏，别一次扫光
用 SCAN 清理过期归档数据时，避免一次性拉几千个 key 导致瞬时内存回收压力大：
- 每次 SCAN 设置
COUNT 200，限制单次返回数量 - 每处理完一批（如 300 个 key），调用
Thread.sleep(5)暂停几毫秒，给 Redis 缓冲时间 - Java 调度任务中定期检查
INFO memory的mem_fragmentation_ratio，若 >1.8 就暂停清理，先执行CONFIG SET activedefrag yes
服务端必须开启主动碎片整理
只靠客户端优化不够。Redis ≥4.0 支持内存碎片自动整理，但默认关闭：
- 配置 redis.conf：
activedefrag yes - 调优参数（根据内存压力调整）：
active-defrag-threshold-lower 10（碎片率超 10% 开始整理）、active-defrag-cycle-min 25（最低 CPU 占用率） - 该功能依赖 jemalloc 分配器，物理机部署时确认已启用（避免使用 libc malloc）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
