面试八股 on 方糖猫Blog

从Redis核心原理到 IPTV 视频项目落地

Tue, 28 Sep 2021 10:00:00 +0800

从Redis核心原理到 IPTV 视频项目落地

先系统梳理 Redis 的核心原理与面试高频知识点，再结合 IPTV（交互式网络电视）视频业务场景，给出可直接运行的 Demo。最后讨论 Redis 为什么不适合长期存储、常见踩坑点，以及 List / Pub/Sub / Stream 三种消息队列实现。

一、Redis 是什么？一句话定位

Redis（Remote Dictionary Server）是一个开源的、基于内存的高性能键值对数据库，支持多种数据结构、持久化、高可用与分布式扩展。

graph LR
    A[Redis] --> B[内存存储]
    A --> C[数据结构服务器]
    A --> D[单线程命令执行]
    A --> E[IO 多路复用]
    A --> F[持久化 + 高可用]
    B --> G[读写毫秒级]
    C --> H[String/Hash/List/Set/ZSET/Stream/Bitmap/Geo/HyperLogLog]
    F --> I[RDB/AOF/主从/哨兵/Cluster]

与 Memcached 等纯缓存不同，Redis 的核心价值在于丰富的数据结构与原子操作，可以直接在内存中完成排序、计数、限流、去重、队列等复杂逻辑。

二、Redis 为什么快？

面试常问「Redis 为什么快」，通常从四个层面回答：

原因	说明
内存操作	数据存于内存，无需磁盘寻道，访问速度是 SSD 的千倍以上。
单线程命令执行	避免多线程上下文切换、锁竞争，CPU 缓存命中率更高。
IO 多路复用	基于 epoll/kqueue/select 用一个线程处理大量连接。
高效数据结构	String 底层 SDS、ZSET 底层跳表+字典、List 底层 quicklist 等。

graph TB
    subgraph Redis 6/7 线程模型
        M[主线程<br/>命令执行 + IO 多路复用]
        IO[IO 线程池<br/>仅网络读写]
        BG[后台进程<br/>RDB fork / AOF rewrite]
    end
    C1[Client 1] --> M
    C2[Client 2] --> M
    C3[Client 3] --> M
    M <--> IO
    M -.-> BG

注意：Redis 6/7 引入的多线程只用于网络 IO 读写，命令执行依旧是单线程。所以单条慢命令仍会阻塞整个实例。

三、Redis 数据类型与使用场景

3.1 五种基本数据类型

类型	底层结构	典型场景
String	SDS（简单动态字符串）	缓存、计数器、分布式锁、Session
Hash	ziplist / hashtable	对象缓存、用户信息、EPG 节目单
List	quicklist（ziplist + 双向链表）	消息队列、最新 N 条记录
Set	intset / hashtable	去重、共同关注、抽奖
ZSET	ziplist / skiplist + dict	排行榜、延时队列、范围查询

注：表中 ziplist 在 Redis 7 起已被 listpack 替代（动机见 §4.2），配置项改名 *-max-listpack-*，旧名仍兼容。

3.2 三种特殊数据类型

类型	说明	场景
Bitmap	位数组，按位操作	用户签到、在线状态、UV 统计
HyperLogLog	基数估计算法	海量 UV 去重计数，误差约 0.81%
Geo	地理位置坐标	附近的人、POI 搜索

3.3 String：最常用却被低估

String 不仅能存字符串，还能存整数、浮点数、二进制数据。常用命令：

SET key value EX 3600
GET key
INCR view_count
INCRBY view_count 10
SETNX lock:order:123 true EX 30  # 分布式锁核心命令

SDS 的优势（相对 C 字符串）：

O(1) 获取长度。
二进制安全，可存图片、序列化数据。
预分配空间，减少内存重分配次数。
杜绝缓冲区溢出。

3.4 Hash：对象缓存首选

Hash 适合存「一组字段」的对象，比 JSON String 更节省内存、更新更灵活。

HSET user:1001 name "张三" age 30 city "北京"
HGET user:1001 name
HGETALL user:1001
HINCRBY user:1001 age 1

3.5 ZSET：排行榜的王牌

ZSET 底层同时维护「跳表」和「字典」：

跳表（skiplist）：支持 O(log N) 的范围查询和排序。
字典（dict）：支持 O(1) 按 member 查 score。

ZADD hot:tv 1000 "庆余年"
ZADD hot:tv 800 "狂飙"
ZINCRBY hot:tv 50 "狂飙"
ZREVRANGE hot:tv 0 9 WITHSCORES
ZREVRANK hot:tv "狂飙"

3.6 List 与 Stream：队列双雄

List 适合简单队列，Stream 适合生产级消息队列，后面第十四部分会详细对比。

3.7 Bitmap 与 HyperLogLog：海量 UV 统计的利器

Bitmap 为什么能天然去重？

Bitmap 本质是一个超长 bit 数组，每个 bit 只能是 0 或 1。把 user_id 作为偏移量（offset），用户访问一次就把对应位置 1：

天然去重：同一用户重复访问，置的都是同一个 bit，无需额外判断。
极致省内存：1 亿用户只需 1 亿 bit ≈ 12MB；而 Set 存 1 亿个 ID 要占用数 GB。
支持位运算：BITOP AND/OR 可以直接算多日留存（今天访问 AND 昨天也访问）。

SETBIT uv:20210928 10086 1   # 用户 10086 访问
SETBIT uv:20210928 10086 1   # 重复访问，结果不变
BITCOUNT uv:20210928         # 直接得出 UV 数

局限：要求 user_id 是连续整数，ID 稀疏时浪费内存。

HyperLogLog 为什么 12KB 能数一亿？

HyperLogLog 基于概率估计算法：把每个元素 hash 成均匀分布的随机数，观察 hash 值二进制串中前导零的最大个数。

类比抛硬币：想连续抛出 N 次正面，平均要抛 2^N 次。反过来，如果见过最长连续 N 次正面，就估计大约抛了 2^N 次——前导零越多，说明见过的不同元素越多。
单次估计误差大，所以内部用 16384 个分桶（寄存器，每个 6 bit） 分别记录，再取调和平均数消除偶然性，最终误差稳定在 0.81% 左右。
内存恒定 约 12KB，与元素个数无关：统计 1 亿 UV 还是 10 亿 UV 都是 12KB。

PFADD uv:20210928 "user:10086"
PFADD uv:20210928 "user:10086"  # 重复添加不影响计数
PFCOUNT uv:20210928             # 估算 UV

局限：有误差、不可逆（不能取出具体是哪些用户）。

怎么选：

需求	推荐
精确计数、算多日留存（交并集）、ID 是连续整数	Bitmap
只要近似 UV、数据量极大、ID 是任意字符串	HyperLogLog

四、Redis 底层数据结构速览

graph TD
    A[Redis 数据类型] --> B[String]
    A --> C[Hash]
    A --> D[List]
    A --> E[Set]
    A --> F[ZSET]
    B --> G[SDS]
    C --> H[ziplist]
    C --> I[hashtable]
    D --> J[quicklist]
    E --> K[intset]
    E --> L[hashtable]
    F --> M[ziplist]
    F --> N[skiplist + dict]

底层结构	特点
SDS	带长度、预分配、二进制安全。
ziplist	紧凑列表，小数据量时省内存；大数据量时改为 hashtable/skiplist。
listpack	ziplist 的修正版（Redis 7+）：entry 只记自身长度，消灭连锁更新。
quicklist	List 的底层，由多个紧凑块（Redis 7 前是 ziplist，之后是 listpack）节点组成的双向链表。
hashtable	标准哈希表，渐进式 rehash 避免一次性阻塞。
intset	Set 在元素全为整数且数量少时的紧凑实现。
skiplist	多层索引链表，实现 ZSET 的有序范围查询。

下面把 5 种核心结构「画」出来。

4.1 SDS（Simple Dynamic String）

Redis 没有直接用 C 字符串，而是包了 SDS：

flowchart LR
    L["len<br/>已用长度（4B）<br/>= 5"] --- A["alloc<br/>总容量<br/>= 8"] --- F["flags<br/>编码位<br/>= 0"] --- B["buf[]<br/>实际字符/二进制数据<br/>H e l l o \0 ..."]
    N1["O(1) 取长度"] -.-> L
    N2["末尾保留 \0<br/>兼容 C 字符串函数"] -.-> B

len：已用长度，取长度 O(1)。
alloc：分配的总空间；free = alloc - len 可减少内存重分配。
二进制安全：内容中间可以有 \0，长度由 len 决定。
预分配：修改时若 free 足够就不 realloc；不足时按 2 倍或 1MB 上限预分配。

4.2 ziplist（压缩列表）

ziplist 是一块连续内存，把所有 entry 紧凑排列：

flowchart LR
    A["zlbytes<br/>总字节数<br/>4B"] --- B["zltail<br/>尾偏移量<br/>4B"] --- C["zllen<br/>节点数<br/>2B"] --- D["entry1<br/>变长字节"] --- E["entry2<br/>变长字节"] --- F["..."] --- G["zlend<br/>0xFF<br/>1B"]

每个 entry 的内部结构：

flowchart LR
    A["prevlen<br/>前节点长度<br/>1B 或 5B"] --- B["encoding<br/>编码/长度类型<br/>1B 或更多"] --- C["content<br/>实际数据<br/>变长"]

连续内存、无额外指针，所以省内存。
插入/删除需要整体 memmove，因此只用于小数据量。
Hash/List/ZSET 元素少且单元素短时先用 ziplist，超过阈值升级为 hashtable/skiplist。

listpack（Redis 7 的替代者）：ziplist 的致命伤就藏在 prevlen 里——每个 entry 要记录前一个 entry 的长度：前 entry 小于 254 字节时 prevlen 占 1B，达到 254 字节时占 5B。于是一个 entry 从 253 涨到 254 字节，会让后面每个 entry 的 prevlen 从 1B 膨胀到 5B，膨胀又可能触发下一个 entry 继续膨胀——连锁更新，最坏 O(N²)。

listpack 的修法：每个 entry 只记录自己的总长度，且存在 entry 末尾，entry 之间互不引用——改任何一个 entry 都不会波及邻居，连锁更新从根上消失。Redis 7 起 Hash/List/ZSET 的小对象编码全部换成 listpack，配置项同步改名（hash-max-listpack-entries 等，旧的 *-ziplist-* 名仍兼容）。面试回答「ziplist 和 listpack 的区别」，核心就是这一句：ziplist 记前驱长度所以连锁更新，listpack 记自身长度所以免疫。

4.3 quicklist（快速列表）

Redis 3.2 后，List 的底层是 quicklist = 双向链表 + ziplist：

flowchart LR
    H["head"] --> A["ziplist A<br/>[a|b|c]<br/>count=3<br/>sz=..."] <--> B["ziplist B<br/>[d|e|f|g]<br/>count=4<br/>sz=..."] <--> C["..."]
    N["每个节点是一个 ziplist<br/>节点之间用 prev/next 指针连接"] -.-> A

quicklistNode 结构：

flowchart LR
    A["prev<br/>指针"] --- B["next<br/>指针"] --- C["zl<br/>ziplist"] --- D["sz<br/>字节数"] --- E["count<br/>元素个数"] --- F["encoding<br/>是否压缩"]

结合了双向链表「插入删除快」和 ziplist「省内存」的优点。
每个节点只存少量元素，避免单个 ziplist 太大导致 memmove 开销。
Redis 7 起节点从 ziplist 换成 listpack（动机见 §4.2），但 quicklist 的「链表 + 紧凑块」思想不变。

4.4 intset（整数集合）

Set 在元素全为整数且数量少时使用 intset，否则升级为 hashtable：

flowchart LR
    A["encoding<br/>编码类型<br/>2B/4B/8B"] --- B["length<br/>元素个数<br/>4B"] --- C["contents[]<br/>有序整数数组<br/>[1] [3] [5] [7] [9] ..."]

有序数组，支持二分查找 O(log N)。
所有元素用同一 encoding；加入更大范围整数时可能整体升级（如 int16 → int32），升级是 O(N)。
无重复元素（Set 语义）。

4.5 skiplist（跳表）

ZSET 同时维护 skiplist + dict：

skiplist：按 score 排序，支持范围查询 / 排名 O(log N)。
dict：按 member 查 score，O(1)。

普通有序链表只能顺序扫描，跳表加了多层「快速通道」：

flowchart LR
    subgraph L3["level 3"]
        A3["1"] --> B3["9"] --> C3["15"]
    end
    subgraph L2["level 2"]
        A2["1"] --> B2["5"] --> C2["9"] --> D2["13"] --> E2["15"]
    end
    subgraph L1["level 1"]
        A1["1"] --> B1["3"] --> C1["5"] --> D1["7"] --> E1["9"] --> F1["11"] --> G1["13"] --> H1["15"]
    end
    A3 --- A2 --- A1
    B3 --- C2 --- E1
    C3 --- E2 --- H1
    HEAD["头节点"] -.-> A1
    H1 -.-> TAIL["尾节点"]

跳表节点结构：

flowchart LR
    A["member<br/>成员字符串<br/>（sds）"] --- B["score<br/>分数<br/>（double）"] --- C["forward[] 数组<br/>[L1指针， L2指针， L3指针， ...]<br/>最高层数 = 随机 1~32"]

概率平衡：不用像红黑树那样做复杂旋转。
查找 score=11 时，先在高层大步跳跃，再逐层下降，平均 O(log N)。
配合 dict 实现 ZSCORE 的 O(1) 查询。

五、Redis 持久化：RDB 与 AOF

Redis 提供两种持久化方式，各有优劣。

5.1 RDB（Redis Database）

在指定时间间隔内将内存数据集快照写入磁盘。

save 900 1      # 900 秒内至少 1 次修改则触发
save 300 10     # 300 秒内至少 10 次修改则触发
save 60 10000   # 60 秒内至少 10000 次修改则触发

优点：

文件紧凑，适合备份和灾难恢复。
恢复速度快。

缺点：

两次快照之间数据可能丢失。
bgsave 通过 fork() 子进程生成，大数据集时可能阻塞主线程。

5.2 AOF（Append Only File）

将每次写操作命令追加到日志文件。

appendonly yes
appendfsync everysec  # 每秒刷盘一次（推荐）
# appendfsync always  # 每次写都刷盘，最安全但最慢
# appendfsync no      # 由操作系统决定，最快但不安全

优点：

数据安全性更高，默认最多丢失 1 秒数据。

缺点：

文件体积大。
恢复速度慢。
AOF 重写（rewrite）时会占用额外资源。

5.3 混合持久化（Redis 4.0+）

AOF 重写时先写入 RDB 全量数据，再追加增量 AOF，兼顾恢复速度和数据安全。

aof-use-rdb-preamble yes

graph LR
    A[持久化选择] --> B[RDB]
    A --> C[AOF]
    A --> D[混合持久化]
    B --> E[适合备份/快速恢复]
    C --> F[适合低丢失容忍]
    D --> G[生产推荐]

八股重点：Redis 的持久化是「灾难恢复手段」，不是「主存储方案」。

六、过期删除与内存淘汰

6.1 过期删除策略

Redis 对过期 Key 采用两种策略结合：

策略	说明	优点	缺点
惰性删除	访问 Key 时检查是否过期，过期则删除。	CPU 开销小	过期 Key 可能长期占用内存
定期删除	每隔一段时间随机抽查部分 Key 删除。	平衡内存与 CPU	仍可能有漏网之鱼

6.2 内存淘汰策略

当内存达到 maxmemory 时，根据 maxmemory-policy 决定如何淘汰：

策略	说明
`noeviction`	不淘汰，写操作直接报错。
`allkeys-lru`	所有 Key 中淘汰最近最少使用。
`volatile-lru`	只在设置了 TTL 的 Key 中淘汰最近最少使用。
`allkeys-random`	所有 Key 中随机淘汰。
`volatile-random`	只在设置了 TTL 的 Key 中随机淘汰。
`volatile-ttl`	淘汰即将过期的 Key。
`allkeys-lfu`	所有 Key 中淘汰使用频率最低的。
`volatile-lfu`	只在设置了 TTL 的 Key 中淘汰使用频率最低的。

生产建议：

必须设置 maxmemory。
缓存场景推荐 allkeys-lru 或 allkeys-lfu。
有冷热区分时可用 volatile-lru，但必须给 Key 设置 TTL。

七、Redis 高可用架构

7.1 主从复制（Replication）

一主多从，读流量分摊到从节点。

graph LR
    M[Master<br/>写 + 读] -->|全量/增量同步| S1[Slave 1<br/>读]
    M --> S2[Slave 2<br/>读]
    M --> S3[Slave 3<br/>读]

复制过程：

Slave 发送 PSYNC runId offset。
如果 runId 一致且 offset 在复制积压缓冲区中，则增量同步。
否则全量同步：Master 执行 bgsave 生成 RDB，发送给 Slave。

复制延迟问题：

主从异步复制必然存在延迟。
读从库时可能读到旧数据，需要业务容忍或强制走主库。

7.2 哨兵（Sentinel）

实现自动故障转移，解决主节点宕机问题。

graph TB
    subgraph Sentinel 集群
        Se1[Sentinel 1]
        Se2[Sentinel 2]
        Se3[Sentinel 3]
    end
    M[Master] --> S1[Slave 1]
    M --> S2[Slave 2]
    Se1 -->|监控| M
    Se2 -->|监控| M
    Se3 -->|监控| M
    Se1 -.-> Se2
    Se2 -.-> Se3

核心机制：

主观下线（SDOWN）：单个 Sentinel 认为 Master 不可用。
客观下线（ODOWN）：多数 Sentinel 达成一致。
Leader 选举：Sentinel 之间通过 Raft 算法选举出执行故障转移的 Leader。
故障转移：选一个 Slave 提升为 Master，通知其他 Slave 和客户端。

7.3 Cluster 集群

Redis Cluster 采用无中心架构，数据按槽位分布。

graph TB
    subgraph Redis Cluster
        N1[Node 1<br/>0-5460]
        N2[Node 2<br/>5461-10922]
        N3[Node 3<br/>10923-16383]
    end
    N1 <--> N2
    N2 <--> N3
    N1 <--> N3

关键概念：

集群共有 16384 个槽（slot）。
每个 Key 通过 CRC16(key) % 16384 计算所属槽。
每个 Master 负责一部分槽，可配置 Slave 做高可用。
客户端访问错误节点时，会收到 MOVED 或 ASK 重定向。

MOVED vs ASK：

MOVED：槽已经永久迁移到目标节点。
ASK：槽正在迁移中，先访问目标节点一次。

八、事务与 Lua 脚本

8.1 事务（MULTI/EXEC/DISCARD/WATCH）

MULTI
SET a 1
INCR b
EXEC

特点：

命令按顺序入队，EXEC 时一次性执行。
执行期间不会被其他客户端打断。
但没有回滚机制：如果某条命令语法错误，整个事务不执行；如果运行时错误（如 INCR 字符串），后续命令仍会执行。

8.2 Lua 脚本

EVAL "return redis.call('incr', KEYS[1])" 1 counter

特点：

整个脚本作为一个整体在单线程中原子执行。
适用于需要多个命令且要保证原子性的场景，如秒杀、分布式锁、限流。
集群模式下所有 Key 必须落在同一 slot，否则需要加 hash tag，如 {user}:1001:profile。

九、缓存经典问题

9.1 缓存穿透

问题：查询不存在的数据，缓存不命中，请求直接打到数据库。

解法：

缓存空值（设置短 TTL）。
使用布隆过滤器预先判断 Key 是否存在。

9.2 缓存击穿

问题：热点 Key 突然过期，大量请求同时打到数据库。

解法：

热点 Key 设置永不过期，异步更新。
加互斥锁（SETNX），只允许一个线程重建缓存。

9.3 缓存雪崩

问题：大量 Key 同时过期，或 Redis 宕机，数据库压力陡增。

解法：

给 TTL 加随机值，避免同时失效。
多级缓存（本地 + Redis）。
熔断降级。

9.4 缓存与数据库一致性

常见策略：

策略	说明	问题
Cache Aside	读：先读缓存，未命中读 DB 并写回缓存；写：先更新 DB，再删缓存。	短暂不一致
Read/Write Through	由缓存层统一维护 DB 和缓存。	实现复杂
Write Behind	先写缓存，异步写 DB。	可能丢数据

最常用的是 Cache Aside，配合「先更新数据库，再删除缓存」+ 延时双删 + 消息队列补偿，能在大多数场景下保证最终一致。

十、Redis 在 IPTV 系统中的角色

IPTV 系统的特点是：高并发读、强实时性、热点集中、写流量脉冲式。用户在换台、看 EPG、播放点播、抢购付费节目时，系统需要在毫秒级返回结果。

flowchart TB
    subgraph 用户层
        A[机顶盒 / 手机 / Web]
    end

    subgraph 接入层
        B[CDN / 边缘节点]
        C[API Gateway]
    end

    subgraph 应用层
        D[鉴权服务]
        E[EPG 服务]
        F[播放调度服务]
        G[订单 / 秒杀服务]
    end

    subgraph 数据层
        H[(MySQL / 长视频元信息)]
        I[(对象存储 OSS)]
        J[(Redis 缓存 + 实时计算)]
    end

    A --> B --> C
    C --> D & E & F & G
    D --> J
    E --> J
    F --> J
    G --> J
    E --> H
    F --> I
    G --> H
    J -.-> H

场景	Redis 数据结构	作用
用户会话 / Token	String + EXPIRE	毫秒级鉴权
EPG 节目单缓存	Hash / JSON String	减少数据库查询
热播榜单 / 推荐位	Sorted Set (ZSET)	实时排序
播放限速 / 防刷	Lua + INCR + EXPIRE	滑动窗口限流
秒杀 / 付费解锁	SETNX + DECR + Lua	库存扣减
消息通知 / 任务队列	List / Stream	异步解耦

十一、IPTV 项目 Demo

11.1 用户会话缓存

import redis
import uuid
import time

r = redis.Redis(host='localhost', port=6379, db=0, decode_responses=True)

def login(user_id: str, device_id: str, ttl: int = 3600) -> str:
    token = str(uuid.uuid4())
    key = f"session:{token}"
    r.hset(key, mapping={
        "user_id": user_id,
        "device_id": device_id,
        "login_at": str(time.time())
    })
    r.expire(key, ttl)
    return token

def auth(token: str) -> dict | None:
    return r.hgetall(f"session:{token}")

11.2 EPG 节目单缓存

import json
from datetime import datetime

def cache_epg(channel_id: str, programs: list[dict]):
    key = f"epg:{channel_id}:{datetime.today().strftime('%Y%m%d')}"
    pipe = r.pipeline()
    for p in programs:
        pipe.hset(key, p['start_time'], json.dumps(p))
    pipe.expire(key, 86400 * 2)
    pipe.execute()

def get_program(channel_id: str, start_time: str) -> dict | None:
    data = r.hget(f"epg:{channel_id}:{datetime.today().strftime('%Y%m%d')}", start_time)
    return json.loads(data) if data else None

11.3 热播排行榜

def record_view(program_id: str, score: float = 1.0):
    r.zincrby("hot:tv:daily", score, program_id)

def top_n(n: int = 10) -> list[tuple[str, float]]:
    return r.zrevrange("hot:tv:daily", 0, n - 1, withscores=True)

11.4 滑动窗口限流

LIMIT_SCRIPT = """
local key = KEYS[1]
local window = tonumber(ARGV[1])
local limit = tonumber(ARGV[2])
local now = tonumber(ARGV[3])
local min = now - window

redis.call('zremrangebyscore', key, '-inf', min)
local count = redis.call('zcard', key)
if count < limit then
    redis.call('zadd', key, now, now)
    redis.call('expire', key, math.ceil(window / 1000))
    return 1
else
    return 0
end
"""

limiter = r.register_script(LIMIT_SCRIPT)

def allow(user_id: str, max_qps: int = 10, window_ms: int = 1000) -> bool:
    key = f"rate_limit:{user_id}"
    now = int(time.time() * 1000)
    return bool(limiter(keys=[key], args=[window_ms, max_qps, now]))

11.5 秒杀 / 限时解锁

SECKILL_SCRIPT = """
local key = KEYS[1]
local user_id = ARGV[1]
local stock = tonumber(redis.call('get', key) or '0')
if stock <= 0 then
    return -1
end
if redis.call('sismember', key .. ':users', user_id) == 1 then
    return 0
end
redis.call('decr', key)
redis.call('sadd', key .. ':users', user_id)
return 1
"""

seckill = r.register_script(SECKILL_SCRIPT)

def try_buy(activity_id: str, user_id: str, total_stock: int) -> int:
    key = f"seckill:{activity_id}:stock"
    r.setnx(key, total_stock)
    return int(seckill(keys=[key], args=[user_id]))

十二、为什么 Redis 不适合做长期存储？

12.1 持久化不是主存储

RDB 会丢数据，AOF 文件大且恢复慢。Redis 的持久化定位是「灾难恢复」，不是「可靠主存」。

12.2 内存成本过高

内存价格是 SSD 的 10-50 倍。IPTV 的媒资、播放记录、订单流水动辄几十 TB，全放 Redis 不现实。

12.3 单线程执行风险

大数据集下，一个 KEYS *、HGETALL 或慢查询可能阻塞整个实例。

12.4 缺乏复杂查询能力

Redis 不支持 SQL、JOIN、二级索引。长期业务数据需要分析统计时，应使用 MySQL / PostgreSQL / ClickHouse。

结论：

Redis 适合「热数据 + 临时状态 + 实时计算」，价值在于速度；长期存储应交给磁盘数据库 + 对象存储。

十三、Redis 容易踩坑的地方

坑	说明	解法
大 Key	String > 10MB，集合元素百万级	拆分、分片、UNLINK 异步删除
热 Key	单个 Key 被高频访问	本地缓存、Key 分片、Cluster
缓存穿透/击穿/雪崩	缓存失效导致 DB 被打挂	布隆过滤器、互斥锁、随机 TTL
未设置 maxmemory	内存打满后写操作报错	设置 maxmemory 和淘汰策略
误用 KEYS	`KEYS *` 扫描全库阻塞主线程	生产禁用，改用 SCAN
Lua 跨 slot	Cluster 下脚本 Key 不在同一 slot	使用 hash tag `{user}:1001:xxx`
事务没有回滚	EXEC 后某命令失败不会撤销前面命令	业务层保证幂等，或用 Lua
主从延迟	读从库可能读到旧数据	对一致性要求高的读走主库

十四、Redis 做消息队列的方法

14.1 List：轻量队列

flowchart LR
    P[Producer] -->|LPUSH queue:transcode task| R[(Redis List)]
    C[Consumer] -->|BRPOP queue:transcode 5| R
    C --> S[执行转码]

r.lpush("queue:transcode", json.dumps({"video_id": "v123"}))
_, task = r.brpop("queue:transcode", timeout=5)

优点：简单、阻塞读。缺点：无 ACK、无多消费者组、无消息回溯。

14.2 Pub/Sub：实时广播

r.publish("live:start", json.dumps({"channel_id": "cctv1"}))

优点：实时、多订阅者。缺点：不持久化，消费者断线期间消息丢失。

14.3 Stream：生产级队列

r.xadd("mq:events", {"event": "video:play", "user_id": "u10086"})

r.xgroup_create("mq:events", "group_log", id="0", mkstream=True)

messages = r.xreadgroup(
    groupname="group_log",
    consumername="worker_1",
    streams={"mq:events": ">"},
    count=10,
    block=5000
)
for stream, entries in messages:
    for msg_id, fields in entries:
        process(fields)
        r.xack("mq:events", "group_log", msg_id)

优点：支持消费者组、ACK、消息回溯。

方式	推荐场景
List	简单任务队列
Pub/Sub	实时广播
Stream	生产级消息队列

十五、总结

《Redis in Action》的核心思想可以概括为一句话：把 Redis 当成内存里的数据结构工具箱，而不是数据库。

Redis 适合：

缓存加速（会话、配置、热点数据）。
实时计算（排行榜、计数器、限流、秒杀）。
异步解耦（List / Pub/Sub / Stream）。

Redis 不适合：

长期持久化存储。
复杂查询与大数据分析。
超大数据集主存储。

避免踩坑的关键是：控制 Key 大小、设置合理 TTL、配置淘汰策略、慎用阻塞命令、理解持久化边界。Redis 用好了是神兵利器，用错了就是生产事故的导火索。

JVM 内功修炼：运行时数据区、GC 演进与现代调优实践

Wed, 28 Mar 2018 14:00:00 +0800

JVM 内功修炼：运行时数据区、GC 演进与现代调优实践

JVM 是 Java 程序员逃不掉的「操作系统」。懂它不是为了背八股，而是为了在 OOM、Full GC、CPU 飙升时，能一眼定位根因并给出调优方案。

一、高层次思想：JVM 在帮你解决什么问题？

JVM 的核心职责可以抽象成三件事：

一次编译，到处运行：通过字节码 + 解释/编译执行，屏蔽底层 OS 与硬件差异。
自动内存管理：让开发者专注于业务，而不是像 C/C++ 那样手动 malloc/free。
运行时优化：JIT 编译、逃逸分析、内联、锁消除等，把「解释执行」慢慢优化成「本地机器码执行」。

graph LR
    A[.java 源码] -->|javac| B[字节码 .class]
    B -->|类加载子系统| C[方法区/Metaspace]
    C -->|解释器| D[逐行解释执行]
    C -->|JIT 编译器| E[本地机器码]
    D --> F[执行引擎]
    E --> F
    F --> G[操作系统]

避坑指南 #1：不要只把 JVM 当「黑盒」。线上 90% 的 Java 性能问题，根源都在堆外内存泄漏、GC 停顿过长、Metaspace 膨胀、线程栈溢出这四类。

二、运行时数据区：新版 JDK 的版图

不同虚拟机的运行时数据区实现略有差异，但都遵循《Java 虚拟机规范》。现代视角下，区域可划分为「线程私有」和「线程共享」两类：

graph TD
    subgraph 线程私有
        A[程序计数器 PC Register]
        B[虚拟机栈 JVM Stack]
        C[本地方法栈 Native Method Stack]
    end
    subgraph 线程共享
        D[堆 Heap]
        E[方法区 Method Area / Metaspace]
        F[直接内存 Direct Memory]
    end
    A --> G[线程执行上下文]
    B --> G
    C --> G
    D --> H[几乎所有对象实例]
    E --> I[类元数据/常量/静态变量]
    F --> J[NIO / 堆外内存]

2.1 程序计数器（Program Counter Register）

当前线程执行字节码的行号指示器。
分支、循环、跳转、异常处理、线程恢复都依赖它。
线程私有，生命周期与线程一致。
唯一一个在《Java 虚拟机规范》中没有规定 OOM 的区域。

2.2 Java 虚拟机栈（JVM Stack）

每个方法执行时创建一个栈帧（Stack Frame）。
栈帧里包含：局部变量表、操作数栈、动态链接、方法返回地址。
局部变量表中的基本数据类型和对象引用在编译期大小就确定。

graph TD
    A[JVM Stack] --> B[栈帧 Frame 1]
    A --> C[栈帧 Frame 2]
    A --> D[栈帧 Frame 3]
    B --> B1[局部变量表]
    B --> B2[操作数栈]
    B --> B3[动态链接]
    B --> B4[方法返回地址]

避坑指南 #2：-Xss 设置线程栈大小。递归过深、方法调用链过长会抛出 StackOverflowError；如果线程创建太多，总栈空间超过限制，会抛出 OutOfMemoryError: unable to create new native thread。

2.3 本地方法栈（Native Method Stack）

与虚拟机栈作用相同，只是为 Native 方法服务。
HotSpot 中把虚拟机栈和本地方法栈合二为一了。

2.4 Java 堆（Java Heap）

JVM 管理的最大一块内存，被所有线程共享。
几乎所有对象实例和数组都在这里分配。
现代 GC 基本都采用分代收集，逻辑上分为新生代、老年代。

graph LR
    A[Java Heap] --> B[Young Generation 新生代]
    A --> C[Old Generation 老年代]
    B --> D[Eden 区]
    B --> E[Survivor From]
    B --> F[Survivor To]

避坑指南 #3：不要把「堆」和「栈」对立记忆。对象在堆里，引用在栈里；但 HotSpot 的逃逸分析 + 标量替换会把未逃逸的小对象直接分配在栈上，减轻 GC 压力。

2.5 方法区（Method Area）与 Metaspace

存储类信息、常量、静态变量、JIT 编译后的代码缓存。
JDK 7 之前：方法区在 PermGen（永久代）中，大小固定，-XX:MaxPermSize。
JDK 8 及以后：PermGen 被移除，方法区使用本地内存中的 Metaspace，默认只受限于系统内存，用 -XX:MaxMetaspaceSize 控制。

版本	实现	配置参数	常见问题
JDK 7-	PermGen	`-XX:PermSize` / `-XX:MaxPermSize`	动态生成类过多导致 `OutOfMemoryError: PermGen space`
JDK 8+	Metaspace	`-XX:MetaspaceSize` / `-XX:MaxMetaspaceSize`	类加载器泄漏导致 Metaspace 持续增长

避坑指南 #4：Metaspace 默认无上限，服务运行久了可能把容器内存撑爆。线上建议显式设置 -XX:MaxMetaspaceSize，配合监控告警。

2.6 直接内存（Direct Memory）

不属于 JVM 堆，但会被 JVM 直接使用，常见于 NIO 的 DirectByteBuffer。
分配和回收成本较高，但读写 I/O 时避免了堆内外内存拷贝（Zero Copy）。
默认大小约等于 -Xmx，可用 -XX:MaxDirectMemorySize 控制。

避坑指南 #5：Netty、RocketMQ、Elasticsearch 等中间件大量使用堆外内存。出现 OutOfMemoryError: Direct buffer memory 时，先检查是否有 ByteBuf / DirectByteBuffer 未释放，而不是盲目加堆内存。

三、垃圾回收：从算法到收集器演进

3.1 判断对象是否存活

引用计数法：Python 用，但 Java 不用，因为解决不了循环引用。
可达性分析（Reachability Analysis）：从 GC Roots 出发，不可达则回收。

常见 GC Roots：

虚拟机栈中局部变量表引用的对象。
方法区中类静态属性、常量引用的对象。
本地方法栈中 JNI 引用的对象。
被同步锁持有的对象。

graph TD
    A[GC Roots] --> B[栈帧局部变量]
    A --> C[静态变量]
    A --> D[常量]
    A --> E[JNI 引用]
    A --> F[锁持有对象]
    B --> G[可达对象]
    C --> G
    D --> H[不可达对象<br/>等待回收]

3.2 四种基础 GC 算法

算法	思想	优点	缺点
标记-清除	标记无用对象，然后清除	简单，不需要移动对象	效率低，产生内存碎片
复制	内存分两块，活着的对象复制到另一块	无碎片，回收效率高	内存利用率只有一半
标记-整理	标记后把存活对象移到一端，清理边界外	无碎片，内存利用率高	移动对象开销大
分代收集	按对象存活周期分代，不同代用不同算法	兼顾吞吐与停顿	需要维护复杂的跨代引用

3.3 经典垃圾收集器

收集器	工作区域	算法	特点	适用场景	状态
Serial	新生代	复制	单线程，简单高效	客户端模式 / 单核	可用
ParNew	新生代	复制	Serial 的多线程版	配合 CMS	随 CMS 移除
Parallel Scavenge	新生代	复制	吞吐量优先	后台计算	可用
Serial Old	老年代	标记-整理	单线程	客户端模式	可用
Parallel Old	老年代	标记-整理	多线程吞吐量优先	后台计算	可用
CMS	老年代	标记-清除	低停顿，并发收集	互联网低延迟服务	JDK 14 已移除
G1	整堆	标记-整理 + 复制	可控停顿， region 化	大堆、低延迟	JDK 9-22 默认
ZGC	整堆	标记-复制/整理	亚毫秒停顿，TB 级堆	极低延迟	JDK 23+ 默认（分代）
Shenandoah	整堆	标记-复制/整理	低停顿，独立于分代	低延迟	可用，JDK 24 实验分代

graph LR
    A[Serial] --> B[ParNew]
    B --> C[Parallel Scavenge]
    C --> D[G1]
    D --> E[ZGC / Shenandoah]
    style E fill:#f9f,stroke:#333

3.4 分代模型的工作流程

新生代默认占堆的 1/3，老年代占 2/3。新生代内部 Eden:From Survivor:To Survivor 默认约为 8:1:1。

sequenceDiagram
    participant Eden
    participant From as Survivor From
    participant To as Survivor To
    participant Old as Old Generation
    Note over Eden,Old: Minor GC 触发
    Eden->>To: 存活对象复制到 To
    From->>To: 存活对象复制到 To
    From->>Old: 年龄超过阈值的对象晋升
    Note over Eden,From: 清空 Eden 和 From
    To->>From: To 变 From，From 变 To

避坑指南 #6：不要把 Survivor 区看作「两个对称缓存区」。它们在一次 Minor GC 后会交换身份，始终有一个是空的，用于下一次复制目标。

3.5 G1 收集器：里程碑式的设计

G1（Garbage First）把堆划分为多个大小相等的 Region，每个 Region 动态扮演 Eden、Survivor 或 Old 角色。

graph TD
    A[G1 Heap Regions] --> B[Eden Region]
    A --> C[Survivor Region]
    A --> D[Old Region]
    A --> E[Humongous Region<br/>大对象]
    A --> F[Free Region]

G1 的核心优势：

可预测的停顿时间模型：通过 -XX:MaxGCPauseMillis 设定目标停顿。
整体基于标记-整理，局部基于复制：不会产生大面积内存碎片。
回收优先级按垃圾最多的 Region 来：Garbage First 名字来源。

避坑指南 #7：G1 的 -XX:MaxGCPauseMillis 不是越小越好。设得太低（如 50ms）会导致回收 Region 太少、GC 频率飙升，反而降低吞吐。通常建议 100-200ms。

3.6 现代低延迟 GC：ZGC 与 Shenandoah

特性	ZGC	Shenandoah
设计目标	亚毫秒级停顿，支持 TB 级堆	低停顿，独立于分代
并发能力	标记、转移、重定位几乎都并发	并发标记、并发压缩
着色指针	使用	不使用
分代	JDK 21 引入分代 ZGC，JDK 23 起为默认	JDK 24 引入实验性分代 Shenandoah
适用版本	JDK 11+（生产推荐 JDK 17+）	OpenJDK 12+

graph LR
    A[传统 GC<br/>Serial/Parallel/CMS/G1] -->|停顿目标 ms~百 ms 级| B[G1]
    B -->|停顿目标 < 10ms| C[ZGC / Shenandoah]
    C -->|JDK 21+| D[分代 ZGC]
    D -->|JDK 23+| E[分代 ZGC 默认]
    C -->|JDK 24+| F[分代 Shenandoah 实验]

高性能建议 #1：如果应用对延迟敏感（如金融交易、在线游戏、实时推荐），JDK 17 下优先考虑 G1；JDK 21+ 可直接启用 分代 ZGC（-XX:+UseZGC -XX:+ZGenerational），在吞吐和延迟之间取得更好平衡；升级到 JDK 23+ 后分代 ZGC 已是默认，无需额外参数。

3.7 JDK 21/22/23/24 的 GC 演进大事记

JDK 版本	GC 相关变化	影响
JDK 21	JEP 439 正式发布分代 ZGC	默认仍是 G1，但可显式启用 `-XX:+ZGenerational` 获得更低延迟
JDK 22	JEP 423 G1 Region Pinning	G1 在 JNI 临界区内无需禁用 GC，降低延迟毛刺
JDK 23	JEP 474 分代 ZGC 成为默认；非分代 ZGC 废弃	新默认 GC 从 G1 切换到分代 ZGC，亚毫秒级停顿更易获得
JDK 23	JDK-8322630 ZGC 延迟优化	减少 GC 根节点扫描抖动
JDK 24	JEP 490 移除非分代 ZGC	简化 ZGC 维护，统一使用分代模式
JDK 24	JEP 404 分代 Shenandoah（实验性）	Shenandoah 也走向分代，未来低延迟 GC 竞争更激烈
JDK 24	JEP 475 G1 Late Barrier Expansion	优化 G1 写屏障，提升编译和运行时性能

timeline
    title GC 默认与里程碑
    section JDK 8
        默认 : Parallel Scavenge + Parallel Old
    section JDK 9
        默认 : G1
    section JDK 11
        ZGC 实验性
    section JDK 15
        ZGC 生产可用
    section JDK 17
        G1 默认，ZGC/Shenandoah 成熟
    section JDK 21
        分代 ZGC 正式发布（仍非默认）
    section JDK 23
        分代 ZGC 成为默认 GC
    section JDK 24
        非分代 ZGC 移除；分代 Shenandoah 实验

避坑指南 #7.5：网上有说法称 “JDK 21 默认 GC 是 ZGC”，这是错误的。JDK 21 默认仍是 G1；分代 ZGC 只是正式发布，需要显式开启。真正的默认切换发生在 JDK 23。

四、引用类型：不只是强引用

引用类型	回收时机	使用场景
强引用	永不回收，即使 OOM	普通对象
软引用 SoftReference	内存不足前回收	缓存，如图片缓存
弱引用 WeakReference	下一次 GC 时回收	防止内存泄漏，如 `WeakHashMap`
虚引用 PhantomReference	随时可能被回收，必须配合 ReferenceQueue	跟踪对象被回收的事件，做资源后置清理

graph LR
    A[强引用] -->|最强| B[不会被回收]
    C[软引用] -->|内存紧张| D[回收]
    E[弱引用] -->|下次 GC| F[回收]
    G[虚引用] -->|无法获取对象| H[仅回收通知]

避坑指南 #8：不要把软引用当「万能缓存」。在内存紧张时软引用会被批量回收，导致缓存命中率骤降。高并发缓存建议用 Caffeine 等带 TTL 和淘汰策略的专业缓存框架。

五、类加载机制：双亲委派与破坏

5.1 类加载器层次

graph TD
    A[自定义类加载器] -->|委托| B[应用程序类加载器 AppClassLoader]
    B -->|委托| C[平台类加载器 PlatformClassLoader]
    C -->|委托| D[启动类加载器 BootstrapClassLoader]

注意：JDK 9 引入模块化系统后，原来的 Extension ClassLoader 被改名为 Platform ClassLoader，负责加载平台模块（如 java.sql、java.xml 等）。

5.2 双亲委派模型

类加载器收到加载请求，先不自己加载。
向上委托给父加载器。
父加载器无法加载时，子加载器才尝试加载。

避坑指南 #9：Tomcat、SPI、OSGi 都破坏了双亲委派。如果你的项目出现 NoSuchMethodError / ClassCastException: cannot cast to the same class，很可能是同一个类被不同类加载器加载了两次。

六、JIT 编译与执行优化

Java 代码先被解释器执行，热点代码会被 JIT 编译成本地机器码。

6.1 HotSpot 的两层编译器

编译器	别称	特点
C1	Client Compiler	编译快，优化简单，适合启动速度和 GUI
C2	Server Compiler	编译慢，激进优化，适合长期运行的服务端

JDK 7 引入分层编译（Tiered Compilation），JDK 8 默认开启：

0: 解释执行
1~3: C1 编译，带简单/复杂优化
4: C2 编译，激进优化

6.2 常见 JIT 优化

优化	说明
方法内联	把短方法体直接嵌入调用处，减少栈帧开销
逃逸分析	判断对象是否逃出方法/线程作用域
标量替换	把对象拆成基本类型分配在栈上
锁消除	确认对象只被单线程访问时去掉同步锁
锁粗化	把相邻的同步块合并，减少加解锁次数

高性能建议 #2：不要过度纠结「每个对象都在堆上分配」。现代 JVM 的逃逸分析已经很强，写代码时优先保证对象作用域最小化、避免无意义的全局引用，让 JIT 有优化空间。

七、现代 JVM 前沿特性（JDK 21+）

除了 GC，JDK 21 及之后版本还在内存模型、执行模型和 Native 互操作上做了大量演进，这些也会间接影响 JVM 调优思路。

7.1 虚拟线程（Virtual Threads，JEP 444 / JDK 21）

虚拟线程是 JVM 管理的轻量级线程，由 JVM 调度到少量平台线程（Carrier Thread）上运行。
创建成本极低（KB 级栈），适合高并发 I/O 密集型应用。
对 JVM 数据区的影响：虚拟线程的栈帧仍存在于 Java 堆中（作为 Continuation 对象），而不是传统的线程栈。

graph LR
    A[平台线程 Platform Thread] -->|1:N 映射| B[虚拟线程 Virtual Thread]
    B -->|挂载| C[Carrier Thread]
    C -->|运行在| D[OS 线程]

避坑指南 #9.5：虚拟线程虽好，但不要和 synchronized 块、本地方法、文件 I/O 混用导致 “Pinning”，会让载体线程被卡住，降低并发收益。优先使用 ReentrantLock 和异步 I/O。

7.2 Foreign Function & Memory API（JEP 454 / JDK 22）

正式替代 sun.misc.Unsafe 进行堆外内存操作。
通过 Arena 管理堆外内存生命周期，更安全、更可移植。
对直接内存调优的影响：未来 DirectByteBuffer 的底层实现会逐步迁移到 FFM API。

7.3 Project Lilliput：压缩对象头

目标是把 HotSpot 的对象头从 96/128 bit 压缩到 64 bit。
可以显著降低内存占用，提升缓存命中率。
JDK 24 起部分功能已集成（如 64-bit object headers）。

7.4 Project Valhalla：值类型（Value Classes / Primitive Classes）

引入 “值对象”，避免对象头和引用开销。
未来 int[] 和 Integer[] 之间的性能鸿沟会缩小。
目前处于预览阶段，持续关注即可。

7.5 Project Leyden：Java 静态镜像

目标是通过 “静态图像” 加速 Java 启动时间。
类似 GraalVM Native Image，但保持完整 Java 语义和 JVM 运行时能力。
对 Serverless、CLI 工具、云原生场景意义重大。

八、避坑指南：线上常见问题

8.1 慎用 `System.gc()`

只是「建议」JVM 进行 Full GC，不保证执行。
很多框架（如某些老版本 JDBC）会调用它，导致不可控停顿。
线上建议关闭：-XX:+DisableExplicitGC。

8.2 finalize() 已过时

JDK 9 起标记为 @Deprecated。
对象回收前不保证一定执行 finalize()，且执行顺序不确定。
资源清理用 try-with-resources 或 Cleaner。

8.3 大对象与 Humongous

G1 中超过 Region 大小一半的对象叫 Humongous Object，直接进老年代，增加 GC 负担。
避免一次性创建超大数组或字符串。

8.4 动态代理与 CGLIB 的 Metaspace 泄漏

Spring AOP、MyBatis、Dubbo 大量生成代理类。
如果 ClassLoader 没释放，代理类元数据会持续占用 Metaspace。
常见于热部署、OSGi、动态脚本场景。

8.5 大堆 + Full GC 的雪崩

堆内存越大，G1 的 Mixed GC、CMS 的 Full GC 停顿越长。
超过 32GB 时，指针压缩会失效，对象头变大，反而浪费内存。
建议堆大小控制在 16GB-32GB 之间，再大的堆考虑横向拆分服务或换 ZGC。

九、高性能调优建议

9.1 选择 GC 与 JDK 版本

场景	推荐配置
通用 Web 服务，JDK 17-22	`-XX:+UseG1GC -XX:MaxGCPauseMillis=200`
通用 Web 服务，JDK 23+	默认已是分代 ZGC，一般无需改动
延迟敏感，JDK 21-22	`-XX:+UseZGC -XX:+ZGenerational`
延迟敏感，JDK 23+	默认分代 ZGC，无需显式开启
批处理/大数据，吞吐优先	`-XX:+UseParallelGC` 或 G1
容器环境	显式设置 `-Xmx`、`-Xms`、`-XX:MaxMetaspaceSize`，并开启 `-XX:+UseContainerSupport`

9.2 参数模板

JDK 17-22 通用 Web 服务（G1）

java \
  -Xms4g -Xmx4g \
  -XX:MetaspaceSize=256m \
  -XX:MaxMetaspaceSize=512m \
  -XX:+UseG1GC \
  -XX:MaxGCPauseMillis=200 \
  -XX:+AlwaysPreTouch \
  -XX:+DisableExplicitGC \
  -XX:+HeapDumpOnOutOfMemoryError \
  -XX:HeapDumpPath=/var/log/app/heapdump.hprof \
  -jar app.jar

JDK 23+ 通用 Web 服务（默认分代 ZGC）

java \
  -Xms4g -Xmx4g \
  -XX:MetaspaceSize=256m \
  -XX:MaxMetaspaceSize=512m \
  -XX:+AlwaysPreTouch \
  -XX:+DisableExplicitGC \
  -XX:+HeapDumpOnOutOfMemoryError \
  -XX:HeapDumpPath=/var/log/app/heapdump.hprof \
  -Xlog:gc*:file=/var/log/app/gc.log:time,uptime,level,tags:filecount=10,filesize=100m \
  -jar app.jar

说明：JDK 23 起默认就是分代 ZGC，不需要 -XX:+UseZGC。如果仍想显式启用，可保留；如果想用回 G1，使用 -XX:+UseG1GC。

9.3 监控与诊断三板斧

工具	用途
`jstat -gcutil <pid> 1000`	实时查看 GC 频率与内存占比
`jmap -dump:format=b,file=... <pid>`	生成堆快照，MAT 分析内存泄漏
`jstack <pid>`	打印线程栈，排查死锁与 CPU 热点
GC 日志 / `-Xlog:gc*`	分析 GC 原因与停顿时间
`async-profiler`	低开销 CPU/内存/锁分析

高性能建议 #3：调优前一定先定目标——是降低停顿？提高吞吐？还是减少内存？没有目标的调优就是瞎调。先用 GC 日志和监控找到瓶颈，再改参数，而不是反向操作。

十、JVM 问题排查实战：发现 → 定位 → 修复

线上 JVM 问题通常表现为：服务卡顿、响应 P99 飙高、CPU 打满、内存持续增长、频繁 OOM。解决它们的核心思路是：先量化，再猜测。

10.1 问题发现的四层入口

graph TD
    A[业务层] -->|接口超时/P99 飙升| B[应用层]
    B -->|Full GC 频繁/GC 时间长| C[JVM 层]
    C -->|堆/栈/Metaspace 异常| D[系统层]
    D -->|容器 OOMKilled/CPU 限流| E[基础设施层]

入口	典型现象	常见根因
业务监控	接口 RT 上涨、错误率增加	GC 停顿、线程阻塞、锁竞争
APM / Trace	某段链路偶发耗时几百 ms	Full GC、Metaspace 扩容、类加载
容器监控	Pod 内存触顶被 OOMKilled	堆外内存泄漏、堆太大、Metaspace 无上限
GC 日志	GC 频率异常、停顿时间超标	收集器选择不当、堆大小不合理、大对象过多
JVM 告警	Heap 使用率 > 85%、FGC 次数突增	内存泄漏、流量突增、缓存失控

10.2 排查工具箱

10.2.1 命令行工具（适合快速止血）

命令	场景	输出重点
`jps -lvm`	找到 Java 进程 PID	主类名、启动参数
`jstat -gcutil <pid> 1000`	实时监控 GC 与内存	S0/S1/E/O/M 各区使用率、YGC/FGC 次数
`jmap -heap <pid>`	查看堆配置与概览	新生代/老年代大小、收集器
`jmap -histo <pid>`	查看对象直方图	哪个类实例数/占用最多
`jmap -dump:format=b,file=... <pid>`	生成堆 dump	配合 MAT / JProfiler 分析
`jstack <pid>`	打印线程栈	死锁、CPU 热点线程、Blocked 线程
`jcmd <pid> VM.native_memory summary`	查看 Native Memory Tracking	堆外内存、Metaspace、Symbol 区占用

10.2.2 可视化 / 专业工具

工具	适用场景	特点
MAT (Eclipse Memory Analyzer)	分析堆 dump	大对象、内存泄漏、支配树、Leak Suspects
JProfiler / YourKit	全链路 JVM 分析	CPU、内存、线程、GC 一体化
async-profiler	生产环境火焰图	低开销，适合线上持续采样
GCViewer / GCEasy	解析 GC 日志	可视化 GC 事件、停顿分布
Prometheus + Grafana	长期监控与告警	自定义 JVM 指标大盘
Arthas	线上实时诊断	无需重启，支持 trace、watch、thread、heapdump

10.3 典型问题排查流程

场景 1：CPU 飙升

# 1. 找到 CPU 占用最高的线程
ps -mp <pid> -o THREAD,tid,time | sort -rn

# 2. 把 tid 转成十六进制
printf "%x\n" <tid>

# 3. 用 jstack 查看对应线程栈
jstack <pid> | grep -A 30 <hex_tid>

常见根因：

死循环或复杂正则
Young GC 过于频繁
JIT 编译器 C2 线程忙碌（启动期正常）
大量 ThreadLocal 未清理

场景 2：内存持续增长 / OOM

# 1. 确认哪个区域增长
jstat -gcutil <pid> 1000

# 2. 开启 Native Memory Tracking
jcmd <pid> VM.native_memory baseline
jcmd <pid> VM.native_memory summary.diff

# 3. 触发堆 dump（若还能响应）
jmap -dump:live,format=b,file=/tmp/heap.hprof <pid>

常见根因：

堆：缓存无淘汰、大对象、集合只增不减
Metaspace：动态代理/CGLIB 类加载器泄漏
堆外：Netty ByteBuf 未释放、NIO DirectBuffer 堆积

场景 3：接口偶发卡顿 / P99 高

打开 GC 日志，看是否有 长停顿。
用 jstack 抓取卡顿时刻线程栈，看是否有大量 BLOCKED。
用 async-profiler 采集 CPU 火焰图，定位热点方法。
检查是否有 System.gc()、Metaspace 扩容、类加载抖动。

10.4 JVM 监控告警建议

建议把以下指标接入 Prometheus + Grafana，并设置合理阈值：

指标	告警阈值建议	说明
`jvm_memory_used_bytes / jvm_memory_max_bytes`	> 85%	堆/非堆内存使用率
`jvm_gc_pause_seconds_sum`	P99 > 200ms	GC 停顿时间
`jvm_gc_memory_allocated_bytes_total` 增长率	突增 2 倍以上	对象分配速率异常
`jvm_classes_loaded_total`	持续增长	类泄漏嫌疑
`process_cpu_usage`	> 80% 持续 5min	CPU 压力
`jvm_threads_live`	突增或接近上限	线程泄漏
容器维度 `container_memory_working_set_bytes`	> 90% limit	容器 OOMKilled 预警

graph LR
    A[应用埋点] -->|Micrometer| B[Prometheus]
    C[GC 日志] -->|Loki / Filebeat| D[日志平台]
    B --> E[Grafana 大盘]
    D --> E
    E -->|阈值触发| F[AlertManager]
    F -->|通知| G[钉钉/企业微信/Slack]

十一、不同场景的 JVM 配置策略

11.1 配置前的通用原则

先压测，再调优：没有真实流量数据，调参都是拍脑袋。
Xms = Xmx：避免运行时堆扩容带来的 GC 抖动。
Metaspace 必须设上限：容器环境下尤其重要。
GC 日志一定要开：-Xlog:gc*（JDK 9+）成本很低，信息无价。
容器环境开启 Container Support：-XX:+UseContainerSupport（JDK 8u191+/10+ 默认开启）。
不要堆内存无限大：超过 32GB 指针压缩失效，性价比骤降。

11.2 场景一：高并发 Web / API 服务

特征：QPS 高、对象生命周期短、响应延迟敏感。

目标：降低 GC 停顿、控制 P99。

推荐配置（JDK 17-22，G1）：

java \
  -Xms4g -Xmx4g \
  -XX:MetaspaceSize=256m \
  -XX:MaxMetaspaceSize=512m \
  -XX:+UseG1GC \
  -XX:MaxGCPauseMillis=100 \
  -XX:InitiatingHeapOccupancyPercent=35 \
  -XX:+AlwaysPreTouch \
  -XX:+DisableExplicitGC \
  -XX:+HeapDumpOnOutOfMemoryError \
  -XX:HeapDumpPath=/var/log/app/heapdump.hprof \
  -Xlog:gc*:file=/var/log/app/gc.log:time,uptime,level,tags:filecount=10,filesize=100m \
  -jar app.jar

推荐配置（JDK 23+，默认分代 ZGC）：

java \
  -Xms4g -Xmx4g \
  -XX:MetaspaceSize=256m \
  -XX:MaxMetaspaceSize=512m \
  -XX:+AlwaysPreTouch \
  -XX:+DisableExplicitGC \
  -XX:+HeapDumpOnOutOfMemoryError \
  -XX:HeapDumpPath=/var/log/app/heapdump.hprof \
  -Xlog:gc*:file=/var/log/app/gc.log:time,uptime,level,tags:filecount=10,filesize=100m \
  -jar app.jar

调优要点：

新生代尽量大，让短生命周期对象在 Young GC 回收。
-XX:MaxGCPauseMillis 根据业务容忍度设置，100-200ms 常见。
监控 jvm_gc_pause_seconds_sum，若频繁触发 Mixed GC，考虑增大 -XX:InitiatingHeapOccupancyPercent。

11.3 场景二：高流量 / 削峰填谷（消息队列消费者）

特征：突发流量、消息处理批量化、吞吐优先、允许一定延迟。

目标：提高吞吐，避免 OOM 和 Full GC。

推荐配置：

java \
  -Xms8g -Xmx8g \
  -XX:MetaspaceSize=256m \
  -XX:MaxMetaspaceSize=512m \
  -XX:+UseG1GC \
  -XX:MaxGCPauseMillis=300 \
  -XX:G1HeapRegionSize=16m \
  -XX:InitiatingHeapOccupancyPercent=40 \
  -XX:+AlwaysPreTouch \
  -XX:+DisableExplicitGC \
  -XX:+HeapDumpOnOutOfMemoryError \
  -XX:HeapDumpPath=/var/log/app/heapdump.hprof \
  -Xlog:gc*:file=/var/log/app/gc.log:time,uptime,level,tags:filecount=10,filesize=100m \
  -jar consumer.jar

调优要点：

堆可以比 Web 服务稍大，因为要缓冲突发消息。
批量消费时注意控制单次拉取消息数，避免一次创建过多对象。
如果业务允许更高延迟，可考虑 -XX:+UseParallelGC 追求极致吞吐。

11.4 场景三：低延迟金融 / 交易 / 实时推荐

特征：P99 要求 < 10ms，任何 GC 停顿都可能导致业务损失。

目标：亚毫秒级 GC 停顿。

推荐配置（JDK 21+）：

java \
  -Xms16g -Xmx16g \
  -XX:MetaspaceSize=256m \
  -XX:MaxMetaspaceSize=512m \
  -XX:+UseZGC \
  -XX:+ZGenerational \
  -XX:+AlwaysPreTouch \
  -XX:+DisableExplicitGC \
  -XX:+HeapDumpOnOutOfMemoryError \
  -XX:HeapDumpPath=/var/log/app/heapdump.hprof \
  -Xlog:gc*:file=/var/log/app/gc.log:time,uptime,level,tags:filecount=10,filesize=100m \
  -jar trading.jar

JDK 23+ 可简化为（默认就是分代 ZGC）：

java \
  -Xms16g -Xmx16g \
  -XX:MetaspaceSize=256m \
  -XX:MaxMetaspaceSize=512m \
  -XX:+AlwaysPreTouch \
  -XX:+DisableExplicitGC \
  -XX:+HeapDumpOnOutOfMemoryError \
  -XX:HeapDumpPath=/var/log/app/heapdump.hprof \
  -Xlog:gc*:file=/var/log/app/gc.log:time,uptime,level,tags:filecount=10,filesize=100m \
  -jar trading.jar

调优要点：

堆 > 16GB 时 ZGC 优势更明显。
避免大对象（Humongous），ZGC 对大对象分配路径不如小对象高效。
监控 jvm_gc_pause_seconds_max，正常应在 1ms 以内。

11.5 场景四：大数据 / 批处理 / ETL

特征：长时间运行、对象存活久、吞吐优先、延迟不敏感。

目标：最大化吞吐，减少总 GC 时间。

推荐配置：

java \
  -Xms16g -Xmx16g \
  -XX:MetaspaceSize=512m \
  -XX:MaxMetaspaceSize=1g \
  -XX:+UseParallelGC \
  -XX:ParallelGCThreads=8 \
  -XX:+UseLargePages \
  -XX:+AlwaysPreTouch \
  -XX:+DisableExplicitGC \
  -XX:+HeapDumpOnOutOfMemoryError \
  -XX:HeapDumpPath=/var/log/app/heapdump.hprof \
  -Xlog:gc*:file=/var/log/app/gc.log:time,uptime,level,tags:filecount=10,filesize=100m \
  -jar etl.jar

调优要点：

Parallel GC 在纯吞吐场景下通常优于 G1。
大堆 + 大页（LargePages）减少 TLB miss。
如果批处理任务会频繁 Full GC，考虑分阶段释放引用或使用堆外缓存。

11.6 场景五：容器 / K8s 微服务

特征：资源受限、弹性伸缩、多实例共享节点。

目标：稳定、不 OOMKilled、启动快。

推荐配置：

java \
  -XX:+UseContainerSupport \
  -XX:InitialRAMPercentage=70.0 \
  -XX:MaxRAMPercentage=70.0 \
  -XX:MetaspaceSize=128m \
  -XX:MaxMetaspaceSize=256m \
  -XX:+UseG1GC \
  -XX:MaxGCPauseMillis=200 \
  -XX:+AlwaysPreTouch \
  -XX:+DisableExplicitGC \
  -XX:+HeapDumpOnOutOfMemoryError \
  -XX:HeapDumpPath=/var/log/app/heapdump.hprof \
  -Xlog:gc*:file=/var/log/app/gc.log:time,uptime,level,tags:filecount=5,filesize=50m \
  -jar service.jar

调优要点：

用 -XX:MaxRAMPercentage 替代固定 -Xmx，适配不同 Limit。
容器 memory limit 要预留 10%-20% 给堆外内存、Metaspace、线程栈、JVM 自身。
不要把 -Xmx 设成容器 limit 的 100%，否则容易被 OOMKilled。
JDK 23+ 在容器里可直接用默认分代 ZGC。

11.7 场景六：Spring Boot / 微服务网关

特征：启动时大量类加载、反射多、动态代理多。

目标：启动快 + 运行稳。

推荐配置：

java \
  -Xms2g -Xmx2g \
  -XX:MetaspaceSize=256m \
  -XX:MaxMetaspaceSize=512m \
  -XX:+UseG1GC \
  -XX:MaxGCPauseMillis=150 \
  -XX:+AlwaysPreTouch \
  -XX:+DisableExplicitGC \
  -XX:+HeapDumpOnOutOfMemoryError \
  -XX:HeapDumpPath=/var/log/app/heapdump.hprof \
  -Dspring.backgroundpreinitializer.ignore=true \
  -jar gateway.jar

调优要点：

Spring Boot 启动时 Metaspace 会快速上涨，初始值不要设太小。
如果启动慢，可用 -XX:+TieredCompilation 配合 -XX:TieredStopAtLevel=1 加速启动（牺牲峰值性能）。
网关避免在请求路径创建大对象，优先复用对象和缓冲区。

十二、一句话总结

内存：堆内分代、堆外 Direct、Metaspace 存类元数据；虚拟线程栈帧在堆中。
GC：Serial → Parallel → CMS → G1 → 分代 ZGC；JDK 21 分代 ZGC 正式发布，JDK 23 起成为默认 GC。
引用：强 > 软 > 弱 > 虚，缓存别滥用软引用。
性能：JDK 17-22 优先 G1；JDK 23+ 默认分代 ZGC；延迟极致用 ZGC，吞吐优先用 Parallel。
排查：监控先行 → 日志定位 → 工具分析 → 压测验证 → 持续观察。
场景：Web 服务控延迟、消息队列保吞吐、金融交易用 ZGC、批处理用 Parallel、容器环境留余量。

JVM 调优没有银弹，但有方法论：理解数据区 → 选对收集器 → 设定合理目标 → 用日志验证 → 持续监控。把这套流程跑熟，面试八股和线上救火就都不慌了。

参考

《深入理解 Java 虚拟机》（第三版）周志明
OpenJDK HotSpot Virtual Machine Garbage Collection Tuning Guide
JEP 333: ZGC
JEP 439: Generational ZGC
JEP 474: ZGC Generational Mode by Default
JEP 490: Remove the Non-Generational ZGC Mode
JEP 404: Generational Shenandoah (Experimental)
JEP 444: Virtual Threads
JEP 454: Foreign Function & Memory API
Project Lilliput