导论 on Dorkytiger 的小屋

三类问题必须分开处理

Mon, 01 Jan 0001 00:00:00 +0000

0.1 三类问题必须分开处理

上一节：无（这是全书的起点）　|　下一节：0.2 吞吐、延迟、成本的三方权衡配套代码：00-introduction/01-three-kinds-of-problems

一句话结论

「性能」不是一个问题，而是三个不同的问题：这段代码本身快不快、这个服务能扛多少、它为什么慢。三者需要三套不同的方法，混用就会得到错误的答案。

一、从一个真实的对话开始

同事：我们的订单接口太慢了，你能不能看一下？你（凭直觉）：我先压一下看看。

这次「我先压一下」大概率会浪费半天。因为你并不知道自己在回答哪个问题：

你是想验证「订单接口的代码写得不好」吗？→ 那应该做微基准，把某个函数单独拎出来测。
你是想知道「它能扛多少流量、什么时候垮」吗？→ 那应该做负载测试。
你是想知道「它现在为什么慢、时间花在哪」吗？→ 那应该做性能剖析。

这三件事的输入、输出、工具、时间成本完全不同。 先搞清楚要做哪一件，再动手。

二、三类问题对照表

	微基准（Microbenchmark）	负载测试（Load Test）	性能剖析（Profiling）
你在问	这段代码本身有多快？	这个系统能扛多少？	现在为什么慢？
典型提问	「`copy()` 和手动复制哪个快？」	「上线前它能撑住 1000 QPS 吗？」	「P99 从 80ms 涨到 400ms，卡在哪？」
是否隔离	完全隔离，只测一个函数	不隔离，全链路一起测	不隔离，在生产同构环境上采样
典型工具	JMH、kotlinx-benchmark	k6、Gatling、wrk2	async-profiler、JFR、火焰图
主要输出	`ns/op` 或 `ops/s`	吞吐-延迟曲线、拐点、崩溃点	时间花在哪条调用链上
测量粒度	纳秒	毫秒	采样栈（可以是函数级）
主要风险	被 JIT 优化掉，测出假数据	压测机自己成为瓶颈	只看到 CPU 时间，漏掉等待

一个通俗的类比：医院检查

检查项目	对应	能回答	不能回答
化验一滴血	微基准	这个指标本身正常吗？	你能不能跑完马拉松
跑步机压力测试	负载测试	你的心肺能撑多大强度、什么时候出问题	是哪根血管堵了
拍 CT / 造影	性能剖析	到底是哪里堵了	你能跑多快

最常见的错误，是拿「化验结果」去回答「能跑多快」的问题。

吞吐、延迟、成本的三方权衡

Mon, 01 Jan 0001 00:00:00 +0000

0.2 吞吐、延迟、成本的三方权衡

上一节：0.1 三类问题必须分开处理　|　下一节：0.3 延迟是分布，不是数字

一句话结论

「让性能变好」是一句没有意义的话。 任何优化都是在「吞吐量、延迟、资源成本」三者之间做取舍——你必须说清楚：在什么成本约束下，把哪个指标改善到什么程度。

一、用一个快递公司的故事理解三者关系

假设你开了一家快递站，每天要送 1000 个包裹：

策略	吞吐量	单个包裹的延迟	成本
一件一送：每来一个包裹就派一辆车	低（一天最多几十趟）	极低（来了就走）	极高（要几十辆车、几十个司机）
攒够 100 件送一趟	高（10 趟送完）	高（第一个包裹要等到第 100 个才出发）	低（一辆车就够）

看出来了吗？「吞吐高」和「延迟低」在这里是直接冲突的。

再看第三个维度：那辆车的载重、司机的数量、仓库的大小——这就是资源成本。想同时提高吞吐、降低延迟，唯一办法是加钱（更多车辆、更多司机）。

性能优化就是这么回事：

性能优化的本质，是在给定的成本预算下，重新分配「吞吐—延迟」这一对矛盾。

所以当有人说「我要性能更好」时，你必须追问：

「你能接受多大成本？你更在意「每秒处理更多」还是「每个请求更快」？」

二、三个指标的通俗定义与精确含义

2.1 吞吐量（Throughput）

通俗：单位时间能干完多少活。
精确：每秒完成的请求数（req/s、QPS、RPS）。注意分母是「成功完成」的请求数——返回 500 的错误请求不该算进吞吐。

2.2 延迟（Latency / Response Time）

通俗：一个请求从发出到收到结果，等了多久。
精确：必须说明是哪个点测的——客户端观测、网关观测、服务端 handler 内部，三者数值不同（第 1 章会展开）。

2.3 资源成本（Cost / Resource）

通俗：为了达到上面两个数字，花了多少钱。
精确：CPU 核数、内存、连接数、副本数、以及这些折算成的账单。

记住：延迟和吞吐是「结果」，成本是「代价」。只谈前两个而不谈代价的性能报告，是不完整的。

三、一个具体的数字例子：批量 vs 单条

假设你在写一个批量导入功能，要往数据库插 1000 行。

方案 A：逐条插入

延迟是分布，不是数字

Mon, 01 Jan 0001 00:00:00 +0000

0.3 延迟是分布，不是数字

上一节：0.2 吞吐、延迟、成本的三方权衡　|　下一节：0.4 用 Little’s Law 估算容量配套代码：00-introduction/03-latency-distribution 动手：建议先跑一遍配套代码，本节的两个现象都能亲眼看到。

一句话结论

「这个接口的平均延迟是 11 ms」这句话，可能同时意味着「99% 的人只等了 1 ms」和「1% 的人等了整整 1 秒」。 后端必须看延迟的分布，尤其是尾部。

一、一个 100 个请求的数字游戏

假设你的接口收到了 100 个请求：

99 个请求很快，各花了 1 ms；
1 个请求很慢，花了 1000 ms（比如遇到了 GC 停顿或数据库锁等待）。

现在计算平均值：

总耗时 = 99 × 1 ms + 1 × 1000 ms = 1099 ms
平均延迟 = 1099 / 100 ≈ 11 ms

报出去的数是 11 ms。听起来很棒，对吧？

但对那 1 个用户来说，他结结实实地等了 1 秒。如果这个接口一天被调用 100 万次，那就是一万个用户每天遇到「卡了一秒」。

用 Little's Law 估算容量

Mon, 01 Jan 0001 00:00:00 +0000

0.4 用 Little’s Law 估算容量

上一节：0.3 延迟是分布，不是数字　|　下一节：0.5 为什么 90% 利用率已经很危险配套代码：00-introduction/04-littles-law

一句话结论

「店里同时有多少人」= 「每分钟进来多少人」× 「每个人待多久」。 这个小学除法能让你在动手压测之前就算出：连接池要多大、线程要多少、协程并行度设多少。

一、先说人话：小饭馆的例子

你开了一家小饭馆：

平均每分钟进来 5 个客人（到达率 λ）；
每个客人平均坐 20 分钟（停留时间 W）。

那么店里平均同时坐着多少人？

5 人/分钟 × 20 分钟 = 100 人

显然——每分钟进来的人 × 每人待的分钟数 = 店里同时有人数。

这个「显然」的结论，就是 Little’s Law（利特尔法则）。它之所以重要，是因为把「客人」换成「请求」、把「座位」换成「连接」，它就变成了容量估算公式。

二、公式与每个符号的人话含义

L = λ × W

符号	名字	人话	在这个公式里的单位
L	并发数 / 在途请求数	任意时刻系统里「正在被处理、还没结束」的请求个数	个
λ	到达率	每秒有多少个请求进来	req/s
W	驻留时间	一个请求从进来到结束平均花多久	秒

单位换算的直觉：req/s × s = 个——秒被约掉了，剩下的就是「同时有几个」。

为什么 90% 利用率已经很危险

Mon, 01 Jan 0001 00:00:00 +0000

0.5 为什么 90% 利用率已经很危险

上一节：0.4 用 Little’s Law 估算容量　|　下一节：0.6 协调遗漏：压测报告的最大谎言配套代码：00-introduction/05-queueing 动手：这一节强烈建议跑一遍配套模拟，因为结论违反直觉。

一句话结论

延迟对「利用率」的反应不是线性的。 CPU 用到 50% 时，排队几乎不存在；用到 90% 时，平均排队时间已经是服务时间的 9 倍。这就是容量规划必须留 30%–50% 余量的数学依据，而不是「保险起见」。

一、先用超市收银台建立直觉

想象一家超市只有一个收银台（一个 CPU 核 / 一个连接）：

收银员的忙碌程度	你去结账时的体验
50% 忙（一半时间在发呆）	你走过去基本不用等，直接结账
80% 忙	有时要等一下，因为前面可能正好有人
90% 忙	大概率要排队，而且队伍不短
95% 忙	几乎每次都要排长队
99% 忙	队伍无限增长，系统实际上已经瘫了

关键洞察：收银员只从 50% 忙到 90% 忙，「空闲时间」只从 50% 降到 10%（少了 5 倍），但你的等待时间却涨了远不止 5 倍。

为什么？因为空闲时间是「吸收波动」的缓冲。当收银员有 50% 空闲时，偶尔来一波客人马上就能消化掉；当只剩 10% 空闲时，一波客人来了就得排队，而排队期间又来了新客人——排队会自我强化。

二、把它量化：排队公式

在「单队列、单服务、到达时间随机、服务时间随机」这个简化模型下（学术上叫 M/M/1），平均排队等待时间的近似公式是：

平均等待时间 ≈ (ρ / (1 - ρ)) × 服务时间

其中 ρ（rho）就是利用率，取值 0 到 1。

协调遗漏：压测报告的最大谎言

Mon, 01 Jan 0001 00:00:00 +0000

0.6 协调遗漏：压测报告的最大谎言

上一节：0.5 为什么 90% 利用率已经很危险　|　下一节：0.7 九条常见谬误自查清单配套代码：00-introduction/06-coordinated-omission 这是本章最重要的一节。 它解释了一个现象：为什么你的压测 P99 很漂亮，上线后用户却在抱怨卡顿。

一句话结论

大多数压测工具是「收到响应才发下一个请求」。 这导致服务端卡顿的那一秒里，工具几乎没发请求，于是这次卡顿只被记录成 1 个慢样本、而不是几百个。尾延迟被系统性地藏起来了。这个现象叫协调遗漏（Coordinated Omission）。

一、用一个故事理解它

假设你开了一个办事窗口，外面有 100 个客户排队办事。

平时每个人办 1 秒。突然，第 50 号客户遇到一个复杂情况，窗口卡了整整 1 秒（比如系统查不动了）。

真实世界会怎样（客户自己来）

100 个客户是按自己的节奏来的。窗口卡住的那 1 秒里，外面又来了 100 个新客户（假设每秒来 100 个）。

所以这次卡顿的后果是：

100 个在排队的客户，每人多等 1 秒；
100 个新来的客户，一进门就要等；
总共 200 个客户的体验被拖慢了 1 秒。

用「轮到我才去」的方式会怎样（典型压测工具）

现在换一种组织方式：每次只派 1 个客户去窗口，他办完回来，再派下一个。

窗口卡住的那 1 秒里，外面没有任何新客户进来——因为那唯一一个客户还在窗口前等着呢。

于是统计结果变成：

这 1 秒的卡顿，只影响了 1 个客户；
报告里写：「100 个请求中有 1 个慢了 1 秒」，P99 看起来还凑合；
但那 200 个在真实世界里被拖慢的客户，根本没有出现在统计里。

这就是协调遗漏：压测工具的「节奏」与服务端的「卡顿」被协调在了一起，卡顿越大，工具发得越慢，慢样本越少，尾延迟被低估得越严重。

九条常见谬误自查清单

Mon, 01 Jan 0001 00:00:00 +0000

0.7 九条常见谬误自查清单

上一节：0.6 协调遗漏：压测报告的最大谎言　|　下一节：0.8 性能工程闭环用法：拿你现在项目里的做法，逐条对照。踩了 3 条以上，说明你现在的性能数据基本不可用。

一、九条谬误（对照自查）

❶ 只看均值，不看分布

表现：汇报「平均延迟 12 ms，性能良好」。
为什么错：均值会把 1% 用户的糟糕体验摊薄掉（见 0.3）。
改成：至少同时报 P50 / P95 / P99 + 错误率 + 样本量。

❷ 用闭环（VU）模型测尾延迟

表现：「用 100 个并发用户压了 5 分钟」。
为什么错：协调遗漏会系统性低估尾延迟，服务越糟报告越好看（见 0.6）。
改成：用恒定到达率（开环）模型；或至少交叉验证实际请求数是否等于期望值。

❸ 压测期间不观测服务端

表现：只盯着压测工具输出的 QPS 和延迟，服务端除了一个 top 什么都没看。
为什么错：你只知道「慢了」，不知道「为什么慢」，无法定位也无法优化。压测的价值有 80% 在服务端数据里。
改成：压测同时采集四层指标（业务/延迟/资源/饱和度），并保存火焰图与 GC 日志。

❹ 改完代码不回归压测

表现：「我觉得这次改动应该快了不少，直接上线吧。」
为什么错：没有 before/after 对比，优化收益无法证明，甚至可能引入了退化。
改成：同一脚本、同一环境、≥3 轮对比，并用统计方法判断差异是否显著（第 5 章）。

❺ 把一次运行的结果当结论

表现：「跑了一次，P99 是 95 ms，达标。」
为什么错：你自己的环境噪声可能有 ±8%，单次运行的数字毫无意义。
改成：先量化噪声底线（跑 5 次相同配置），再做结论；报告里给出每轮的值。

❻ 忽略预热（JVM 特有）

表现：服务启动后立刻压测，把前 30 秒的数据算进 P99。
为什么错：那时代码还在解释执行 / C1 阶段、连接池还是空的、数据库缓存还没热，数据不能代表稳态。
改成：预热阶段独立于测量阶段，且预热数据不计入统计。

❼ 数据集与线上不一致

表现：用 1 万行数据压测，线上是 1 亿行。
为什么错：数据量决定执行计划——1 万行可能全表扫描很快，1 亿行则会走索引。结论完全不可迁移。同样，均匀分布的数据会让缓存命中率虚高、锁竞争虚低。
改成：数据量与线上同数量级，访问分布用**幂律（齐夫）**模拟真实热点。

❽ 压测客户端与服务同机

表现：在同一台机器上跑服务和 k6。
为什么错：压测工具自己也要吃 CPU、内存、网络，和服务互相抢资源，两边数据都失真。而且会掩盖网络延迟。
改成：压测客户端独立部署；至少做到绑核隔离。

❾ 只看性能不看错误率

表现：「QPS 从 3000 提升到 5000，优化成功！」——同时错误率从 0.1% 涨到 4%。
为什么错：这不是性能提升，是把「慢」换成了「错」。返回 500 的请求不计入成功延迟统计，所以延迟数字反而「变好」了。
改成：性能与错误率必须同时看，且延迟统计的分母用总请求数，不是成功请求数。

二、这些谬误会互相掩盖

单独看每一条都不致命，但它们组合起来会形成「看起来很专业、实际上毫无信息量」的报告：

性能工程闭环

Mon, 01 Jan 0001 00:00:00 +0000

0.8 性能工程闭环

上一节：0.7 九条常见谬误自查清单　|　下一节：0.9 从 C++ 到 JVM：哪些直觉必须修正

一句话结论

性能工作不是一个「上线前压一次」的动作，而是一个八步循环。 每一次优化后的回归数据，都会成为下一轮的基线。

一、八步闭环

        ┌─────────────────────────────────────────────────┐
        │                                                 │
        ▼                                                 │
① 定义目标(SLO)                                           │
        ↓                                                 │
② 建立模型（Little's Law / 队列估算）                       │
        ↓                                                 │
③ 采集数据（压测 + 四层指标）                                │
        ↓                                                 │
④ 剖析归因（火焰图 / JFR / 线程快照）                         │
        ↓                                                 │
⑤ 定位根因（证据链 + 贡献占比）                              │
        ↓                                                 │
⑥ 优化（按优先级）                                          │
        ↓                                                 │
⑦ 回归验证（统计显著 + 长稳）                                │
        ↓                                                 │
⑧ 固化为门禁与监控 ─────────────────────────────────────────┘

为什么是循环而不是流程：第 ⑧ 步的监控数据会成为下一轮第 ① 步「目标是否需要调整」的输入；第 ⑦ 步的回归结果会成为下一轮第 ③ 步的基线。性能工作没有终点，只有「当前这一轮的稳定态」。

从 C++ 到 JVM：哪些直觉必须修正

Mon, 01 Jan 0001 00:00:00 +0000

0.9 从 C++ 到 JVM：哪些直觉必须修正

上一节：0.8 性能工程闭环　|　下一节：0.10 Lab 0：先被骗一次

一句话结论

你从 C++ 并发里练出来的直觉大部分仍然有效，但有 6 条在 JVM 上会给出错误结论。这一节逐条说清：哪些要保留、哪些要推翻、为什么。

一、先说好消息：哪些直觉完全成立

你的直觉	在 JVM 上是否成立	说明
减少内存访问、提高局部性有帮助	✅ 成立	CPU 缓存层级没变，缓存未命中依然昂贵
伪共享（false sharing）会拖慢性能	✅ 成立	只是修复手段不同（见下）
锁竞争会限制扩展性	✅ 成立	且 JVM 上更容易被 GC 与安全点放大
上下文切换有成本	✅ 成立	且协程的价值正是把切换成本降下来
批量处理能提高吞吐	✅ 成立	代价同样是延迟（见 0.2）
先测量再优化	✅ 成立	而且比 C++ 更重要（因为 JVM 更难预测）
算法复杂度决定上限	✅ 成立	任何平台都逃不过

所以不要把这一节理解成「C++ 经验没用」——恰恰相反，你的优势在于「知道到底在发生什么」，这是很多只会调参的人不具备的。

二、必须修正的 6 条直觉

❶ 「代码写出来，性能就定了」

C++ 的现实：编译产物固定，同一段代码第一次调用和第一万次调用性能基本一致。
JVM 的现实：代码要经历 解释执行 → C1 编译 → C2 编译 三个阶段，性能随调用次数变化。C2 还会根据运行时的类型分布做激进优化（比如把虚调用变成直接调用），一旦类型变了就**去优化（deoptimization）**退回重来。

后果：不预热的测量毫无意义；一次压测的前 30 秒和后 5 分钟是两个不同的系统。

Lab 0：先被骗一次

Mon, 01 Jan 0001 00:00:00 +0000

0.10 Lab 0：先被骗一次

上一节：0.9 从 C++ 到 JVM：哪些直觉必须修正　|　下一节：第 1 章指标与目标配套代码：00-introduction/10-lab0 预计时长：60 分钟（编码 20 分钟 + 观察与记录 40 分钟）

一、这个 Lab 想让你获得什么

不是学会写基准测试——那是第 2 章的事。

而是：亲手制造一次「数据完全错误，但看起来很正常」的经历，并把这种不适感记住。

因为你之后每一次看到漂亮的性能数字，都需要先怀疑一次。这种怀疑能力没法靠读书获得，只能靠被骗过一次。

二、实验的三个阶段

阶段 1：制造一个荒谬的数字（不消费返回值）

写一个「看起来有计算量」的函数，例如：对一个 4096 个元素的 IntArray 求和。

然后用 System.nanoTime() 包住一个循环调用它，打印每次迭代的平均耗时。故意不做任何防护：

不预热；
不消费返回值；
输入数组用规律数据（IntArray(4096) { it }）。

跑三次，观察数字。

阶段 2：加上防护，看数字怎么变

只改两件事：

消费返回值（把结果累加到一个外部的变量里，防止被优化掉）；
输入改成运行时随机数据（防止常量折叠）。

再跑 20 轮，观察数字如何从「几百纳秒」逐步下降到稳定值。

阶段 3：观察预热曲线

每 2000 次迭代采样一次耗时，打印 60 个采样点，画出（或观察）曲线，找到进入平台的时刻。

三、你应该观察到什么（预期现象）

⚠️ 你的具体数字会和我这里不同（取决于 CPU、JDK 版本、是否向量化），但现象的形态应该一致。

阶段 1 的预期：荒谬

round 0: 131.74 ns/op     ← 第一次很慢：类加载 + 解释执行
round 1:   0.21 ns/op     ← 荒谬！比一次内存访问还快
round 2:   0.19 ns/op     ← 依然荒谬

为什么荒谬：在现代 CPU 上，一次内存访问大约 1 纳秒，一次加法大约 0.3 纳秒。4096 次加法不可能在 0.19 纳秒内完成——这个数字在物理上不可能。