1. 课程导入
1.1 为什么需要系统化的性能分析
性能问题从来不是单一组件的问题。当用户反馈“系统变慢了”，可能的原因分布在硬件资源、内核调度、网络协议栈、应用代码、数据库查询乃至前端渲染的每一个环节。缺乏系统化方法时，工程师往往陷入“头痛医头”的局部优化：CPU 高就加 CPU，内存不足就扩容，却忽略了真正的瓶颈可能藏在锁竞争、中断风暴或磁盘 I/O 队列的深处。
本课程的核心目标，是帮助你建立一条从现象到根因的完整分析链路。你将学会：
- 使用
top、vmstat、pidstat、perf、bpf等工具定位资源瓶颈； - 理解 CPU 运行队列、内存回收机制、块设备 I/O 调度、TCP 拥塞控制等内核行为；
- 将应用层指标（延迟、吞吐、错误率）与内核指标（上下文切换、软中断、页错误）关联分析；
- 掌握从“猜测优化”转向“测量—假设—验证”的工程化方法。
1.2 课程结构：三层递进与四大专题
全课程共 30 章，按“基础层 → 内核层 → 应用层”三层递进，并穿插四个横向专题。下表展示了整体章节布局：
| 模块 | 章节范围 | 核心内容 |
|---|---|---|
| 基础方法 | 第 1–4 章 | 性能分析框架、指标体系、工具链、实验设计 |
| 内核机制 | 第 5–14 章 | CPU 调度、内存管理、文件系统、网络协议栈、块设备 |
| 应用与运行时 | 第 15–24 章 | Java/Go 运行时、数据库、缓存、消息队列、容器 |
| 综合实战 | 第 25–30 章 | 全链路追踪、容量规划、性能调优案例复盘 |
每一章都遵循“原理讲解 → 工具实操 → 案例剖析 → 误区复盘”的循环结构，确保知识既能落地，又能沉淀为可复用的分析经验。
1.3 性能分析的整体框架：USE 与 RED 方法
面对复杂的系统，我们需要一套快速缩小范围的检查清单。USE 方法（Utilization, Saturation, Errors）面向基础设施资源，RED 方法（Rate, Errors, Duration）面向服务请求。两者结合，构成了从资源到服务的完整观测视角。
USE 方法核心问题：对于每一个资源（CPU、内存、磁盘、网络），分别检查——
- 利用率（Utilization）：资源忙于工作的时间百分比。例如 CPU 用户态+内核态占比、磁盘吞吐与最大带宽比。
- 饱和度（Saturation）：资源无法及时处理的额外排队量。例如 CPU 运行队列长度、内存页交换率、TCP 重传队列深度。
- 错误（Errors）：资源发生的错误事件。例如网卡丢包计数、磁盘 I/O 错误、内存 ECC 纠错次数。
RED 方法则从服务视角出发：监控每个服务的请求速率（Rate）、错误率（Errors）和延迟分布（Duration）。当 RED 指标异常时，再向下用 USE 方法检查支撑该服务的资源层。这种“自上而下分解、自下而上定位”的策略，能有效避免在无关组件上浪费时间。
下图展示了本课程贯穿始终的分析框架——从用户请求出发，逐层映射到资源消耗：
图中自上而下的箭头表示一次性能问题的定位路径：先看服务 RED 指标是否异常，再下沉到资源 USE 检查，最后深入内核指标确认根因。右侧的反馈回路则强调：每次优化后必须重新测量，确认指标是否改善，避免“优化了但没效果”的尴尬。
1.4 核心思想：测量驱动，而非猜测驱动
性能分析最大的误区是凭经验猜测。例如“数据库慢查询多，所以加索引”或“CPU 高，所以扩容”。这些判断往往忽略了真正的瓶颈——可能是连接池配置过小导致线程等待，也可能是锁竞争导致 CPU 空转。
本课程反复强调的核心理念是：
- 先测量，后行动：任何优化前，必须用工具量化当前状态，建立基线数据。
- 单一变量原则：每次只改变一个参数，对比前后指标，避免多个变量互相干扰。
- 关注尾部延迟：平均值会掩盖长尾问题，要关注 P99、P999 延迟。
- 端到端视角：从用户请求入口到数据库落盘，全链路埋点，而非只看单机指标。
实操建议：在开始任何调优之前，先花 30 分钟收集以下基线数据——
# 1. 系统整体负载
uptime && vmstat 1 5
# 2. CPU 和进程详情
top -b -n 1 | head -30
pidstat -u -p ALL 1 3
# 3. 内存与页错误
sar -r 1 3
cat /proc/meminfo | grep -E "^(MemFree|Dirty|Writeback)"
# 4. 磁盘 I/O
iostat -x 1 3
# 5. 网络连接状态
ss -s
netstat -i这些数据将作为后续所有判断的基准。没有基线，就无法判断优化是否有效。
1.5 常见误区与复盘
在长期的教学与实战中，我们总结了初学者最容易犯的五个错误，这里提前指出，帮助你在课程学习中建立正确的思维模式：
| 误区 | 错误表现 | 正确做法 |
|---|---|---|
| 只看 CPU 使用率 | CPU 100% 就认为 CPU 不够 | 检查运行队列长度、上下文切换、是否在自旋等待锁 |
| 忽略饱和度 | 磁盘利用率 80% 认为安全 | 查看 I/O 等待队列长度和平均服务时间 |
| 平均延迟掩盖问题 | 平均延迟 50ms 认为正常 | 绘制延迟分布直方图，关注 P99 和最大值 |
| 工具输出堆砌 | 收集大量数据但无法解读 | 先明确问题假设，再有针对性地选择指标 |
| 优化后不验证 | 修改参数后凭感觉认为变快 | 用相同压力工具重新压测，对比基线数据 |
复盘一个真实案例：某团队反馈“服务响应变慢”，工程师首先扩容了 CPU，但问题依旧。后来用 perf top 发现热点集中在 spin_lock，进一步用 pidstat -w 看到大量非自愿上下文切换，最终定位到共享日志队列的锁竞争。通过将日志写入改为无锁环形缓冲区，P99 延迟从 800ms 降至 120ms。这个案例说明：没有系统化的框架，扩容只是浪费资源；有了框架，才能直击要害。