性能 on 纪伟的个人博客

跟着一个 API 请求走完全程：后端全链路解剖

Fri, 20 Mar 2026 10:00:00 +0800

写在前面

Nginx、Kestrel、Redis、数据库——单看每一层，这个博客都有专文讲过。但它们怎么串成一次真实的请求？这篇把所有层穿起来，跟着一个 GET /api/orders/123 走完全程。

每一跳只讲三件事：原理（链到已有专文，不重复展开）、大概多慢（链到《每个程序员都该知道的延迟数字》）、怎么优化。这是博客的"集大成"篇——读完你会看到这些独立的文章其实是一条线上的事。

场景

用户在 App 里点开一个订单详情，前端发：

1
2


GET https://api.example.com/orders/123
Authorization: Bearer <JWT>

后端要做：验 JWT → 查 Redis 订单缓存 → 没命中就查 DB → 订单里要显示用户名，可能调下游用户服务 → 返回 JSON。

一次请求，九跳：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


浏览器 / App
 │ GET /orders/123 (JWT)
 ▼
[DNS] api.example.com → IP 第 0 跳
 ▼
[TCP + TLS 握手] 冷启动 2-3 RTT / 复用 0 第 1 跳
 ▼
[四层 LB (LVS / 云 SLB)] ───▶ [Nginx 反代] 第 2-3 跳
 │ TLS 终止 / 路由 / 限流
 ▼
 [Kestrel] epoll / IOCP 第 4 跳
 │ 中间件管线 第 5 跳
 ▼
 [Controller]
 │ │
 Redis ◀───┘ └──▶ 数据库 第 6-7 跳
 (缓存命中) (索引 / 磁盘 IO)
 │
 ▼ (可选)
 [下游用户服务] 第 8 跳
 HttpClient + 可能穿 sidecar
 │
 ▼
 JSON 返回 ▶ gzip ▶ TLS ▶ 客户端 第 9 跳

第 0 跳：DNS 解析

api.example.com 要先变成 IP。浏览器 / OS 本地缓存命中就 <1ms；没命中就走递归 DNS 一层层问上去，10–100ms。移动端弱网和运营商劫持会放大这一跳。

优化：DNS 预解析、合理 TTL、HTTPDNS（绕过运营商）。冷启动才痛，热请求基本免费。

第 1 跳：TCP + TLS 握手

TCP 三次握手 1 RTT；TLS 1.3 握手 1 RTT（1.2 是 2 RTT）。所以冷启动一个 HTTPS 请求要付 2–3 RTT，同机房就是 1–2ms，跨城就是几十 ms。

这一跳最重要的结论：连接复用是第一优化。keep-alive / 连接池把 2 个握手 RTT 省成 0，之后每次只剩 1 RTT。TLS 1.3 + session resumption + 0-RTT 进一步压。

这正是《HttpClient 的前世今生》那篇的核心——new HttpClient() 每次新建连接，把本该复用的 TCP 连接主动掐断、端口踢进 TIME_WAIT，是 .NET 史上最著名的反模式之一。

第 2 跳：入口（CDN / 四层负载均衡）

静态资源走 CDN 就近返回（不进后端）；动态 API 进四层负载均衡（LVS / 云 SLB / NLB），按 IP + 端口把包转发到某一台 Nginx。LB 本身 μs–ms 级，几乎不花钱。

优化：CDN 边缘缓存把静态挡在外面；LB 健康检查要及时摘掉挂掉的 Nginx，别把流量往死节点送。

第 3 跳：Nginx 反向代理

到七层入口 Nginx 了，它做四件事：TLS 终止（在这里解密，上游走明文）、路由（按 path / host 转发到对应上游）、限流（limit_req）、可选的鉴权前置。然后转发给 Kestrel。

详见《Nginx 学习笔记（二）：反向代理与负载均衡》《（三）：HTTPS、性能优化与实战》。Nginx 自身处理是 ms 级。

优化：最容易忘的一条是 upstream keepalive——Nginx 到 Kestrel 也要复用连接，别每个请求都新建一次 TCP（又掉进第 1 跳的坑）。其次是 HTTP/2、gzip 压缩响应。

第 4 跳：Kestrel 接收（I/O 模型 + Pipelines + 线程池）

包到内核了。Kestrel 用异步 I/O（Linux 上 epoll，Windows 上 IOCP）拿到数据，用 Pipelines（池化的零拷贝缓冲区）解析 HTTP 帧，再把请求丢给 ASP.NET Core 管线。全程不阻塞线程。

这一跳的灵魂是为什么不能阻塞线程——I/O 是 ms 级、线程是宝贵的纳秒级资源，让线程等 I/O 是用"贵的东西等便宜的东西"。完整的 I/O 模型谱系（阻塞/非阻塞/IO多路复用/异步）见《操作系统学习笔记（一）：I/O 模型全解》，.NET 视角的落地见《.NET 高并发编程全景》。

延迟：内核↔用户态拷贝 μs 级，几乎可以忽略。

第 5 跳：ASP.NET Core 中间件管线

请求流过中间件链：路由匹配 → 鉴权（验 JWT 签名和过期）→ 限流 → 日志 / 追踪埋点 → 进 Controller。这一段是纯 CPU，μs–ms 级。

详见《ASP.NET Core 学习笔记（一）：基础架构与启动流程》（中间件管线的本质）。

优化：中间件顺序有讲究（能短路的尽量靠前，比如鉴权失败直接 401，别白跑后面的活）；热路径上别 new 重对象、别做重活；依赖注入按需，别把瞬态服务当万金油。

第 6 跳：Redis 缓存层

Controller 先查 Redis（order:123）。命中 → 直接反序列化返回，跳过第 7 跳。

详见《Redis 学习笔记（二）：缓存实战》。同机房 GET 大约 ~0.1–0.3ms。

优化：缓存 key 设计、过期 + 预刷新、防穿透（空值也缓存一层）、防击穿（热 key 互斥重建）、防雪崩（过期时间加随机抖动）。

这一跳命中省下的是第 7 跳的 ~ms–10ms，是全链路杠杆最大的一处。缓存命中率从 90% 提到 99%，DB 压力差 10 倍。

第 7 跳：数据库（缓存未命中）

Redis 没命中 → 查 DB。SELECT ... WHERE id = 123 走一遍：解析 → 优化器选执行计划 → 走索引（B+ 树）→ 命中 buffer pool 直接返回；没命中触发磁盘 IO。

buffer pool 命中：~0.5–2ms；
触发磁盘 IO：再 +1ms（SSD）/ +10ms（HDD）。

索引原理见《数据库系列（三）：索引原理》，慢查询定位和 SQL 调优见《数据库性能优化实战》，《数据库系列（四）：事务与 ACID》里给过 fsync 的实测对照（HDD ~10ms / SSD ~1ms / NVMe ~0.1ms）。

优化：索引建对是 DB 性能的头号杠杆（一个该建没建的索引能让查询从 1ms 变 100ms）；其次是连接池、慢查询监控、把随机写转顺序写（WAL）。绝大多数"接口慢"的根因在这一跳，不在代码里。

第 8 跳：下游服务调用（微服务场景）

订单要显示用户名，本地没有，得调用户服务：应用层 HttpClient 发请求 → 可能穿过 sidecar（Envoy / ztunnel）→ 网络 → 对端 sidecar → 对端应用。

延迟 = 1 RTT + 两端序列化 + 对端处理 + sidecar 税。其中 sidecar 每 hop 多 2–5ms（Istio 官方 ~3ms p50 / ~10ms p99），详见《服务网格：从 sidecar 到 Ambient，那笔"分布式税"怎么省》。这也是《后端架构实战（四）：微服务的"分布式税"》讲的"分布式税"的本金。

优化：

并行调用——要调多个下游，用 Task.WhenAll 并发，别串行 await 三次（串行 vs 并行差的是整倍 RTT，见《.NET 高并发编程全景》）；
连接池（同第 1 跳，HttpClient 必须复用）；
缓存下游结果（用户名这种不常变的，缓存几分钟省一次跨服务调用）；
如果 sidecar 税痛，考虑 sidecar-less（Ambient / Cilium）。

第 9 跳：序列化 + 返回

对象 → JSON（中等对象 ~10–100μs）→ 原路返回：中间件收尾 → Kestrel 写响应 → Nginx gzip 压缩 → TLS 加密 → 客户端。

优化：压缩省带宽（但别 gzip 已经压过的图/视频）；大响应用异步流，别一次性 buffer 进内存；字段精简，别返回前端用不上的列（既浪费序列化又浪费带宽）。

把全程延迟叠起来

同机房、热请求（连接已复用、Redis 命中），这一路大概：

跳	热请求	冷启动 / 缓存未命中
DNS	<1ms（命中）	10–100ms
TCP + TLS	0（连接复用）	1–2ms（2–3 RTT）
LB + Nginx	~1ms	~1ms
Kestrel + 中间件	~1ms	~1ms
Redis（命中）	~0.2ms	—
DB（未命中才走）	—	~2–10ms
下游服务	0–5ms（视是否调用）	+2–5ms
序列化 + 返回	~1ms	~1ms
合计	~3–5ms	~15–30ms+

核心洞察：总延迟是各跳之和，抓最贵的那几跳——几乎总是 DB 的磁盘 IO + 网路的 RTT。在一个 μs 级的 JSON 序列化上纠结，不如把一个 DB 查询的索引建对（省 10ms）、把一个跨服务调用并行化（省一个 RTT）。这就是延迟数字篇"把现实操作拆回原子项"方法论的全链路应用。

全链路可观测

这么多跳，出问题了怎么定位"慢在哪"？给每个请求一个 traceId，跨所有跳透传（HTTP header），每一跳是一个 span。OpenTelemetry 把它们串成一条 trace，一眼看到哪一跳吃了 80% 的时间。

没有全链路追踪，慢请求是个黑盒；有了它，瓶颈一目了然。详见《后端架构实战（七）：可观测性——微服务的神经系统》。这是全链路的"运维面"，和前面十一跳的"原理面"同样重要。

小结

一次请求 = 九跳：DNS → TCP/TLS → LB → Nginx → Kestrel → 中间件 → Redis → DB →（下游服务）→ 序列化返回。每一跳都有专文展开原理、有延迟量级、有优化点。
总延迟 = 各跳之和，抓大头：DB 磁盘 IO 和网络 RTT 永远是重点，μs 级 CPU 处理不是。
杠杆最大的两处：缓存命中（直接省掉 DB 那一跳）+ 连接复用（省掉握手那两跳）。
微服务多一跳税：sidecar 每 hop +2–5ms，能并行就别串行。
排障靠全链路 trace：traceId 贯穿所有跳，是"慢在哪"的答案。

单看每一层是知识点，把它们串成一次请求，才是系统。这也是这个博客写到 117 篇，该有的那张"总图"。

参考资料

这篇是 capstone，主要交叉链接本博客的专题文章（见正文《》引用）。延迟量级全部来自《每个程序员都该知道的延迟数字》。想看跨层的系统性视角，推荐《Designing Data-Intensive Applications》（Martin Kleppmann）。

每个程序员都该知道的延迟数字：CPU、内存、磁盘、网络的数量级直觉

Wed, 04 Mar 2026 10:00:00 +0800

写在前面

做后端久了，你会发现所有性能问题本质都是同一个问题：你对各种操作到底有多快、有多慢，没有量级直觉。

为什么缓存要分三级？为什么等数据库时不能阻塞线程？为什么一次微服务调用"看起来只是个函数调用"却贵那么多？为什么压缩有时候反而更快？——这些决策的答案，都藏在一张表里：每个常见操作大概要花多少时间。

这篇就把这张表摆出来，逐个量级讲清楚，再落到工程决策上。不是让你背绝对值，而是建立"什么东西比什么东西快/慢多少个数量级"的直觉。有了它，你不用压测就能大概估出一个设计靠不靠谱——这就是所谓封底估算（back-of-the-envelope estimation）的底气。

这张表最早来自 Google 的 Jeff Dean 在 2010 年左右的那张著名幻灯片，后来被很多人更新过。本文用 Colin Scott 2020 年的更新版为基准，再补上真实系统里的常见量级。

一、那张经典表：每个操作要多久

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


先看全貌（典型量级，非精确值）：

 操作 延迟 换算成 ns
 ─────────────────────────────────────────────────────────────
 L1 缓存引用 0.5 ns
 分支预测错误 5 ns
 L2 缓存引用 7 ns
 互斥锁加/解锁 25 ns
 主存（DRAM）引用 100 ns
 用 Snappy 压缩 1 KB 3 μs 3 000
 1 Gbps 网络发送 1 KB 10 μs 10 000
 SSD 随机读 4 KB 150 μs 150 000
 内存顺序读 1 MB 250 μs 250 000
 同一数据中心往返（RTT） 0.5 ms 500 000
 SSD 顺序读 1 MB 1 ms 1 000 000
 机械硬盘寻道 10 ms 10 000 000
 机械硬盘顺序读 1 MB 20 ms 20 000 000
 数据包 加州↔荷兰 往返 150 ms 150 000 000

几个一眼能看出来的事实：

从 L1 缓存到主存，差了 200 倍（0.5 ns → 100 ns）；
从主存到 SSD 随机读，又差了 1500 倍（100 ns → 150 μs）；
从 SSD 到机械硬盘寻道，再差近 100 倍（150 μs → 10 ms）；
一切"快"的操作都在纳秒级，一切"慢"的操作都在毫秒级——微秒是分水岭。

记住这个"分水岭"，比记住任何一个具体数字都重要。

关于这张表的出处和精度：它是 Jeff Dean 2010 年那张著名幻灯片的经典数值集（业界转载数十年的版本），给你的是数量级而非精确值。比如 SSD 随机读 150 μs 是 SATA 时代的数，NVMe 已压到 ~16–100 μs；现代 CPU 的 L1 也更接近 1 ns。比例关系（主存比 L1 慢 200 倍、磁盘比内存慢 10 万倍）才是长期稳定的部分。完整来源与逐年演进见第十节。

二、把 1 纳秒放大成 1 秒

人对纳秒、毫秒没感觉，对秒、分钟、年有感觉。把整张表按 “如果 1 纳秒 = 1 秒” 放大，就能直观体会 CPU 视角下的世界有多慢：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


操作 实际 放大（1 ns = 1 s）
─────────────────────────────────────────────────────
L1 缓存 0.5 ns 0.5 秒 ← CPU 自己的节奏
L2 缓存 7 ns 7 秒
主存引用 100 ns 约 1.5 分钟 ← 走去茶水间
SSD 随机读 150 μs 约 1.7 天 ← 周末都没回来
同城网络往返 ~2 ms 约 23 天
数据中心往返 0.5 ms 约 5.8 天
机械硬盘寻道 10 ms 约 4 个月 ← 一个学期
跨洲网络往返 150 ms 约 4.75 年 ← 大学都毕业了

CPU 的"一秒"是 L1 缓存级别的瞬间。它要读个主存，相当于你等一杯咖啡；要等一次磁盘寻道，相当于等一个学期；要等一个跨洲网络包，相当于等大学读完。

这就是为什么"CPU 很快、磁盘很慢"不是一句口号，而是差着七八个数量级的鸿沟。 一切性能优化技巧——缓存、批量、异步、数据本地性——本质上都是"别让 CPU 去等那个学期的磁盘"。

三、CPU 与内存：跨不过的"内存墙"

CPU 这十几年频率涨不动了（GHz 顶天），靠的是多核和缓存。真正卡性能的是 CPU 和主存之间那条"内存墙"。

1
2
3
4


CPU 想用数据，先找寄存器 → L1（0.5 ns）→ L2（7 ns）→ L3 → 主存（100 ns）→ 磁盘

 每往外走一层，延迟翻几倍到几十倍。
 缓存行（cache line）通常 64 字节：一次搬 64 字节，不是 1 字节。

这条层次结构直接决定了三条写代码的铁律：

数据本地性（locality） 顺序访问数组，缓存命中，几乎免费；跳跃访问链表节点，每次都可能 miss 主存，慢两个数量级。这就是"同样逻辑，List<T> 比 LinkedList<T> 快得多"的根因——不是算法复杂度，是缓存。
分支预测 if 分支如果不可预测（比如对无序数据做条件筛选），CPU 流水线要付出 ~5 ns 的预测错误代价。把数据先排序再筛选，反而更快——因为分支变得可预测了。这是教科书级别的反直觉。
结构体布局 把经常一起用的字段放一起、紧凑排列（struct、缓存行对齐、避免伪共享），就是为了让一次缓存行加载尽量多带"有用数据"。.NET 里 Span、Memory、struct、stackalloc 的存在，全是服务于这条。

这些点在《.NET 高并发编程全景》《.NET 性能优化与 Profiling》里都有 .NET 视角的落地，这里只讲它背后的硬件量级。

四、磁盘：机械、固态、NVMe 三个量级

存储这条线上，硬件代际差着整整三个数量级，而且"随机"和"顺序"是两套世界。

1
2
3
4
5
6


 随机访问 顺序读 1 MB
─────────────────────────────────────────────────────
机械硬盘（HDD） 寻道 ~10 ms ~20 ms
SATA SSD ~150 μs ~1 ms
NVMe SSD ~10–100 μs ~0.5–1 ms
内存（对照） 100 ns 250 μs

几个关键直觉：

机械硬盘的随机访问是灾难性的。一次寻道 ~10 ms，因为它真的有个机械臂在物理移动。HDD 上做随机小 IO，每秒撑死几百次；
SSD 把"寻址"从机械运动变成了电子操作，随机访问掉了一个半数量级。所以数据库从 HDD 换 SSD，是"换了个数据库"级别的提升；
但随机 vs 顺序的差距，SSD 仍然存在（哪怕 NVMe）。所以"把随机写变成顺序写"这条铁律，在 SSD 时代依然成立。

这条铁律催生了两个最经典的工程实践：

WAL（预写日志）：数据库不直接随机改磁盘上的数据页，而是先把改动顺序追加到日志。fsync 一条顺序日志，比随机改 N 个数据页便宜得多。详见《数据库系列（四）：事务与 ACID》——里面给过 fsync 的实测对照：HDD ~10 ms / SSD ~1 ms / NVMe ~0.1 ms；
LSM 树 / Kafka：把随机写转成顺序写，牺牲一点读放大，换写入吞吐。Kafka 能扛百万级 TPS，根本原因就是它本质上是"顺序追加日志 + 零拷贝"，没有任何随机写。

五、网络：从机柜到跨洲

网络的延迟，主要由距离（光速）和跳数（路由器/交换机）决定。同一个机房和跨洲，差着两三个数量级：

1
2
3
4
5
6
7
8


场景 典型 RTT
──────────────────────────────────────────
同机 / 同机柜 ~0.1 ms
同数据中心（跨机柜） 0.5 ms
同城（同城双活） 1–3 ms
跨区域（北京 ↔ 上海） 20–30 ms
跨洲（中美 / 中欧） 120–200 ms
地球对跖点（光速理论极限） ~200 ms

RTT（Round-Trip Time）= 一个数据包打个来回的时间。地球表面两点的 RTT，物理上被光速（光纤里约 2×10⁸ m/s）封顶，再快的网络也突破不了——北京到上海 ~1200 km，光纤走线更长，单程再快也得 ~5 ms，来回就是十几到二十几 ms，这就是"跨城必然 20ms 起"的物理原因。

一个反直觉的点：小请求的延迟是 RTT 主导的，不是带宽主导的。

1
2
3
4
5
6


1 Gbps 网络发 1 KB：
 传输时间 = 1 KB / 1 Gbps ≈ 10 μs ← 带宽部分，很小
 但 RTT（同城） ≈ 2 ms ← 这才是你等的时间

 → 一次跨网小请求，你等的是"光跑一个来回"，不是"网线粗细"。
 所以"升级带宽"对降低单次小请求延迟几乎没用，得靠"减少 RTT 次数"。

这就解释了为什么 批量（batching）永远有效：把 1000 次"各跑一个来回"合成 1 次"跑一个来回"，延迟和往返次数一起降。

六、一次 HTTP 请求到底慢在哪

把上面几节拼起来，拆一次普通的 HTTPS 调用：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


冷启动（首次连接，不复用）—— 同机房为例，单次 RTT ≈ 0.5 ms：

 ① DNS 解析 命中本地缓存 <1ms；未命中走递归 10–100 ms
 ② TCP 三次握手 1 RTT ≈ 0.5 ms
 ③ TLS 握手 TLS 1.3 = 1 RTT（1.2 是 2 RTT） ≈ 0.5 ms
 ④ 请求 + 响应 1 RTT（小 body 被 RTT 主导） ≈ 0.5 ms
 ⑤ 服务端处理 业务 + DB，视情况 ~1–10 ms

 冷启动合计 ≈ 3 RTT + 服务端 ≈ 2.5–5 ms（同机房）
 跨城呢？每个 RTT 变 ~25 ms → 冷启动 ≈ 80–90 ms，服务端反而成了零头

两个直接结论：

连接复用是第一优化。冷启动要付 2 个 RTT 的握手税；复用连接（HTTP keep-alive / 连接池）后，每次只剩 1 个 RTT。HttpClient、Redis 连接池、数据库连接池，本质上都是在"省掉那 2 个 RTT"。这也是为什么 new HttpClient() 每次新建连接是个著名反模式——《HttpClient 的前世今生》那篇讲的就是这个坑；
跨城调用时，握手成本会把业务处理时间淹掉。所以"把服务和它的强依赖部署在同一个机房"几乎永远是值的。

七、把这些数字用起来：8 条工程决策

有了量级直觉，下面这些"经验法则"就不再是口口相传的玄学，每条都能对回那张表：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34


1. 缓存分层：L1 内存 → L2 Redis → DB
 每跨一层，差 ~100–1000×。本地内存命中 ~ns，Redis ~0.2ms，DB ~1–10ms。
 详见《Redis 学习笔记（二）：缓存实战》。

2. 异步 / I/O 并发：等 I/O 时绝不阻塞线程
 I/O 是 ms 级，CPU 是 ns 级——线程等 I/O 是"用 100 万倍贵的东西等便宜的东西"。
 Task.WhenAll 让多个 ms 级 I/O 并发，而不是串行累加。
 详见《.NET 高并发编程全景》《操作系统学习笔记（一）：I/O 模型全解》。

3. 批量：把 N 次 RTT 合成 1 次
 单次小请求被 RTT 主导，批量一次发完，往返次数从 N 降到 1。
 管线化（Redis pipeline）、批量插入（EF Core 的 AddRange + 一次 SaveChanges）、
 Kafka 的批量发送，都是这条。

4. 数据本地性：缓存友好的数据布局
 数组 > 链表、紧凑 struct、缓存行对齐、避免伪共享。
 算法复杂度相同，缓存命中决定实际快慢。

5. 顺序写：把随机写变成顺序写
 WAL、LSM、Kafka。这条让 HDD/SSD 的写入吞吐差出数量级。

6. 超时要有依据，别拍脑袋设 30s
 同机房调用设 1s 都算宽；跨城设几百 ms。依据 = RTT × 倍数 + 下游 p99。
 一律 30s 的超时，等于"允许一个慢调用占住线程半分钟"，是雪崩的温床。
 详见《后端架构实战（四）：微服务的"分布式税"》。

7. 微服务调用的真实成本
 每次跨服务 = 序列化 + 1 RTT + 反序列化 + 对端处理 ≈ ms 级。
 一个用户请求串 5 个服务，光网络就 +5ms+，还得算上重试/超时的尾部放大。
 单体里一个纳秒级的函数调用，到这就是几毫秒——这就是"分布式税"的本金。

8. 压缩的权衡
 压缩 1 KB ≈ 3 μs CPU，但能省下网络传输的 10 μs+/KB。
 跨网传输时压缩几乎总是赚的；同机房、大 CPU、小 body 时可能不赚。

八、现实世界一次操作要多久

经典表给的是硬件/网络的原子操作量级。这一节把它们组装成你日常后端真正会发起的那些操作——读一次 Redis、查一次库、两个 Pod 之间通一次信、穿过一层 sidecar。同样声明在前：全是量级参考，不是精确值，随硬件、CNI、负载、运行时而漂移；尤其 K8s 网络和 sidecar，不同 CNI（Calico/Cilium）和配置能差出几倍。

进程内 / 运行时

操作	典型量级
本地函数调用	~1 ns
本地缓存命中（IMemoryCache / 字典）	~ns–μs
一次系统调用（syscall）	~0.1–1 μs
一次线程上下文切换	~1–10 μs
一次 JSON 序列化（中等对象）	~10–100 μs
Minor GC 暂停	~1–10 ms
Full GC 暂停	数百 ms–秒级

数据层

操作	典型量级
Redis GET（同机房，连接复用）	~0.1–0.3 ms
Redis pipeline / MGET（批量，单条摊薄）	~几 μs/条
DB 主键查询（buffer pool 命中）	~0.5–2 ms
DB 索引范围扫描（返回 100 行）	~2–10 ms
DB 查询触发磁盘 IO	+ ~1 ms（SSD）/ ~10 ms（HDD）
Elasticsearch 查询（命中分片）	~5–50 ms
Kafka 单条 produce（acks=1，同步）	~1–5 ms
Kafka 单条 consume（顺序读页缓存）	~μs–ms
DNS 递归查询	10–100 ms（本地命中 <1 ms）

RPC / 网络层（K8s 视角）

这一层经典表里没有，但微服务时代每天都打。RTT 主导，每跨一跳加一次 RTT：

操作	典型量级
同 Pod 内（loopback，如 app ↔ sidecar）	~10–20 μs
同 Node 跨 Pod（veth pair）	~20–50 μs
跨 Node Pod 通信（overlay/VXLAN，同机房）	~0.1–0.5 ms
经 ClusterIP（kube-proxy / iptables DNAT）	几乎零额外（μs 级，高并发 conntrack 有损耗）
经 Service Mesh sidecar（Envoy，每 hop）	2–5 ms（每 hop 额外；Istio 官方 ~3 ms p50 / ~10 ms p99）
经 Ingress / API 网关（TLS + 路由 + 鉴权）	+1–5 ms
gRPC 单次调用（同机房，HTTP/2 连接复用）	~0.5–2 ms
REST/HTTP 单次调用（同机房，连接复用）	~1–3 ms
跨可用区调用（同城）	+2–5 ms
跨 region 调用	+几十 ms

Service Mesh 的"税"有多重：sidecar 模式下，一个请求要走 app → 本地 Envoy → 网络 → 对端 Envoy → 对端 app，多出两个本地 hop、两次 mTLS 加密。Istio 官方基准给的是 ~3 ms p50 / ~10 ms p99，业界普遍引用 2–5 ms 每 hop；高负载（数千 RPS）时一篇 arXiv 对比测出 Istio 延迟增加可达基线的 166%。这就是为什么 Ambient mesh（sidecar-less，ztunnel）和 eBPF 数据面（Cilium）在抢这块——把 sidecar 从数据路径上挪走。

拆解的乐趣：现实操作 = 原子项之和

把上面这些和经典表对照着看，你会发现真实系统的延迟，基本都能拆回"那张表"里的几个原子项：

一次 DB 查询 ≈ 若干次内存访问 + 可能的一次磁盘 IO；
一次同机房 gRPC ≈ 1 个数据中心 RTT + 两端序列化 + 两端处理；
一次穿 Service Mesh 的调用 ≈ 上一条 + 两个 sidecar 的 2–5 ms 税；
一次跨 region 调用 ≈ 基础调用 + 光速封顶的几十 ms RTT。

建立这种"把现实操作拆回原子项“的习惯，是性能估算的核心能力——也是这张表真正的用法。

九、数量级直觉练习

拿几个常见问题练手（答案都在前面那张表里）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


Q1：顺序读一个 10 GB 的文件，内存 / SSD / HDD 分别大概多久？
 → 内存：250 μs × 10240 ≈ 2.5 s
 → SSD：1 ms × 10240 ≈ 10 s
 → HDD：20 ms × 10240 ≈ 200 s（三分钟多）
 同一个文件，HDD 比 SSD 慢 20 倍、比内存慢 80 倍——这就是为什么要"热数据进内存"。

Q2：1000 次 Redis GET（同机房，连接复用），大约多久？
 → 单次 ~0.2 ms。串行：~200 ms。用 pipeline 批量（1 次 RTT）：~1 ms 量级。
 → 串行 vs 批量，差两个数量级。

Q3：一个 API 内部要调 3 个下游服务，串行调，跨城，每个 ~25ms RTT。
 改成并行（Task.WhenAll）能省多少？
 → 串行：3 × 25 = 75 ms。并行：max(25,25,25) ≈ 25 ms。
 → 省 50 ms。这是"能用 WhenAll 就别 await 三次"最直观的收益。

Q4：缓存穿透打到 DB，一次查询 5ms。QPS 2000，缓存命中率从 99% 掉到 90%，
 DB 压力翻几倍？
 → 99% 命中：2000 × 1% = 20 次/s 落库。
 → 90% 命中：2000 × 10% = 200 次/s 落库。10 倍。
 → 命中率"只"掉了 9 个百分点，DB 压力翻 10 倍——缓存命中率的杠杆极大。

这种估算不需要跑压测，对着表心算就行。一个能随时做这种估算的工程师，做设计时几乎不会犯"明显不合理"的性能错误。

十、数字从哪来，以及别死记

最后，关于这些数字本身：

出处：本文那张经典表用的是 Jeff Dean 2010 年那张著名幻灯片（“Latency Numbers Every Programmer Should Know”）的经典数值集——业界被转载了十几年的版本。UC Berkeley 的 Colin Scott 把它扩展成按年份滑动的交互图，能看到 1990→现在每个数怎么随硬件漂移；想看最易读的可视化，推荐 samwho 的 2020 版；
它们是量级参考，不是精确值。Dean 经典值和 Scott 的现代值在几处差一档（同数量级内）：L1 缓存 0.5 ns → 现代 ~1 ns、分支预测 5 ns → ~3 ns、L2 缓存 7 ns → ~4 ns、SSD 随机读 150 μs → NVMe 时代 ~16–100 μs；而主存 100 ns、数据中心 RTT 0.5 ms、磁盘寻道 10 ms 这些长期稳定。硬件还在继续漂移（HBM/CXL 压缩 CPU↔内存鸿沟、QUIC/TLS 1.3 砍握手 RTT）。抓"数量级和相对比例”，而不是死记绝对值——5 年后绝对值会过时，“主存比 L1 慢 200 倍"这种比例关系却长期稳定；
要测自己的系统。生产里的真实数字，永远来自你自己的监控：看 p50 / p95 / p99 / p99.9，不要看平均值（长尾会被平均掉）。平均值是性能世界里最大的谎言之一。

参考资料

Latency Numbers Every Programmer Should Know — Colin Scott（交互图，按年份滑动）
colin-scott/interactive_latencies — GitHub 源数据仓库
Latency Numbers Every Programmer Should Know — samwho（2020 可视化）
More Numbers Every Awesome Programmer Must Know — High Scalability
Latency numbers every programmer should know — Hacker News 讨论（含质疑：部分数字是推算而非实测）
Jeff Dean, Software Engineering Advice from Building Large-Scale Distributed Systems（Stanford, 2009）—— 那张表的原始出处
Performance and Scalability — Istio 官方（sidecar 延迟基准：~3 ms p50 / ~10 ms p99）
Performance Comparison of Service Mesh Frameworks — arXiv（mTLS 下各 mesh 延迟对比）

想深入，推荐读《Designing Data-Intensive Applications》（Martin Kleppmann）第一章——它对"封底估算"这件事有极好的示范。

小结

一张表：从 L1 缓存（0.5 ns）到跨洲网络（150 ms），跨 8 个数量级；微秒是快慢的分水岭；
人化直觉：把 1 ns 当 1 秒，CPU 读主存 = 等一杯咖啡，等磁盘 = 等一个学期，等跨洲网络 = 等到毕业；
CPU↔内存：差 200 倍，缓存层次和数据本地性是一切优化的根基；
磁盘：HDD/SSD/NVMe 差三个量级，“随机 vs 顺序"是永恒命题，WAL/LSM/Kafka 都是把随机转顺序；
网络：RTT 受光速封顶，小请求延迟是 RTT 主导而非带宽，所以批量永远有效；
HTTP 请求 = 几个 RTT + 服务端处理，连接复用省掉的就是那 2 个握手 RTT；
现实操作量级：Redis/DB/gRPC 同机房都是 ms 级；K8s 同 Node 跨 Pod 是 μs 级、跨 Node ~0.1–0.5 ms；Service Mesh sidecar 每 hop 再 +2–5 ms；每跨一层网络加一次 RTT；
8 条决策：缓存分层、异步并发、批量、数据本地性、顺序写、有依据的超时、正视微服务调用成本、压缩的权衡；
方法论：抓数量级而非绝对值，看 p99 而非平均，用封底估算做设计判断。

记不住全部没关系——记住"内存比缓存慢 200 倍、磁盘比内存慢 10 万倍、一次跨网至少毫秒级"这三句，日常 90% 的性能判断就够用了。其余的，回来查这张表。

数据库性能优化实战：从慢查询定位到 SQL 调优的完整方法论

Tue, 24 Feb 2026 10:00:00 +0800

数据库性能优化,在很多人眼里是门"玄学"——慢了就加个索引,还慢就加内存,再慢就分库分表。这套凭感觉的打法,偶尔管用,经常把系统搞得更糟。

真正的性能优化是有方法论的:先定位瓶颈在哪,再看执行计划为什么慢,然后针对性地改索引 / 改 SQL / 改结构,最后验证。 跳过前两步直接动手,是优化最大的原罪。

本文以 Oracle 为主线（它的 AWR / ASH / DBMS_XPLAN 工具链最完整,是 DB 性能方法论的"参考实现"）,在每个分叉点给出 MySQL / PostgreSQL / SQL Server 的命令对照。原理通用,命令分库——方法论可以平移到任何一个关系数据库。

这是数据库系列的实战补充:系列（三）讲了索引是什么、（九）讲了优化器怎么工作,这篇回答的是手上拿到一个慢查询,怎么把它调快。

一、方法论:先定位,再优化

把优化分成三个层次,自顶向下,先确定"病在哪一层"再开方:

1
2
3
4
5
6
7
8


系统层 系统整体慢吗?瓶颈是 CPU / IO / 锁 / 等待?
 │ → 看等待事件、资源使用率
 ▼
会话层 是某几个会话 / 某几条 SQL 拖垮的吗?
 │ → 找 Top SQL、活跃会话
 ▼
SQL 层 这条 SQL 为什么慢?
 → 看执行计划,改索引 / 改 SQL

最大的反模式:跳过定位,直接"加索引"。 索引不是越多越好——它加速读,却拖慢写、占空间、还可能因为统计信息不准而根本不被使用。正确的姿势永远是:先用工具看清"慢在哪、为什么慢",再做最小且对症的改动。

二、第一步 · 定位慢查询

优化的第一步不是改 SQL,而是找出哪条 SQL 值得改。两个维度:累计耗时最长的和执行次数最多 × 单次代价的。

Oracle 主线:AWR + ASH + V$SQL

AWR(Automatic Workload Repository):周期性快照,记录系统统计。两个快照之间生成报告,直接看 “Top SQL by Elapsed Time / by Buffer Gets”。
1

sqlplus / as sysdba @?/rdbms/admin/awrrpt.sql # 选快照范围,生成 HTML 报告
ASH(Active Session History):每秒采样一次活跃会话,用于定位"某个时间点系统在等什么"。V$ACTIVE_SESSION_HISTORY。

V$SQL 找 Top SQL:

1
2
3
4
5


-- 平均单次耗时最长的 SQL
SELECT sql_id, executions, elapsed_time/1e6 AS elapsed_s,
 ROUND(elapsed_time/GREATEST(executions,1)/1e6, 3) AS avg_s
FROM v$sql
ORDER BY avg_s DESC FETCH FIRST 20 ROWS ONLY;

等待事件(wait events)判断瓶颈类型,这是 Oracle 方法论的精华:
- db file sequential read → 在做索引单块读(正常,但过多说明扫描次数多)
- db file scattered read → 在做全表/全索引扫描(可疑)
- log file sync → 提交(commit)代价,事务粒度太细
- enq: TX - row lock contention → 行锁等待,并发写冲突
- buffer busy waits / latch: ... → 热块 / 内存结构竞争

四库对照:慢查询定位工具

维度	Oracle（主线）	MySQL	PostgreSQL	SQL Server
历史 Top SQL	AWR 报告 / `DBA_HIST_SQLSTAT`	`performance_schema` / `sys` schema	`pg_stat_statements`	Query Store / `sys.dm_exec_query_stats`
实时活跃会话	ASH / `V$SESSION`	`sys.processlist` / `performance_schema.threads`	`pg_stat_activity`	`sys.dm_exec_requests` / `sys.dm_os_waiting_tasks`
等待事件	`V$SESSION_WAIT` / `V$SYSTEM_EVENT`	`performance_schema.events_waits_*`	`pg_stat_activity.wait_event`	`sys.dm_os_wait_stats`（等待统计的标杆）
慢日志	可选,通常用 AWR	`slow_query_log` + `long_query_time`	`log_min_duration_statement`	扩展事件 / 跟踪标志

通用法则:先看等待事件回答"在等什么"(CPU / IO / 锁 / 日志),再用 Top SQL 回答"谁在等"。两者一交叉,病根就出来了。

三、第二步 · 读懂执行计划

这是性能优化最核心的技能。看不懂执行计划,等于在黑暗里改 SQL。

Oracle 主线:DBMS_XPLAN

估算计划(不实际执行):

1
2


EXPLAIN PLAN FOR SELECT ... ;
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY());

真实计划(执行后看真实行数 / 时间,这才是生产排障用的):

1
2
3
4


-- 先让本次会话收集执行统计
ALTER SESSION SET STATISTICS_LEVEL = ALL;
-- 执行目标 SQL,然后取其游标的真实计划
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(format => 'ALLSTATS LAST'));

ALLSTATS LAST 会显示 A-Rows(真实行数)、Starts(执行次数)、A-Time(真实耗时)、Buffers(逻辑读)。

看计划时盯住这几样(通用)

真实行数 vs 估算行数:差一个数量级以上 → 统计信息过期,优化器基于错误估算选了烂计划。这是性能问题头号元凶。
访问方式:TABLE ACCESS FULL(全表扫)、INDEX RANGE SCAN(索引范围扫)、INDEX UNIQUE SCAN(索引唯一扫)。全表扫不一定坏(小表、或返回大比例数据时全扫反而更快),但大表全扫 + 高频 = 红灯。
JOIN 方式:NESTED LOOPS(适合驱动表小、内表走索引)、HASH JOIN(适合大表等值连接)、SORT MERGE JOIN。选错驱动表或 JOIN 方式是常见瓶颈。
有没有落盘排序/临时:SORT 但内存不够 → 写 temp,代价陡增。

四库对照:执行计划

维度	Oracle（主线）	MySQL	PostgreSQL	SQL Server
估算计划	`EXPLAIN PLAN FOR` + `DBMS_XPLAN`	`EXPLAIN`	`EXPLAIN`	`SET SHOWPLAN_XML/TEXT ON`
真实计划	`DBMS_XPLAN.DISPLAY_CURSOR('ALLSTATS LAST')`	`EXPLAIN ANALYZE`(8.0+)	`EXPLAIN (ANALYZE, BUFFERS)`	实际执行计划(图形)/`STATISTICS IO`
关键看点	`A-Rows` vs `E-Rows`、`Buffers`	`type`(ALL/range/ref/eq_ref)、`Extra`(`Using index`/`Using filesort`)	`rows`(估) vs `actual rows`(真)、`Buffers: shared hit/read`	估计行数 vs 实际行数、逻辑读
强制统计收集	`DBMS_STATS.GATHER_*`	`ANALYZE TABLE`	`ANALYZE` / autovacuum	自动(可手动 `UPDATE STATISTICS`)

通用判断:统计信息要准(这是地基);警惕"估算行数远小于真实行数"导致的错误 JOIN 顺序;任何"全表扫大表 + 高频"或"落盘排序"都值得深究。

四、第三步 · 索引调优

这是性价比最高、最通用的优化手段。系列（三）讲了索引的数据结构,这里讲怎么用索引提速。

通用法则

在 WHERE / JOIN / ORDER BY / GROUP BY 的列上建索引,优先选择性高(基数大)的列。
复合索引与最左前缀:(a, b, c) 能服务 a、(a,b)、(a,b,c),但不能服务 b 单独。把等值条件列放前、范围条件列放后。
覆盖索引避免回表:查询列都在索引里,就不用回表取数据。SELECT 别写 *,只取需要的列,才有机会用覆盖索引。
警惕索引失效的写法(让优化器放弃索引、退回全表扫):
- 函数包裹列:WHERE YEAR(create_time)=2024 → 改 WHERE create_time >= ... AND create_time < ...
- 隐式类型转换:WHERE phone = 13800000000(列是字符,值是数字)→ 统一类型
- 前导通配:WHERE name LIKE '%张' → 走不了普通 B 树索引
- OR 两边不全有索引 → 考虑拆 UNION ALL 或补索引
- IS NULL 的处理各库不同(PG 会索引 NULL,部分库默认不索引)

Oracle 索引类型补充

B-tree(默认)、位图索引(低基数列、数据仓库,OLTP 慎用)、反键索引(单调递增键消除热块)、函数索引(CREATE INDEX i ON t(UPPER(name)))、索引组织表(IOT)。

四库对照:索引能力

维度	Oracle	MySQL(InnoDB)	PostgreSQL	SQL Server
默认表模型	堆表	聚簇(主键即数据)	堆表	聚簇(默认)
特色索引	位图 / 反键 / 函数 / IOT	全文 / 空间 / 函数(8.0+)	部分索引 / 表达式索引 / GIN	列存索引 / 包含列(`INCLUDE`)
NULL 是否入索引	默认入	入	入	入
收集统计	`DBMS_STATS`	`ANALYZE`	`ANALYZE` / autovacuum	自动 / `UPDATE STATISTICS`

通用铁律:加了索引要验证它真被用了(看执行计划),并保持统计信息新鲜。索引建了却没被用,是最常见的"优化了个寂寞"。

五、第四步 · SQL 改写

写法不对,再好的索引也救不了。下面这些反模式几乎全库通用。

通用反模式

SELECT *:多取列 → 无法用覆盖索引、增加网络与内存开销。永远只取需要的列。
N+1 查询:循环里逐条查(通常是 ORM 的锅)。→ 改成一次 IN / 批量查。
深分页:OFFSET 1000000 LIMIT 20 要先扫过前 100 万行。→ keyset(游标)分页:WHERE id > :last_id ORDER BY id LIMIT 20。
IN 子查询:部分库优化器对 IN (subquery) 优化不佳。→ 改 JOIN 或 EXISTS。
COUNT(*) 全表:大表上很贵。→ 业务能接受就用近似值,或维护计数表。
笛卡尔积 / DISTINCT 滥用:JOIN 条件缺失或多余的去重,常常是中间结果集爆炸的根源。
相关子查询:每行都执行一次。→ 改成 JOIN 或窗口函数。

四库对照:分页与批量写语法

操作	Oracle	MySQL / PostgreSQL	SQL Server
分页	`OFFSET n ROWS FETCH NEXT m ROWS ONLY`(12c+)或 `ROWNUM`	`LIMIT m OFFSET n`	`OFFSET n ROWS FETCH NEXT m ROWS ONLY`
keyset 分页	`WHERE id > :last ORDER BY id FETCH NEXT 20 ROWS ONLY`	`WHERE id > :last ORDER BY id LIMIT 20`	同 Oracle
批量插入	多行 `INSERT` / `INSERT ALL` / PL/SQL `FORALL` / SQL*Loader	多行 `INSERT` / `LOAD DATA INFILE`(MySQL)、`COPY`(PG)	`BULK INSERT` / 表值参数

改写的核心思想:让优化器能走索引、减少中间结果集、减少排序与聚合代价。每改一处,用执行计划前后对比验证。

六、第五步 · 写优化与批量

读优化讲得多,但写往往是系统瓶颈所在。

批量 > 循环单条:Oracle 用 FORALL 批量绑定、多行 INSERT、SQL*Loader / 外部表;MySQL LOAD DATA INFILE;PG COPY;SQL Server BULK INSERT / SqlBulkCopy。逐条 INSERT + 逐条 commit 是性能杀手。
合理的事务粒度:log file sync(Oracle)/ binlog 同步代价来自 commit。太小(commit 太频繁)→ 日志成为瓶颈;太大 → 锁持有久、回滚贵。按业务折中。
大批量写入前先减负:临时禁用非关键索引(建完数据再建)、Oracle 用 NOLOGGING + APPEND 减少 redo。
顺序写优于随机写:自增主键 / 序列插入顺序,减少索引页分裂与热点。

七、第六步 · 结构与连接层

SQL 和索引调到头了,就上结构层:

连接池:短连接每次建连 + 认证开销巨大。务必用连接池(Oracle 用 UCP / 应用侧 HikariCP,PG 配 pgbouncer,MySQL/SQL Server 用应用侧池),池大小不是越大越好(数据库的进程/线程和内存有上限)。
读写分离:读多写少的场景,主写从读,把读压力分摊到副本。
分区(Partitioning):大表按范围 / 列表 / 哈希分区,配合分区裁剪(partition pruning),让查询只扫相关分区。
反范式 / 冗余:为了少 JOIN,适度冗余高 frequency 读取的字段(用空间换时间,要权衡一致性)。
缓存层:热点数据放 Redis,挡在数据库前面。

四库对照:分区

维度	Oracle	MySQL	PostgreSQL	SQL Server
分区类型	范围 / 列表 / 哈希 / 组合	范围 / 列表 / 哈希(`RANGE/LIST/HASH`)	范围 / 列表 / 哈希	范围 / 列表
分区裁剪	自动	自动	自动	自动
交换分区	`EXCHANGE PARTITION`	`ALTER TABLE ... EXCHANGE PARTITION`	`pg_partman`(扩展)	`ALTER TABLE ... SWITCH PARTITION`

八、避坑清单 + 结语

常见坑:

凭感觉加索引,不验证是否真被用、不收集统计信息。
不看执行计划就改 SQL,改完不对比。
只盯着单条 SQL,忽略等待事件暴露的系统性问题。
OFFSET 深分页、N+1、SELECT * 这类反模式。
忽略写入代价:逐条 commit、大批量写入时不减负。
过度优化:为了 1% 的场景把系统搞复杂,得不偿失。

结语:

数据库性能优化不是"加索引"三个字,而是一套先定位、再诊断、后动手的工程方法论。它的通用内核是:用等待事件回答"系统在等什么",用执行计划回答"这条 SQL 为什么慢",用索引 / SQL / 结构三层武器对症下药,每一步都用数据(执行计划、统计)验证,而不是靠手感。

这套方法论在 Oracle 上最成熟(AWR / ASH / DBMS_XPLAN 是标杆),但思想完全平移到 MySQL、PostgreSQL、SQL Server——工具名换了,逻辑不变。掌握了它,你面对任何一个"慢"字,都不再是玄学,而是可拆解、可验证的工程问题。

.NET 性能优化与 Profiling：定位瓶颈与榨干性能

Mon, 04 Aug 2025 10:00:00 +0800

写在前面

这是 .NET 性能系列的第三篇（前两篇是 Dump 诊断、高并发编程）。前两篇讲"出问题怎么查"和"怎么扛住流量"，这篇讲怎么跑得更快——如何用工具定位性能瓶颈，以及优化手段。

性能优化最容易犯的错是"凭感觉优化"。本文的核心是：先测量，再优化。掌握工具链比记住一堆技巧重要。

版本说明：基于 .NET 8 LTS。NativeAOT、InterpolatedStringHandler 等特性在 .NET 8 上均适用。

一、性能优化的黄金法则

1.1 测量优先

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


性能优化第一定律：
 "过早优化是万恶之源" —— Donald Knuth

正确的流程：
 1. 建立基线（当前性能是多少）
 2. 用工具定位瓶颈（慢在哪、为什么慢）
 3. 针对瓶颈优化
 4. 测量优化效果（验证真的变快了）
 5. 回归测试（没破坏功能）

错误的做法：
 ✗ 凭直觉优化（"我觉得这里慢"）
 ✗ 优化不重要的代码（占总时间 1% 的地方优化到极致没用）
 ✗ 没有基线就改（不知道改完是快了还是慢了）
 ✗ 牺牲可读性换微优化（得不偿失）

1.2 帕累托法则

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


80% 的时间花在 20% 的代码上

优化策略：
 找到那 20%（热点路径）→ 集中优化
 其余 80% 的代码 → 保持简洁可读

热点路径通常是：
 - 循环体
 - 高频调用的方法
 - I/O 操作（数据库、HTTP、磁盘）
 - 序列化/反序列化

1.3 优化的层级

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


优化收益从大到小：

 1. 架构优化 — 加缓存、异步化、读写分离、消息队列（收益 10x~100x）
 2. 算法优化 — O(n²) → O(n log n)（收益 10x）
 3. I/O 优化 — 减少 DB 往返、批量、连接复用（收益 5x）
 4. 实现优化 - LINQ 改循环、避免分配（收益 2x）
 5. 微优化 — struct、Span、内联（收益 1.2x）

 从上层往下做，微优化放最后。
 架构不对，微优化再多是杯水车薪。

1.4 性能问题的分类

动手前先判断"是哪一类问题"，这决定了用什么工具、查什么方向。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


按资源维度分类：

 CPU 密集型
 特征：CPU 持续 > 80%，吞吐上不去
 场景：复杂计算、正则滥用、低效算法
 看指标：cpu-usage 高
 工具：dotnet-trace（火焰图找热点函数）

 内存/GC 密集型
 特征：% Time in GC 高、内存持续增长
 场景：过度分配、内存泄漏、LOH 碎片
 看指标：time-in-gc、gc-heap-size、gen-2-gc-count
 工具：dotnet-gcdump / dotnet-dump

 I/O 密集型
 特征：CPU 不高但响应慢
 场景：数据库慢查询、外部 API、磁盘读写
 看指标：cpu-usage 低 + 响应慢
 工具：APM 链路追踪、数据库慢日志

 锁竞争
 特征：多核机器但只有一个核跑满，其他在等锁
 场景：全局锁、lock 持有时间过长
 看指标：contention rate 高
 工具：dotnet-stack（看线程在等什么）

1
2
3
4
5
6
7
8
9


按症状快速排查：

 症状 可能原因 排查方向
 ─────────────────────────────────────────────────────────────
 启动慢 依赖加载、JIT、初始化 启动日志、模块加载
 请求响应慢 DB 查询、外部 API、计算 APM 追踪、慢日志
 内存持续增长 泄漏、缓存无上限 gcdump 分析、GC 日志
 CPU 飙升 死循环、异常、高频计算 火焰图、线程栈
 间歇性卡顿 GC、定时任务、线程池耗尽 GC 日志、线程池监控

先分清类别，再选工具——避免拿着锤子到处找钉子。

二、性能分析工具链

.NET 有世界级的诊断工具链（dotnet-* 全家桶），覆盖从监控到采样到内存分析。

1
2
3
4
5
6
7


工具 用途 频率
──────────────────────────────────────────────────────
dotnet-counters 实时指标监控（CPU/GC/线程池） 实时
dotnet-trace CPU 采样、事件追踪、火焰图 录制
dotnet-stack 实时线程栈快照 实时
dotnet-dump 内存/线程/锁分析（离线） 抓取
dotnet-gcdump 托管堆分析（轻量） 抓取

2.1 dotnet-counters — 实时指标

第一步永远是看指标，判断瓶颈类型（CPU？内存？GC？线程池？）。

1
2
3
4
5
6
7
8
9


# 安装
dotnet tool install -g dotnet-counters

# 实时监控（默认 System.Runtime）
dotnet-counters monitor -p 12345

# 指定监控的计数器
dotnet-counters monitor -p 12345 \
 System.Runtime[cpu-usage,gc-heap-size,gen-0-gc-count,gen-1-gc-count,gen-2-gc-count,time-in-gc,threadpool-queue-length]

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


关键指标解读：

 指标 含义 正常 异常/告警
 ───────────────────────────────────────────────────────────────────────
 cpu-usage CPU 使用率 < 60% > 80% 持续
 time-in-gc GC 占 CPU 比例 < 10% > 20%
 alloc-rate 分配速率 稳定 持续高位
 gen-0-gc-count Gen 0 GC 次数 频繁（正常） —
 gen-1-gc-count Gen 1 GC 次数 偶尔 频繁
 gen-2-gc-count Gen 2 GC 次数 很少（几分钟一次） 频繁
 gc-heap-size GC 堆大小 稳定 持续增长（泄漏）
 threadpool-queue-length 线程池队列 < 10 > 100
 exception-count 异常总数 极少 持续增长
 working-set 内存占用 稳定 持续增长

诊断思路：
 cpu-usage 高 + time-in-gc 低 → 真正的 CPU 计算（算法/循环）
 cpu-usage 不高但卡 → I/O 等待或锁竞争
 time-in-gc 高（> 20%） → 分配过多，要减少分配
 threadpool-queue-length 高 → 线程阻塞（同步 I/O / 死锁）

2.2 dotnet-trace — CPU 采样与火焰图

dotnet-counters 告诉你"有问题"，dotnet-trace 告诉你"问题在哪行代码"。

1
2
3
4
5
6
7
8
9


# 安装
dotnet tool install -g dotnet-trace

# CPU 采样，录 30 秒，输出 speedscope 格式
dotnet-trace collect -p 12345 --profile cpu-sampling --format Speedscope -d 30
# 输出：xxx.speedscope.json

# 也可以用 nettrace 格式（PerfView 打开）
dotnet-trace collect -p 12345 -d 30

录完生成的 .speedscope.json 文件，上传到 https://speedscope.app 即可看火焰图。

高级：直接指定 ETW Provider

--profile cpu-sampling 是预设组合。需要更细的事件（比如只看 GC 分配），可以直接指定 ETW Provider 关键字：

1
2
3
4
5
6
7
8
9


# 只收集 GC 事件（找 GC 热点）
dotnet-trace collect -p 12345 \
 --providers Microsoft-DotNETCore-SampleProfiler,Microsoft-Windows-DotNETRuntime:0x1:4 \
 -d 30

# 专门收集堆分配（0x10000，找分配热点最有用）
dotnet-trace collect -p 12345 \
 --providers Microsoft-Windows-DotNETRuntime:0x10000:4 \
 -d 30

1
2
3
4
5
6
7
8


DotNETRuntime 常用关键字（掩码）：
 0x1 — GC（垃圾回收事件）
 0x4 — JIT（即时编译）
 0x10000 — GC Heap Allocation（堆分配，找分配热点最有用）
 0x20000 — GC Heap Survive and Movement（对象存活/移动）

格式：Provider:关键字:级别（4 = Informational）
排查分配问题，0x10000 最有用

2.3 dotnet-stack — 实时线程栈

不抓 dump，直接看所有线程当前在执行什么。适合排查"瞬时卡顿"。

1
2
3
4
5
6
7
8


# 安装
dotnet tool install -g dotnet-stack

# 打印所有线程栈（一次性快照）
dotnet-stack report -p 12345

# 持续轮询（每秒一次，看趋势）
dotnet-stack report -p 12345 --duration 00:00:30

2.4 内存分析（dotnet-dump / dotnet-gcdump）

内存泄漏和分配分析详见《.NET Dump 诊断》那篇，这里只列要点：

1
2
3
4
5
6
7
8


# 轻量堆 dump，看分配和引用
dotnet-gcdump collect -p 12345

# 完整 dump，深入分析
dotnet-dump collect -p 12345
dotnet-dump analyze xxx.dmp
> dumpheap -stat # 按类型统计
> gcroot <地址> # 引用链

三、火焰图：定位 CPU 热点

火焰图是性能分析最有力的工具，但很多人不会读。专门讲一下。

3.1 什么是火焰图

1
2
3
4
5
6
7
8


火焰图把采样数据可视化：
 - 横轴：函数调用栈（展开成"火焰"）
 - 纵轴：调用深度（底层是调用者，顶层是被调用者）
 - 宽度：该函数占用 CPU 的比例（越宽 = 越慢 = 优化重点）

读法核心：
 看最宽的"墙"——那是最耗时的调用栈
 从下往上读，找到最宽的那一层，就是瓶颈函数

3.2 火焰图示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


┌──────────────────────────────────────────────────────────┐
│ [Idle] │ ← 空闲
├──────────────────────────────────────────────────────────┤
│ Run() │
│ ├────────────────────────────┬─────────────────┤ │
│ │ ProcessRequest() │ LogRequest() │ │
│ │ ├───────────────┬────────┐ │ ├──────────┐ │ │
│ │ │ ParseJson() │ Query()│ │ │ Write() │ │ │
│ │ │ ███████████ │ ██████│ │ │ ██ │ │ │
│ │ │ (很宽=慢) │ │ │ │ │ │ │
└────────┴───────────────┴────────┘─┴─┴──────────┘────┘
 ↑ 宽度=CPU占比
 读图：ParseJson() 那块最宽 → 它是瓶颈 → 优化它

3.3 两种视角

1
2
3
4
5
6
7
8


speedscope 提供三种视图：

1. Time Order（时间顺序）— 按采样时间排列，看某个时刻在干嘛
2. Left Heavy（左重） — 按调用栈聚合，最常用，找最宽的块
3. Sandwich（三明治） — 按函数汇总，看每个函数的总耗时和调用次数

 找瓶颈：用 Left Heavy，看最宽的栈
 对比函数：用 Sandwich，按 Total Time 排序

3.4 常见火焰图形态

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


宽且平的"平台" → 某个函数本身耗时（CPU 密集计算）
 → 优化算法或实现

窄而深的"塔" → 调用链很长，但每层不耗时
 → 通常不是瓶颈，看塔顶

突然变宽的"瓶颈层" → 某一层突然占满，下面层层都宽
 → 那一层就是热点

大片 [Idle] → CPU 空闲，瓶颈在 I/O 或锁（不在 CPU）
 → 改用 dotnet-stack 看线程在等什么

四、BenchmarkDotNet — 微基准测试

想优化具体方法、对比两种实现，不要用 Stopwatch 手写——会测不准。用 BenchmarkDotNet。

4.1 为什么不能用 Stopwatch

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


// 错误：手写基准
var sw = Stopwatch.StartNew();
for (int i = 0; i < 1000; i++)
 MethodA();
sw.Stop();
Console.WriteLine(sw.ElapsedMilliseconds);

// 问题：
// ✗ 没预热（JIT 第一次执行慢）
// ✗ 没考虑 GC 时机（GC 恰好发生在 MethodA 里）
// ✗ 编译器可能优化掉"没用的"循环
// ✗ 没考虑 CPU 频率波动、其他进程干扰
// ✗ 样本太少，没有统计意义

4.2 基本用法

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30


// 安装
// dotnet add package BenchmarkDotNet

using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Running;

[MemoryDiagnoser] // 报告内存分配和 GC 次数
public class StringBenchmarks
{
 [Benchmark(Baseline = true)]
 public string StringConcat()
 {
 var s = "";
 for (int i = 0; i < 100; i++)
 s += i.ToString();
 return s;
 }

 [Benchmark]
 public string StringBuilder()
 {
 var sb = new StringBuilder();
 for (int i = 100; i > 0; i--)
 sb.Append(i);
 return sb.ToString();
 }
}

// 入口
var summary = BenchmarkRunner.Run<StringBenchmarks>();

4.3 读懂报告

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


| Method | Mean | Error | StdDev | Ratio | Allocated |
|--------------- |---------:|---------:|---------:|------:|----------:|
| StringConcat | 15.32 us | 0.312 us | 0.456 us | 1.00 | 6000 B |
| StringBuilder | 2.14 us | 0.043 us | 0.061 us | 0.14 | 320 B |

解读：
 Mean 平均耗时
 StdDev 标准差（越小越稳定）
 Ratio 相对基线的倍数（0.14 = 比 StringConcat 快 7 倍）
 Allocated 分配的内存（6000B vs 320B，差异巨大）

 结论：StringBuilder 比 += 快 7 倍，内存少 18 倍

4.4 常用特性

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


[SimpleJob(RuntimeMoniker.Net80)] // 指定运行时
[MemoryDiagnoser] // 内存/GC 诊断
[ThreadingDiagnoser] // 线程池诊断
public class MyBenchmarks
{
 [Params(100, 1000, 10000)] // 多种参数
 public int N { get; set; }

 [ParamsAllValues] // 所有值
 public StringComparison SC { get; set; }

 [Benchmark]
 public void Method() { /* 用 N */ }

 [Benchmark]
 [Arguments(1, "test")] // 直接传参
 public void WithArgs(int a, string b) { }
}

1
2
3
4
5
6
7
8


BenchmarkDotNet 的保证：
 ✓ 预热（JIT 编译、CPU 升频）
 ✓ 多轮采样，统计置信区间
 ✓ 隔离 GC 干扰
 ✓ 防止编译器"优化掉"测试代码
 ✓ 报告 Mean / Median / StdDev / Allocated / Gen0/1/2
 
 这是工业级的基准测试，结果可信

五、GC 调优

GC（垃圾回收）是 .NET 性能的核心。理解 GC 才能理解"为什么要减少分配"。

5.1 GC 基础

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


.NET 的 GC 是分代的：
 Gen 0 — 短生命周期对象，回收最频繁、最快
 Gen 1 — 缓冲区
 Gen 2 — 长生命周期对象，回收最慢（全堆扫描）
 LOH — 大对象堆（≥ 85000 字节），直接进 Gen 2

回收流程：
 Gen 0 满 → 回收 Gen 0（快）
 存活的对象晋升 Gen 1
 Gen 1 满 → 回收 Gen 1（连带 Gen 0）
 存活的晋升 Gen 2
 Gen 2 满 → 完整 GC（慢，可能 STW 几十毫秒）

性能核心：减少 Gen 2 回收
 Gen 2 GC 贵，会停顿所有线程（STW）
 办法：减少分配、复用对象、避免大对象频繁分配

5.2 Workstation GC vs Server GC

1
2
3
4
5
6
7


<!-- runtimeconfig.json / .csproj -->
{
 "configProperties": {
 "System.Runtime.GC.Server": true, // Server GC
 "System.Runtime.GC.Concurrent": true // 后台 GC
 }
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


 Workstation GC Server GC
──────────────────────────────────────────────────────────
堆数量 1 个 每核 1 个（并行回收）
线程 少 多（每核 GC 线程）
吞吐量 低 高
内存占用 小 大（多堆）
适用 客户端、单核 服务器、多核、高并发

ASP.NET Core 默认 Server GC（多核服务器最优）
桌面应用用 Workstation GC

1
2
3


// 代码里判断当前 GC 模式
Console.WriteLine(GCSettings.IsServerGC); // 是否 Server GC
Console.WriteLine(GCSettings.LatencyMode); // 延迟模式

5.3 GC 延迟模式

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


// 临时降低 GC 影响（关键路径不想被打断）
var oldMode = GCSettings.LatencyMode;
try
{
 GCSettings.LatencyMode = GCLatencyMode.SustainedLowLatency;
 // 这段代码期间，GC 尽量不做完整回收
 DoLatencySensitiveWork();
}
finally
{
 GCSettings.LatencyMode = oldMode; // 恢复
}

1
2
3
4
5


GCLatencyMode：
 Interactive 标准（平衡吞吐和延迟）
 LowLatency 短时低延迟（Gen 2 回收被抑制，仅 Gen 0/1）
 SustainedLowLatency 持续低延迟（适合实时场景）
 Batch 最高吞吐（不顾延迟，适合后台任务）

5.4 减少分配（GC 调优的根本）

GC 压力的根源是分配。分配越少，GC 越少。

1
2
3
4
5
6
7
8


减少分配的手段（实战角度，详见高并发文章的 Span/Pool 章节）：
 ✓ Span<T> / stackalloc — 零拷贝、栈分配
 ✓ ArrayPool<T>.Shared — 复用数组
 ✓ ObjectPool<T> — 复用对象
 ✓ 预分配集合容量 — new List<T>(128) 避免 resize
 ✓ struct 替代 class — 栈分配，无 GC（适用时）
 ✓ 避免 LINQ 在热路径 — 每次都分配迭代器
 ✓ string 插值替代拼接 — C# 10+ 的 InterpolatedStringHandler

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


// GC 通知：在 Gen 2 回收前收到通知（适合做平滑处理）
GC.RegisterForFullGCNotification(10, 10);
// 在后台线程轮询
Task.Run(() =>
{
 while (true)
 {
 GCNotificationStatus s = GC.WaitForFullGCApproach();
 if (s == GCNotificationStatus.Succeeded)
 {
 // Gen 2 即将发生，可做些准备（如拒绝新请求）
 }
 GC.WaitForFullGCComplete();
 }
});

六、JIT 与 AOT

.NET 默认是 JIT（即时编译），但也有 AOT（提前编译） 选项。

6.1 JIT 工作原理

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


源码 → IL（中间语言） → JIT → 机器码

JIT 的特点：
 ✓ 方法首次调用时才编译（按需）
 ✓ 基于实际运行情况优化（分层编译、PGO）
 ✓ 跨平台（IL 与 CPU 无关）
 ✗ 首次调用有编译开销（冷启动慢）
 ✗ 运行时占用内存（JIT + 优化代码）

.NET 8 的优化：
 分层编译（Tiered Compilation）— 先快速编译，热点再重新优化
 动态 PGO（Dynamic PGO） — 根据运行 profile 优化热点

6.2 ReadyToRun（R2R）— 预编译 IL

1
2


# 发布时预编译为机器码（但仍是托管，可 JIT 兜底）
dotnet publish -c Release -r win-x64 -p:PublishReadyToRun=true

1
2
3
4
5
6
7


R2R 的特点：
 ✓ 启动更快（部分方法已编译）
 ✓ 仍是托管代码（可被 JIT 进一步优化）
 ✗ 文件更大（包含预编译代码）
 ✗ 绑定平台（win-x64 / linux-x64）

适合：启动速度敏感、可接受更大体积的场景

6.3 NativeAOT — 完全提前编译

1
2
3
4
5
6


# .NET 8 正式支持
dotnet new console
# 在 csproj 加 <PublishAot>true</PublishAot>
dotnet publish -c Release -r win-x64

# 输出：单个原生可执行文件，无需 .NET 运行时

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


NativeAOT 的特点：
 ✓ 启动极快（无 JIT）
 ✓ 内存占用小（无运行时）
 ✓ 单文件部署，无依赖
 ✓ 部署到容器/边缘设备
 ✗ 不支持反射（或需显式 trim）
 ✗ 不支持动态加载程序集
 ✗ 编译时绑定平台
 ✗ 部分库不兼容（需要 AOT 友好）

适合：
 CLI 工具、云函数（冷启动敏感）、微服务、边缘计算
不适合：
 重度反射、动态代码生成的应用

1
2
3
4


JIT vs R2R vs NativeAOT 选择：
 标准部署（服务器、长期运行） → JIT（运行时优化最强）
 启动敏感、要兜底 → R2R
 冷启动极致、单文件、无依赖 → NativeAOT

七、常见性能反模式

实际项目中最常见的性能坑，附优化前后对比。

7.1 字符串拼接

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


// ❌ 慢：循环里 += （每次创建新字符串）
string result = "";
foreach (var item in items)
 result += item.ToString(); // O(n²)，大量中间字符串

// ✅ 快：StringBuilder
var sb = new StringBuilder();
foreach (var item in items)
 sb.Append(item);
var result = sb.ToString(); // O(n)

// ✅ 更快：string.Join（C# 内部优化）
var result = string.Join(",", items);

// ✅ 现代插值（C# 10+，零分配优化）
// InterpolatedStringHandler 直接写入目标，不分配中间 string
$"Total: {count:N0} items"; // 高效

7.2 LINQ 误用

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


// ❌ 热路径用 LINQ（每次分配迭代器、委托）
foreach (var x in list.Where(x => x.Active).Select(x => x.Value))
 Process(x);

// ✅ 热路径用显式循环
foreach (var x in list)
{
 if (x.Active)
 Process(x.Value);
}

// LINQ 适合可读性优先的非热路径；
// 性能敏感的热路径，显式循环更快（少分配）

7.3 装箱（Boxing）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


// ❌ 装箱：值类型转 object，堆分配
ArrayList list = new ArrayList(); // 老式集合，存 object
list.Add(42); // int → object，装箱！分配

// ✅ 泛型集合，无装箱
List<int> list = new List<int>();
list.Add(42); // 无装箱

// 隐蔽的装箱：
Console.WriteLine("Count: " + count); // string + int → 装箱
// C# 6+ 插值优化后：
Console.WriteLine($"Count: {count}"); // 无装箱（InterpolatedStringHandler）

7.4 async 误用

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


// ❌ async void（异常无法捕获，会崩溃进程）
async void DoWork() { await Task.Delay(100); throw new Exception(); }

// ✅ async Task
async Task DoWorkAsync() { await Task.Delay(100); }

// ❌ 异步里同步阻塞（死锁风险 + 线程池耗尽）
async Task BadAsync()
{
 var result = SomeSyncMethod().Result; // .Result 阻塞！
}

// ✅ 全程异步
async Task GoodAsync()
{
 var result = await SomeMethodAsync();
}

// ❌ Task.Run 包异步方法（多此一举，浪费线程）
var x = await Task.Run(async () => await httpClient.GetStringAsync(url));

// ✅ 直接 await（HttpClient 本身是异步 I/O）
var x = await httpClient.GetStringAsync(url);

7.5 集合未预分配容量

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


// ❌ 不指定容量：List 多次扩容（每次复制数组）
var list = new List<int>();
for (int i = 0; i < 10000; i++)
 list.Add(i); // 多次 resize + 复制

// ✅ 预分配容量：一次到位
var list = new List<int>(10000);
for (int i = 0; i < 10000; i++)
 list.Add(i); // 无 resize

// 同理：Dictionary、HashSet、StringBuilder 都支持容量
var dict = new Dictionary<string, int>(capacity: 1000);
var sb = new StringBuilder(capacity: 256);

7.6 闭包捕获

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


// ❌ 闭包捕获循环变量（分配委托 + 闭包对象）
foreach (var item in items)
{
 tasks.Add(Task.Run(() => Process(item))); // 每次分配闭包
}

// ✅ 显式传参（无闭包分配）
foreach (var item in items)
{
 var local = item;
 tasks.Add(Task.Run(() => Process(local)));
}

// 热路径避免频繁创建 lambda / 闭包

八、减少分配实战（复习）

减少分配 = 减少 GC = 提升性能。这部分在高并发文章详细讲过，这里从性能角度快速复习。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


// 1. ArrayPool — 复用数组（热路径必备）
byte[] buffer = ArrayPool<byte>.Shared.Rent(4096);
try { Process(buffer); }
finally { ArrayPool<byte>.Shared.Return(buffer); }

// 2. stackalloc — 栈分配（小缓冲，零 GC）
Span<byte> stackBuf = stackalloc byte[128];

// 3. string.Create — 高效构造字符串
string result = string.Create(length, state, (span, s) =>
{
 // 直接在目标内存写入，无中间分配
 for (int i = 0; i < span.Length; i++)
 span[i] = (char)('0' + (s.Value % 10));
});

// 4. struct 而非 class（适用时，避免堆分配）
// 小型、值语义的数据用 readonly struct
public readonly struct Point { public int X; public int Y; }

// 5. 避免防御性拷贝：用 readonly struct / in 参数
static void Process(in BigStruct data) { } // in = 按引用只读传入

九、性能优化流程总结

把前面所有内容串成一个可执行的流程：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


1. 建立基线
 dotnet-counters 看整体指标
 记录当前 QPS、P99 延迟、CPU、内存

2. 定位瓶颈类型
 CPU 高？→ CPU 密集（算法/分配）
 CPU 低但卡？→ I/O 等待 / 锁竞争
 time-in-gc 高？→ 分配过多
 threadpool-queue 长？→ 线程阻塞

3. 定位瓶颈位置
 CPU 密集 → dotnet-trace 录火焰图 → 找最宽的栈
 瞬时卡顿 → dotnet-stack 看线程栈
 内存问题 → dotnet-gcdump / dotnet-dump

4. 针对优化
 算法层 → 换数据结构 / 算法
 I/O 层 → 缓存、批量、异步、连接池
 实现层 → 减少分配、Span、避免 LINQ 热路径
 用 BenchmarkDotNet 验证优化效果

5. 验证收益
 重新测量，对比基线
 确认真的变快了（不是测量误差）

6. 回归测试
 确保功能没坏
 加上 benchmark 防止性能退化

优化决策树

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


慢在哪？
├─ CPU 高
│ ├─ 火焰图找到热点函数
│ ├─ 算法可优化？→ 换算法（收益最大）
│ ├─ 分配多？→ 减少分配（Span/Pool/容量）
│ └─ 计算密集？→ 并行化（Parallel/PLINQ）
├─ I/O 等待
│ ├─ 数据库？→ 缓存、批量、索引、连接池
│ ├─ HTTP？→ 并发（Task.WhenAll）、连接池、重试
│ └─ 全异步化（async/await 全链路）
├─ 内存/GC
│ ├─ time-in-gc 高？→ 减少分配
│ ├─ LOH 频繁？→ 复用大对象（ArrayPool）
│ └─ Server GC 开启？
└─ 锁竞争
 └─ 无锁化（Channel/并发集合/Interlocked）

十、实战案例

把前面的工具和流程串起来，看两个真实场景。

10.1 场景一：Web API 响应慢

现象：用户反馈接口响应 5 秒+，但 APM 显示数据库查询只要 100ms。

第一步：看指标判断类型

1
2
3


dotnet-counters monitor -p 12345 System.Runtime
# cpu-usage 飙到 95%，time-in-gc 正常
# → 判定：CPU 密集型（不是 I/O，不是 GC）

第二步：录火焰图找热点

1
2


dotnet-trace collect -p 12345 --profile cpu-sampling --format Speedscope -d 30
# 在 speedscope 打开，发现 80% CPU 花在某个 LINQ 查询

第三步：定位代码

1
2
3
4
5
6


// 火焰图指向这段：循环里调 .Any()，触发 N+1 查询
foreach (var order in orders)
{
 var hasDetails = _context.OrderDetails
 .Any(x => x.OrderId == order.Id); // 每个 order 一次 DB 往返
}

第四步：修复（批量查询替代循环查询）

1
2
3
4
5
6
7
8


var orderIds = orders.Select(x => x.Id).ToList();
var hasDetailsMap = _context.OrderDetails
 .Where(x => orderIds.Contains(x.OrderId))
 .GroupBy(x => x.OrderId)
 .ToDictionary(g => g.Key, g => g.Any()); // 一次查询全部

foreach (var order in orders)
 _ = hasDetailsMap.ContainsKey(order.Id);

第五步：Benchmark 验证

1
2
3


修复前：4500 ms, 1200 MB allocated
修复后： 120 ms, 25 MB allocated
提速 37 倍，分配减少 48 倍

10.2 场景二：内存持续增长（泄漏）

现象：进程内存每小时涨 200MB，最终 OOM 重启。

第一步：确认是泄漏

1
2
3


dotnet-counters monitor -p 12345 System.Runtime
# gc-heap-size 持续增长，gen-2-gc-count 越来越频繁
# → 判定：托管内存泄漏

第二步：抓 gcdump 看谁占内存

1
2
3


dotnet-gcdump collect -p 12345
# 用 PerfView / dotMemory 打开
# 发现 50 万个 DataItem 对象，疑似泄漏

第三步：用 dump 找引用链

1
2
3
4
5
6


dotnet-dump collect -p 12345
dotnet-dump analyze xxx.dmp
> dumpheap -type DataItem
> gcroot <DataItem 地址>
# 输出引用链：
# EventHandler[] → DataService.DataReceived → DataItem

第四步：定位根因

1
2
3


// 事件订阅了但从没取消，DataService 是长生命周期单例
service.DataReceived += OnDataReceived;
// DataConsumer 被 DataReceived 持有，永不释放

第五步：修复

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


public class DataConsumer : IDisposable
{
 private readonly DataService _service;
 private readonly EventHandler<DataEventArgs> _subscription;

 public DataConsumer(DataService service)
 {
 _service = service;
 _subscription = OnDataReceived;
 _service.DataReceived += _subscription;
 }

 public void Dispose()
 {
 _service.DataReceived -= _subscription; // 释放时取消订阅
 }
}

总结：内存泄漏三件套——dumpheap -stat 找大户、gcroot 找引用链、改代码断开引用。详见《.NET Dump 诊断》。

十一、小结

本文系统讲解了 .NET 性能优化与 profiling：

方法论：测量优先、帕累托、优化层级（架构 > 算法 > I/O > 实现 > 微优化）
工具链：dotnet-counters（指标）、dotnet-trace（火焰图）、dotnet-stack（线程栈）、dotnet-dump/gcdump（内存）
火焰图：怎么读，看最宽的栈找瓶颈
BenchmarkDotNet：工业级微基准，不要用 Stopwatch 手写
GC 调优：分代、Server GC、延迟模式、减少分配是根本
JIT / AOT：R2R、NativeAOT 的适用场景
反模式：字符串拼接、LINQ 热路径、装箱、async 误用、容量、闭包
优化流程：基线 → 定位 → 优化 → 验证 → 回归
实战案例：API 慢（N+1 查询）、内存泄漏（事件订阅）端到端排查

性能优化的核心心法：先测量，再优化；先架构，再微调；先热点，再全局。

至此 .NET 性能系列三篇（Dump 诊断、高并发、性能优化）完结。

.NET 高并发编程全景：从异步到高性能实战

Thu, 31 Jul 2025 10:00:00 +0800

写在前面

高并发是后端绕不开的话题。面试问、生产遇、架构要想。.NET 在高并发这块其实很强——async/await 模型、Channel、Span、Kestrel 都是世界级的实现，只是被 Java/Go 的声量盖住了。

本文系统梳理 .NET 处理高并发的全景：从理论概念，到异步编程、同步原语、并发集合、并行计算、高性能内存、缓存、限流熔断，最后落到数据库和监控。读完能建立完整的 .NET 高并发知识体系。

版本说明：本文基于 .NET 8 LTS（代码风格与 API 均适用），最低要求 .NET 7（内置限流中间件 AddRateLimiter 是 .NET 7 引入）。所有特性向上兼容 .NET 9 / .NET 10。涉及的关键 API 引入版本见各章节注释。

一、什么是高并发

1.1 定义

高并发没有绝对标准，通常指系统在短时间内处理大量请求的能力。但"高"是相对的：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


场景 QPS（每秒请求数） 并发连接数
─────────────────────────────────────────────────
个人博客 10 ~ 100 < 100
中型网站 1k ~ 5k 1k ~ 5k
电商秒杀 1万 ~ 10万 1万 ~ 5万
双十一峰值 10万 ~ 百万 十万级
搜索/广告 百万级 百万级

高并发不是单一指标，是 QPS、响应时间、并发数、
错误率、资源占用等多个维度的综合表现。

1.2 核心指标

1
2
3
4
5
6
7
8
9


QPS / TPS — 每秒请求数 / 事务数（吞吐量）
并发数 — 同时处理的请求数
响应时间（RT） — P50 / P95 / P99（看尾部延迟，不只看平均）
错误率 — 失败请求占比
资源占用 — CPU、内存、网络、磁盘 I/O

黄金法则：
 吞吐量（QPS）= 并发数 / 平均响应时间
 想提高 QPS：要么提高并发数，要么降低响应时间

1.3 高并发的挑战

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


1. 资源竞争
 多线程访问共享资源 → 需要同步（锁）→ 锁竞争降低性能

2. 数据一致性
 并发写同一数据 → 脏读、丢失更新、超卖

3. 性能瓶颈
 数据库连接、网络 I/O、CPU、内存都可能成为瓶颈

4. 系统稳定性
 流量突增 → 雪崩（一个服务拖垮整个链路）
 需要限流、熔断、降级

5. 可观测性
 高并发下问题难定位 → 需要链路追踪、指标监控

二、概念澄清：并发、并行、异步

这三个词常被混用，但本质不同。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


并发（Concurrency）— 同时应对多件事（可能交替执行）
 一个厨师同时做三道菜：切菜→炒A→切肉→炖汤→炒B...
 单核 CPU 也能并发（时间片轮转）

并行（Parallelism）— 同时做多件事（真正同时）
 三个厨师同时做三道菜
 需要多核 CPU 才能真正并行

异步（Asynchronous）— 不等待，先干别的
 厨师把菜放进烤箱，趁这时间去切菜，烤箱好了再回来
 本质是"不阻塞等待 I/O"

关系：
 异步是实现并发的一种方式（不阻塞线程）
 并行是利用多核同时计算
 高并发系统通常 = 异步 I/O + 适度并行 + 缓存 + 限流

1
2
3
4


.NET 中的对应：
 异步 → async/await、Task（处理 I/O 等待）
 并行 → Parallel.For、PLINQ（利用多核计算）
 并发 → 并发集合、Channel（多线程协作）

三、异步编程：async/await（.NET 的招牌）

async/await 是 .NET 高并发的基石。它让你写出看起来同步、实际异步的代码，不阻塞线程。

3.1 为什么异步能扛高并发

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


同步代码：
 请求1：读数据库（线程等 50ms）→ 处理 → 返回
 请求2：读数据库（线程等 50ms）→ 处理 → 返回

 每个请求占用一个线程，线程在等 I/O 时空转
 线程池默认几十个线程 → 几十个并发就饱和

异步代码：
 请求1：发起读数据库（线程释放）→ I/O 完成回调 → 处理 → 返回
 请求2：发起读数据库（线程释放）→ ...

 等 I/O 时不占线程，少量线程就能处理上万并发
 这就是 Kestrel 单机能扛数十万并发的根本原因

3.2 基本用法

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


// 同步（阻塞线程）
public User GetUser(int id)
{
 return _db.Users.Find(id); // 线程在这里等数据库
}

// 异步（不阻塞线程）
public async Task<User> GetUserAsync(int id)
{
 return await _db.Users.FindAsync(id); // 等待时线程释放
}

3.3 async/await 的本质：状态机

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


// 你写的代码
public async Task<string> GetDataAsync()
{
 var a = await GetDataAAsync();
 var b = await GetDataBAsync();
 return a + b;
}

// 编译器生成的（简化）
// 本质是一个状态机，await 之间是状态切换
public Task<string> GetDataAsync()
{
 var stateMachine = new StateMachine();
 stateMachine.builder = AsyncTaskMethodBuilder<string>.Create();
 stateMachine.MoveNext(); // 执行到第一个 await
 return stateMachine.builder.Task;
}

// MoveNext 内部根据状态决定执行哪一段
// state 0: 调 GetDataAAsync，注册回调，return
// state 1: A 完成，调 GetDataBAsync，注册回调，return
// state 2: B 完成，拼接结果，完成 Task

1
2
3
4


关键理解：
 await 不是"阻塞等待"，而是"注册回调后返回"
 线程在 await 处释放，I/O 完成后用线程池线程继续执行后续代码
 这就是为什么异步不占线程

3.4 Task vs ValueTask

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


// Task — 引用类型，每次都分配对象
public async Task<int> CountAsync()
{
 if (_cached) return _value; // 即使同步返回，也分配了 Task
 return await ComputeAsync();
}

// ValueTask — 结构体，热路径可避免分配
public ValueTask<int> CountAsync()
{
 if (_cached) return new ValueTask<int>(_value); // 零分配！
 return new ValueTask<int>(ComputeAsync());
}

1
2
3
4
5
6
7
8


选择：
 Task — 一般场景，API 简单，默认用它
 ValueTask — 高频调用、可能同步完成的热路径
 （缓存命中、内存计算）

注意：
 ValueTask 只能 await 一次（不能多次 await）
 不确定就用 Task，性能敏感再上 ValueTask

3.5 CancellationToken（取消）

高并发系统必须有取消机制——超时、用户放弃、服务降级时及时停止。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


public async Task<User> GetUserAsync(int id, CancellationToken cancellationToken)
{
 // 传递给下游
 return await _db.Users.FindAsync(id, cancellationToken);
}

// 调用方控制取消
using var cts = new CancellationTokenSource(TimeSpan.FromSeconds(5));
try
{
 var user = await GetUserAsync(1, cts.Token);
}
catch (OperationCanceledException)
{
 // 超时或主动取消
}

// 手动取消
cts.Cancel();

1
2
3
4
5


最佳实践：
 ✓ 所有公开的异步方法都接受 CancellationToken
 ✓ 传递给下游（数据库、HTTP、延时）
 ✓ 在循环里检查 token.ThrowIfCancellationRequested()
 ✗ 不要吞掉 CancellationToken 参数

3.6 ConfigureAwait

1
2
3
4
5


// 库代码：不要捕获同步上下文（避免死锁、提升性能）
await DoSomethingAsync().ConfigureAwait(false);

// ASP.NET Core：没有同步上下文，ConfigureAwait(false) 无意义
// （但写了也没坏处，库代码建议写）

1
2
3
4
5
6
7


历史背景：
 老的 ASP.NET / WinForms / WPF 有 SynchronizationContext
 await 默认回到原上下文 → 可能死锁
 ConfigureAwait(false) 避免

 ASP.NET Core 没有 SynchronizationContext → 不存在这问题
 但写库时养成习惯，跨平台兼容

3.7 IAsyncEnumerable（异步流）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


// 异步流：边产生边消费，不用一次性全部加载
public async IAsyncEnumerable<User> GetUsersAsync(
 [EnumeratorCancellation] CancellationToken ct = default)
{
 await foreach (var row in _db.Users.AsAsyncEnumerable().WithCancellation(ct))
 {
 yield return row; // 产生一个就返回一个
 }
}

// 消费
await foreach (var user in GetUsersAsync())
{
 Process(user); // 流式处理，内存友好
}

四、同步原语

先解释这个词，“同步原语”（Synchronization Primitive）不太好理解，拆开看：

同步 — 协调多个线程/进程，让它们有序访问共享资源，避免抢成一团
原语 — 最基础、不可分割的操作单元（primitive，“原始的”）

合起来：操作系统/运行时提供的、用来协调多线程访问共享资源的最底层机制。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


为什么需要"原语"：
 多个线程同时执行 _count++，看似一行，实际是三步：
 1. 读 _count 到寄存器
 2. 寄存器 +1
 3. 写回 _count
 线程 A、B 同时执行，可能互相覆盖 → 丢更新

 你没法自己"实现"一个原子操作，必须用系统/运行时提供的工具
 这些工具就是"原语"——它们是构建复杂同步逻辑的"原子积木"

打个比方：
 同步原语 = 乐高的基础积木块（lock、Semaphore、Event...）
 Channel、生产者-消费者 = 用积木拼出来的复杂结构

.NET 里的同步原语：
 lock / Monitor — 互斥锁
 Semaphore / SemaphoreSlim — 信号量
 Interlocked — 原子操作
 ManualResetEvent 系列 — 事件等待句柄
 Mutex / ReaderWriterLockSlim — 互斥锁 / 读写锁

当多线程必须访问共享资源时，就用这些原语来协调。下面逐一介绍。

4.1 选择指南

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


场景 推荐
──────────────────────────────────────────────
简单的临界区保护 lock / Monitor
异步代码里的锁 SemaphoreSlim
原子计数/标志 Interlocked
读多写少 ReaderWriterLockSlim
进程内信号量/并发限制 SemaphoreSlim
跨进程互斥 Mutex
跨进程信号量/并发限制 Semaphore
跨进程事件通知 EventWaitHandle
线程间事件通知（进程内） ManualResetEventSlim
等待N个任务完成（fork-join） CountdownEvent
生产者-消费者 Channel<T>（不用自己加锁）
高并发字典 ConcurrentDictionary

4.2 lock / Monitor

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


private readonly object _lock = new();
private int _count;

public void Increment()
{
 lock (_lock) // 等价于 Monitor.Enter / Exit
 {
 _count++;
 }
}

// 注意：
// 1. lock 对象要是 readonly private，别 lock(this)、lock(typeof(X))
// 2. lock 内不要 await（lock 不支持，会编译错误）
// 3. 持锁时间尽量短

4.3 SemaphoreSlim（异步友好）

lock 不能 await，异步代码用 SemaphoreSlim。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


private readonly SemaphoreSlim _semaphore = new(1, 1); // 初始1，最大1 = 互斥

public async Task UpdateAsync()
{
 await _semaphore.WaitAsync(); // 异步等待锁
 try
 {
 await DoWorkAsync(); // 锁内可以 await
 }
 finally
 {
 _semaphore.Release(); // 必须释放
 }
}

// 也可以做并发数限制（不只是互斥）
private readonly SemaphoreSlim _concurrencyLimit = new(100); // 最多100并发

4.4 Semaphore（跨进程信号量）

SemaphoreSlim 只能进程内，需要跨进程限制资源并发访问时用 Semaphore。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


// 命名信号量：跨进程可见
// 限制本机最多 3 个进程同时访问某资源
using var semaphore = new Semaphore(
 initialCount: 3,
 maximumCount: 3,
 name: @"Global\MyAppResourceLimit"); // 命名 → 跨进程

semaphore.WaitOne(); // 获取（计数-1），满了就等
try
{
 AccessSharedResource(); // 临界区，跨进程生效
}
finally
{
 semaphore.Release(); // 释放（计数+1）
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


Semaphore vs SemaphoreSlim：
 Semaphore SemaphoreSlim
─────────────────────────────────────────────────────────
底层实现 OS 内核对象 托管对象（用户态）
异步等待 WaitAsync ✗（只有 WaitOne） ✓
跨进程（命名） ✓ ✗
性能 较低（内核态切换） 高

选择：
 进程内 + 异步 → SemaphoreSlim（绝大多数场景）
 跨进程限制并发 → Semaphore（命名信号量）

1
2
3
4


信号量 vs Mutex：
 Mutex — 互斥，同一时刻只允许 1 个
 Semaphore — 计数，允许 N 个（initialCount 控制）
 适合"资源池"场景（限制最多 N 个并发连接/任务）

4.5 事件等待句柄（信号通知）

用于线程（或进程）之间的信号通知——一个线程通知另一个线程某事件发生了。

1
2
3
4
5
6


EventWaitHandle 家族：
 EventWaitHandle — 基类，支持命名（跨进程）
 ManualResetEvent — 手动重置（继承 EventWaitHandle）
 AutoResetEvent — 自动重置（继承 EventWaitHandle）
 ManualResetEventSlim — 轻量版，进程内，性能更好
 CountdownEvent — 等待 N 个信号（fork-join）

ManualResetEvent（闸门）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


// 像一道闸门：打开后保持打开，所有等待者都通过，直到手动关闭
var gate = new ManualResetEvent(initialState: false); // 初始关闭

// 多个工作线程等待开工信号
for (int i = 0; i < 10; i++)
 Task.Run(() => {
 gate.WaitOne(); // 阻塞，直到闸门打开
 DoWork();
 });

// 主线程打开闸门 → 所有等待线程同时放行（广播）
gate.Set();

// 闸门保持打开；需要再次阻塞时手动关闭
gate.Reset();

1
2


特点：Set 后保持 signaled，所有 WaitOne 立即返回
适合：一次性广播通知（初始化完成、开始信号）

AutoResetEvent（旋转门）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


// 像旋转门：Set 放行一个等待者后，自动关上
var turnstile = new AutoResetEvent(initialState: false);

// 消费者
Task.Run(() => {
 while (true)
 {
 turnstile.WaitOne(); // 等待信号
 ProcessItem();
 }
});

// 生产者：每来一个就 Set 一次（放行一个）
turnstile.Set();

1
2
3


特点：Set 释放一个等待者后自动 Reset
适合：一次通知一个（经典生产者-消费者信号）
 但现代推荐用 Channel<T>，更强大

ManualResetEventSlim（轻量版）

1
2
3
4
5
6
7
8
9


// 进程内的 ManualResetEvent，性能更好
var slim = new ManualResetEventSlim(initialState: false);

slim.Wait(); // 先自旋一小段，再阻塞（短等待更快）
slim.Set();
slim.Reset();

// 区别：不能跨进程，但短时间等待性能更好
// 进程内场景优先用它

CountdownEvent（fork-join）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


// 等待 N 个并行任务全部完成
var countdown = new CountdownEvent(5); // 等 5 个信号

Parallel.For(0, 5, i =>
{
 DoTask(i);
 countdown.Signal(); // 完成 1 个，计数 -1
});

countdown.Wait(); // 等待全部完成

1
2


适合：分叉-汇合（fork-join）模式
 启动 N 个并行任务，等所有完成

跨进程事件通知

1
2
3
4
5
6
7
8


// 命名事件：跨进程可见（两个进程协调）
var evt = new EventWaitHandle(
 initialState: false,
 mode: EventResetMode.AutoReset,
 name: @"Global\MyAppStartSignal");

evt.WaitOne(); // 进程A 等待
evt.Set(); // 进程B 通知

1
2
3
4
5


现代场景的替代：
 异步等待信号 → TaskCompletionSource（把信号变成可 await 的 Task）
 生产者-消费者 → Channel<T>
 这些等待句柄是阻塞式的，async 场景不太合适
 但跨进程协调、遗留代码兼容、特定同步场景仍不可替代

4.6 Interlocked（原子操作）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


private int _counter;

// 原子自增（无锁，极快）
Interlocked.Increment(ref _counter);
Interlocked.Decrement(ref _counter);
Interlocked.Add(ref _counter, 10);

// 原子读取/赋值（64位在32位系统上需要）
long value = Interlocked.Read(ref _largeValue);
Interlocked.Exchange(ref _counter, 0);

// CAS（Compare-And-Swap）— 无锁编程基础
int original;
do
{
 original = _counter;
} while (Interlocked.CompareExchange(ref _counter, original + 1, original) != original);

4.7 ReaderWriterLockSlim（读多写少）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


private readonly ReaderWriterLockSlim _rwLock = new();

// 多个读线程可以同时进入
public User Read(int id)
{
 _rwLock.EnterReadLock();
 try { return _cache[id]; }
 finally { _rwLock.ExitReadLock(); }
}

// 写线程独占
public void Write(int id, User user)
{
 _rwLock.EnterWriteLock();
 try { _cache[id] = user; }
 finally { _rwLock.ExitWriteLock(); }
}

五、并发集合与 Channel

多线程协作时，优先用并发集合而不是自己加锁。

5.1 并发集合一览

1
2
3
4
5
6
7


集合 特点 适用
──────────────────────────────────────────────────────────────
ConcurrentDictionary 线程安全字典 高并发读写、缓存
ConcurrentQueue<T> 无锁 FIFO 队列 生产者-消费者
ConcurrentStack<T> 无锁 LIFO 栈 工作窃取
ConcurrentBag<T> 无序，线程本地存储 无顺序要求的并行
BlockingCollection<T> 带阻塞的集合（封装上面） 经典生产者-消费者

5.2 ConcurrentDictionary

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


var cache = new ConcurrentDictionary<string, User>();

// 原子的 GetOrAdd（不存在才添加）
var user = cache.GetOrAdd("key", k => LoadFromDb(k));

// 原子的 AddOrUpdate
cache.AddOrUpdate("key",
 addValue: k => new User(),
 updateValueFactory: (k, old) => UpdateUser(old));

// 注意：GetOrAdd 的工厂可能被多次调用（非原子）
// 高性能场景用 TryGetValue + TryAdd 手动控制

5.3 Channel（.NET 高并发的明星）

System.Threading.Channels 是 .NET 专门为高并发生产者-消费者场景设计的，性能远超 ConcurrentQueue + BlockingCollection。

1
2
3
4
5
6
7
8


// 安装
// dotnet add package System.Threading.Channels

// 创建 channel（无界）
var channel = Channel.CreateUnbounded<Order>();

// 创建 channel（有界，背压控制）
var bounded = Channel.CreateBounded<Order>(1000); // 最多缓冲 1000

生产者

1
2
3
4
5
6


// 写入
await channel.Writer.WriteAsync(order); // 满了会等待（有界）
channel.Writer.TryWrite(order); // 不等待，返回是否成功

// 完成
channel.Writer.Complete(); // 通知没有更多数据

消费者

1
2
3
4
5
6
7


// 读取
await foreach (var order in channel.Reader.ReadAllAsync())
{
 await ProcessAsync(order);
}

// channel 完成且读完时，循环自动结束

完整示例：订单处理管道

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37


public class OrderPipeline
{
 private readonly Channel<Order> _channel;

 public OrderPipeline(int capacity = 1000)
 {
 _channel = Channel.CreateBounded<Order>(new BoundedChannelOptions(capacity)
 {
 FullMode = BoundedChannelFullMode.Wait, // 满了等待
 SingleReader = false,
 SingleWriter = false
 });
 }

 // 生产者：接收订单
 public async Task EnqueueAsync(Order order, CancellationToken ct)
 {
 await _channel.Writer.WriteAsync(order, ct);
 }

 // 消费者：多 worker 并行处理
 public async Task ConsumeAsync(int workerCount, CancellationToken ct)
 {
 var workers = Enumerable.Range(0, workerCount)
 .Select(_ => Task.Run(async () =>
 {
 await foreach (var order in _channel.Reader.ReadAllAsync(ct))
 {
 await ProcessOrderAsync(order);
 }
 }));

 await Task.WhenAll(workers);
 }

 public void Complete() => _channel.Writer.Complete();
}

1
2
3
4
5
6
7
8


Channel 的优势：
 ✓ 无锁或细粒度锁，性能极高
 ✓ 支持 async/await（不阻塞线程）
 ✓ 支持背压（BoundedChannel 控制内存）
 ✓ 支持 SingleReader/SingleWriter 优化
 ✓ 是 ASP.NET Core 内部用的（SignalR、Quartz 等）

 可以说：Channel 是 .NET 替代 Go channel 的方案

5.4 不可变集合

1
2
3
4
5
6
7
8
9


// System.Collections.Immutable
// 每次修改返回新实例，天然线程安全

var list = ImmutableList<int>.Empty;
var list2 = list.Add(1); // list 不变，list2 是新的
var list3 = list2.Add(2);

// 适合：配置、只读缓存、共享状态
// 修改开销大（复制），但读取绝对安全

六、并行计算：TPL

CPU 密集型任务要利用多核，用 TPL（Task Parallel Library）。

6.1 Parallel.For / Parallel.ForEach

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


// 并行处理（CPU 密集型）
var data = Enumerable.Range(0, 1_000_000).ToArray();

// 并行 For
Parallel.For(0, data.Length, i =>
{
 data[i] = Compute(data[i]);
});

// 并行 ForEach
Parallel.ForEach(data, item =>
{
 Process(item);
});

// 控制并发度
var options = new ParallelOptions
{
 MaxDegreeOfParallelism = Environment.ProcessorCount
};
Parallel.ForEach(data, options, item => Process(item));

6.2 PLINQ（并行 LINQ）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


// AsParallel() 把 LINQ 变成并行
var result = data
 .AsParallel()
 .Where(x => x % 2 == 0)
 .Select(x => x * x)
 .OrderBy(x => x)
 .ToList();

// 控制并发度
var result2 = data
 .AsParallel()
 .WithDegreeOfParallelism(8)
 .Select(Compute)
 .ToList();

1
2
3
4
5


注意：
 ✗ 小数据集别用并行（调度开销 > 收益）
 ✗ I/O 密集型别用 Parallel/PLINQ（它们是为 CPU 设计的）
 I/O 用 Task.WhenAll
 ✓ 数据量大 + 计算密集才用

6.3 Task.WhenAll（并发 I/O）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


// 并发请求多个 I/O（不是并行计算，是并发等待）
var urls = new[] { "url1", "url2", "url3" };

// 错误：串行（一个等一个）
var results = new List<string>();
foreach (var url in urls)
{
 results.Add(await httpClient.GetStringAsync(url)); // 串行！
}

// 正确：并发（一起发起，一起等）
var tasks = urls.Select(url => httpClient.GetStringAsync(url));
var results = await Task.WhenAll(tasks); // 总耗时 ≈ 最慢的那个

1
2
3
4
5


区分：
 Task.WhenAll — 并发 I/O（等网络，不占 CPU）
 Parallel.For — 并行计算（占 CPU 多核）
 
 这是新手最常搞错的点：I/O 密集用 WhenAll，CPU 密集用 Parallel

七、高性能内存：Span、Pipelines、Pool

.NET Core 之后引入了一系列高性能内存原语，这是 .NET 能和原生 C++ 掰手腕的资本。

7.1 Span / Memory（零拷贝）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


// Span<T> — 连续内存的视图，不复制数据
// 堆栈上分配（ref struct），极快

// 切分数组，零拷贝
byte[] buffer = new byte[1000];
Span<byte> slice = buffer.AsSpan(100, 50); // 从100开始，取50个

// stackalloc — 栈上分配（不进堆，无 GC）
Span<int> stackData = stackalloc int[100]; // 栈上，方法结束自动回收

// 字符串操作零拷贝
string text = "Hello, World";
ReadOnlySpan<char> hello = text.AsSpan(0, 5); // "Hello"，不新建字符串

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


// 高性能解析示例
// 旧：每步都分配新字符串
var parts = input.Split(','); // 分配数组 + 多个字符串

// 新：用 Span 零拷贝解析
var reader = new SpanReader(input.AsSpan());
while (!reader.Done)
{
 var token = reader.ReadUntil(',');
 Process(token); // token 是原始数据的切片，不分配
}

1
2
3
4
5
6


Span 限制（ref struct）：
 ✗ 不能作为类的字段
 ✗ 不能跨 await
 ✗ 不能装箱
 
 需要跨 await / 存字段 → 用 Memory<T>（堆上，可异步）

7.2 System.IO.Pipelines

专门为高性能网络 I/O 设计，Kestrel 内部就用它。解决"数据不完整、粘包"的问题。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


// 安装
// dotnet add package System.IO.Pipelines

async Task ProcessPipeAsync(PipeReader reader)
{
 while (true)
 {
 ReadResult result = await reader.ReadAsync();
 ReadOnlySequence<byte> buffer = result.Buffer;

 // 尝试解析完整消息
 while (TryParseMessage(ref buffer, out var message))
 {
 ProcessMessage(message);
 }

 // 告诉 PipeReader 消费了多少、还剩多少
 reader.AdvanceTo(buffer.Start, buffer.End);

 if (result.IsCompleted) break;
 }
}

1
2
3
4
5
6


Pipelines 解决的痛点：
 ✓ 自动管理缓冲区（不用自己 new byte[]）
 ✓ 处理消息不完整（等更多数据）
 ✓ 处理消息粘包（一次读多条）
 ✓ 内存复用（零拷贝、少分配）
 ✓ 背压（消费慢时通知生产者暂停）

7.3 ArrayPool / ObjectPool

减少 GC 压力的利器——复用对象而不是反复分配。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


// ArrayPool — 复用数组
byte[] buffer = ArrayPool<byte>.Shared.Rent(1024); // 租借（可能更大）
try
{
 ProcessData(buffer);
}
finally
{
 ArrayPool<byte>.Shared.Return(buffer); // 归还（不是 GC 回收）
}

// ObjectPool — 复用对象（Microsoft.Extensions.ObjectPool）
var pool = new DefaultObjectPool<StringBuilder>(
 new DefaultPooledObjectPolicy<StringBuilder>());

var sb = pool.Get();
try
{
 sb.Append("...");
 var result = sb.ToString();
}
finally
{
 sb.Clear();
 pool.Return(sb);
}

1
2
3
4
5
6


何时用 Pool：
 ✓ 高频分配 + 大对象（大 byte[]、StringBuilder）
 ✓ 热路径（每秒成千上万次）
 ✗ 低频场景（开销 > 收益）

 原理：对象复用，减少 GC，降低内存分配压力

八、线程池与 Kestrel

8.1 线程池机制

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


.NET 线程池（ThreadPool）：
 - 托管所有工作线程
 - 按需增长（IO 密集型增长快）
 - 复用线程（避免频繁创建销毁）

线程池的"饥饿"问题：
 - 所有线程都被阻塞（同步 I/O）
 - 新任务排队等待
 - 响应时间飙升

 这就是为什么强调异步：
 异步释放线程 → 线程池可用线程多 → 抗并发
 同步阻塞线程 → 线程池耗尽 → 系统卡死

1
2
3
4
5
6
7


// 配置线程池（.NET 中通常用环境变量或 ThreadPool.SetMinThreads）
// 设置最小线程数，避免冷启动时线程增长慢
ThreadPool.SetMinThreads(workerThreads: 100, completionPortThreads: 100);

// 推荐：在 Program.cs 早期设置
// 或用环境变量
// DOTNET_ThreadPool_MinThreads=100

8.2 Kestrel（ASP.NET Core 服务器）

Kestrel 是 ASP.NET Core 的内置 Web 服务器，性能世界级。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


Kestrel 为什么快：
 ✓ 基于 libuv / IOCP（异步 I/O 完成端口）
 ✓ 完全异步架构（async/await 全链路）
 ✓ Pipelines 处理网络数据
 ✓ 内存池（ArrayPool）减少分配
 ✓ HTTP/2、HTTP/3 支持

性能参考（官方基准）：
 简单 JSON 接口：单机 10万+ RPS
 Plaintext（TechEmpower）：单机百万级 RPS
 位居 TechEmpower 前列（和 Rust/C++ 一个梯队）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


// Program.cs 配置 Kestrel
var builder = WebApplication.CreateBuilder(args);

builder.WebHost.ConfigureKestrel(options =>
{
 options.Limits.MaxConcurrentConnections = 10000; // 最大连接数
 options.Limits.MaxConcurrentUpgradedConnections = 10000; // WebSocket
 options.Limits.MaxRequestBodySize = 10 * 1024 * 1024; // 10MB
 options.Limits.KeepAliveTimeout = TimeSpan.FromMinutes(2);
 options.Limits.RequestHeadersTimeout = TimeSpan.FromSeconds(30);
});

九、缓存

缓存是高并发的第一道防线——能用缓存的绝不打数据库。

9.1 多级缓存

1
2
3
4
5
6
7
8


浏览器缓存 — 客户端，静态资源
CDN — 边缘节点，静态 + 动态加速
Nginx 缓存 — 反向代理层，减少打到应用的请求
内存缓存 — 进程内（IMemoryCache），最快
分布式缓存 — Redis/Memcached，跨实例共享
数据库缓存 — MySQL 查询缓存（已废弃）、缓冲池

层级越靠前，速度越快，容量越小

9.2 IMemoryCache（进程内缓存）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


// 注册
builder.Services.AddMemoryCache();

// 使用
public class UserService
{
 private readonly IMemoryCache _cache;

 public UserService(IMemoryCache cache) => _cache = cache;

 public async Task<User> GetUserAsync(int id)
 {
 // 缓存键
 var key = $"user:{id}";

 // GetOrCreateAsync：不存在则加载并缓存
 return await _cache.GetOrCreateAsync(key, async entry =>
 {
 entry.AbsoluteExpirationRelativeToNow = TimeSpan.FromMinutes(30); // 30分钟过期
 entry.SlidingExpiration = TimeSpan.FromMinutes(10); // 10分钟无访问过期
 return await _db.Users.FindAsync(id);
 });
 }
}

9.3 IDistributedCache + Redis

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


// 注册 Redis
builder.Services.AddStackExchangeRedisCache(options =>
{
 options.Configuration = "localhost:6379";
 options.InstanceName = "myapp:";
});

// 使用（和 IMemoryCache 接口类似）
public class CacheService
{
 private readonly IDistributedCache _cache;

 public async Task<string> GetAsync(string key)
 {
 return await _cache.GetStringAsync(key);
 }

 public async Task SetAsync(string key, string value)
 {
 var options = new DistributedCacheEntryOptions
 {
 AbsoluteExpirationRelativeToNow = TimeSpan.FromHours(1)
 };
 await _cache.SetStringAsync(key, value, options);
 }
}

1
2
3
4
5


IMemoryCache vs IDistributedCache：
 IMemoryCache — 进程内，最快，但多实例不共享，重启丢失
 IDistributedCache — Redis 等，跨实例共享，持久，但网络开销

 实战：本地缓存做一级（抗热点），Redis 做二级（一致性）

十、限流与熔断

高并发系统必须保护自己——流量超载时主动拒绝，而不是被拖垮。

10.1 限流（.NET 7+ 内置）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33


// .NET 7+ 内置限流中间件
builder.Services.AddRateLimiter(options =>
{
 // 全局并发限制
 options.GlobalLimiter = PartitionedRateLimiter.Create<HttpContext, string>(
 httpContext => RateLimitPartition.GetConcurrencyLimiter(
 partitionKey: "global",
 factory: _ => new ConcurrencyLimiterOptions
 {
 PermitLimit = 1000, // 全局最多 1000 并发
 QueueLimit = 100
 }));

 // 按 IP 限流
 options.AddPolicy("per-ip", httpContext =>
 RateLimitPartition.GetTokenBucketLimiter(
 partitionKey: httpContext.Connection.RemoteIpAddress!.ToString(),
 factory: _ => new TokenBucketRateLimiterOptions
 {
 TokenLimit = 100,
 TokensPerPeriod = 100,
 ReplenishmentPeriod = TimeSpan.FromSeconds(1)
 }));

 options.OnRejected = async (context, ct) =>
 {
 context.HttpContext.Response.StatusCode = 429;
 await context.HttpContext.Response.WriteAsync("Too Many Requests", ct);
 };
});

var app = builder.Build();
app.UseRateLimiter();

1
2
3
4
5


限流算法：
 并发限流（ConcurrencyLimiter） — 限制同时在处理的请求数
 令牌桶（TokenBucket） — 允许突发，平均速率限制
 固定窗口（FixedWindow） — 每个时间窗口固定配额
 滑动窗口（SlidingWindow） — 更平滑的窗口算法

10.2 熔断、重试、超时（Polly）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


// 安装
// dotnet add package Microsoft.Extensions.Http.Polly
// dotnet add package Polly

// HttpClient 熔断 + 重试
builder.Services.AddHttpClient("api")
 .AddTransientHttpErrorPolicy(policyBuilder =>
 policyBuilder.WaitAndRetryAsync(3, attempt =>
 TimeSpan.FromSeconds(Math.Pow(2, attempt)))) // 重试 3 次，指数退避
 .AddTransientHttpErrorPolicy(policyBuilder =>
 policyBuilder.CircuitBreakerAsync(
 handledEventsAllowedBeforeBreaking: 5, // 连续失败 5 次
 durationOfBreak: TimeSpan.FromSeconds(30))); // 熔断 30 秒

// 超时
 .AddPolicyHandler(Policy.TimeoutAsync<HttpResponseMessage>(TimeSpan.FromSeconds(10)));

1
2
3
4
5
6


熔断器三种状态：
 Closed（关闭） — 正常请求
 Open（打开） — 失败率达阈值，直接拒绝（快速失败）
 Half-Open — 试探性放行几个请求，成功则恢复

 作用：下游服务挂了，快速失败，不把整个链路拖死

十一、数据库层面

数据库往往是高并发系统的瓶颈所在。

11.1 连接池

1
2
3
4
5
6
7
8


// ADO.NET / EF Core 默认开启连接池
// 连接字符串配置
"Server=...;Database=...;Pooling=true;Max Pool Size=100;Min Pool Size=10;"

// 注意：
// 连接用完必须 Dispose（using 或 await using）
// 否则连接泄漏，连接池耗尽
await using var conn = new SqlConnection(connStr); // 自动归还连接池

11.2 异步 EF Core

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


// 全异步，不阻塞线程
var users = await _db.Users
 .Where(u => u.IsActive)
 .ToListAsync(); // 异步查询

// 注意 N+1 问题
// 错误（N+1 查询）
foreach (var user in await _db.Users.ToListAsync())
{
 var orders = await _db.Orders.Where(o => o.UserId == user.Id).ToListAsync();
 // 100 个用户 = 101 次查询
}

// 正确（Include / Join）
var users = await _db.Users
 .Include(u => u.Orders)
 .ToListAsync(); // 1 次查询

11.3 Dapper（高性能 ORM）

1
2
3
4
5
6
7


// Dapper 比 EF Core 快 5-10 倍（轻量，接近原生 ADO.NET）
// 适合：性能敏感的查询、复杂 SQL

using var conn = new SqlConnection(connStr);
var users = await conn.QueryAsync<User>(
 "SELECT * FROM Users WHERE IsActive = @isActive",
 new { isActive = true });

1
2
3
4
5


EF Core vs Dapper：
 EF Core — 开发效率高，功能全，性能中等
 Dapper — 性能极致，SQL 自己写
 
 实战：核心 CRUD 用 EF Core，热点查询用 Dapper

11.4 数据库层面优化

1
2
3
4
5
6


✓ 索引优化（避免全表扫描）
✓ 读写分离（主写从读）
✓ 分库分表（数据量大时）
✓ 慢查询日志 + EXPLAIN
✓ 批量操作（减少往返）
✓ 连接池合理配置

十二、监控与诊断

高并发系统必须有可观测性，否则出问题两眼一抹黑。

12.1 性能计数器（dotnet-counters）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# 实时监控 .NET 应用指标
dotnet-counters monitor -p 12345 \
 System.Runtime \
 Microsoft.AspNetCore.Hosting

# 关注指标：
# cpu-usage CPU 使用率
# gc-heap-size GC 堆大小
# gen-0/1/2-gc-count GC 次数（频繁 GC = 分配过多）
# time-in-gc GC 占用时间
# threadpool-queue-length 线程池队列（长了 = 线程不足/阻塞）
# working-set 内存占用

12.2 火焰图（dotnet-trace）

1
2
3


# 录制性能数据
dotnet-trace collect -p 12345 --format Speedscope -d 30
# 用 https://speedscope.app 打开，看 CPU 时间花在哪

12.3 链路追踪（OpenTelemetry）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


// 安装
// dotnet add package OpenTelemetry.Extensions.Hosting
// dotnet add package OpenTelemetry.Instrumentation.AspNetCore
// dotnet add package OpenTelemetry.Exporter.OpenTelemetryProtocol

builder.Services.AddOpenTelemetry()
 .WithTracing(tracing =>
 {
 tracing.AddAspNetCoreInstrumentation() // HTTP 请求
 .AddHttpClientInstrumentation() // 外部调用
 .AddEntityFrameworkCoreInstrumentation() // 数据库
 .AddOtlpExporter(); // 导出到 Jaeger/Tempo
 });

1
2
3
4
5
6
7


可观测性三支柱：
 Metrics（指标） — CPU、QPS、错误率（聚合数据）
 Tracing（追踪） — 一个请求经过的所有服务（链路）
 Logging（日志） — 具体的事件记录

 工具：OpenTelemetry（标准）+ Prometheus + Grafana + Jaeger
 或商业：Application Insights、Datadog

十三、高并发架构总结

把前面所有技术组合起来，一个典型的高并发 .NET 系统架构：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


 客户端
 │
 ┌─────▼─────┐
 │ CDN │ 静态资源缓存
 └─────┬─────┘
 │
 ┌─────▼─────┐
 │ Nginx │ 负载均衡 + 缓存 + 限流 + HTTPS
 │ 集群 │
 └─────┬─────┘
 │
 ┌───────────┼───────────┐
 │ │ │
 ┌─────▼─────┐ ┌──▼───┐ ┌─────▼─────┐
 │ Kestrel │ │Kestrel│ │ Kestrel │ ASP.NET Core 集群
 │ App #1 │ │App #2 │ │ App #3 │ （全异步、Channel、Span）
 └─────┬─────┘ └───┬───┘ └─────┬─────┘
 │ │ │
 └─────┬─────┘───────────┘
 │
 ┌───────────┼───────────┐
 │ │ │
 ┌────▼────┐ ┌────▼────┐ ┌────▼────┐
 │ Redis │ │ 消息队列 │ │ 数据库 │
 │ 缓存 │ │(削峰) │ │(读写分离)│
 └─────────┘ └─────────┘ └─────────┘

1
2
3
4
5
6
7
8


每一层的高并发手段：
 CDN/Nginx — 缓存、负载均衡、限流（前文 Nginx 系列讲过）
 Kestrel — 异步架构、Pipelines、内存池
 应用层 — async/await、Channel、并发集合、对象池
 缓存层 — IMemoryCache + Redis 多级缓存
 消息队列 — 削峰填谷，异步解耦
 数据库 — 连接池、读写分离、分库分表、索引
 全链路 — 限流、熔断、重试（Polly）+ 监控（OpenTelemetry）

核心原则

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


1. 异步优先
 I/O 用 async/await，绝不阻塞线程

2. 减少分配
 Span、ArrayPool、对象池，降低 GC 压力

3. 无锁优先
 Channel、并发集合、Interlocked，避免锁竞争

4. 缓存为王
 能缓存的绝不查数据库，多级缓存

5. 保护自己
 限流、熔断、降级，超载时主动拒绝

6. 水平扩展
 无状态设计，随时加机器

7. 可观测
 指标、追踪、日志，问题可定位

十四、小结

本文系统梳理了 .NET 高并发编程的全景：

基础概念：高并发的指标、挑战，并发/并行/异步的区别
异步编程：async/await 状态机、Task/ValueTask、CancellationToken、IAsyncEnumerable
同步原语：lock、SemaphoreSlim、Interlocked、ReaderWriterLockSlim
并发集合：ConcurrentDictionary、Channel（明星）、不可变集合
并行计算：TPL、Parallel、PLINQ，区分 CPU 并行和 I/O 并发
高性能内存：Span/Memory、Pipelines、ArrayPool/ObjectPool
服务器：线程池机制、Kestrel 为什么快
缓存：IMemoryCache、Redis、多级缓存
保护机制：.NET 限流、Polly 熔断重试
数据库：连接池、异步 EF Core、Dapper、读写分离
可观测性：dotnet-counters、dotnet-trace、OpenTelemetry
整体架构：各层高并发手段 + 核心原则

.NET 在高并发领域的能力是被低估的——async/await 模型、Channel、Span、Kestrel 都是顶级实现。掌握这套全景，应对绝大多数高并发场景绰绰有余。

下一篇将深入 .NET 性能优化与 profiling，讲解如何用火焰图定位性能瓶颈。

.NET Dump 诊断：从抓取到分析（Linux + Windows）

Sun, 27 Jul 2025 10:00:00 +0800

写在前面

生产环境的应用出问题，往往不能直接 Attach 调试器——服务正在跑，停不了；问题转瞬即逝，复现不了；线上机器没装 IDE。这时候 dump（内存转储） 就是排错的救命稻草。

.NET 应用现在普遍 Linux 部署（容器、K8s），但开发机往往是 Windows，分析工具链也大不相同。本文对比讲解两个平台如何抓 dump、如何分析，以及内存泄漏、CPU 飙高、死锁、崩溃四大典型场景。

一、什么是 dump

1.1 定义

dump 是某个时刻进程内存的完整快照，相当于给运行中的程序"拍一张照片"。

1
2
3
4
5
6
7
8
9


dump 包含什么：
 - 所有线程的调用栈
 - 托管堆上的所有对象（.NET 对象）
 - 非托管内存（C++ 层）
 - GC 状态（各代堆大小）
 - 锁信息（Monitor、SyncBlock）
 - 异常对象
 - AppDomain、Module 信息
 - 寄存器和线程上下文

1.2 为什么用 dump 而不是直接调试

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


直接 Attach 调试器的问题：
 ✗ 需要停住进程，影响线上服务
 ✗ 需要源码和符号文件
 ✗ 问题可能已经发生过了，现场不在

dump 的优势：
 ✓ 抓取快（几秒），对线上影响小
 ✓ 离线分析，不占用生产机器
 ✓ 可以反复分析，团队协作
 ✓ 捕获"案发现场"，事后也能查

二、Linux 和 Windows 的根本差异

很多人觉得"dump 不就那样"，但两个平台从文件格式、抓取工具到分析工具链差异很大。先建立整体认知。

2.1 dump 文件格式

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


平台 格式 抓取工具
─────────────────────────────────────────────────────────
Linux minidump（.NET 工具抓的） dotnet-dump / createdump
Linux ELF core dump（OS 抓的） gcore / 系统崩溃
Windows Windows minidump (.dmp) dotnet-dump / Procdump / 任务管理器

关键点：
 .NET 官方工具（dotnet-dump、createdump）在两个平台都生成
 统一的 minidump 格式 → 抓出来的 dump 可以跨平台分析
 （Linux 上抓的 dump，拷到 Windows 用 WinDbg 也能分析，反之亦然）

 但 OS 原生工具抓的不一样：
 gcore（Linux）→ ELF core dump，需要 LLDB 分析
 任务管理器（Windows）→ minidump，WinDbg / VS / dotnet-dump 都能开

2.2 抓取方式的差异

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


Linux 的特点：
 ✓ 命令行为主（服务器无 GUI）
 ✓ 工具：dotnet-dump、createdump、gcore
 ✓ 环境变量配置 OOM 自动抓（生产标配）
 ✓ 容器环境要考虑镜像精简、权限
 → 偏"运维向"，脚本化

Windows 的特点：
 ✓ GUI + 命令行都有
 ✓ 工具：任务管理器（一键）、Procdump（条件触发）、WinDbg
 ✓ Procdump 的条件触发（CPU/内存/异常阈值）极其强大
 ✓ 符号服务器集成完善
 → 偏"开发向"，图形化体验好

2.3 分析方式的差异

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


Linux 的分析：
 ✓ 命令行为主
 ✓ dotnet-dump analyze（官方，推荐）
 ✓ LLDB + SOS 插件（老牌，功能全但配置麻烦）
 ✗ 几乎没有图形化工具

Windows 的分析：
 ✓ 图形化为主
 ✓ WinDbg（最强，命令 + GUI）
 ✓ Visual Studio（有源码时最舒服）
 ✓ PerfView（微软，免费，内存分析强）
 ✓ dotMemory（JetBrains，收费，体验最好）
 → 工具链远比 Linux 丰富

2.4 平台对比总览

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


维度 Linux Windows
────────────────────────────────────────────────────────────
抓取主力 dotnet-dump / createdump Procdump / 任务管理器
自动抓 OOM 环境变量（DOTNET_Dbg*） Procdump -e 守护
GUI 抓取 无 任务管理器 / Process Explorer
分析主力 dotnet-dump analyze WinDbg / VS
图形化分析 无 WinDbg / VS / PerfView / dotMemory
符号 .pdb + dotnet 符号 符号服务器 _NT_SYMBOL_PATH
容器调试 主战场（Docker/K8s） Windows 容器较少
典型场景 生产排错 开发机分析 + 生产抓取

实战常见组合：生产环境是 Linux，抓完 dump 拷到 Windows 开发机，用 WinDbg/VS 图形化分析。这是最顺手的姿势。

三、跨平台工具：dotnet-dump 和 dotnet-gcdump

这两个是 .NET 官方 CLI 工具，Linux 和 Windows 完全一样，是两个平台共通的基础。

3.1 dotnet-dump

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


# 安装（两个平台相同）
dotnet tool install -g dotnet-dump

# 找进程
dotnet-dump ps

# 抓 Full dump
dotnet-dump collect -p 12345
dotnet-dump collect -p 12345 --type Full # 完整（默认）
dotnet-dump collect -p 12345 --type Heap # 堆
dotnet-dump collect -p 12345 --type Triage # 脱敏，适合分享

# 指定输出
dotnet-dump collect -p 12345 -o ./myapp.dmp

# 直接分析（跨平台）
dotnet-dump analyze ./myapp.dmp

3.2 dotnet-gcdump（轻量堆 dump）

1
2
3
4
5


dotnet tool install -g dotnet-gcdump

# 只抓托管堆，文件几 MB
dotnet-gcdump collect -p 12345
dotnet-gcdump collect -p 12345 -o ./myapp.gcdump

1
2
3


什么时候用哪个：
 Full dump（dotnet-dump） — 全面排查，看线程/锁/异常，文件大
 gcdump（dotnet-gcdump） — 只查内存，文件小，VS/dotMemory 可打开

四、Linux 平台：抓 dump

4.1 createdump（.NET 运行时自带）

1
2
3
4
5
6
7
8


# 路径在 .NET runtime 旁边
# /usr/share/dotnet/shared/Microsoft.NETCore.App/<版本>/createdump

# 抓 Full dump
/usr/share/dotnet/shared/Microsoft.NETCore.App/8.0.0/createdump 12345

# 找路径的快捷方式
ls $(dirname $(readlink -f $(which dotnet)))/shared/Microsoft.NETCore.App/*/createdump

1
2
3
4


特点：
 .NET 自带，无需额外安装
 生产镜像里直接可用
 抓的是 minidump，dotnet-dump / LLDB 都能分析

4.2 gcore（系统通用，抓 ELF core）

1
2
3
4
5
6


# 通用工具，抓任何进程
gcore 12345
# 输出：core.12345（ELF core dump 格式）

# 指定输出名
gcore -o /tmp/myapp 12345

1
2
3
4


注意：
 gcore 抓的是 ELF core dump（不是 minidump）
 分析需要 LLDB + SOS，不能直接用 dotnet-dump analyze
 通常推荐用 createdump 或 dotnet-dump，除非它们不可用

4.3 OOM / 崩溃自动抓（生产标配）

这是 Linux 生产环境最重要的配置——进程崩溃时自动留一份 dump。

1
2
3
4
5
6
7
8
9


# 启动应用前设置环境变量
export DOTNET_DbgEnableMiniDump=1
export DOTNET_DbgMiniDumpType=4 # 4 = Full
export DOTNET_DbgMiniDumpName=/tmp/coredump.%p

# 启动应用
dotnet MyApp.dll

# 进程 OOM 或未处理异常时，自动在 /tmp/ 生成 dump

1
2
3
4
5
6
7
8


DOTNET_DbgMiniDumpType 取值：
 1 — Mini（小）
 2 — Heap（堆）
 3 — Triage（脱敏）
 4 — Full（完整，推荐）

这个配置对 Windows 也有效，但 Linux 生产环境用得最多
（因为 Linux 服务通常在容器里，崩了就重启，没自动 dump 就彻底没现场）

4.4 容器环境（Docker / K8s）

容器里通常镜像精简（alpine 无 glibc），工具缺失，要特殊处理。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 方案一：宿主机抓（容器进程对宿主机可见）
docker top myapp # 找容器内进程在宿主机的 PID
dotnet-dump collect -p <宿主机PID> # 在宿主机抓

# 方案二：进容器抓（镜像里要有工具）
docker exec -it myapp dotnet-dump collect -p 1

# 方案三：用 SDK 镜像临时调试（精简镜像的救星）
kubectl debug pod/myapp-pod -it \
 --image=mcr.microsoft.com/dotnet/sdk:8.0 \
 --target=myapp

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


# K8s Pod 配置 OOM 自动抓 + 持久化 dump
apiVersion: v1
kind: Pod
spec:
 containers:
 - name: myapp
 image: myapp:latest
 env:
 - name: DOTNET_DbgEnableMiniDump
 value: "1"
 - name: DOTNET_DbgMiniDumpType
 value: "4"
 - name: DOTNET_DbgMiniDumpName
 value: "/dumps/coredump.%p"
 volumeMounts:
 - name: dumps
 mountPath: /dumps
 volumes:
 - name: dumps
 emptyDir: {}

五、Windows 平台：抓 dump

5.1 任务管理器（最简单）

1
2
3
4
5
6


1. Ctrl+Shift+Esc 打开任务管理器
2. 切换到"详细信息"（Details）标签
3. 右键目标进程 → 创建转储文件（Create dump file）
4. 弹窗显示路径，通常在 %TEMP%\<进程名>.DMP

适合：临时抓一下，啥工具都没装

5.2 Procdump（Sysinternals，最强大）

Windows 抓 dump 的王牌，条件触发是它最强大的能力。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


# 下载：https://learn.microsoft.com/sysinternals/procdump

# 抓一次 Full dump
procdump -ma 12345
procdump -ma 12345 C:\dumps\ # 指定目录

# CPU 超过 80% 持续 5 秒时抓
procdump -ma -c 80 -s 5 12345

# 内存超过 2GB 时抓
procdump -ma -m 2000 12345

# 进程崩溃时自动抓（-e 异常触发，守护模式）
procdump -ma -e 1 -f "" 12345

# 特定异常触发（如 OutOfMemoryException）
procdump -ma -e 1 -f "OutOfMemoryException" 12345

# 抓 5 个，间隔 5 秒（看趋势）
procdump -ma -n 5 -s 5 12345

# 进程无响应时抓
procdump -ma -t 12345

1
2
3
4


Procdump vs Linux 的 OOM 环境变量：
 Procdump 更灵活——可以按 CPU、内存、异常类型多种条件触发
 还能抓多个 dump 看趋势
 这是 Windows 平台的独门优势

5.3 Process Explorer（Sysinternals）

1
2
3
4


图形化进程管理器，也能抓 dump：
 右键进程 → Create Dump → Mini / Full

好处：能直观看到进程树、CPU、内存，挑准了再抓

六、Linux 平台：分析 dump

6.1 dotnet-dump analyze（推荐）

1
2


dotnet-dump analyze ./myapp.dmp
# 进入交互式命令行

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


> help # 所有命令
> clrstack # 当前线程调用栈
> clrstack -all # 所有线程
> dumpheap -stat # 堆对象按类型统计
> dumpheap -type User # 查 User 类型对象
> gcroot <地址> # 查引用链（内存泄漏关键）
> syncblk # 锁状态（死锁排查）
> pe # 当前异常
> eeheap -gc # GC 堆各代大小
> exit

6.2 LLDB + SOS（功能更全）

LLDB 是 Linux 上的 WinDbg 对应物，配合 SOS 插件能分析 .NET dump。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# 安装 LLDB
apt install lldb

# 加载 dump
lldb --core ./core.12345

# 加载 SOS 插件
(lldb) plugin load /usr/share/dotnet/shared/Microsoft.NETCore.App/8.0.0/libsosplugin.so

# 之后 SOS 命令可用（和 dotnet-dump analyze 的命令一致）
(lldb) sos dumpheap -stat
(lldb) sos clrstack

1
2
3
4
5


dotnet-dump analyze vs LLDB+SOS：
 dotnet-dump analyze — 官方推荐，开箱即用，命令够用
 LLDB + SOS — 功能更全（能看原生栈、寄存器），但配置麻烦
 
 绝大多数场景 dotnet-dump analyze 就够了

1
2
3
4
5


Linux 分析的现实：
 命令行为主，没有图形化
 老手用着顺手，新人上手陡
 
 所以常见做法：Linux 抓 dump → scp 拷到 Windows → WinDbg/VS 图形化分析

七、Windows 平台：分析 dump

Windows 的分析工具链远比 Linux 丰富，这是 Windows 平台的最大优势。

7.1 WinDbg（最强）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


安装：
 Microsoft Store 搜 "WinDbg"（新版 WinDbg Preview）
 或下载 Windows SDK

加载 dump：
 File → Open dump file
 或 windbg -z myapp.dmp

加载 SOS（.NET 调试扩展）：
 .loadby sos coreclr # .NET Core / 5+
 .loadby sos mscorwks # .NET Framework

WinDbg 独有优势：
 ✓ 图形化调用栈、变量、内存
 ✓ !analyze -v 自动分析崩溃
 ✓ SOS 命令和 dotnet-dump 一致（dumpheap/gcroot/syncblk）
 ✓ 支持 .NET Framework 老项目

7.2 Visual Studio（有源码时最舒服）

1
2
3
4
5
6
7
8


直接用 VS 打开 .dmp：
 File → Open → File → 选 .dmp
 → 点"调试托管内存"

适合：
 有源码和符号
 想图形化查看对象树、调用栈
 团队成员不熟命令行

7.3 PerfView（微软，免费）

1
2
3
4
5
6
7


分析 .gcdump 文件的利器：
 打开 .gcdump → 看对象引用树
 打开 .etl（性能日志）→ 看火焰图

特点：
 界面朴素但功能强大
 专门优化内存和性能分析

7.4 dotMemory（JetBrains，收费）

1
2
3
4
5


体验最好的内存分析工具：
 支持 .gcdump / .dmp
 两个 dump 对比，一眼看出增长的对象
 可视化引用链
 自动检测常见泄漏模式

八、跨平台通用分析命令

无论 Linux（dotnet-dump analyze）还是 Windows（WinDbg + SOS），核心分析命令都是同一套（SOS 命令）。这部分两个平台完全通用。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29


线程相关：
 clrstack # 当前线程调用栈
 clrstack -all # 所有线程（CPU/死锁排查）
 threads # 列出所有线程
 setthread <id> # 切换线程
 dso (dumpstackobjects) # 栈上的所有对象

堆相关：
 dumpheap -stat # 按类型统计（内存排查第一步）
 dumpheap -type <类名> # 查指定类型对象
 dumpheap -mt <MT地址> # 按方法表查
 dumpheap -min 10000 # 大于 10KB 的对象
 eeheap -gc # GC 堆各代大小

对象相关：
 do <地址> (dumpobject) # 看对象内容
 gcroot <地址> # 引用链（谁引用了它）
 dumpvc <MT> <地址> # 看值类型

锁相关：
 syncblk # 锁状态（死锁）
 dumpheap -thinlock # 轻量级锁

异常相关：
 pe (print exception) # 当前异常
 dumpheap -type Exception # 所有异常

异步相关：
 dumpasync # 异步状态机

九、场景实战（命令跨平台，标注平台习惯）

9.1 内存泄漏

抓取：抓两个 dump 对比（任何平台）

1
2
3
4


# 跨平台
dotnet-gcdump collect -p 12345 -o /tmp/d1.gcdump
# 等 10-30 分钟
dotnet-gcdump collect -p 12345 -o /tmp/d2.gcdump

分析：

1
2
3
4


# Linux / Windows 都一样
> dumpheap -stat # 第一步：找可疑类型
> dumpheap -type UserCache # 第二步：看具体对象
> gcroot 000002a3b4c50000 # 第三步：找引用链

1
2
3
4
5
6
7


gcroot 输出示例：
 HandleTable (pinned):
 → MyApp.Services.CacheService
 → Dictionary<string, UserCache>
 → UserCache (泄漏对象)

结论：静态 CacheService 的 Dictionary 持有对象，永不释放

9.2 CPU 飙高

dump 看 CPU 不够实时，先看平台对应的实时工具：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# Linux / Windows 都能用的官方工具
dotnet-counters monitor -p 12345 System.Runtime[cpu-usage,gen-0-gc-count]
dotnet-stack report -p 12345 # 实时线程栈
dotnet-trace collect -p 12345 --format Speedscope # 录火焰图

# 也可以抓两个 dump 对比调用栈
dotnet-dump collect -p 12345 -o cpu1.dmp
sleep 5
dotnet-dump collect -p 12345 -o cpu2.dmp

# 分析：找两次调用栈相同的线程（一直在跑同一段代码）
> clrstack -all

9.3 死锁

抓一个 Full dump，用 syncblk

1
2
3
4
5
6
7
8


> syncblk
# 输出会显示：
# Thread A 持有锁 12，等待锁 15
# Thread B 持有锁 15，等待锁 12
# → 互相等待 = 死锁

> setthread <Thread A>
> clrstack # 看 A 卡在哪段代码

9.4 崩溃 / 异常

关键：提前配置自动抓

1
2
3
4
5
6
7


# Linux：环境变量（生产标配）
export DOTNET_DbgEnableMiniDump=1
export DOTNET_DbgMiniDumpType=4
export DOTNET_DbgMiniDumpName=/tmp/crash.%p.dmp

# Windows：Procdump 守护
procdump -ma -e 1 -f "" 12345 C:\dumps\

分析崩溃 dump

1
2
3
4


> pe # 看导致崩溃的异常
# 输出：OutOfMemoryException / StackOverflowException / NullReferenceException
> do <异常对象地址> # 看异常详情
# StackTrace 直接指到崩溃代码位置

十、平台选择建议

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


什么时候在 Linux 上分析：
 ✓ 生产是 Linux，想就地快速看一眼
 ✓ 熟悉命令行，dotnet-dump analyze 够用
 ✓ 没法把 dump 拷出来（体积大、网络受限）

什么时候拷到 Windows 分析：
 ✓ 开发机是 Windows，工具链熟
 ✓ 需要图形化（WinDbg / VS / dotMemory）
 ✓ 团队协作，要发给别人看
 ✓ .NET Framework 老项目（只能 Windows）

最佳实践组合：
 Linux 生产 → 抓 dump（dotnet-dump / createdump / OOM 自动）
 ↓ scp / kubectl cp
 Windows 开发机 → 图形化分析（WinDbg / VS / dotMemory）

十一、生产环境最佳实践

11.1 提前准备（部署时就配好）

1
2
3
4
5
6
7
8
9


# Linux 镜像预装诊断工具 + 开启自动 dump
FROM mcr.microsoft.com/dotnet/aspnet:8.0
RUN dotnet tool install -g dotnet-dump \
 && dotnet tool install -g dotnet-gcdump \
 && dotnet tool install -g dotnet-counters
ENV PATH="$PATH:/root/.dotnet/tools"
ENV DOTNET_DbgEnableMiniDump=1
ENV DOTNET_DbgMiniDumpType=4
ENV DOTNET_DbgMiniDumpName=/dumps/coredump.%p

11.2 符号文件

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


无论哪个平台，分析 dump 都需要符号（.pdb）才能看到方法和行号：

Linux：
 把 .pdb 放到 DLL 同目录
 或打包归档，分析时对应上

Windows：
 配置符号服务器（_NT_SYMBOL_PATH）
 WinDbg / VS 会自动从微软下载系统库符号
 set _NT_SYMBOL_PATH=srv*c:\symbols*https://msdl.microsoft.com/download/symbols

11.3 安全注意

1
2
3
4
5


dump 含敏感数据（密码、token、用户信息）：
 ✓ 加密存储、访问控制
 ✓ 分析完及时删除
 ✗ 不要提交 Git，不要传公共平台
 ✓ 给第三方用 Triage 类型（dotnet-dump --type Triage 已脱敏）

11.4 排查流程速查

1
2
3
4
5
6


问题 Linux 抓取 Windows 抓取 分析命令
──────────────────────────────────────────────────────────────────────────
内存泄漏 dotnet-gcdump ×2 dotnet-gcdump ×2 dumpheap -stat / gcroot
CPU 飙高 dotnet-dump ×2 procdump -c 80 clrstack -all / dotnet-trace
死锁 dotnet-dump ×1 procdump -ma syncblk / clrstack
崩溃 OOM 环境变量自动抓 procdump -e 守护 pe / StackTrace

十二、小结

本文从 Linux 和 Windows 两个平台对比讲解了 .NET dump 诊断：

根本差异：文件格式、抓取工具、分析工具链各不相同；但 .NET 官方工具（dotnet-dump）抓的 minidump 跨平台可分析
Linux 抓取：dotnet-dump / createdump / gcore + OOM 环境变量自动抓 + 容器调试
Windows 抓取：任务管理器一键 / Procdump 条件触发（独门优势）
Linux 分析：dotnet-dump analyze / LLDB+SOS（命令行为主）
Windows 分析：WinDbg / VS / PerfView / dotMemory（图形化，工具链丰富）
通用命令：SOS 命令（dumpheap/gcroot/syncblk/pe）两个平台完全一致
四大场景：内存泄漏、CPU 飙高、死锁、崩溃的抓取和分析
最佳组合：Linux 生产抓 dump → 拷到 Windows 图形化分析

核心思路：dump 是事后分析的"黑匣子"，平时配好自动抓取，出问题才有料可查；两个平台工具不同但目标一致。

Linux 性能诊断速查手册

Thu, 26 Sep 2024 10:00:00 +0800

写在前面

本文整理了 Linux 系统性能排查的常用命令和思路，涵盖 CPU、内存、磁盘、网络四大方向。按照"先定位问题方向，再深入排查"的逻辑组织，方便遇到性能问题时快速入手。

一、排查思路总览

遇到性能问题时，建议按以下顺序定位：

1
2
3
4
5
6
7


1. top / htop — 快速看全局，确认是 CPU、内存、还是 I/O 问题
2. 针对性深入排查：
 - CPU 高 → 进程级别分析（第三章）
 - 内存高 → 内存分配分析（第四章）
 - 磁盘慢 → I/O 分析（第五章）
 - 网络慢 → 网络分析（第六章）
3. 结合日志和监控确认根因

二、全局概览

2.1 top — 系统资源总览

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# 实时查看系统资源使用情况
top

# 常用交互操作：
# P — 按 CPU 排序
# M — 按内存排序
# 1 — 展开显示每个 CPU 核心
# c — 显示完整命令行
# k — 终止指定进程（输入 PID）
# q — 退出

关键字段解读：

1
2
3
4
5
6
7
8


top - 14:30:01 up 30 days, 3:20, 2 users, load average: 2.5, 1.8, 1.2
# 当前时间 运行时间 用户数 负载均值（1分钟/5分钟/15分钟）

%Cpu(s): 25.0 us, 3.0 sy, 0.0 ni, 70.0 id, 1.5 wa, 0.5 si
# 用户态 内核态 空闲 I/O等待 软中断

MiB Mem : 7823.0 total, 256.0 free, 4096.0 used, 3471.0 buff/cache
# 总内存 空闲 已使用 缓冲/缓存

load average：三个数字分别表示过去 1、5、15 分钟的平均负载。数值接近 CPU 核心数时系统满载，超过则有过载。比如 4 核机器，load 到 4 就是满载。

wa（iowait）：持续高于 5% 说明磁盘 I/O 是瓶颈。

2.2 htop — 增强版 top

1
2
3
4


# 更直观的资源监控（需安装）
htop

# 优势：支持鼠标、颜色区分、快捷键更友好、可直接看到每个核心使用率

2.3 uptime — 快速看负载

1
2
3


# 一行输出系统运行时间和负载
uptime
# 14:30:01 up 30 days, 3:20, 2 users, load average: 2.5, 1.8, 1.2

2.4 vmstat — 系统活动统计

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


# 每隔2秒采样一次，共采5次
vmstat 2 5

# 关键列：
# r — 运行队列中的进程数（持续大于 CPU 核心数说明 CPU 瓶颈）
# b — 等待 I/O 的进程数（持续大于 0 说明 I/O 瓶颈）
# swpd — 已使用的 swap 大小（持续增长说明内存不够）
# si — 每秒从 swap 读入内存（swap in）
# so — 每秒从内存写入 swap（swap out）
# bi — 每秒从磁盘读入的块数
# bo — 每秒写入磁盘的块数
# us — 用户态 CPU 时间百分比
# sy — 内核态 CPU 时间百分比
# id — 空闲 CPU 时间百分比
# wa — I/O 等待时间百分比

三、CPU 排查

3.1 定位高 CPU 进程

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 按CPU使用率排序，显示前10个进程
ps aux --sort=-%cpu | head -10

# 或者用 top 的批处理模式（适合脚本采集）
top -b -n 1 | head -20

# 查看指定进程的线程CPU占用
top -H -p <PID>

# 查看进程的所有线程
ps -T -p <PID>

3.2 分析进程在做什么

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# 查看进程的系统调用（跟踪进程在干什么）
strace -p <PID> -c
# -c 会统计每种系统调用的次数和耗时，Ctrl+C 后输出汇总

# 实时跟踪进程的系统调用
strace -p <PID>

# 跟踪进程并统计耗时排序
strace -p <PID> -c -S time

# 只跟踪网络相关的系统调用
strace -p <PID> -e trace=network

3.3 perf — 性能分析

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 对指定进程做 CPU profiling（采样10秒）
sudo perf top -p <PID>

# 记录性能数据
sudo perf record -p <PID> -g -- sleep 10

# 查看记录的性能报告
sudo perf report

# 查看系统全局的热点函数
sudo perf top

3.4 常见 CPU 高的原因

1
2
3
4


计算密集型业务 → 正常，考虑优化算法或扩容
频繁 GC → java 应用的常见问题，查看 GC 日志
死循环 → 代码 bug，用 strace/perf 定位
上下文切换多 → 线程数过多，用 vmstat 看 cs 列

3.5 查看上下文切换

1
2
3
4
5
6
7
8


# 查看每秒上下文切换次数
vmstat 1 5
# 看 cs 列（context switch）

# 查看进程级别的自愿/非自愿上下文切换
pidstat -w 1 5
# cswch/s — 自愿上下文切换（主动让出 CPU）
# nvcswch/s — 非自愿上下文切换（被内核抢占，说明 CPU 竞争激烈）

四、内存排查

4.1 查看内存使用

1
2
3
4
5
6
7
8
9


# 查看内存总览
free -h
# total used free shared buff/cache available
# Mem: 7.6Gi 4.0Gi 256Mi 16Mi 3.4Gi 3.2Gi
# Swap: 2.0Gi 512Mi 1.5Gi

# 重要：看 available 而不是 free
# available = 系统实际可用内存（包含可回收的缓存）
# free 只是完全未使用的内存，通常很少

buff/cache 是内核用作缓冲的内存，应用需要时会自动释放，不算"被占用"。

4.2 进程内存排名

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# 按内存使用率排序，显示前10
ps aux --sort=-%mem | head -10

# 查看指定进程的内存详情
cat /proc/<PID>/status | grep Vm
# VmRSS — 实际使用的物理内存（最常关注的）
# VmSize — 虚拟内存大小
# VmSwap — 使用的 swap 大小

# 查看进程内存映射
pmap -x <PID>

# 更直观的进程内存排序
smem -t -k -s rss # 需安装 smem

4.3 查看 swap 使用情况

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# 查看哪些进程在使用 swap
for pid in $(ls /proc | grep -E '^[0-9]+$'); do
 swap=$(cat /proc/$pid/status 2>/dev/null | grep VmSwap | awk '{print $2}')
 if [ -n "$swap" ] && [ "$swap" -gt 0 ]; then
 name=$(cat /proc/$pid/cmdline 2>/dev/null | tr '\0' ' ')
 echo "PID: $pid Swap: ${swap}kB CMD: $name"
 fi
done | sort -k4 -rn | head -10

# 简化版：查看系统 swap 使用
swapon --show
cat /proc/swaps

4.4 slab 缓存分析

1
2
3
4
5
6
7
8


# 查看内核 slab 缓存占用
slabtop

# 查看内核内存使用概况
cat /proc/meminfo | grep -i slab
# Slab — slab 缓存总量
# SReclaimable — 可回收的 slab
# SUnreclaim — 不可回收的 slab（持续增长需关注）

4.5 常见内存问题的排查方向

1
2
3
4


available 持续下降 → 内存泄漏，用 pmap 或应用工具定位
Swap 使用量高 → 物理内存不够，考虑加内存或优化进程
进程 RSS 异常大 → 检查是否有内存泄漏，查看 heap dump
系统 OOM Kill → dmesg | grep -i oom 查看被杀的进程

4.6 OOM 日志查看

1
2
3
4
5
6
7


# 查看 OOM killer 记录
dmesg | grep -i "out of memory"
dmesg | grep -i "killed process"

# 从系统日志查看
grep -i "oom" /var/log/messages
journalctl -k | grep -i "oom"

五、磁盘 I/O 排查

5.1 iostat — 磁盘 I/O 统计

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# 查看所有磁盘的 I/O 统计（每秒刷新）
iostat -x 1

# 关键指标：
# %util — 磁盘繁忙程度（接近 100% 说明磁盘饱和）
# await — 平均 I/O 等待时间（ms），高于 10ms 需关注
# svctm — 平均服务时间
# r/s — 每秒读次数
# w/s — 每秒写次数
# rkB/s — 每秒读速度（KB）
# wkB/s — 每秒写速度（KB）
# avgqu-sz — 平均 I/O 队列长度（持续大于 1 说明有积压）

await 持续高于 10ms 或 %util 持续高于 80%，说明磁盘是瓶颈。

5.2 iotop — 查看哪个进程在疯狂读写磁盘

1
2
3
4
5
6
7
8


# 实时查看各进程的磁盘 I/O（需 root）
sudo iotop

# 只看有 I/O 活动的进程
sudo iotop -o

# 批处理模式（适合脚本采集）
sudo iotop -b -o -n 3

5.3 pidstat — 按进程查看 I/O

1
2
3
4
5
6
7


# 查看各进程的磁盘读写（每秒刷新）
pidstat -d 1

# 输出说明：
# kB_rd/s — 每秒读 KB
# kB_wr/s — 每秒写 KB
# kB_ccwr/s — 每秒取消写入的 KB

5.4 查看磁盘使用空间

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 查看各磁盘使用率
df -h

# 查看目录大小
du -sh /var/log/*

# 找出最大的文件
find / -type f -size +500M -exec ls -lh {} \; 2>/dev/null | sort -k5 -rh | head -20

# 查看inode使用率（inode满了也会报 No space left on device）
df -i

5.5 磁盘性能测试

1
2
3
4
5
6
7
8
9


# 测试顺序读速度
sudo hdparm -Tt /dev/sda

# 用 dd 测试写入速度（写一个 1GB 文件）
dd if=/dev/zero of=/tmp/testfile bs=1M count=1024 oflag=dsync
# 看输出中的速度，一般在 100MB/s 以上为正常（SSD 更高）

# 测试完成后删除测试文件
rm /tmp/testfile

5.6 常见磁盘问题

1
2
3
4
5
6


磁盘空间满 → df -h 定位，然后 du -sh * 找大文件
inode 满 → df -i 检查，通常是大量小文件导致
I/O wait 高 → iostat -x 1 看 %util 和 await
某个进程疯狂写盘 → iotop -o 定位进程
日志文件太大 → 用 logrotate 管理日志轮转
删除文件空间未释放 → lsof | grep deleted 查看，重启占用进程释放

5.7 查找已删除但未释放空间的文件

1
2
3
4
5


# 查看已删除但被进程占用未释放的文件
lsof | grep deleted

# 查看指定进程打开的文件
lsof -p <PID>

六、网络排查

6.1 网络连通性

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# 测试网络是否通
ping 8.8.8.8

# 测试指定端口是否通
telnet 192.168.1.100 8080
# 或
nc -zv 192.168.1.100 8080

# 测试到目标的网络路径和延迟
traceroute 8.8.8.8
# 或
mtr 8.8.8.8 # 持续版本的 traceroute（需安装）

6.2 mtr — 网络链路质量

1
2
3
4
5
6
7
8


# 持续探测到目标的每一跳
mtr --report baidu.com

# 关键指标：
# Loss% — 丢包率（大于 0 需关注）
# Avg — 平均延迟
# Worst — 最差延迟
# StDev — 延迟波动（越大越不稳定）

6.3 网卡流量与错误

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# 查看网卡流量
ip -s link show eth0

# 实时监控网卡流量（需安装）
iftop -i eth0

# 查看网卡统计信息（关注错误和丢包）
cat /proc/net/dev
# 关注：errors（错误数）、dropped（丢包数）

# 用 nload 看实时流量（需安装）
nload

6.4 TCP 连接统计

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# 查看所有 TCP 连接状态统计
ss -ant | awk '{print $1}' | sort | uniq -c | sort -rn

# 常见状态：
# ESTABLISHED — 已建立的连接
# TIME_WAIT — 等待关闭的连接（大量堆积需关注）
# CLOSE_WAIT — 等待应用关闭的连接（大量堆积说明应用没正确关闭连接）
# SYN_SENT — 正在建立连接（多说明连接慢或目标不可达）

# 查看连接数最多的 IP
ss -ant | grep ESTAB | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -10

# 查看指定端口的连接数
ss -ant state established '( dport = :8080 or sport = :8080 )' | wc -l

6.5 sar — 网络历史统计

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 查看历史网络流量（需安装 sysstat）
sar -n DEV

# 查看今天的网络流量，每秒刷新
sar -n DEV 1

# 查看 TCP 统计
sar -n TCP 1

# 查看 SOCK 统计（socket 使用情况）
sar -n SOCK 1

6.6 抓包分析

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


# 抓取指定网卡的所有包
sudo tcpdump -i eth0

# 抓取指定端口的包
sudo tcpdump -i eth0 port 8080

# 抓取指定 IP 的包
sudo tcpdump -i eth0 host 192.168.1.100

# 抓取并保存到文件（用 Wireshark 分析）
sudo tcpdump -i eth0 -w capture.pcap

# 抓取指定端口的前 100 个包，显示内容
sudo tcpdump -i eth0 port 8080 -c 100 -A

# 组合过滤
sudo tcpdump -i eth0 host 192.168.1.100 and port 8080 -nn

6.7 curl 测量接口耗时

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


# 测量请求各阶段耗时
curl -o /dev/null -s -w "\
time_namelookup: %{time_namelookup}s\n\
time_connect: %{time_connect}s\n\
time_starttransfer: %{time_starttransfer}s\n\
time_total: %{time_total}s\n\
http_code: %{http_code}\n" https://example.com/api

# 各阶段含义：
# time_namelookup — DNS 解析耗时
# time_connect — TCP 连接耗时
# time_starttransfer — 首字节到达耗时（含服务端处理）
# time_total — 总耗时

# 判断依据：
# DNS 慢 → time_namelookup 高
# 网络慢 → time_connect 高
# 服务端慢 → time_starttransfer - time_connect 高
# 传输慢 → time_total - time_starttransfer 高

6.8 常见网络问题

1
2
3
4
5
6


连接超时 → 防火墙、路由、目标服务未启动
丢包严重 → mtr 逐跳排查，定位哪一跳开始丢包
TIME_WAIT 过多 → 短连接太多，考虑长连接或调整内核参数
CLOSE_WAIT 过多 → 应用没正确关闭连接，检查代码
带宽跑满 → iftop 定位哪个连接占用带宽
DNS 解析慢 → 换 DNS 或配置 /etc/hosts

七、综合排查场景

场景1：服务器响应变慢

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


# 第一步：快速全局查看
top
# 看 load average、%us、%sy、wa、内存

# 第二步：确认方向
vmstat 1 5
# r 列（运行队列）、wa（I/O等待）、swpd（swap使用）

# 第三步：根据方向深入
# CPU 高 → ps aux --sort=-%cpu | head -10
# 内存高 → free -h && ps aux --sort=-%mem | head -10
# 磁盘慢 → iostat -x 1
# 网络慢 → curl 测耗时，iftop 看流量

场景2：CPU 使用率突然飙高

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


# 找到占用 CPU 最高的进程
ps aux --sort=-%cpu | head -5

# 看这个进程的线程情况
top -H -p <PID>

# 跟踪进程在做什么
strace -p <PID> -c

# 如果是 Java 应用
jstack <PID> > thread_dump.txt
# 或者
jcmd <PID> Thread.print

场景3：应用频繁 OOM

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


# 查看 OOM 记录
dmesg | grep -i "killed process"

# 查看当前内存使用
free -h

# 找出内存占用最大的进程
ps aux --sort=-%mem | head -10

# 查看进程内存详情
pmap -x <PID>

# 如果是 Java 应用
jmap -heap <PID>
jmap -histo <PID> | head -20

场景4：磁盘 I/O 导致应用变慢

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# 确认 I/O wait
top # 看 wa 百分比
vmstat 1 5 # 看 wa 列和 b 列

# 查看哪个磁盘繁忙
iostat -x 1

# 找到疯狂读写磁盘的进程
sudo iotop -o

# 查看磁盘空间
df -h

场景5：网络请求慢

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# 测试网络连通性和延迟
ping target-server
mtr target-server

# 测量接口各阶段耗时
curl -o /dev/null -s -w "DNS: %{time_namelookup}s\nConnect: %{time_connect}s\nFirstByte: %{time_starttransfer}s\nTotal: %{time_total}s\n" http://target-server/api

# 查看连接状态
ss -ant | awk '{print $1}' | sort | uniq -c | sort -rn

# 抓包分析
sudo tcpdump -i eth0 port 8080 -nn -c 100

八、常用工具速查

按场景选工具

场景	首选命令	辅助命令
快速全局查看	top / htop	vmstat、uptime
CPU 高	ps、top -H	strace、perf、pidstat
内存高	free、ps	pmap、slabtop
磁盘慢	iostat -x	iotop、pidstat -d
网络慢	ping、mtr	curl、iftop、tcpdump
查看进程详情	/proc/PID/*	pmap、lsof
查看系统日志	dmesg	journalctl、/var/log/*

工具安装

1
2
3
4
5
6
7


# CentOS / RHEL
sudo yum install -y sysstat iotop htop iftop nload mtr

# Ubuntu / Debian
sudo apt install -y sysstat iotop htop iftop nload mtr-tiny

# sysstat 包含：iostat、mpstat、pidstat、sar