Java 实习生必须掌握的 Redis 核心知识点（工程向）

Ne0inhk

21 Mar 2026 — 7 min read

Java 实习生必须掌握的 Redis 核心知识点（工程向）

Redis 是 Java 后端面试中出现频率最高的中间件之一。
对实习生而言，面试官并不期待你会调优或源码级理解，
但必须清楚 Redis 是什么、能干什么、怎么用、会踩什么坑。

本文从 工程实用角度，总结 Java 实习生需要掌握的 Redis 核心知识。

一、Redis 是什么？解决什么问题？

Redis 本质是一个：

基于内存的 Key–Value 数据结构服务器

它主要解决三类问题：

性能问题：数据库太慢
并发问题：共享状态、计数
解耦问题：缓存、简单通信

在真实系统中，Redis 常见位置是：

Java Service → Redis → MySQL

二、Java 与 Redis 如何通信？（高频面试点）

结论先给出：

Java 和 Redis 之间，既不是 HTTP，也不是 RPC，而是 RESP 协议

RESP（Redis Serialization Protocol）
基于 TCP 长连接
极简、低延迟

在 Java 中你感知不到 RESP

因为你通常使用的是：

Jedis
Lettuce
Redisson
Spring Data Redis

例如：

redisTemplate.opsForValue().set("key","value");

底层流程是：

Java Client → RESP 命令 → Redis → RESP 返回

三、Redis 五大核心数据类型（重点）

1️⃣ String（最常用）

本质：key → 一个二进制值

SET k v GET k INCR counter

典型场景：

缓存 JSON
分布式计数器
分布式锁（SET NX EX）

2️⃣ Hash（对象型数据）

HSET user:1 name Tom age 18 HGET user:1 name

适合：

用户信息
配置对象

👉 比 String + JSON 更灵活

3️⃣ List（有序、可重复）

LPUSH queue task RPOP queue

典型场景：

简单消息队列
任务队列

4️⃣ Set（无序、唯一）

SADD tags java redis SMEMBERS tags

典型场景：

去重
标签系统
共同好友

5️⃣ ZSet（有序集合，面试常问）

ZADD rank 100 user1 ZREVRANGE rank 09 WITHSCORES

典型场景：

排行榜
延时队列

四、Redis 的数据模型抽象（加分项）

从逻辑层看，Redis 可以抽象为：

String: map<string, bytes> Hash: map<string, map<string, bytes>> List: map<string, list<bytes>> Set: map<string, set<bytes>> ZSet: map<string, map<string, double>> + score ordered index

这是逻辑模型，不是底层实现
底层会根据数据规模使用不同编码优化

五、Redis 常见使用场景（必须会讲）

1️⃣ 缓存

读多写少
减轻数据库压力

2️⃣ 分布式锁（知道即可）

SET lock_key value NX EX 10

核心点：

原子性
超时释放

3️⃣ 计数 / 限流

INCR request_count

4️⃣ 简单消息队列

List（简单）
Stream（推荐）

六、Redis 和 HTTP / RPC 的关系（容易混）

Redis 不是 HTTP 服务
也不是 RPC 服务
它是 数据结构服务器

👉 Java 服务之间：

用 HTTP / RPC 调用
用 Redis 共享数据或解耦

七、Java 实习生常见 Redis 面试坑

❌ 把 Redis 当数据库

Redis 是缓存 / 中间件
不是强一致存储

❌ 忽略缓存失效

TTL 没设
缓存穿透 / 雪崩

❌ 用 Redis 当 MQ

List 没 ack
消息丢失风险

八、你至少要会的 Java API（Spring）

// String redisTemplate.opsForValue().set("k","v");// Hash redisTemplate.opsForHash().put("user:1","name","Tom");// List redisTemplate.opsForList().leftPush("queue","task");// Set redisTemplate.opsForSet().add("tags","java");// ZSet redisTemplate.opsForZSet().add("rank","u1",100);

九、Redis 如何删除过期 key？

这个问题非常核心，而且是 Redis 面试的分水岭题。
我不直接甩结论，而是用**「从表象 → 机制 → 底层实现」**一步一步给你拆清楚，你会发现 Redis 的设计其实非常“工程化”。

1、先给一句「标准结论」（你可以直接背）

Redis 的 key 过期是通过
过期字典（expiration dictionary）+ 惰性删除 + 定期删除
共同实现的，
并不是为每个 key 单独维护一个定时器。

这是核心答案，下面我帮你把每个词拆明白。

2、Redis 是怎么“记录” key 的过期时间的？

关键点 1：过期时间不是存在 value 里的

Redis 内部维护了 两张表：

db.dict : key -> value db.expires : key -> expireTimestamp (毫秒)

👉 只有设置了过期时间的 key，才会出现在 expires 表中

例如：

SET a 123 EXPIRE a 10

内部变成：

dict: a -> 123 expires: a -> 1690000000000

3、Redis 如何删除过期 key？（重点）

很多人会误以为：

❌ “Redis 给每个 key 都设置了一个定时器”

这是完全错误的，原因是：

key 数量可能是百万 / 千万级
定时器会把 CPU 打爆

4、Redis 实际采用的是：两种策略配合

策略一：惰性删除（Lazy Deletion）

是什么？

不主动删
等你来访问 key 的时候，顺便检查

流程是：

客户端 GET key ↓ 检查 key 是否设置了过期时间 ↓ 如果过期了： 删除 key 返回 nil

优点

几乎不耗 CPU
简单

缺点

如果 key 一直不被访问，就永远不会删

👉 所以 惰性删除不够

策略二：定期删除（Active Expiration）

是什么？

Redis 会定期随机抽样一部分过期 key 来清理

执行频率

默认 每秒 10 次（hz = 10）

每次做什么？

从 expires 表中 随机抽取一批 key
检查是否过期
如果过期就删除
如果过期比例过高 → 继续抽

👉 这是一个 自适应算法

伪代码理解：

do { sample N keys from expires delete expired keys } while (expired_ratio > threshold && time_not_exceeded)

⚠️ 重点：不是全量扫描！

随机抽样
时间受限
不阻塞主线程太久

5、为什么 Redis 不用“定时器”？

这是一个非常好的反问点。

原因只有一个：

规模问题

百万 key = 百万定时器
定时器调度本身就是 O(logN)
Redis 是单线程，顶不住

👉 所以 Redis 选择了：

概率正确 + 性能可控

6、过期 key 一定会“立刻”删除吗？

❌ 不一定

可能存在三种状态：

逻辑过期
- 已经过期时间
- 但还在内存里
访问触发删除
- GET 时删
定期扫描删除
- 后台清理

👉 对用户来说是 “看起来已经过期”

7、过期 key 和内存淘汰策略的关系（进阶）

⚠️ 这是很多人漏掉的点

过期 ≠ 淘汰
过期是：时间到了必须删
淘汰是：内存不够被迫删

淘汰策略例如：

LRU
LFU
allkeys / volatile

👉 如果内存满了：

即使 key 没过期
也可能被淘汰

8、结合 Java 实习生的“工程理解版”

你可以这样理解：

Redis 不追求过期时间的绝对精确，
而是通过惰性删除保证访问正确性，
通过定期删除控制内存占用，
在单线程模型下取得性能和一致性的平衡。

9、面试官追问时，你可以这样接（高级）

Q：那 Redis 会不会内存泄漏？

👉 回答：

不会。
即使 key 一直不被访问，
定期删除机制也会逐步清理过期 key，
同时在内存压力下，
淘汰策略也会兜底。

面试一句话总结（直接背）

Redis 是基于内存的 Key–Value 数据结构服务器，
Java 应用通过 TCP 上的 RESP 协议与 Redis 通信。
Redis 提供多种数据结构以支持高性能缓存、计数、
排行榜和简单消息队列等场景，
在系统中主要用于提升性能和解耦。

给 Java 实习生的学习建议（真心话）

如果你是 Java 实习生：

第一阶段：会用（String / Hash / List）
第二阶段：理解场景（缓存 / 锁 / 计数）
第三阶段：知道坑（雪崩 / 穿透）

👉 不需要一上来啃源码
👉 但一定要理解“为什么这么设计”