优化与验证 on Dorkytiger 的小屋

优先级金字塔：先问要不要做

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

7.1 优先级金字塔：先问要不要做

上一节：无　|　下一节：7.2 减少工作配套代码：07-optimization-and-validation/01-priority-pyramid

一句话结论

优化的收益从「不做」到「调 JVM 参数」递减，而成本和风险递增。 把顺序做反了，你会花一周调 GC 参数去优化一个本该加索引的查询。

一、用「医院分诊」理解优先级

急诊室不会按「谁先来」看病，而是按紧急程度分诊：

优先级	情况	处理
1	心跳骤停	立刻抢救
2	大出血	尽快处理
3	骨折	排队等
4	擦伤	最后处理

如果先给擦伤的人包扎，心跳骤停的人就死了。

性能优化完全一样。「不做某个功能」的收益常常大于「把它优化得快一点」。

二、六级金字塔

⑥ JVM 参数调优          ← 收益最小、风险最高、最容易做错
⑤ 微观常数优化（减少分配、避免装箱、换序列化器）
④ 缓存与池化
③ 架构与并发（批量、异步、隔离、背压）
② 算法与数据访问（复杂度、IO 次数、N+1、缺索引）
① 先问「这个功能真的需要吗」  ← 收益最高、成本最低

每一级的说明与典型收益

级别	做什么	典型收益	成本/风险
① 不必要	砍掉不必要的功能、减少返回字段、去掉重复计算	极大（直接省掉）	低（但是产品决策）
② 算法与数据访问	加索引、消除 N+1、批量查询、改进算法	数倍	低–中（改 SQL/代码）
③ 架构与并发	批量、异步化、隔离资源池、加背压	数倍	中（改架构）
④ 缓存与池化	多级缓存、连接池调优	中（P50 明显，P99 未必）	中–高（一致性风险）
⑤ 微观常数	减少分配、避免装箱、换序列化器	个位数百分比	中（可读性下降）
⑥ JVM 参数	堆大小、GC 选型	个位数百分比	高（需长期验证）

关键观察：①–③ 的收益是数倍级，⑤–⑥ 是个位数百分比级。

减少工作：最可靠的一类优化

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

7.2 减少工作：最可靠的一类优化

上一节：7.1 优先级金字塔　|　下一节：7.3 并发与并行配套代码：07-optimization-and-validation/02-reduce-work

一句话结论

与其把一件事做得更快，不如不做它。 「减少工作」类的优化（批处理、消除 N+1、提前剪枝、避免重复序列化）收益最确定、副作用最小、几乎不需要权衡——因为没有引入新的组件、缓存或并发。

一、用「少跑腿」理解减少工作

你每天要跑 5 趟超市，每趟 20 分钟，共 100 分钟。

优化方向	做法	效果
提高速度	开车更快（危险）	100 → 80 分钟
减少工作 ⭐	一次买齐（列清单）	100 → 24 分钟

后者的收益是前者的 8 倍，而且没有风险。

后端完全一样：把 N 次查询合并成 1 次，比「把每次查询优化得快 20%」收益大得多。

二、五种「减少工作」的模式

❶ 批处理：N 次变 1 次

// ❌ N 次往返
val orders = ids.map { repo.findById(it) }        // 100 次查询

// ✅ 1 次往返
val orders = repo.findByIds(ids)                  // 1 次：where id = any(?)

典型收益：组件基准实测（第 3 章 3.2 节）——批量比循环快 82 倍（P99 从 210 ms 降到 6.2 ms）。

并发与并行：加资源不等于变快

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

7.3 并发与并行：加资源不等于变快

上一节：7.2 减少工作　|　下一节：7.4 缓存配套代码：07-optimization-and-validation/03-concurrency-and-parallelism

一句话结论

并行化的收益有上限，而且过了某个点就变成负的。 原因是：并行需要共享资源（CPU、数据库、下游），而共享资源会排队。所以「加线程/协程」不是免费的加速——它常常只是把瓶颈从应用层转移到下游。

一、用「超市收银台」理解并行的上限

超市有 8 个收银台（= CPU 核数）。顾客排队结账。

做法	结果
开 4 个台	队伍较长
开 8 个台	最优（与核数匹配）
开 16 个台	收银员互相挤，通道拥堵 → 反而更慢
开 100 个台	完全没有空间，无法工作

关键洞察：收银员多了，但超市的物理空间、仓库补货能力没变——瓶颈转移了。

后端完全一样：

加了 2 倍线程 → 应用能并发处理 2 倍请求
但数据库只有那么多连接和处理能力
→ 请求全部堵在数据库前面
→ 整体更慢（因为锁竞争 + 上下文切换 + 数据库过载）

二、并行的三种正确用法

❶ 对 IO 密集操作：用协程，但要限制并发

// ❌ 无限制：10 万个协程全打到下游
suspend fun fetchAll(ids: List<Long>) = coroutineScope {
    ids.map { async { httpGet(it) } }.awaitAll()
}

// ✅ 限制并发（保护下游，也保护自己）
private val limiter = Semaphore(64)
suspend fun fetchAll(ids: List<Long>) = coroutineScope {
    ids.map { id -> async { limiter.withPermit { httpGet(id) } } }.awaitAll()
}

// ✅ 或按批次（更可控）
suspend fun fetchAllBatched(ids: List<Long>, batch: Int = 64) =
    ids.chunked(batch).flatMap { chunk ->
        coroutineScope { chunk.map { async { httpGet(it) } }.awaitAll() }
    }

为什么要限制：你是下游的客户端，你的并发就是下游的负载。 无限制的并发 = 对下游的 DDoS。

缓存：三重防护与三重代价

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

7.4 缓存：三重防护与三重代价

上一节：7.3 并发与并行　|　下一节：7.5 背压与韧性配套代码：07-optimization-and-validation/04-caching

一句话结论

缓存是"用一致性和复杂度换延迟"的交易，不是免费的加速。而且它有个反直觉的性质：能改善 P50，却可能让 P99 变差（因为未命中的那部分请求变慢了）。所以缓存必须有防护、有指标、有代价评估。

一、用「把工具放手边」理解缓存

你在修车，工具都在 20 米外的工具间。两种做法：

做法	好处	代价
每次去工具间拿	永远是"最新最全"的	慢
把常用工具放手边	快	工具会占地方；可能不是最新的；要找地方放

缓存完全一样：快，但要占内存、可能过期（数据不一致）、需要管理（失效逻辑）。

二、三个收益

收益	说明	典型量级
降低延迟	内存读取（纳秒）vs 数据库查询（毫秒）	10–1000 倍（单次）
提高吞吐	同样硬件能扛更多请求	取决于命中率
保护下游	减少打到数据库的请求	按命中率折算

注意第一项：单次缓存的收益是巨大的（纳秒 vs 毫秒），但整体收益取决于命中率：

命中率 90% → 90% 的请求快 100 倍，10% 的请求慢一点（缓存开销）
命中率 50% → 一半快，一半慢——P99 可能变差
命中率 10% → 几乎没有收益，但引入了全部复杂度

三、三个代价（必须评估）

❶ 一致性风险 🔴 最危险

场景	后果
缓存更新失败但数据库成功	用户看到旧数据，且不知道会持续多久
多实例缓存不一致	用户刷新两次看到不同结果
缓存过期与写入竞争	旧值覆盖新值（经典的缓存并发问题）

必须回答的问题：

背压与韧性：保护自己也保护下游

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

7.5 背压与韧性：保护自己也保护下游

上一节：7.4 缓存　|　下一节：7.6 池化与复用配套代码：07-optimization-and-validation/05-backpressure-and-resilience

一句话结论

这五种手段（限流、熔断、隔板、超时、重试）共同回答一个问题：当压力超过承载能力时，系统该"怎么坏"。 好的设计是快速失败、局部失败、可恢复；坏的设计是排队到崩、全局崩、需要重启。

一、用「水库」理解背压

一座水库遇到暴雨（流量激增）：

措施	作用	对应
溢洪道	超过容量就放掉多余的水	限流（拒绝多余请求）
水位警戒线	到线就开闸，不等到决堤	熔断（提前失败）
分区堤坝	一个区决堤不影响其他区	隔板（资源隔离）
泄洪时间	给下游留出消化时间	超时（及时放弃）
重试	放掉的水再试一次	重试（要有退避和上限）

关键洞察：水库不会等到决堤才行动——它在警戒水位就开始泄洪。这就是"提前失败"的价值。

二、五种手段的分工

手段	防什么	关键参数	失败时的行为
限流	自己被打垮	速率上限	快速返回 429/503
熔断	被下游拖垮	错误率阈值 + 半开探测	快速失败（不调用下游）
隔板	一个依赖拖垮全部	每个依赖的独立资源池	该依赖的请求排队，其他正常
超时	资源被长期占用	逐层递减的超时	主动放弃并释放资源
重试	偶发失败	次数上限 + 退避 + 抖动	放大压力（必须约束）

注意最后一行：重试是唯一一个会"放大压力"的手段——所以它必须有严格约束。

三、超时预算（最重要，也最容易做错）

核心规则

本层的超时 < 上游给你的超时
且逐层递减

客户端 500ms
  └→ 网关 400ms
       └→ 应用 300ms
            ├→ 数据库 80ms
            ├→ 缓存 10ms
            └→ 下游服务 100ms

为什么这是"最救命"的一条

❌ 错误配置：应用给数据库的超时是 30 秒（默认值，没人改）

① 数据库变慢，每个查询要 3 秒
② 应用线程被占住 3 秒（因为超时是 30 秒，不会提前放弃）
③ 网关在 1 秒时超时返回 504 给用户
④ 但应用线程还在等数据库（还有 2 秒）
⑤ 新请求继续进来，占用新线程 → 线程池耗尽
⑥ 所有接口开始超时 → 服务雪崩
⑦ 流量回落后，那些连接还在等 → 【无法自愈】

超时不是「容忍时间」，而是「放弃的时机」——放弃得早，系统才能自愈（第 3 章 3.6 节）。

池化与复用：连接池要算，对象池要慎

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

7.6 池化与复用：连接池要算，对象池要慎

上一节：7.5 背压与韧性　|　下一节：7.7 JVM 调优配套代码：07-optimization-and-validation/06-pooling

一句话结论

池化是在「复用成本」与「获取成本」之间做取舍。 对真正昂贵的资源（数据库连接、线程）池化收益巨大；对本身就很便宜的（普通对象），池化在 JVM 上通常是负优化——因为池的同步成本可能超过分配成本。

一、用「租车 vs 买车」理解池化

做法	获取成本	持有成本	适用
每次买车	极高（几十万）	—	❌ 不现实
租车（池化）	低（走过去开走）	租金 + 停车位	✅ 偶尔用车
自己组装再拆开	组装费 > 直接买	—	❌ 荒谬

后端对应：

资源	获取成本	池化
数据库连接	高（TCP 握手 + 认证 + 数据库侧分配进程/内存）	✅ 必须池化
线程	高（几十微秒 + 1MB 栈）	✅ 必须池化
HTTP 连接	中（TCP + TLS 握手）	✅ 应该复用
普通对象	极低（TLAB 指针碰撞，比一次内存访问还快）	❌ 通常是负优化
大缓冲（ByteArray）	中（分配 + GC + 可能 Humongous）	⚠️ 可能值得
直接内存缓冲	高	✅ 值得

注意第四行：这是 JVM 与 C++ 最大的直觉差异之一（第 6.7 节）。

JVM 调优：永远排在最后

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

7.7 JVM 调优：永远排在最后

上一节：7.6 池化与复用　|　下一节：7.8 优化的三问纪律配套代码：07-optimization-and-validation/07-jvm-tuning

一句话结论

JVM 调优是「榨取最后几个百分点」的手段，不是解决性能问题的方法。 它的收益通常是个位数百分比，而验证成本高、风险大（可能让吞吐下降而延迟只改善一点）。所以它永远排在最后。

一、用「修车」理解 JVM 调优的顺序

车开得慢，你会先检查什么？

顺序	检查项	对应
1	轮胎气压是否正常	代码合理性（有没有明显的浪费）
2	是不是一直踩着刹车	有没有阻塞、排队
3	油路是否通畅	数据库、网络是否正常
4	驾驶习惯	架构、并发模型
最后	调 ECU（发动机控制单元）	JVM 参数

如果你先调 ECU，而轮胎没气——你会花几天时间，最后发现没用。

二、JVM 调优能做什么、不能做什么

能做的

目标	手段
降低 GC 停顿	换低停顿 GC（ZGC/Shenandoah）、调堆、调 region 大小
提高吞吐	换 Parallel GC、加大堆
降低冷启动时间	AppCDS、减少类加载
减少内存占用	调堆、调元空间

不能做的

错误期望	现实
解决「N+1 导致的慢」	GC 参数与查询次数无关
解决「连接池排队」	与 GC 无关
解决「锁竞争」	换 GC 不会减少锁竞争（可能更糟）
解决「下游慢」	完全不相关
「让代码更快」	JIT 已经做了优化，参数影响有限

一句话：JVM 调优只影响「同一份代码的执行效率」，不影响「代码做了多少工作」。

优化的三问纪律与收益报告

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

7.8 优化的三问纪律与收益报告

上一节：7.7 JVM 调优　|　下一节：7.9 Lab 7 配套代码：07-optimization-and-validation/08-optimization-discipline

一句话结论

每一项优化都必须回答三个问题：提升多少？代价是什么？回归验证了吗？——答不出第三个问题的优化，本质上是技术债，而不是优化。

一、用「报销凭证」理解三问

公司报销，你需要三样东西：

报销	优化
发票（花了多少）	提升多少（before/after 数据）
用途说明（为什么花）	代价是什么（复杂度、风险、成本）
审批记录（谁批的）	回归验证了吗（功能 + 性能 + 长稳）

缺一样都不能报销——性能优化也一样：缺了"回归验证"，这次改动就是一笔没有凭证的开销。

二、三问详解

第一问：提升多少？

必须给出：

| 指标 | before | after | 变化 | 显著性 |
| --- | --- | --- | --- | --- |
| P50 | 20.1 ms | 8.3 ms | -58.7% | p=0.008 ✅ |
| P99 | 210.4 ms | 95.2 ms | -54.7% | p=0.008 ✅ |
| QPS | 498 | 499 | +0.2% | 不显著 |
| 错误率 | 0.05% | 0.03% | -0.02pp | — |

环境噪声底线：P99 ±13.2%，MDD ±26.4%
结论：改善 54.7%，远超 MDD，可信

三个要点：

Lab 7：优化 Lab 6 找到的瓶颈

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

7.9 Lab 7：优化 Lab 6 找到的瓶颈

上一节：7.8 优化的三问纪律　|　下一节：第 8 章持续化配套代码：07-optimization-and-validation/09-lab7 预计时长：90 分钟

一、这个 Lab 的目标

对 Lab 6 找到的三个瓶颈，实施优化并完成三问验证。

关键的训练点不是「会改代码」，而是：

按优先级排序（先改哪个？）
一次只改一处（否则无法归因）
每处都做三问验证（提升多少、代价、回归）
至少否决一项（比如"加缓存"）

二、任务清单

#	任务	产出	时长
1	列出候选优化并排序	优先级清单	15 min
2	实施优化 1（减少工作类）	before/after 数据	25 min
3	实施优化 2（架构/并发类）	before/after 数据	25 min
4	评估并否决一项优化	否决记录	10 min
5	写优化收益报告	`OPTIMIZATION.md`	15 min

三、任务 1：候选优化与排序

针对 Lab 6 的三个瓶颈，列出候选优化：

瓶颈	候选优化	金字塔层级	预期收益	代价
`/slow-cpu`（重复编译正则）	① 把 Regex 提到顶层（编译一次）	② 算法/IO	高	极低
	② 缓存 findAll 的结果	④ 缓存	中	一致性（数据变化）
	③ 减少正则匹配次数（改算法）	② 算法	高	中（需理解业务）
`/slow-io`（Default 上阻塞）	① 切到 `Dispatchers.IO`	③ 架构/并发	高	低
	② 改用异步驱动	③ 架构/并发	高	高（改驱动）
	③ 加信号量限制并发	③ 架构/并发	中	低
`/slow-db`（N+1）	① 改成批量查询	② 算法/IO	极高	低
	② 加缓存	④ 缓存	中	一致性风险
	③ 加索引	② 算法/IO	中	低

排序原则（第 7.1 节）：先做「减少工作」和「架构」层，缓存和常数最后。