Performance on 纪伟的个人博客

Python 编程基础与工程实践（十）：性能分析、构建与交付

Wed, 08 Jul 2026 10:00:00 +0800

性能优化最危险的方式是凭感觉重写代码，交付最危险的方式是“把开发目录复制到服务器试试”。前者可能优化不存在的瓶颈，后者无法证明生产运行的代码就是测试过的代码。

本文是系列收官篇，以 Python 3.14 为基线，建立“定义目标—测量—定位—优化—回归”的性能闭环，并说明如何构建、验证和交付 Python 应用或库。

1. 先定义性能问题

“程序慢”至少可能指：

单次请求延迟高；
吞吐量不足；
P95/P99 尾延迟抖动；
启动时间过长；
内存峰值或常驻集过大；
CPU、磁盘、网络或数据库资源耗尽；
达到目标负载时错误率上升。

优化前先确定指标、输入规模、机器、解释器构建、依赖版本和并发度。微基准快 20% 不代表端到端请求更快：真正瓶颈可能在网络、数据库锁或下游限流。

一个可验证目标应类似：“在指定测试环境和固定数据集上，100 个并发请求下 P95 小于 200 ms，错误率低于 0.1%，进程内存峰值小于 512 MiB”，而不是“尽量快”。数字应来自项目约束，不应照抄别人的经验阈值。

2. 正确测量小段代码

timeit 会重复执行小段代码，适合比较局部实现：

1

python -m timeit -s "values = list(range(10000))" "sum(values)"

也可以在代码中使用：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


from timeit import repeat


results = repeat(
 "sum(values)",
 setup="values = list(range(10000))",
 repeat=5,
 number=1000,
)
print(min(results))

取最小值有助于观察较少受系统干扰的一次，但完整分布也有价值。微基准要注意：

包含必要初始化，排除不相关启动成本；
防止比较双方做了不同工作；
使用具有代表性的数据规模和分布；
多次运行，记录解释器、硬件和系统负载；
不从纳秒级差异推导生产结论。

端到端基准应使用单独压测工具和接近生产的依赖环境，并同时观察错误率和资源使用。

3. 用 `cProfile` 找热点

标准库推荐大多数用户使用 cProfile 做确定性分析：

1
2


python -m cProfile -o profile.pstats -m temperature_service.cli
python -m pstats profile.pstats

进入 pstats 后可按累计时间排序：

1
2


sort cumulative
stats 30

关注：

tottime：函数自身消耗时间；
cumtime：函数及其调用链累计时间；
调用次数：是否存在意外的 N+1 或重复解析；
调用路径：热点究竟来自业务代码、序列化还是外部库。

Profiler 本身会引入开销，尤其会让 Python 级代码和 C 扩展的相对表现失真。它适合定位热点，不适合充当精确基准；优化前后仍要回到独立测量。

4. 从算法和数据结构开始

通常最有价值的优化不是把循环换成晦涩表达式，而是减少工作量：

1
2
3
4
5


# 每次在线性列表中查找
allowed_list = [f"ID-{index}" for index in range(100_000)]

# 如果语义是频繁成员检查，预先构造集合
allowed_set = set(allowed_list)

集合平均成员检查通常比列表线性扫描更适合这一任务，但集合需要额外内存，且最坏情况与实际常数仍受实现和数据影响。先按语义选结构，再用真实数据验证。

常见高收益方向：

消除重复 I/O、重复解析和 N+1 查询；
批量处理，减少跨进程、网络和数据库往返；
使用字典或集合建立索引；
把循环不变量移出热路径；
避免无意义的中间容器；
给缓存设置容量、过期和一致性策略。

缓存会用内存和一致性复杂度换时间。没有失效策略、命中率和容量边界的缓存，不是免费的性能优化。

5. 惰性处理与内存占用

生成器能避免一次加载全部数据：

1
2
3
4
5
6
7
8
9


from collections.abc import Iterator
from pathlib import Path


def read_values(path: Path) -> Iterator[float]:
 with path.open(encoding="utf-8") as file:
 for line in file:
 if text := line.strip():
 yield float(text)

但生成器会把错误和资源生命周期推迟到消费时。不要返回一个依赖已关闭文件的生成器，也不要在需要多次遍历时误以为它能自动重放。

sys.getsizeof() 只报告对象本身直接占用的大小，不会递归计算它引用的整个对象图，也属于实现相关信息：

1
2
3
4
5


import sys


values = [1, 2, 3]
print(sys.getsizeof(values))

因此不能把这个数字当成列表及全部整数的总内存。

6. 用 `tracemalloc` 定位 Python 分配

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


import tracemalloc


tracemalloc.start()

before = tracemalloc.take_snapshot()
result = build_report() # 以你的待测函数为例
after = tracemalloc.take_snapshot()

for statistic in after.compare_to(before, "lineno")[:10]:
 print(statistic)

tracemalloc 跟踪 Python 内存分配及其调用位置，适合比较快照和发现持续增长的分配点。它不等于进程总内存监控：原生库、内存映射、分配器保留和操作系统页面都可能不完整地反映在其中。

诊断内存要区分：

暂时峰值；
仍被 Python 引用的对象；
已释放给 Python 分配器但未归还操作系统的内存；
C 扩展或外部进程分配；
无界缓存、队列和任务积压。

不要通过频繁手工 gc.collect() 掩盖对象仍被引用的问题；先找持有路径和增长来源。

7. 解释器、扩展与并行策略

性能不足时可按成本逐层选择：

改算法、数据访问和批处理方式；
使用标准库或成熟库中已由 C、C++、Rust 等实现的向量化操作；
对 CPU 热点采用进程并行，评估序列化成本；
在依赖兼容且共享状态正确时评估 Python 3.14 自由线程构建；
最后才考虑编写原生扩展或更换实现，并承担构建、安全和跨平台维护成本。

不要假设“用 NumPy”“去掉 GIL”或“改成异步”必然更快。数据规模太小时，转换与调度开销可能占主导；I/O 系统受限时，提高 CPU 并行度也没有帮助。

8. 构建 wheel 与源码发行包

在包含 pyproject.toml 的项目根目录安装构建前端并构建：

1
2


python -m pip install --group build
python -m build

通常会在 dist/ 生成：

wheel（.whl）：构建好的安装发行格式，安装时通常不必再执行项目构建；
source distribution（sdist，通常是 .tar.gz）：包含可用于构建的源代码发行包。

构建应从干净版本控制检出执行，避免把本地未跟踪文件、旧生成物或凭据意外打包。实际包含哪些文件受构建后端配置影响，必须查看产物内容而不是猜测。

验证闭环：

1
2
3
4
5


python -m build
python -m venv .verify-venv
.\.verify-venv\Scripts\python.exe -m pip install dist\temperature_service_example-0.1.0-py3-none-any.whl
.\.verify-venv\Scripts\python.exe -c "import temperature_service; print(temperature_service.__file__)"
.\.verify-venv\Scripts\temperature-service.exe

wheel 文件名由规范化发行名、版本、Python/ABI/平台标签决定，不能在自动化中永久硬编码示例文件名。真实脚本应先列出或由构建元数据确定唯一产物，并在发现零个或多个候选时失败。

9. 发布库与部署应用是两件事

发布库的目标是让其他项目安装并解析依赖：

提供稳定公共 API、版本和兼容范围；
构建 wheel 与 sdist；
在干净环境测试产物；
发布到 PyPI 或内部索引；
不把开发依赖和本地秘密写入元数据。

部署应用的目标是复现一套完整运行环境：

锁定经测试的直接与传递依赖；
固定 Python 特性版本、操作系统和必要原生库；
提供配置、秘密注入、健康检查和回滚；
将同一构建产物逐级提升到测试和生产；
记录产物与源提交、构建过程的关联。

库倾向声明兼容范围，应用倾向锁定具体解析结果。把两者混在一起，要么让库依赖过度严格，要么让生产环境不可复现。

10. 安全发布

PyPA 对受支持 CI/CD 平台推荐使用 PyPI Trusted Publishing，通过短期身份联合发布，避免长期 API Token。具体平台配置应以 PyPI 当前官方文档为准。

无论采用何种发布方式，都应：

保护包索引账户并启用多因素认证；
把发布权限限制到专用环境和受保护分支/标签；
先验证发行名、版本和产物内容；
不在日志中输出令牌；
不从拉取请求中的不受信任代码直接触发带凭据发布；
发布已经测试过的产物，不在发布步骤重新构建另一份。

手工发布可使用 Twine，但不要使用已弃用且不安全的 python setup.py upload。所有直接执行 setup.py 的命令都已弃用；现代构建应通过 PEP 517/518 兼容前端调用声明的构建后端。

11. 部署后的性能闭环

实验室结果不等于生产结果。上线后至少观察：

请求量、延迟分位数和错误率；
CPU、内存、文件描述符、线程和任务队列；
外部依赖调用的耗时与失败；
缓存命中、队列积压和限流；
版本、配置和部署批次。

优化发布应小步进行，并保留快速回滚路径。一次只改变关键变量，比较同一负载条件下的指标；如果业务流量不可控，使用灰度、对照组或可重复回放降低误判。

性能退化要转化为自动化保护：为关键算法建立可重复基准，为请求链路设置服务级目标，为资源增长设置观测与告警。但基准阈值要容忍共享 CI 机器的合理噪声，避免把偶发抖动当回归。

12. 系列总结

这十篇文章形成了一条完整路径：

确认 CPython 3.14 解释器与隔离环境；
用名称绑定和对象模型理解基础语法；
按语义选择容器并管理可变性；
用函数、迭代器和上下文协议构建抽象；
用类、数据类与组合表达领域模型；
建立异常、资源、模块、配置和日志边界；
用类型标注增强静态契约；
按 CPU/I/O 特性选择线程、进程或 asyncio；
用测试、pyproject.toml 和 CI 保证可重建；
以测量驱动优化，并交付已验证的同一产物。

Python 的易学来自表达简洁，工程可靠性则来自边界清晰、事实可验证和失败路径完整。写出第一个脚本只需几分钟，把程序长期维护好，依靠的是这套持续闭环。

参考资料

Python 编程基础与工程实践（八）：线程、进程、asyncio 与 GIL

Sat, 04 Jul 2026 10:00:00 +0800

并发问题最容易被一句“Python 有 GIL”讲坏：有人因此认为线程毫无用处，也有人误以为 GIL 会自动保证数据安全。Python 3.14 又让情况多了一层——自由线程构建已经获得官方支持，但仍不是默认构建。

本文以 CPython 3.14 为基线，先按任务性质选择工具，再解释线程、进程、asyncio、取消和 GIL 的准确边界。

1. 并发、并行和异步不是同义词

并发（Concurrency）：多个任务的生命周期重叠，可以交替推进；
并行（Parallelism）：多个任务在同一时刻由不同计算资源执行；
异步（Asynchrony）：调用方发起操作后不必阻塞等待，以事件或可等待对象继续协调。

选择方案先看瓶颈：

任务	常见首选	原因
阻塞式文件、网络、设备 I/O	`threading` / `ThreadPoolExecutor`	能复用同步库，等待期间可推进其他线程
高并发异步网络 I/O	`asyncio`	单线程事件循环可管理大量协作式任务
纯 Python CPU 密集计算	`multiprocessing` / `ProcessPoolExecutor`	默认 CPython 中绕开进程内 GIL，利用多核
可隔离、可序列化的 CPU 任务	`InterpreterPoolExecutor`	每个工作线程使用独立解释器和独立 GIL，可在单进程内利用多核
支持自由线程的 CPU 工作负载	自由线程 CPython + `threading`，经实测决定	可并行执行 Python 代码，但生态与同步设计需验证

这只是起点。数据复制成本、第三方库是否释放 GIL、部署平台和故障隔离也会改变结论，最终要用真实工作负载测量。

2. 默认 CPython 的 GIL 到底保证什么

全局解释器锁（Global Interpreter Lock，GIL）在默认 CPython 构建中，通常只允许一个线程在同一时刻执行 Python 字节码并操作 Python 对象。线程在阻塞 I/O 时会释放 GIL，部分 C 扩展也会在长时间本地计算时主动释放它。

GIL 不等于：

整个 Python 语句都是原子的；
多步业务操作天然线程安全；
容器复合操作不会竞态；
内存可见性和事务一致性已经得到业务层保证。

下面的“先检查再写入”由多个步骤组成：

1
2


if key not in cache:
 cache[key] = load_value(key)

两个线程可能都发现键不存在，然后重复加载并覆盖。正确方案取决于语义：可以用锁保护复合不变量，也可以使用允许重复计算但结果幂等的设计。

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


from threading import Lock


cache: dict[str, str] = {}
cache_lock = Lock()


def load_value(key: str) -> str:
 return key.upper()


def get_or_load(key: str) -> str:
 with cache_lock:
 if key not in cache:
 cache[key] = load_value(key)
 return cache[key]

这个版本在锁内执行加载，能避免重复加载，却也让慢 I/O 阻塞其他键。生产代码可能使用每键锁、Future 占位或锁外加载后再合并，必须围绕业务不变量权衡。

3. Python 3.14 的自由线程构建

CPython 3.13 开始提供可禁用 GIL 的自由线程构建；Python 3.14 根据 PEP 779 进入“官方支持但可选”的阶段。它并没有取代默认构建，也不意味着所有扩展和程序自动获得线性加速。

可以检查当前运行时：

1
2
3
4
5
6
7
8


import sys
import sysconfig


supports_free_threading = sysconfig.get_config_var("Py_GIL_DISABLED") == 1
gil_enabled = sys._is_gil_enabled()

print(supports_free_threading, gil_enabled)

sys._is_gil_enabled() 在 Python 3.14 可报告当前进程是否启用了 GIL。自由线程构建仍可在运行时启用 GIL；导入未声明兼容自由线程的 C 扩展时，也可能自动重新启用 GIL 并给出警告。

自由线程不取消同步需求，恰恰会让真实并行下的数据竞争更容易暴露。迁移前要检查：

第三方二进制扩展是否提供兼容构建；
共享可变状态是否有明确所有权或锁；
代码是否依赖“看起来原子”的 CPython 偶然行为；
单线程性能、内存开销和扩展兼容性是否可接受；
基准是否覆盖真实请求、数据规模和硬件。

4. 线程：适合阻塞 I/O 和同步库

高层接口 ThreadPoolExecutor 比手工管理线程更适合一批独立任务：

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


from concurrent.futures import ThreadPoolExecutor, as_completed
from urllib.request import urlopen


def fetch_length(url: str) -> tuple[str, int]:
 with urlopen(url, timeout=5) as response:
 return url, len(response.read())


urls = [
 "https://www.python.org/",
 "https://docs.python.org/3/",
]

with ThreadPoolExecutor(max_workers=4) as executor:
 futures = [executor.submit(fetch_length, url) for url in urls]
 for future in as_completed(futures):
 try:
 url, length = future.result()
 except OSError as error:
 print(f"请求失败：{error}")
 else:
 print(url, length)

注意边界：

future.result() 会重新抛出工作线程异常；
超时要传给实际 I/O API，不能只给等待 Future 的调用加超时；
线程池大小不是越大越好，受远端限流、连接数、内存和调度影响；
关闭执行器默认会等待任务结束，进程不会靠“忘记引用”可靠退出。

共享数据使用 Lock、RLock、Condition、Semaphore、Event 或线程安全队列协调。优先通过队列传递数据、缩小共享状态，而不是给每个字段随手加锁。

5. 进程：隔离地址空间并利用多核

ProcessPoolExecutor 把可序列化任务提交给子进程：

 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


from concurrent.futures import ProcessPoolExecutor


def count_primes(limit: int) -> int:
 def is_prime(value: int) -> bool:
 if value < 2:
 return False
 divisor = 2
 while divisor * divisor <= value:
 if value % divisor == 0:
 return False
 divisor += 1
 return True

 return sum(1 for value in range(limit) if is_prime(value))


def main() -> None:
 limits = [50_000, 55_000, 60_000]
 with ProcessPoolExecutor() as executor:
 print(list(executor.map(count_primes, limits)))


if __name__ == "__main__":
 main()

入口保护是跨平台进程代码的必要习惯。提交的函数、参数和返回值通常需要可 pickle；REPL 中定义的局部函数、lambda、打开的连接和锁通常不适合直接传递。

Python 3.14 之后，fork 不再是任何平台的默认启动方式。支持通过 Unix 管道传递文件描述符的 POSIX 平台（如 Linux）默认使用 forkserver，macOS 和 Windows 默认使用 spawn。不要假设所有系统都使用同一种方式，库也不应擅自全局设置启动方式。确需指定时，由应用入口通过上下文显式选择，并验证第三方库兼容性。

进程有序列化、启动和数据复制成本。很小的任务可能比单进程更慢；把工作分成足够大的批次，并避免在进程间来回搬运巨量对象。

6. Python 3.14 的子解释器执行器

Python 3.14 新增 InterpreterPoolExecutor。它是 ThreadPoolExecutor 的子类，但每个工作线程运行在独立解释器中；每个解释器拥有独立 GIL，因此默认构建也能让纯 Python 任务在不同 CPU 核上并行：

1
2
3
4
5
6
7
8
9


from concurrent.futures import InterpreterPoolExecutor


def square(value: int) -> int:
 return value * value


with InterpreterPoolExecutor() as executor:
 print(list(executor.map(square, range(5))))

隔离是它的核心边界：不同解释器拥有各自的模块、sys、内置对象和运行时状态，不能直接共享普通可变对象。执行器会使用 pickle 传递初始化器、任务参数和返回值，因此函数必须可导入、数据必须可序列化，传输成本也不会消失。

与进程池相比，子解释器仍处于同一操作系统进程，故障隔离和扩展兼容性不同；与自由线程相比，它通过隔离减少共享状态，而不是让多个线程共同操作同一套对象。它是 Python 3.14 值得评估的新选择，不是对进程池或自由线程的全面替代。

7. `asyncio`：协作式并发

协程遇到 await 才把控制权交回事件循环：

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


import asyncio


async def worker(name: str, delay: float) -> str:
 await asyncio.sleep(delay)
 return f"{name} done"


async def main() -> None:
 async with asyncio.TaskGroup() as group:
 first = group.create_task(worker("A", 0.2))
 second = group.create_task(worker("B", 0.1))

 print(first.result(), second.result())


if __name__ == "__main__":
 asyncio.run(main())

TaskGroup 提供结构化并发：离开上下文前等待所有任务；某个任务以普通异常失败时，会取消其余任务，并在清理后以异常组传播失败。它比创建一批无人持有、无人等待的后台任务更容易管理生命周期。

async 函数调用只创建协程对象，不会自动执行：

1

coroutine = worker("A", 1.0)

需要 await coroutine、创建 Task，或由 asyncio.run() 驱动顶层协程。

8. 不要阻塞事件循环

下面的同步休眠会阻塞整个事件循环线程：

1
2
3
4


# 错误示例
async def bad() -> None:
 import time
 time.sleep(1)

异步等待应使用：

1
2


async def good() -> None:
 await asyncio.sleep(1)

无法替换的短期阻塞 I/O 可以交给线程：

1
2
3
4
5
6


import asyncio
from pathlib import Path


async def read_text(path: Path) -> str:
 return await asyncio.to_thread(path.read_text, encoding="utf-8")

to_thread() 主要用于不会长时间占用 GIL 的阻塞调用。默认 GIL 构建下，把纯 Python CPU 密集函数扔给线程通常不会获得多核并行。

9. 超时、取消和清理

1
2
3
4
5
6


import asyncio


async def load_with_timeout() -> bytes:
 async with asyncio.timeout(2.0):
 return await load_bytes()

这里的 load_bytes() 代表项目提供的异步 I/O 函数；超时必须包住真正的等待操作。

超时通过取消当前任务实现。协程应使用 try/finally 释放资源，并在捕获 asyncio.CancelledError 后完成必要清理再重新抛出。这里的 acquire() 与 resource 代表项目中的异步资源获取与句柄操作：

1
2
3
4
5
6
7
8
9


async def consumer() -> None:
 resource = await acquire()
 try:
 await resource.run()
 except asyncio.CancelledError:
 await resource.stop()
 raise
 finally:
 await resource.close()

CancelledError 是 BaseException 的直接子类。结构化并发组件依赖取消工作；吞掉取消又不调用相应的取消状态处理，会造成任务组和超时行为异常。

超时也不等于底层操作一定已停止。线程中的阻塞函数不能被 Python 强行安全终止，远端请求也可能已经产生副作用。幂等性、底层超时和补偿策略仍需单独设计。

10. 背压与有界并发

一次创建百万个任务会消耗大量内存并压垮下游。使用有界队列或信号量限制在途任务：

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


import asyncio
from collections.abc import Iterable


async def fetch_all(urls: Iterable[str], limit: int = 20) -> list[bytes]:
 semaphore = asyncio.Semaphore(limit)

 async def bounded_fetch(url: str) -> bytes:
 async with semaphore:
 return await fetch(url)

 async with asyncio.TaskGroup() as group:
 tasks = [group.create_task(bounded_fetch(url)) for url in urls]

 return [task.result() for task in tasks]

这里的 fetch() 代表异步 HTTP 客户端提供的请求函数。这个版本限制同时执行的 fetch 数量，但仍一次创建所有 Task。输入规模不受控时应进一步使用固定数量消费者和有界 asyncio.Queue，让生产者在队列满时等待，形成真正背压。

11. 如何做选择

可以按以下顺序判断：

先确认瓶颈是 CPU、I/O、锁竞争还是外部限流；
已有同步库且并发量适中，优先线程池；
整条调用链已有异步 API 且需要大量在途 I/O，考虑 asyncio；
默认 CPython 下的纯 Python CPU 密集任务，考虑进程池；
任务可序列化且适合解释器隔离时，评估 3.14 的 InterpreterPoolExecutor；
自由线程构建只有在依赖兼容、共享状态正确且基准受益时才采用；
无论哪种模型，都设置有界并发、超时、取消、错误聚合和关闭流程。

并发模型不是架构身份。一个服务可以在事件循环中管理网络连接，把阻塞调用交给线程，把大块 CPU 计算交给进程，但每跨一层都增加调度、序列化和故障处理成本。

12. 小结

GIL 限制默认 CPython 中 Python 字节码的线程并行，不保证复合业务操作线程安全。
Python 3.14 的自由线程构建已受支持但仍可选；扩展兼容和显式同步仍是前提。
线程适合同步阻塞 I/O，进程适合较粗粒度 CPU 任务，子解释器提供隔离的单进程多核方案，asyncio 适合协作式高并发 I/O。
Python 3.14 不再在任何平台默认使用 fork；Linux 等平台通常使用 forkserver，macOS 和 Windows 使用 spawn，跨平台代码不要依赖隐含默认值。
取消、超时、有界并发和资源关闭是正确性的组成部分，不是上线前再补的优化。

下一篇将把代码组织成可测试、可构建的项目，统一 pyproject.toml、依赖和 CI。

参考资料

线程安全的本质：从 CPU 缓存到内存模型，锁到底在保证什么

Thu, 18 Jun 2026 10:00:00 +0800

写在前面

打开任何一篇"线程安全"教程，多半从 lock 怎么用讲起；打开 Java 的，从 synchronized 讲起；打开 Go 的，从 channel 讲起。工具各不相同，但它们要解决的问题是同一个，而且不属于任何语言——它是"多核硬件 + 编译器优化"与"程序员的顺序直觉"之间的一道鸿沟。

这篇按四层结构从根源讲起：硬件层（缓存与重排序）→ 模型层（内存模型这份"合同"）→ 语言层（.NET / Java / C++ / Go / Rust 五种答案）→ 工具层（C# 同步原语的屏障语义）。示例以 C# 为主，但读完你会发现：lock、synchronized、sync.Mutex 底下是同一套东西。

前置知识：知道线程是什么就够（《操作系统学习笔记（二）：进程、线程与协程》讲了调度侧）；不需要先读任何 .NET 并发文章。

一、三种"不安全"：原子性、可见性、有序性

线程安全不是一个问题，是三个问题的统称。

1. 原子性（atomicity）——一个操作被"劈开"了。

1

counter++; // 看一眼（read）→ 加一（modify）→ 写回（write），三个动作

两个线程各执行一次 counter++，如果交错在"看一眼"和"写回"之间，结果可能是 1 而不是 2。注意这不需要多核：单核上时钟中断导致的线程切换同样能造成交错。原子性问题是三个里最古老、最容易理解的。

2. 可见性（visibility）——写了，别人看不见。

1

while (!stop) { /* 工作 */ } // 另一个线程把 stop 置为 true

一个线程修改了 stop，另一个线程可能一直在读旧值——缓存、寄存器复用和编译器/JIT 优化都可能造成"我写了但你读不到"。即使只有一个处理器，缺少同步仍允许编译器把读取缓存到寄存器或移出循环；多核缓存层级只是让问题更容易暴露。不能把单核环境当成可见性保证。

3. 有序性（ordering）——执行顺序和你写的不一样。

你在单线程里写 a = 1; b = 2;，只要最终结果一样，编译器和 CPU 都有权交换顺序（as-if-serial）。问题出现在另一个线程在旁边看：它观察到的写入顺序可能与你的程序顺序相反。这不是 bug，是优化——但你的直觉没跟上。

把三个问题合起来，得到贯穿全文的定义——数据竞争（data race）：

两个线程访问同一内存位置，至少一个是写，且两者之间没有同步关系。

数据竞争 ≠ 竞态条件

一个容易混淆、值得开头就掰清的区分：数据竞争是内存层面的（定义如上，三条缺一不可），竞态条件（race condition）是逻辑层面的——程序的正确性取决于线程的相对时序。关键是两者可以独立出现。

没有数据竞争、却有竞态条件的例子（每个操作自身都线程安全）：

1
2
3
4


var dict = new ConcurrentDictionary<string, string>();

if (!dict.ContainsKey(key)) // 检查：线程安全
 dict[key] = value; // 行动：也线程安全

两个线程同时通过检查、先后写入——最终"谁后到谁覆盖"，结果对不对取决于时序，而全程没有任何数据竞争（集合内部负责并发安全）。修法也不是在外面重复一次检查，而是使用与业务语义匹配的单操作 API，例如 TryAdd(key, value)。GetOrAdd 能保证字典最终只采用一个值，但它的 valueFactory 在锁外执行，竞争时可能调用多次；工厂若有副作用或创建成本很高，仍要单独设计。

反方向也存在：有数据竞争但结果碰巧正确（两个线程都往同一个 bool 写 true，怎么交错都是 true——所谓 benign data race）。但在 C++ 里它照样是 UB；Java/Go 虽禁止凭空值，一旦类型宽过机器字（Java 的非 volatile long/double、Go 的多字值），撕裂照样可能发生——“碰巧对"不构成依赖的理由。

所以准确的表述是两层：消灭数据竞争是内存正确性的门槛——靠同步原语和内存模型；消灭有害竞态是逻辑正确性的门槛——只能靠把"检查 + 行动"设计成原子单元，硬件帮不了你。

二、硬件层：为什么"看见"这么难

缓存层级：慢的不是运算，是搬运

《每个程序员都该知道的延迟数字》里那张表：L1 缓存约 0.5ns，主内存约 100ns——差了约 200 倍。所以每个核心都有私有缓存（L1/L2），共享的只有 L3。多线程的可见性问题，从这个结构就开始了。

缓存一致性：它保证的比你想的少

硬件当然知道这个问题。现代多核系统用缓存一致性协议（MESI 是最常见的实现）保证两件事（教科书总结为两条不变量）：

SWMR（Single-Writer-Multiple-Reader）：任一时刻，一个缓存行要么没有 writer，要么恰好有一个 writer；
数据值不变量：一个位置的值要么是上次的值，要么是某个处理器真正写进去的值——不会无中生有。

听起来很完美？缓存一致性 ≠ 顺序一致性。一致性协议维护同一缓存行副本之间的规则，却不替语言程序建立 happens-before，也不承诺一个缺少同步的读取必须在某个期限内观察到写入。程序观察到的先后差距来自写缓冲、失效处理和处理器内存排序等机制：

Store buffer（写缓冲区）。CPU 写内存时不是直接写缓存，而是先塞进自己的写缓冲区，然后继续干别的（等缓存行拿到独占权）。副作用：自己的后续读请求可以先于自己之前的写生效——对外表现就是"写还没被别人看见，但后面的读已经跑了”。这就是著名的 store→load 重排序。

用一个经典的 litmus test（litmus test = 判例测试，两个线程各跑几条指令，看哪些结果组合可能出现）：

1
2
3
4
5
6


// 初始 x = 0, y = 0
// 线程 1: // 线程 2:
x = 1; y = 1;
var r1 = y; var r2 = x;
// 直觉：r1、r2 至少一个是 1（总得有人先写完）
// 实际：x86 上 r1 == 0 && r2 == 0 是可能的

怎么可能两个都是 0？两个线程都把写留在 store buffer 里、先执行了读。这个结果不违反缓存一致性（没有"错的值"），但违反你的顺序直觉。

Invalidate queue（失效队列）。收到"别人要独占这行缓存"的通知时，CPU 先回 ACK 再慢慢处理失效，于是写传播又慢了一拍。Paul McKenney 的经典论文《Memory Barriers: a Hardware View for Software Hackers》把这两个部件讲得最透（见参考资料）。

x86 和 ARM：强序与弱序

不是所有架构重排程度一样：

架构	普通读写的重排	说明
x86 / x86-64	只允许 store→load 一种	写写、读读、读写都不重排；学术化的名字是 x86-TSO（Total Store Order，所有核共享一个全局写顺序，每核一个 FIFO store buffer）
ARM / AArch64	比 x86-TSO 更弱，允许更多观察结果	具体约束还受指令类型和地址/数据依赖影响；需要跨核顺序时由语言运行时生成 acquire/release 指令或 DMB 等屏障

这就是为什么"这段代码在我电脑上没问题"不等于没问题：x86 的强序掩盖了很多错误代码，同一段程序跑在 ARM（手机、Apple Silicon、云上的 Graviton）上才暴露。MSDN 的说法很直白：x86 上唯一可能的重排效应就是"写值不会立刻对其他处理器可用"。

别忘了第二个重排来源：编译器

上面全是硬件。但在指令到 CPU 之前，编译器/JIT 已经重排过一轮了——寄存器缓存、指令调度、循环外提，都发生在单核时代。你面对的乱序是两层叠加的：编译器重排 × CPU 重排。所以"volatile 到底拦谁"这类问题的答案永远是"两层都拦"——后面细说。

小结这一层：硬件给你的是性能优先的弱保证。而程序员的直觉是顺序一致性（sequential consistency, SC）——所有线程的操作仿佛排成一条全局队列、按程序顺序交错执行。直觉与硬件之间的鸿沟，就需要下一层的"合同"来填。

三、内存模型：语言和程序员的合同

内存模型（memory model）= 一门语言对"什么操作以什么顺序对谁可见"的正式承诺。它站在你和"编译器 × 硬件"的两次重排之间：语言保证"只要你按合同写代码，我就把底层收拾得符合你的直觉"。

合同的核心概念是 happens-before，由三种关系构成：

程序顺序：单线程内，前面的语句 happens-before 后面的；
同步边：一个同步动作和另一个之间有明确的先后——解锁 happens-before 后续对同一把锁的加锁；volatile 字段的写 happens-before 后续对它的读；
传递性：A happens-before B，B happens-before C，则 A happens-before C。

只要"写 A"和"读 A"之间存在 happens-before 链条，这次读就能看到这次写（以及写之前的一切）——这就是锁语义的真正内涵：进入锁能看到上一个持锁线程做的所有修改，不是"锁有魔法"，而是解锁→加锁构成 happens-before 边。

有了定义，主流语言几乎都遵守同一条总纲——DRF-SC（Data-Race-Free → Sequential Consistency）：

程序没有数据竞争，就表现得像顺序一致；有数据竞争，后果按各语言的条款处理。

“按各语言的条款处理"是关键差异所在，下一节展开。这里先给结论：C/C++ 说有竞争就是未定义行为（编译器可以假设竞争不存在）；Java/Go 承认竞争发生但约束其后果（读到旧值可以，读到凭空的值不行）；Rust 让安全代码根本写不出竞争；.NET 的处境比较微妙——见下。

四、语言层：同一问题的五种答案

.NET：基线很弱，实现很强，文档没跟上

.NET 的正式合同是 ECMA-335 Partition I §12.6（Memory model and optimizations），基线相当保守。落到 C# 规范里有两段可查的硬承诺：

原子性（C# 规范 §9.6）：bool、char、byte/sbyte、short/ushort、int/uint、float、枚举（以上为底层类型）和所有引用类型的读写是原子的；long、ulong、double、decimal 和自定义类型不保证原子。

volatile（C# 规范 §15.5.4）：volatile 读具有 acquire 语义（之后的访存不会提前到它前面），volatile 写具有 release 语义（之前的访存不会推迟到它后面）。

CLR 的具体实现往往比语言规范基线更强，历史文章也记录过特定 CLR 版本和处理器上的额外排序保证。但这些属于“版本 × 运行时 × 架构”的实现事实，不能从旧版 x86/CLR 经验外推到所有现代 .NET 目标。工程代码应依赖 C# 规范和同步 API 的公开合同，而不是依赖某代 JIT 恰好没有采用某种重排。

工程结论：按 ECMA/C# 规范的基线写代码，不要依赖实现的额外保证——代码才可能在 x86 和 ARM 上同时正确。

Java：JSR-133，语言级内存模型的标杆

2004 年的 JSR-133 重写了 Java 内存模型（JMM），至今仍是"语言把内存模型讲清楚"的标杆。它的 happens-before 清单写在 JLS §17.4.5：程序顺序、解锁→加锁、volatile 写→读、线程 start/join、传递性。

两条对工程影响最大的承诺：

volatile 的语义类似锁的获取/释放两侧：官方 FAQ 将 volatile 写的内存效果类比为释放锁，将 volatile 读类比为获取锁；具体生成什么指令取决于 JVM 和处理器。
final 字段的初始化安全保证：只要构造函数里没有让 this 提前逃逸，其他线程在正确取得对象引用后能获得 JLS 对 final 字段规定的可见性保证。它支撑不可变对象设计，但不会自动让对象中的所有可变状态都线程安全。

另外 JLS §17.7 明确：非 volatile 的 long/double 写可能被拆成两个 32 位写（撕裂），和 C# 规范对 64 位类型的保留态度如出一辙。

C++：把选择权全部给你，代价是全归你管

C++11 引入了六档 std::memory_order：relaxed（只保原子性不管顺序）、acquire、release、acq_rel、seq_cst（最强：额外保证所有线程看到同一个全局顺序），外加实践中基本不用的 consume（已走向弃用）。锁在模型里也有位置：mutex 的 lock() 是 acquire 操作、unlock() 是 release 操作。

最重要的条款：数据竞争 = 未定义行为（[intro.races]：“Any such data race results in undefined behavior”）。编译器可以假设你的程序没有竞争来做激进优化——一旦真有竞争，不是"读到旧值"这么温柔，是任何行为都合法。

Go：只给最强档，附赠一句忠告

Go 内存模型（2022 年随 Go 1.19 修订）做了减法：只提供顺序一致的原子操作（“Go only provides sequentially consistent atomics”），不提供 relaxed 等弱形式。happens-before 清单很实用：

go 语句 happens-before 新 goroutine 开始执行（但 goroutine 的结束没有对应保证——这是常见坑）；
channel：发送 happens-before 对应接收完成；关闭 happens-before 收到零值；无缓冲 channel 的接收 happens-before 对应发送完成；容量 C 的 channel 第 k 次接收 happens-before 第 k+C 次发送完成；
sync.Mutex：第 n 次 Unlock() happens-before 第 m 次 Lock() 返回；
sync.Once：f() 的完成 happens-before 任何 Do(f) 的返回。

数据竞争的后果介于 Java 和 C++ 之间：不是完全未定义（读到的一定是某人真正写过的值，禁止凭空值），但多字大小的竞争可能导致"不属于任何一次写入的混合值"甚至内存破坏。Go 文档还专门把双检锁列为错误用法（见第六节），以及那句著名的忠告：

“如果你必须读完这份文档才能理解你程序的行为，你太聪明了。别耍聪明。”

Rust：把线程安全搬进类型系统

Rust 的答案最彻底：两个 marker trait，Send（可以安全地送到另一个线程）和 Sync（可以安全地在线程间共享，T: Sync ⇔ &T: Send），由编译器自动推导、组合传递。效果是：安全 Rust 不可能构造出数据竞争（Rustonomicon 原话：“A data race has Undefined Behavior, and is therefore impossible to perform in Safe Rust”）——不是运行时报错，是编译不过。

注意边界：Rust 防的是 data race，不防一般竞态——死锁、逻辑时序错误在 Rust 里照样合法且"安全”。

五种答案对照

语言	模型文档	data race 后果	原子操作	特色
.NET	ECMA-335 基线 + 实现事实，无完整形式化文档	有约束（按 ECMA），但边界模糊	`Interlocked` 原子操作 + 强同步排序	规范弱、实现强，按基线写
Java	JMM（JLS ch.17，JSR-133）	有约束：禁止凭空值	volatile + `VarHandle` 多档	final 字段安全发布
C++	标准完整	未定义行为	六档 `memory_order`	全给你选，全归你管
Go	官方文档（2022 修订）	有约束：单字有值保证，多字可破坏	只有 seq_cst 一档	“别耍聪明”
Rust	标准库文档 + Nomicon	安全代码不可能	seq_cst 起步	Send/Sync 编译期防护

同一道题，五种解法。选择的差异背后是哲学差异：C++ 信任专家，Go 替你选好，Rust 不信任任何人（包括你）。

五、工具层：C# 的同步原语与屏障语义

现在回到写代码。C# 的同步工具不多，但每个的"屏障语义"不同——选错工具的根源几乎都是没搞清它在三层问题上解决了哪层。

lock / Monitor：互斥 + 获取/释放语义

1
2
3
4
5
6


private static readonly object _gate = new();

lock (_gate) // Monitor.Enter + try/finally + Monitor.Exit
{
 // 临界区
}

lock 一次性解决三个问题：互斥（临界区不会并发交错）、有序性（获取锁具有 acquire 效果，释放锁具有 release 效果）、可见性（上一个持锁者释放同一把锁之前的修改，对随后成功获取它的线程可见）。工程上常把锁概括成“强屏障”，但不能据此说 Enter 和 Exit 各自都是双向全屏障；真正需要依赖的是这对获取/释放语义以及由它建立的同步关系。

C# 13 / .NET 9 起新增 System.Threading.Lock 类型，lock 语句遇到它会编译成 using (x.EnterScope())，语义更干净。

Interlocked：原子操作 + 强同步排序

1
2
3


Interlocked.Increment(ref counter); // 原子 +1
Interlocked.CompareExchange(ref f, newVal, exp); // 原子 CAS
Interlocked.Read(ref bigValue); // 32 位平台上原子的 64 位读

Interlocked 为目标位置提供原子操作：Increment、Add、Exchange、CompareExchange 等是原子读-改-写（RMW），Read 提供原子的 64 位读取；这些 API 同时承担跨线程同步所需的强内存排序。具体机器指令由运行时和目标架构决定，不应把 x86 的 lock 前缀当成跨平台合同。它适合计数器、状态转换和无锁结构内部，但不能自动把多条业务操作组成一个不可分割的临界区。

volatile：半个屏障，三个"不保证"

1

private static volatile bool _stop;

C# 的 volatile 可按读 acquire + 写 release理解。它的三个"不保证"每个都坑过人：

不把复合操作变成原子操作——即使字段可声明为 volatile，counter++ 仍是读、改、写三步；
不提供互斥——两个 volatile 变量的复合操作照样交错；
不保证 volatile 写的全局总顺序——规范原话：“不要求为 volatile 写提供所有线程可见的单一总顺序”。

还有一条硬限制：long、ulong、double、decimal 不能声明为 volatile——正因为它们的读写不保证原子，标 volatile 会给人错误的安全感。微软官方文档对 volatile 的告诫是"常被误解和误用"，建议改用 Interlocked 或 lock。

64 位撕裂：一个跨语言的经典坑

C# 规范明说 long/double 读写不必原子；Interlocked.Read 的文档更直白：“64 位系统上不需要 Read（64 位读已原子）；32 位系统上 64 位读除非用 Read，否则不原子。“两个 32 位写拼出一个混合值的撕裂读，在 32 位运行时是真实风险。Java JLS 对非 volatile long/double 有一样的条款——这是"字长 < 数据宽度"的普遍问题，不是哪家实现的缺陷。

线程 API 自带屏障

容易忽略的一点：Thread.Start、Task.Run/Task.Factory.StartNew、ThreadPool.QueueUserWorkItem 这些 API 隐含屏障语义——启动线程之前的所有写，新线程都能看到（“几乎每个线程 API 都必须有某种屏障语义才能正常工作”）。所以"创建后交给别的线程"这个模式不需要你额外做事；出问题的是后面反复读写共享状态的阶段。

原语对照表

原语	原子性	有序性/屏障	适用
`lock`	✔（临界区整体互斥）	获取/释放语义	保护复合操作，默认选择
`Interlocked.*`	✔（对应的单次操作）	强同步排序	计数、CAS、无锁结构内部
`volatile`	✘	acquire/release	状态标志、发布引用
无标注字段	仅规范列出的类型	无	靠其他手段保护

六、贯穿案例：双检锁的三次重生

双检锁（Double-Checked Locking, DCL）是把前五节串起来的完美案例——它错了二十年、被修复、然后过时，每一步都对应一条内存模型规则。

版本 1：无 volatile 的 DCL——为什么错

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


// ❌ 经典错误版本
private static Singleton _instance; // 没有 volatile
public static Singleton Instance
{
 get
 {
 if (_instance is null) // 第一次检查（无锁）
 {
 lock (_gate)
 {
 if (_instance is null) // 第二次检查
 _instance = new Singleton(); // 问题在这一行
 }
 }
 return _instance;
 }
}

问题在 _instance = new Singleton()。这条语句实际是三步：分配内存 → 运行构造函数 → 把引用写到字段。在没有同步约束的情况下，第 2、3 步可以重排为"分配 → 发布引用 → 构造”。另一个线程在第一次检查处读到非 null，直接开始用一个还没构造完的对象。

注意这里的微妙：两个线程访问 _instance 一个读一个写、没有 happens-before——这是教科书级的 data race，而 data race 的后果按上一节的语言条款来。在 C++ 里直接 UB；在 x86 的 .NET 上"恰好"通常没事（强序掩盖）；ARM 上就是真 bug。

版本 2：加 volatile 的 DCL——为什么对

1
2


// ✅ 语义正确
private static volatile Singleton _instance;

只改一个词。原理正好用上 volatile 的两条语义：

写 release：构造函数的所有写 happens-before 字段写入（之前的访存不会推迟到 volatile 写之后）——保证"发布的一定是构造完的”；
读 acquire：字段读取 happens-before 后续通过该引用的一切访问——保证"看到引用就能看到构造结果"。

C# 语义下这是正确的（ECMA 基线足够）。顺带一提，Java 在 JSR-133 之后 volatile 版 DCL 同样成立（官方 FAQ 明说新模型下"给实例字段加 volatile 能修复双检锁"）；而 Go 官方文档至今把 DCL 列为错误用法，建议改用 sync.Once——同一模式在不同语言的合同下合法性不同，这正是"内存模型是合同"的最好注脚。

版本 3：`static readonly` 与 `Lazy<T>`——为什么过时

《设计模式实战（八）：单例模式》已经给过结论"双检锁过时了"，现在可以说清"过时"的准确含义：不是它错了，是有更省心的。

1
2


// ✅✅ 静态字段：CLR 保证类型初始化的线程安全
public static readonly Singleton Instance = new();

1
2
3


// ✅✅✅ Lazy<T>：显式延迟 + 默认线程安全
private static readonly Lazy<Singleton> _lazy = new(() => new Singleton());
public static Singleton Instance => _lazy.Value;

Lazy<T> 默认使用 ExecutionAndPublication，由运行时负责同步初始化并向其他调用者发布结果。当前运行时源码会使用状态字段和锁协调快路径与初始化路径，但这是实现细节，不是应用代码应复制的合同。工程上直接依赖 Lazy<T> / LazyInitializer 的公开语义，比维护手写双检锁稳妥。

一个案例，三次演进，每一步都是内存模型条款的直接应用。

锁是正确的默认选择，但同步不是免费的。代价主要不在锁指令本身（未争用时一次 lock 只有几十纳秒），而在两个隐蔽的地方。

争用（contention）。锁被别人持有时，你要么自旋烧 CPU，要么挂起——挂起意味着上下文切换（微秒级，见延迟数字篇）加缓存污染。高争用下的锁会从"互斥工具"退化成"排队点"，《.NET 高并发编程全景》里线程安全集合的细粒度锁、无锁队列，都是为了让线程少排队。

False sharing（伪共享）。更隐蔽：两个逻辑上毫无关系的变量，恰好落在同一缓存行（通常 64 字节）里，硬件的一致性协议按缓存行工作，于是两个线程各写各的变量，却让对方的缓存行反复失效——性能损失像是凭空出现的。

1
2
3
4
5
6


// 两个线程各自只碰自己的计数器，看起来毫无共享
class Counters
{
 private long _a; // 相邻字段，大概率同一缓存行
 private long _b; // 线程 2 写 _b → 线程 1 的缓存行失效 → 缓存行在两个核之间弹跳
}

.NET 9 的性能优化文档里 Stephen Toub 给了实测例子：两个逻辑独立的 double 被错误共享后缓存未命中约 3 倍，修复方法是填充（padding）把它们隔开到不同缓存行。工程上的判断顺序：先减少共享（每次请求新建对象、thread-local 状态），真有共享再考虑对齐/填充，最后才是无锁。

八、为什么你的单元测试测不出来

数据竞争最恶心的性质：它是概率性的。竞争窗口可能只有几纳秒，测试环境的线程数、时序、JIT 行为都和生产不同——单测跑一万次全绿，线上偶发一次 mixed value。这类 bug 还具有"观察即扰动"的性质（加日志、断点、调试器都会改变时序让它消失），heisenbug 之名由此而来。

各生态的检测工具现状差距很大：

生态	工具	效果
Go	`go test -race` / `go run -race`（基于 ThreadSanitizer）	插桩后在实际执行覆盖到竞争时报告访问栈；不能证明未覆盖路径没有竞争
C/C++	ThreadSanitizer、Valgrind Helgrind/DRD	前者通常由编译器插桩，后者在动态分析环境中运行；能力和开销不同
Java	OpenJDK jcstress	并发正确性压力测试框架，用大量调度结果验证允许/禁止的观察值，不是通用数据竞争检测器
.NET	无内置等价物（截至 .NET 10）	如实说明：没有 Go 式 `-race` 开关

.NET 这栏值得展开一句：官方 SDK 没有提供 Go 式数据竞争检测开关。开源的 Microsoft Coyote 可以通过重写 IL 和受控调度反复探索并发路径，但它覆盖的是支持和实际建模到的调度点，也不是对任意原生线程竞争的穷举证明。常规工程仍要组合使用压力测试、针对性并发测试和代码评审：检查共享可变状态是否有统一同步策略、锁对象是否一致、复合操作是否由一个原子协议保护。

但比检测更有效的策略是让竞争写不出来——这就到最后一节。

九、边界与取舍：四种并发策略

消灭数据竞争只有两条路：碰同一处就建立同步，或者干脆不碰同一处。工程上展开成四种策略，按"心智负担"排序：

策略	代表工具	保证来源	适用
锁	`lock`、`Monitor`	互斥 + 获取/释放语义	复合操作，默认选择
原子/并发容器	`Interlocked`、`ConcurrentDictionary`	单操作原子性或容器公开的并发合同	计数、状态翻转、缓存结构
不可变	`record`、`ImmutableList`、readonly	值不变则无竞争	配置、快照、值对象
消息传递	`Channel<T>`、actor、Go channel	单线程所有权转移	流水线、生产者-消费者

两个容易问的问题：

“async/await 需要考虑线程安全吗？” 需要，但不能把请求简单等同于线程。一次 async 调用在每个连续代码片段内按程序顺序执行，跨 await 后却可能换线程；多个任务也可能在同一线程上交错。真正的风险仍是多个并发操作共享同一个可变状态——例如 ASP.NET Core singleton 服务的可变字段会被多个请求同时访问。判断时既要检查跨线程的数据竞争，也要检查即使单线程交错仍可能出现的逻辑竞态。

“什么时候可以基本不考虑共享同步？” 状态被限制在单次调用内，且不会通过字段、返回值、回调或任务逃逸给并发执行者时。局部变量这个名字本身并不构成保证：局部引用仍可能指向共享对象；lambda 捕获的局部变量通常会被提升到闭包对象中，闭包一旦被多个任务使用就成为共享状态。每次调用新建对象也只有在对象没有逃逸并被并发共享时才安全。

小结

四层回顾：

硬件层：缓存一致性只保证"值最终正确传播"（SWMR + 无凭空值），store buffer 和失效队列带来重排；x86 只重排 store→load，ARM 四种全来；编译器还叠加一层。硬件的合同是性能，不是你的直觉。
模型层：内存模型是语言替你和底层签的合同，核心是 happens-before；总纲 DRF-SC——没竞争就顺序一致。
语言层：同一道题五种答案——C++ 有竞争就 UB，Java/Go 约束后果，Go 只给最强档还劝你别耍聪明，Rust 让安全代码写不出竞争，.NET 规范弱实现强、按基线写。
工具层：lock 用互斥和获取/释放语义保护临界区，Interlocked 提供单操作原子性与强同步排序，volatile 只提供有限的获取/释放语义且不保护复合操作；64 位类型在规范不保证原子的场景下需要 Interlocked 或锁，延迟初始化优先使用 Lazy<T>。

三句话带走：

内存安全先消灭数据竞争，完整的线程安全还要消灭依赖错误时序的逻辑竞态；
锁的可见性不是魔法，是"解锁 happens-before 加锁"这条合同条款；
在 x86 上能跑不等于正确——按语言的基线合同写，别按硬件的宽容写。

参考资料

硬件与模型：

x86-TSO 形式化模型：Sewell et al., x86-TSO: A Rigorous and Usable Processor Memory Model for x86, CACM 2010 — https://www.cl.cam.ac.uk/~pes20/weakmemory/cacm.pdf
Paul E. McKenney, Memory Barriers: a Hardware View for Software Hackers — http://www.rdrop.com/users/paulmck/scalability/paper/whymb.2010.06.07c.pdf
Nagarajan, Sorin, Hill, Wood, A Primer on Memory Consistency and Cache Coherence（开放获取） — https://link.springer.com/book/10.1007/978-3-031-01764-3
Intel SDM Vol. 3A “Memory Ordering” 章节 — https://www.intel.com/content/www/us/en/developer/articles/technical/intel-sdm.html

.NET：

Igor Ostrovsky, C# Memory Model in Theory and Practice, Part 1（2012） — https://learn.microsoft.com/en-us/archive/msdn-magazine/2012/december/csharp-the-csharp-memory-model-in-theory-and-practice
Igor Ostrovsky, C# Memory Model in Theory and Practice, Part 2（2013） — https://learn.microsoft.com/en-us/archive/msdn-magazine/2013/january/csharp-the-csharp-memory-model-in-theory-and-practice-part-2
Joe Duffy, CLR 2.0 Memory Model（实现模型规则） — https://joeduffyblog.com/2007/11/10/clr-20-memory-model/
Vance Morrison, Understanding Low-Lock Techniques（三层模型） — https://learn.microsoft.com/en-us/archive/msdn-magazine/2005/october/understanding-low-lock-techniques-in-multithreaded-apps
C# 规范 §9.6（原子性） — https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/language-specification/variables
C# 规范 §15.5.4（volatile 字段） — https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/language-specification/classes
volatile 关键字文档（告诫与 64 位限制） — https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/volatile
Interlocked.Read（32 位平台上 64 位读不原子） — https://learn.microsoft.com/en-us/dotnet/api/system.threading.interlocked.read
Lazy<T>（ExecutionAndPublication 与实现源码） — https://learn.microsoft.com/en-us/dotnet/api/system.lazy-1
ConcurrentDictionary.GetOrAdd（工厂可能执行多次） — https://learn.microsoft.com/en-us/dotnet/api/system.collections.concurrent.concurrentdictionary-2.getoradd
Microsoft Coyote（受控并发测试及适用边界） — https://github.com/microsoft/coyote
Stephen Toub, Performance Improvements in .NET 9（false sharing 实测） — https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-9/

其他语言：

Java：JLS ch.17（内存模型） — https://docs.oracle.com/javase/specs/jls/se21/html/jls-17.html ；JSR-133 FAQ — https://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html
OpenJDK jcstress（并发正确性压力测试框架） — https://openjdk.org/projects/code-tools/jcstress/
C++：std::memory_order — https://en.cppreference.com/w/cpp/atomic/memory_order ；标准 [intro.races] — https://eel.is/c++draft/intro.races
Go 内存模型（2022 修订） — https://go.dev/ref/mem
Rust：Send 与 Sync — https://doc.rust-lang.org/nomicon/send-and-sync.html ；数据竞争 — https://doc.rust-lang.org/nomicon/races.html

epoll 的前世今生：从 select/poll 的性能困局到 io_uring 的挑战

Sat, 28 Feb 2026 10:00:00 +0800

epoll 是 Linux 高并发网络编程的重要基础。Nginx、Redis 以及多种语言运行时或事件库在 Linux 上通常会使用 epoll；具体后端仍取决于版本、构建选项和运行环境。很多人把 epoll 简单理解成“支持更多连接的 select”，但两者管理兴趣集和交付就绪事件的方式不同。

这个理解是错的。epoll 不是改良，是一次模型换轨。

select/poll 每次调用都提交整个 fd 集合，并由内核检查；epoll 则把兴趣集保留在内核，在就绪状态变化时把对象加入就绪集合。epoll_wait 的返回成本主要随本次交付的事件数增长，但注册、回调、锁竞争和拷贝仍有成本，不能把整个 epoll 路径概括成严格的 O(1)。

本文从 select 的诞生讲起，把这条演进线（select → poll → kqueue → epoll → io_uring）串起来，再钻进 epoll 内核实现（红黑树、就绪链表、回调链路）、LT/ET 的本质、标志位的演进史，最后聊聊 io_uring 这位新挑战者。前序的 I/O 模型全解和 Reactor 模式讲过宏观定位，这里把 epoll 这一环彻底拆透。

一、故事的起点：一个线程伺候一个连接

在多路复用出现之前，高并发服务器长这样：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


Apache prefork / thread-per-connection 模型：

 主线程 accept() → 拿到一个连接
 ↓
 fork() 一个子进程（或 new 一个线程）
 ↓
 子线程: read() → process() → write()
 （阻塞在这个连接上，直到客户端断开）

 1 个连接 = 1 个线程/进程 全程占用

这套模型在连接数几百时没毛病，代码也最直观。但到了 1999 年，互联网开始膨胀，Dan Kegel 在他那篇著名的 The C10K problem 里把窗户纸捅破了：一台机器要同时扛 1 万个连接，怎么办？

1
2
3
4
5
6
7
8


若某运行时为每线程保留 8 MiB 栈 → 1 万个线程会保留约 78 GiB 虚拟地址空间
 （32 位时代直接撞 4GB 地址墙——C10K 在 2000 年前后成为问题就是这个背景）
1 万个线程频繁切换 → CPU 全耗在 context switch
而且这 1 万个连接 99% 时间都在"等数据"（keep-alive、长轮询、聊天）
 → 1 万个线程傻等，CPU 空转

 结论：在当年的 32 位硬件与线程实现下，thread-per-connection 很难经济地处理 C10K
 现代线程栈、调度器和硬件已经变化，是否可行仍要实测

破局的关键不是"更多线程"，而是"一个线程同时等很多 fd，谁有数据就处理谁"——这就是 I/O 多路复用（I/O multiplexing）。第一个吃螃蟹的，是 1983 年的 select。

二、第一代多路复用：select（1983，4.2BSD）

select 是 BSD UNIX 在 4.2BSD（1983）引入的，思路是：把"我关心的 fd"打包成三组位图，一次性扔给内核，让内核帮你看哪些就绪。

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


#include <sys/select.h>

fd_set readfds;
FD_ZERO(&readfds);
FD_SET(fd1, &readfds);
FD_SET(fd2, &readfds);
// ... 最多 FD_SETSIZE 个

struct timeval tv = { .tv_sec = 5 };
int n = select(maxfd + 1, &readfds, NULL, NULL, &tv);
// ↑ ↑ ↑ ↑
// 读集合 写集 异常集 超时

if (n > 0) {
 for (int fd = 0; fd <= maxfd; fd++) {
 if (FD_ISSET(fd, &readfds)) {
 // fd 就绪，去 read
 }
 }
}

1
2
3
4
5
6
7
8
9


select 的工作流程：

 1. 应用把 3 个 fd_set（读/写/异常）从用户空间拷贝到内核
 2. 内核遍历所有 fd，挨个检查是否就绪，标记到 fd_set 里
 3. 内核把标记后的 fd_set 拷回用户空间
 4. 应用再遍历一遍 fd_set，找出哪些被标记了
 5. 对就绪的 fd 调 read/write

 → 每次调用都重复 1-4 整个流程

select 解决了"一个线程等多个 fd"的问题，功不可没。但它有四个硬伤，每一个都在 C10K 面前致命：

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


硬伤 1：fd_set 容量受 FD_SETSIZE 限制
 glibc 等常见实现中 FD_SETSIZE 通常为 1024，fd_set 是固定位图
 → 把大于等于 FD_SETSIZE 的 fd 交给 FD_SET/select 会越界或产生未定义行为
 → 这不是简单修改内核参数就能安全突破的运行时上限

硬伤 2：每次调用都要传"全部 fd"
 三组 fd_set 在用户↔内核之间来回拷贝
 1 万个 fd 的位图约 1.2 KB，每次 select 都拷两次
 → 连接越多，单次调用越慢

硬伤 3：内核线性扫描 O(n)
 内核要把所有 fd 走一遍查就绪状态
 1 万个 fd 里只有 10 个就绪 → 也要扫 1 万次
 → 浪费的 CPU 与活跃连接数无关，与总连接数成正比

硬伤 4：返回后用户还得再扫一遍 O(n)
 select 只告诉你"有 n 个就绪"，不告诉你哪几个
 你得 FD_ISSET(fd) 从 0 遍历到 maxfd 把就绪的挑出来
 → 第二次 O(n)

1
2


一句话：select 的复杂度是 O(n)，而且 n 是"总连接数"不是"活跃连接数"。
 连接越多越慢，哪怕它们都闲着。

select 不是没救——在连接数少、活跃率高的场景（比如几十个 fd 全都很忙），它简单够用，至今还在用。但 C10K 这种"海量连接、大多空闲"的场景，它扛不住。

三、poll：去掉了 1024，但没去根

poll 是 System V 的产物（SVR3，约 1986），思路和 select 一样，只是换了数据结构：用数组代替位图，每个元素是 struct pollfd。

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


#include <poll.h>

struct pollfd fds[10000];
fds[0].fd = fd1; fds[0].events = POLLIN;
fds[1].fd = fd2; fds[1].events = POLLIN;
// ...

int n = poll(fds, 10000, 5000); // 5000ms 超时
for (int i = 0; i < 10000; i++) {
 if (fds[i].revents & POLLIN) {
 // fds[i].fd 就绪
 }
}

1
2
3
4


poll 相比 select 的改进：
 ✓ 用数组代替位图 → 没有 1024 上限，想多少传多少
 ✓ events/revents 分离 → 不用每次重建"输入"（revents 由内核写，events 不变）
 ✓ 语义更清晰（POLLIN/POLLOUT/POLLERR...）

但 select 的后三个硬伤，poll 一个都没解决：

1
2
3


硬伤 2 仍在：每次调用还是传"全部 fd"（整个 pollfd 数组用户↔内核拷贝）
硬伤 3 仍在：内核还是线性扫描所有 fd O(n)
硬伤 4 仍在：返回后用户还是得遍历整个数组找 revents

1
2


poll 解决的是"数量"问题，没解决"性能"问题。
1 万个连接里只有 10 个活跃？poll 照样每次扫 1 万个。

为什么 poll 没能根治？因为它的模型没变——仍然是"每次调用都把全集扔给内核线性扫"。只要模型是"轮询全集"，复杂度就永远是 O(总连接数)。真正要破 C10K，得换模型。

四、同时代的另一条路：kqueue 与 /dev/poll

Linux 不是唯一被 C10K 逼着想办法的系统。90 年代末到 2000 年初，几条路同时在试：

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


FreeBSD kqueue（2000，4.1-RELEASE）：
 - 不仅告诉你"谁就绪"，还告诉你"发生了什么变化"
 - kevent 结构 + 一次 kevent() 调用既可注册又可取事件
 - 支持 filter（读/写/信号/定时器/子进程...）统一抽象
 - 思路接近"边缘触发"——返回的是"变化"而非"当前状态"
 - 业界公认设计比 epoll 优雅

Solaris /dev/poll（约 1998）：
 - 写一次"兴趣集"到一个特殊设备，内核常驻
 - 后续 poll 只查"就绪"，不用重传全集
 - 第一个把"兴趣集常驻内核"落地的方案

Linux 早期的失败尝试：realtime signals + SIGIO
 - fd 就绪时内核发实时信号
 - 信号队列会溢出（OOM 时丢事件）
 - 信号乱序、合并，无法可靠对应到具体 fd
 - 实践证明不可靠，被放弃

这几条路给出了同一个关键启发：把"我关心哪些 fd"这个状态常驻内核，别每次重传；就绪事件让内核主动通知，别让应用轮询。 Linux 吸收了这些思路，做出了 epoll。

五、epoll 登场（Linux 2.5.44，2002）

epoll 在 2002 年 10 月进入 Linux 2.5.44，2003 年底随 2.6 稳定。API 三个，干净利落：

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


#include <sys/epoll.h>

// 1. 创建一个 epoll 实例（内核里建好数据结构）
int epfd = epoll_create1(0);

// 2. 注册/修改/删除关心的 fd（状态常驻内核）
struct epoll_event ev = { .events = EPOLLIN, .data.fd = fd };
epoll_ctl(epfd, EPOLL_CTL_ADD, fd, &ev); // ADD / MOD / DEL

// 3. 等待就绪（只返回就绪的 fd）
struct epoll_event events[128];
int n = epoll_wait(epfd, events, 128, -1); // -1 = 阻塞
for (int i = 0; i < n; i++) {
 handle(events[i].data.fd); // events 里全是就绪的
}

表面看和 select/poll 差不多，但内核里的机制完全不同。epoll 的三大核心创新：

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


创新 1：兴趣集常驻内核（不再每次重传）
 epoll_ctl ADD 时，fd 被记进内核的"兴趣集"（一棵红黑树）
 后续 epoll_wait 不用再传全集，只传一个输出数组
 → 硬伤 2 消除：没有全集的用户↔内核拷贝

创新 2：就绪靠回调维护，不在每次等待时扫描全部兴趣集
 注册 fd 时，内核在它的等待队列上挂一个回调（ep_poll_callback）
 数据到达时，驱动触发回调，把这个 fd 主动塞进"就绪链表"
 epoll_wait 只需把就绪链表里的元素拷给用户
 → 硬伤 3 消除：不再线性扫描全集，复杂度 O(就绪数)

创新 3：返回的就是就绪的（不用再扫）
 events[] 数组里前 n 个全是就绪 fd，直接用
 → 硬伤 4 消除：不需要 FD_ISSET 二次遍历

1
2
3
4
5
6
7
8


对比一眼就懂：

 select/poll：每次 select() → 内核扫 N 个 fd → 返回 → 用户再扫 N 个找就绪
 复杂度 O(N)，N = 总连接数

 epoll： epoll_ctl ADD（一次性）→ 内核挂回调
 epoll_wait() → 内核把"被回调塞进链表"的就绪 fd 拷给你
 复杂度 O(就绪数)，与总连接数无关

这就是 epoll 适合“大量注册、少量就绪”负载的重要原因：等待时无需每次线性检查全部兴趣集。不过总连接数仍会影响内核内存、epoll_ctl、fd 表、socket 缓冲区和缓存局部性，不能说与总连接数无关。

六、钻进内核：红黑树、就绪链表与回调链路

光说"回调"太虚。来看 epoll 在内核里到底长什么样。核心是 struct eventpoll（在 fs/eventpoll.c）：

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


struct eventpoll（简化）：
 ┌─────────────────────────────────────────────┐
 │ rbr : 红黑树根 —— 兴趣集（所有注册的 fd）│
 │ rdllist : 双向链表 —— 就绪链表（已就绪的 fd）│
 │ wq : 等待队列 —— epoll_wait 在此睡眠 │
 │ ovflist : 溢出链表（遍历 rdllist 期间的暂存）│
 └─────────────────────────────────────────────┘

每个注册的 fd 对应一个 struct epitem：
 - rb_node：挂在 rbr 红黑树上（按 fd 排序，去重）
 - rdllist_node：就绪时挂在 rdllist 链表上
 - ffd：指向 file + fd
 - event：关心的事件（EPOLLIN/OUT/ET...）
 - 注册时在 file 的等待队列上挂了 ep_poll_callback

1
2
3
4


为什么兴趣集用红黑树？
 - epoll_ctl ADD/MOD/DEL 要按 fd 查找/增删 → 红黑树 O(log n)，自平衡、按 fd 有序、天然去重
 - 不用数组：fd 值可能很大（几万甚至十几万），按 fd 直接建数组会浪费巨量空间
 - 当前实现使用内核的红黑树结构获得稳定的对数级查找；为什么没有选择其他结构属于实现权衡，不应只归因于某一个性能指标

完整的数据到达链路（这是 epoll 的灵魂）：

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


 ① 网卡收到数据包 → DMA 写入 ring buffer → 触发硬件中断
 ↓
 ② 中断处理（NAPI）→ 软中断 NET_RX_SOFTIRQ
 ↓
 ③ 协议栈处理 → 数据挂到 socket 的接收队列
 ↓
 ④ sock_def_readable() → 唤醒 socket 的等待队列
 ↓
 ⑤ 等待队列上有 epoll 挂的 ep_poll_callback → 触发回调
 ↓
 ⑥ ep_poll_callback 把这个 fd 的 epitem 挂到 eventpoll->rdllist
 ↓
 ⑦ 唤醒在 eventpoll->wq 上睡眠的 epoll_wait
 ↓
 ⑧ epoll_wait 醒来 → 把 rdllist 里的就绪事件拷到用户 events[]

1
2
3
4


关键洞察：
 - "fd 是否就绪"这个判断，是由数据到达时的回调"推"出来的，不是 epoll_wait 主动"拉"的
 - 所以 epoll_wait 的开销只取决于"有多少 fd 就绪"，与"注册了多少 fd"无关
 - 这是从"轮询"到"事件驱动"的范式转换——和 select/poll 的本质区别就在这一步

1
2
3
4
5
6
7


epoll_wait 内部的小细节：
 - 进 epoll_wait 时先看 rdllist 非空？有就拷给用户（最多 maxevents 个）
 - 空就睡到 wq 上，等回调唤醒
 - 拷出去的 epitem：
 LT 模式：如果拷完发现还就绪（数据没读完），留在 rdllist 里下次还返回
 ET 模式：拷出去就从 rdllist 摘掉，只有"下次有新数据"才重新挂回
 - ovflist：防止"遍历 rdllist 拷给用户"期间又有新就绪 fd 来插队丢事件

七、LT vs ET：两种触发模式，两种哲学

epoll 最容易被用错的地方，是 水平触发（LT） 和 边缘触发（ET） 的选择。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


LT（Level Triggered，默认）：
 只要 fd 上"还有数据没读完"，每次 epoll_wait 都会返回它
 类似 select/poll 的语义
 → 你读一点、剩一点，下次还会通知你

ET（Edge Triggered，EPOLLET）：
 只在 fd "状态变化"时通知一次（从无数据到有数据）
 通知之后你必须一口气把数据读完（读到 EAGAIN）
 否则剩下的数据再也不会通知你 → 数据饥饿
 → 类似"边沿触发"的电路：只在跳变时反应

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


场景：socket 一次到达 4 KB 数据，你的 buf 只有 1 KB

 LT：
 epoll_wait 返回 fd → read 1KB → 剩 3KB
 下次 epoll_wait → 还会返回这个 fd → 再 read 1KB
 ... 直到读完

 ET：
 epoll_wait 返回 fd 一次 → read 1KB → 剩 3KB
 下次 epoll_wait → 不再返回这个 fd（没有"新"数据到达）
 → 那 3KB 可能一直留在接收缓冲区，直到新的状态变化或应用再次主动读取
 → 数据饥饿 / 对端以为你收到了

ET 的纪律（违反任何一条都会出 bug）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


1. fd 必须设为非阻塞（O_NONBLOCK）
 ET 下你要循环 read 到 EAGAIN，阻塞 fd 会在数据读完时卡死整个线程

2. read/write 必须循环到返回 EAGAIN/EWOULDBLOCK
 一次没读完 = 下次没通知 = 数据丢

3. accept 也要循环到 EAGAIN
 listen fd 在 ET 模式下，一次只 accept 一个会导致后续连接排队甚至被拒绝

4. 收到 EAGAIN 不是错误，是"本轮读完了"的正常信号

为什么 ET 理论上更快？

1
2
3
4
5
6
7
8


LT：数据没读完，每次 epoll_wait 都返回 → 可能很多次唤醒
ET：一次跳变只通知一次 → 减少 epoll_wait 的返回次数和用户态↔内核态切换

 一个慢消费者（4KB 数据，每次 read 1KB）：
 LT：4 次 epoll_wait 返回 + 4 次 read
 ET：1 次 epoll_wait 返回 + 4 次循环 read（在用户态连读）

 → ET 把"读完"的循环放在用户态，少了内核唤醒的开销

但 ET 更难写对。生产实践：

1
2
3
4
5
6


谁用 ET：nginx（ET + 多 worker，榨干性能）、早期高性能网络库
谁用 LT：Redis（单线程 LT，简单可靠）、Java NIO 默认、大多数业务服务
 → LT 行为接近 select/poll，迁移成本低，不容易出 bug

 教训：除非你清楚知道为什么需要 ET，否则用默认 LT。
 ET 的性能优势在大多数业务场景被"代码复杂度 + bug 风险"抵消。

八、epoll 的演进史：API 与标志位

epoll 不是一蹴而就的，它自己也在长。每个新标志位都对应一个真实痛点。

 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


2002 Linux 2.5.44 epoll 初登场
 epoll_create(size) / epoll_ctl / epoll_wait
 （size 参数其实没用，内核动态扩展，留着只是兼容）

2003 Linux 2.6 稳定
 EPOLLET（边缘触发）

2007 Linux 2.6.22 signalfd / timerfd / eventfd
 "一切皆文件描述符"——信号、定时器、事件都能变成 fd
 → 可以统一塞进 epoll，一个 wait 等所有事件源
 （timerfd 2.6.25 补齐）

2008 Linux 2.6.27 epoll_create1(flags)
 + EPOLL_CLOEXEC（fork+exec 时不泄漏 fd）
 → 废弃 size 参数，更干净
 + epoll_pwait（2.6.19 引入，可指定信号屏蔽，原子地"等+改屏蔽"）

2003 Linux 2.6 EPOLLONESHOT
 一个 fd 被通知一次后自动禁用，直到 EPOLL_CTL_MOD 重新 arm
 → 线程池场景：保证一个 fd 同一时刻只被一个工作线程处理
 （避免两个线程同时 read 同一个 fd 的竞态）

2016 Linux 4.5 EPOLLEXCLUSIVE
 多个 epoll 实例监听同一个 fd 时，减少以 exclusive 方式等待者的唤醒数量
 → 解决"惊群"（thundering herd）：一个连接到来，N 个 worker 全被唤醒
 抢同一个 accept，N-1 个白跑

1
2
3
4
5


演进脉络能看出 epoll 的设计取向：
 ① 把更多事件源（信号/定时器）统一成 fd → 一个 epoll 管所有
 ② 减少多线程下的竞争（ONESHOT / EXCLUSIVE）
 ③ API 清理化（create1 废弃无用参数）
 → 朝"统一、可扩展、低竞争"走，但本质模型（就绪通知）没变

九、实战：一个 epoll echo server

把前面所有概念落成一个能跑的程序。LT 版（默认，推荐起步）：

 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
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90


#define _GNU_SOURCE
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <errno.h>
#include <sys/epoll.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <fcntl.h>
#include <arpa/inet.h>

#define PORT 9000
#define MAX_EVENTS 1024
#define BUF_SIZE 1024

static int set_nonblocking(int fd) {
 int flags = fcntl(fd, F_GETFL, 0);
 if (flags == -1) return -1;
 return fcntl(fd, F_SETFL, flags | O_NONBLOCK);
}

int main(void) {
 /* 1. listening socket */
 int lfd = socket(AF_INET, SOCK_STREAM, 0);
 int opt = 1;
 setsockopt(lfd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt));
 set_nonblocking(lfd);

 struct sockaddr_in addr = {0};
 addr.sin_family = AF_INET;
 addr.sin_addr.s_addr = INADDR_ANY;
 addr.sin_port = htons(PORT);
 bind(lfd, (struct sockaddr *)&addr, sizeof(addr));
 listen(lfd, SOMAXCONN);

 /* 2. epoll 实例 + 注册 listen fd */
 int epfd = epoll_create1(0);
 struct epoll_event ev = {0};
 ev.events = EPOLLIN; /* LT（默认） */
 ev.data.fd = lfd;
 epoll_ctl(epfd, EPOLL_CTL_ADD, lfd, &ev);

 struct epoll_event events[MAX_EVENTS];
 char buf[BUF_SIZE];
 printf("listening on %d (epoll, LT)\n", PORT);

 /* 3. 事件循环 */
 for (;;) {
 int n = epoll_wait(epfd, events, MAX_EVENTS, -1);
 for (int i = 0; i < n; i++) {
 int fd = events[i].data.fd;

 if (fd == lfd) {
 /* 新连接：循环 accept 到 EAGAIN（LT 下其实 accept 一次也行，循环更稳） */
 for (;;) {
 int cfd = accept(lfd, NULL, NULL);
 if (cfd < 0) {
 if (errno == EAGAIN || errno == EWOULDBLOCK) break;
 perror("accept"); break;
 }
 set_nonblocking(cfd);
 ev.events = EPOLLIN;
 ev.data.fd = cfd;
 epoll_ctl(epfd, EPOLL_CTL_ADD, cfd, &ev);
 }
 } else {
 /* 已连接 fd：循环读到 EAGAIN（LT 下推荐，ET 下必须） */
 for (;;) {
 ssize_t r = read(fd, buf, sizeof(buf));
 if (r > 0) {
 /* 教学简化：生产代码必须处理 partial write、EAGAIN，并按需监听 EPOLLOUT */
 if (write(fd, buf, r) < 0 && errno != EAGAIN && errno != EWOULDBLOCK)
 perror("write");
 } else if (r == 0) {
 /* 对端关闭 */
 epoll_ctl(epfd, EPOLL_CTL_DEL, fd, NULL);
 close(fd);
 break;
 } else {
 if (errno == EAGAIN || errno == EWOULDBLOCK) break;
 epoll_ctl(epfd, EPOLL_CTL_DEL, fd, NULL);
 close(fd);
 break;
 }
 }
 }
 }
 }
}

1
2
3
4
5
6
7


关键点：
 - listen fd 和 conn fd 都设 O_NONBLOCK
 （epoll 高并发下阻塞 fd 会卡死整个事件循环）
 - accept / read 都循环到 EAGAIN
 LT 下这是"推荐"，ET 下这是"必须"
 - 对端关闭（read 返回 0）或出错时 EPOLL_CTL_DEL + close
 （不 DEL 直接 close 也行，内核会自动清理；但显式 DEL 更清晰）

注册为 ET 需要改两处标志位，但完整 ET 服务还要正确处理写缓冲：

1
2
3
4
5


// listen fd 注册：加 EPOLLET
ev.events = EPOLLIN | EPOLLET;

// conn fd 注册：加 EPOLLET
ev.events = EPOLLIN | EPOLLET;

1
2
3
4
5
6


ET 版的硬性要求（上面代码已满足）：
 ✓ fd 非阻塞（已 set_nonblocking）
 ✓ accept 循环到 EAGAIN（已循环）
 ✓ read 循环到 EAGAIN（已循环）
 注意：上面的 echo 示例明确简化了 partial write。生产 ET 代码需要保存未写完的数据，
 在 socket 可写时继续发送，并动态管理 EPOLLOUT；不能只加 EPOLLET 就宣称迁移完成。

十、epoll 的陷阱与坑

坑 1：ET 模式不读到 EAGAIN → 数据饥饿

1
2
3
4
5
6
7


ET 下 read 一次就返回，没读干净
 → 剩下的数据卡在内核缓冲区
 → 没有新的"跳变"，epoll_wait 不再通知
 → 对端以为你收到了，业务层丢数据

 根因：误把 ET 当 LT 用
 修复：ET 下必须循环 read 到 EAGAIN（见上一节的代码）

坑 2：ET 下忘了设 O_NONBLOCK → 线程卡死

1
2
3
4
5
6
7


ET + 阻塞 fd：
 循环 read，最后数据读完时 read 不返回 EAGAIN，而是阻塞
 → 整个事件循环线程挂在一个 fd 上
 → 其他所有连接全部卡死

 根因：ET 的"循环到 EAGAIN"前提是 fd 非阻塞
 修复：epoll 注册的 fd 一律 O_NONBLOCK，无例外

坑 3：accept 惊群 → EPOLLEXCLUSIVE

1
2
3
4
5
6
7
8
9


多个 worker 进程/线程各自 epoll_wait 同一个 listen fd
 新连接到达 → 所有 worker 被唤醒
 只有一个 accept 成功，其余 accept 返回 EAGAIN
 → N-1 个 worker 白醒一次，context switch 浪费

 修复：Linux 4.5+ 给 listen fd 注册时加 EPOLLEXCLUSIVE
 ev.events = EPOLLIN | EPOLLEXCLUSIVE;
 内核会从以 exclusive 方式等待的集合中唤醒一个或较少数量的 waiter；
 与非 exclusive 注册混用时还要按 epoll(7) 的语义分析

坑 4：EPOLLONESHOT 用完不重新 arm → fd 失联

1
2
3
4
5
6
7


ONESHOT 模式：fd 通知一次后自动禁用
 worker 处理完必须 EPOLL_CTL_MOD 重新 arm，否则这个 fd 再也不会有事件
 → 连接"假死"

 适合：线程池模型，保证一个 fd 同一时间只被一个线程碰
 代价：每次处理完多一次 epoll_ctl 系统调用
 陷阱：处理中途异常退出没 arm → fd 保持禁用

坑 5：大量短连接不适合 epoll

1
2
3
4
5
6
7
8


epoll_ctl ADD/DEL 不是免费的：
 - ADD 要建 epitem、插红黑树、在 file 等待队列挂回调
 - DEL 要拆回调、从树里删
 短连接频繁建断 → epoll_ctl 开销可能超过收益

 对比：极低并发 + 短连接，select 反而最简单够用
 实践：nginx 用连接池 + 长连接，避免频繁 ADD/DEL
 短连接密集的场景考虑连接复用或上游加 keepalive

坑 6：fork 后 epoll fd 的继承

1
2
3
4
5
6


fork() 后子进程继承 epoll fd（指向同一个内核 eventpoll）
 但通常你不想父子进程同时 epoll_wait 同一个 epfd
 → `EPOLL_CLOEXEC` 只控制 exec 时关闭，不阻止 fork 继承；通常应使用
 epoll_create1(EPOLL_CLOEXEC) 防止执行新程序时泄漏，并明确设计 fork 后谁负责等待

 陷阱：多进程共享 epfd 的语义复杂，一般每进程一个 epfd 更清晰

十一、谁在用 epoll（后端视角）

 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


nginx
 ET + 多 worker（每 worker 一个 epfd）
 经典的 Reactor：主 worker epoll_wait → 就绪后非阻塞处理
 → 高并发静态/代理的标杆

Redis
 单线程 + epoll（LT）
 6.0 引入多线程 IO，仍是 epoll 驱动，只是把 read/write 分摊到 IO 线程
 → LT 足够，简单可靠优先

Go runtime netpoller
 runtime 把 epoll 封装成"同步接口 + goroutine 调度"
 你写 conn.Read() 看起来是阻塞的，底层 goroutine 在 epoll_wait 上 park
 fd 就绪时 runtime 唤醒对应 goroutine
 → "同步写法、异步底层"，epoll 是 Go 网络的隐藏地基

Java NIO Selector
 Linux 上 SelectorProvider 默认用 epoll
 Netty 在此之上做 Reactor/多线程

Node.js libuv
 Linux 后端就是 epoll（封装成事件循环）

.NET Kestrel（Linux）
 SocketAsyncEventArgs 在 Linux 上映射到 epoll
 → 你写的 async network 代码，到了 Linux 就是 epoll

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


后端工程师的现实：
 你写 await httpClient.GetAsync(...) / go conn.Read() / channel.send()
 ↓
 框架/runtime 把它翻译成 epoll 注册 + 等待
 ↓
 Linux 内核用回调把就绪 fd 推上来

 → epoll 是你所有"高并发网络代码"在 Linux 上的共同底层
 哪怕你从不直接调 epoll API，理解它也能解释你遇到的
 "连接数上不去""CPU 被 epoll_wait 吃了""ET 丢数据"等问题

十二、终章：io_uring 的挑战（2019，Linux 5.1）

epoll 至今仍是主流，但它有一个根本性的局限：它只告诉你"就绪"，不替你干活。

1
2
3
4
5
6
7


epoll 的模型：就绪通知（readiness notification）
 epoll_wait → "fd 可读了" → 你自己调 read() → 阻塞/拷贝
 → 阶段1（等数据）交给内核，阶段2（拷贝）还是你自己干
 → 仍是"同步 I/O"（详见 [I/O 模型全解](../internals/01-io-models/)）

 每次就绪后还要一次 read() 系统调用 → 用户态↔内核态切换
 高 QPS 下系统调用本身就是开销

2019 年，Jens Axboe（Linux 块层维护者）在 Linux 5.1 引入 io_uring，这是一次更大的换轨：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


io_uring 的模型：完成通知（completion notification）
 - 两个共享内存环形缓冲：SQ（提交队列）+ CQ（完成队列）
 - 你往 SQ 塞一个"读请求"（SQE）→ 内核自己去等数据 + 拷贝
 - 完成后内核往 CQ 塞一个"完成结果"（CQE）
 → 阶段1 + 阶段2 全由内核完成，真正的异步 I/O

 杀手锏：
 ① 共享内存 → SQE/CQE 不走系统调用拷贝
 ② 批量提交 → 一次 syscall 提交一摞请求
 ③ 可选 sqpoll → 内核常驻一个线程轮询 SQ，连提交 syscall 都省了

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


epoll vs io_uring：

 维度 epoll io_uring
 ─────────────────────────────────────────────────────────
 模型 就绪通知（你再去 read） 完成通知（内核替你 read）
 真/伪异步 伪（拷贝阶段自己做） 真
 系统调用数 每次就绪后还要 read() 可批量、可零（sqpoll）
 数据拷贝 每次系统调用拷贝 共享内存环形缓冲
 复杂度 简单，API 三个 复杂，SQE/CQE/注册/缓冲管理
 生态成熟度 20 年，绝对主流 2019 起，快速演进中

但 io_uring 的路并不平坦。2023–2024 年，Google 安全团队接连披露多个通过 io_uring 触发的内核提权漏洞，导致：

1
2
3
4
5
6
7


2024 安全风波：
 - io_uring 的攻击面大（内核里加了太多代码、与各种子系统交互）
 - Google 在 Android / ChromeOS 默认关闭 io_uring
 - systemd、部分发行版讨论默认禁用
 - 5.x→6.x 期间多次收紧 io_uring 权限（io_uring_disabled sysctl）

 → io_uring 性能极强，但"是否默认可用"成了新的不确定性

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


epoll 会不会被 io_uring 取代？
 短期不会：
 - epoll 简单、稳定、20 年生态，几乎所有运行时都依赖它
 - io_uring 复杂、API 仍在演进、安全争议未平
 - 对绝大多数应用，epoll + 非阻塞 I/O 已经足够快

 长期看：
 - 极致吞吐（存储、数据库、超高 QPS 网关）会逐步倒向 io_uring
 - 新运行时（如 Rust 的 tokio-uring、Go 的实验性 io_uring 支持）在试水
 - 但 epoll 作为"默认通用方案"的地位，十年内不动摇

 → 类比：io_uring 之于 epoll，像 epoll 之于 select——新方案更优，但老方案不会消失

十三、小结

从 1983 年的 select 到 2019 年的 io_uring，Linux I/O 多路复用走了 40 年。主线只有一条：从"轮询全集"到"回调通知"，从"就绪通知"到"完成通知"——每一次换轨都是把更多工作下沉到内核、减少用户态的无效扫描和系统调用。

select（1983）：位图 + 三组 fd_set，1024 上限，O(n) 双重扫描，每次重传全集
poll（1986）：数组去 1024，但模型没变，仍是 O(n) 全集轮询
epoll（2002）：兴趣集常驻内核 + 回调维护就绪集合，等待交付成本主要随就绪事件数增长
epoll 内核机制：epoll_ctl 挂回调 → 数据到达触发 ep_poll_callback → 入 rdllist → epoll_wait 取件
LT vs ET：LT 重复通知（像 select），ET 只通知跳变一次（必须读到 EAGAIN）
标志位演进：EPOLLET / EPOLLONESHOT（线程池）/ EPOLLEXCLUSIVE（防惊群）/ signalfd·timerfd·eventfd（统一事件源）
实战坑：ET 不耗尽本轮 I/O 会饥饿、忘 O_NONBLOCK 会卡死、短连接会增加注册成本、ONESHOT 不 rearm 会失联
生态：nginx、Redis 和多种运行时在常见 Linux 配置下使用 epoll，但后端取决于具体版本与环境
io_uring（2019）：完成通知 + 共享环 + 批量，是 epoll 的挑战者，但简单可靠的 epoll 仍长期主流

1
2
3
4


记住三句话：
 1. epoll 的本质是把兴趣集常驻内核并维护就绪集合，避免每次等待都扫描全部注册 fd
 2. LT 像电平（有数据就一直通知），ET 像边沿（跳变才通知一次）——ET 必须读到 EAGAIN，否则饥饿
 3. epoll 只告诉你"就绪"，io_uring 替你"完成"——前者是现在的地基，后者是未来的方向

下次看到 epoll_wait 占 CPU、连接数上不去、或者纠结 ET/LT，回头看这条演进线，问题多半能对上号。和本站的 Reactor 模式、零拷贝配起来读，Linux 高并发网络的全貌就齐了。

WinForms 学习笔记（六）：线程与 async——UI 线程、Invoke 与死锁

Sun, 22 Feb 2026 10:00:00 +0800

写在前面

承接篇5。本篇讲 WinForms 的线程模型：UI 线程、跨线程访问的坑、Control.Invoke、async/await，以及经典死锁。

WinForms 是单 UI 线程 架构：所有控件操作必须在创建它们的那个线程（UI 线程）。后台线程碰控件会抛 InvalidOperationException。理解线程模型 + async，才能做"后台加载不卡 UI"和"不被死锁咬到"。

本篇的死锁部分，和本站「.NET 高并发编程全景」的 async 死锁节是同一套机制——WinForms 的 WindowsFormsSynchronizationContext 正是死锁三宿主之一。

一、单 UI 线程模型

1
2
3
4
5


WinForms 线程模型：
 - 主线程 = UI 线程，跑消息循环（Application.Run）
 - 所有控件由 UI 线程创建，只能由 UI 线程访问
 - 耗时操作放 UI 线程 → 界面卡死（消息循环阻塞）
 - 后台线程碰控件 → InvalidOperationException

1
2
3
4
5
6


// 错：后台线程直接改控件
Task.Run(() =>
{
 Thread.Sleep(2000);
 button1.Text = "Done"; // 💥 InvalidOperationException：跨线程访问
});

异常信息：“跨线程操作无效：控件 ‘button1’ 从不是创建它的线程访问它。”

这是 WinForms 的线程亲和：控件绑定创建线程。和 WPF 的 Dispatcher 同理，只是 WPF 报错更友好、WinForms 默认在 Debug 抛 / Release 可能不抛（行为不可预期，别赌）。

二、Control.Invoke / BeginInvoke：回到 UI 线程

后台线程要改控件，把操作投递回 UI 线程 执行：Control.Invoke（同步）/ BeginInvoke（异步）。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


// 后台线程把 UI 更新投递回 UI 线程
Task.Run(() =>
{
 var data = DownloadSlowly(); // 后台跑
 button1.BeginInvoke((Action)(() => // .NET 8：显式转成 Action
 {
 button1.Text = "Done";
 textBox1.Text = data; // 在 UI 线程访问控件，安全
 }));
});

1
2
3
4
5
6


Invoke vs BeginInvoke：
 Invoke 同步：投递 + 等 UI 线程执行完才返回（后台线程阻塞）
 BeginInvoke 异步：投递 + 立即返回（后台线程继续）

 → 绝大多数场景用 BeginInvoke（不阻塞后台线程）
 → Invoke 慎用：后台线程等 UI 线程，UI 线程若也卡 → 死锁

InvokeRequired 属性判断当前是否不在 UI 线程（线程安全的控件更新套路：if InvokeRequired → BeginInvoke 转发）。

本系列以 .NET 8 为基线，因此上例要显式转成 Action。.NET 9 起可使用返回可等待结果的 Control.InvokeAsync，它更容易与 async/await 组合，也不会像同步 Invoke 那样阻塞调用线程。

三、async/await：现代写法

.NET 4.5+ 的 async/await 大幅简化：await 后的代码自动回到 UI 线程（因为 WindowsFormsSynchronizationContext），不用手写 Invoke。

1
2
3
4
5
6
7
8


private async void btnLoad_Click(object sender, EventArgs e)
{
 btnLoad.Enabled = false;
 var data = await Task.Run(() => DownloadSlowly()); // 后台跑
 // await 之后自动回到 UI 线程：
 textBox1.Text = data; // 安全，不用 Invoke
 btnLoad.Enabled = true;
}

1
2
3
4
5


async/await 的妙处：
 - 写起来像同步（顺序代码），实际异步
 - await 处释放 UI 线程（不卡）
 - await 之后由 SyncContext 自动续接到 UI 线程
 - 不用手写 Invoke/BeginInvoke

async void 仅用于事件处理器（btnLoad_Click）。其他地方用 async Task。async void 的坑：异常无法被调用方 await、不可控。

四、WindowsFormsSynchronizationContext：为什么 await 回 UI 线程

WinForms 在 Application.Run 时安装 WindowsFormsSynchronizationContext，它把 Post（投递延续）实现为"塞进 UI 消息队列"。await 默认捕获当前 SyncContext，延续 Post 回它 → 回到 UI 线程。

1
2
3
4
5
6
7
8


await 的内部：
 1. UI 线程跑到 await Task.Run(...)
 2. 捕获当前 SynchronizationContext = WindowsFormsSynchronizationContext
 3. Task.Run 在线程池跑 DownloadSlowly
 4. UI 线程从 await 处返回，继续跑消息循环（不卡）
 5. DownloadSlowly 完成，延续要跑
 6. SyncContext.Post 把延续塞进 UI 消息队列
 7. UI 线程消息循环取出，执行延续（textBox1.Text = data）

关键：UI 线程从 await 处"释放"了（回去跑消息循环），不是阻塞等。这是 async 不卡 UI 的根本。和 WPF 的 DispatcherSynchronizationContext、老 ASP.NET 的 AspNetSynchronizationContext 同构。

五、.Result 死锁：经典坑

最经典、咬人最狠的坑：UI 线程上 await 一个未完成的 Task 时，用 .Result/.Wait() 同步阻塞 → 死锁。

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


// 💥 死锁代码
private void button1_Click(object sender, EventArgs e) // UI 线程
{
 var data = GetDataAsync().Result; // 同步阻塞 UI 线程
 textBox1.Text = data;
}

private async Task<string> GetDataAsync()
{
 var json = await httpClient.GetStringAsync(url); // 默认 ConfigureAwait(true)
 return Parse(json);
}

死锁过程：

1
2
3
4
5


1. UI 线程调 GetDataAsync().Result → 阻塞自己等 Task 完成
2. GetDataAsync 跑到 await，返回，延续注册"完成后回 UI 线程"
3. HTTP 数据回来，延续想在 UI 线程上跑（SyncContext 要求）
4. 但 UI 线程被 .Result 堵着，腾不出手
5. 延续等 UI 线程 → Task 永远完不成 → .Result 永远等 → 死锁

两个相关做法 ：

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


// 解法一：一路 async 到顶（推荐）
private async void button1_Click(object sender, EventArgs e)
{
 var data = await GetDataAsync(); // 不阻塞 UI 线程
 textBox1.Text = data;
}

// 库代码在确实不需要返回 UI 上下文时，可使用 ConfigureAwait(false)
private async Task<string> GetDataAsync()
{
 var json = await httpClient.GetStringAsync(url).ConfigureAwait(false); // 不回 UI 线程
 return Parse(json);
}

ConfigureAwait(false) 是编写不依赖 UI 上下文的库代码时的选项，不是给 UI 层继续使用 .Result/.Wait() 的通行证。调用链中任意一个 await 重新捕获上下文，问题就可能回来，因此首选仍然是 async all the way。

详见本站「.NET 高并发编程全景 · async 死锁节」——同一套 SynchronizationContext 阻塞机制，WPF / 老 ASP.NET / WinForms 都中招，ASP.NET Core 不中招（无 SyncContext）。

六、Task.Run 的正确姿势

后台跑耗时操作用 Task.Run，但要分清"I/O 绑定"和"CPU 绑定"：

1
2
3
4
5
6


CPU 绑定（计算密集）：用 Task.Run
 await Task.Run(() => HeavyCompute());

I/O 绑定（网络/文件/数据库）：用原生异步 API，不要 Task.Run 包
 await httpClient.GetStringAsync(url); // ✓ 底层 IOCP 异步
 await Task.Run(() => httpClient.GetString(url)); // ✗ 多此一举，还占线程池

误用 Task.Run 包 I/O：等于"在线程池线程里阻塞等网络"，浪费一个线程。I/O 用原生 async API 才是真异步。

七、进度与取消

后台任务要报告进度 + 可取消，用 IProgress<T> + CancellationToken：

 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


private CancellationTokenSource? _cts;

private async void btnStart_Click(object sender, EventArgs e)
{
 _cts?.Cancel();
 var cts = new CancellationTokenSource();
 _cts = cts;
 var progress = new Progress<int>(p => progressBar1.Value = p); // 回调自动在 UI 线程

 try
 {
 await Task.Run(() => DoWork(progress, cts.Token));
 MessageBox.Show("完成");
 }
 catch (OperationCanceledException) { MessageBox.Show("已取消"); }
 finally
 {
 if (ReferenceEquals(_cts, cts)) _cts = null;
 cts.Dispose();
 }
}

private void btnCancel_Click(object sender, EventArgs e) => _cts?.Cancel();

private void DoWork(IProgress<int> progress, CancellationToken ct)
{
 for (int i = 0; i <= 100; i++)
 {
 ct.ThrowIfCancellationRequested();
 Thread.Sleep(50); // 模拟干活
 progress.Report(i); // 报告进度（IProgress 自动转到 UI 线程）
 }
}

要点：

Progress<T> 的回调在创建它的线程（UI 线程）触发——不用手 Invoke。
CancellationToken 一路传到底，取消时 ThrowIfCancellationRequested 抛异常，冒泡到调用方。
这两套取代了老的 BackgroundWorker（下面提）。

八、BackgroundWorker（老的，了解即可）

.NET 2.0 时代的后台任务组件，封装了"后台跑 + 进度 + 取消 + 回 UI 线程"，在 async/await 之前是主流：

1
2
3
4
5


var worker = new BackgroundWorker { WorkerReportsProgress = true, WorkerSupportsCancellation = true };
worker.DoWork += (s, e) => { /* 后台跑 */ e.Result = Compute(); };
worker.ProgressChanged += (s, e) => progressBar1.Value = e.ProgressPercentage; // 自动 UI 线程
worker.RunWorkerCompleted += (s, e) => textBox1.Text = e.Result.ToString(); // 自动 UI 线程
worker.RunWorkerAsync();

新代码用 async/await + Progress + CancellationToken，别再用 BackgroundWorker。维护老代码能看懂即可。

九、小结

1
2
3
4
5
6
7
8


WinForms 线程核心：
 ✓ 单 UI 线程，控件只能由 UI 线程访问
 ✓ 后台碰控件 → InvalidOperationException
 ✓ 回 UI 线程：Invoke（同步）/ BeginInvoke（异步）/ async-await（自动）
 ✓ await 默认回 UI 线程（WindowsFormsSynchronizationContext）
 ✓ 死锁禁忌：UI 线程上 .Result/.Wait() 阻塞 async 方法
 ✓ 首选解法：async all the way；不依赖 UI 上下文的库代码可酌情 ConfigureAwait(false)
 ✓ 进度用 IProgress<T>，取消用 CancellationToken（取代 BackgroundWorker）

下一篇：部署——ClickOnce、单文件发布、ReadyToRun、自动更新。

WPF 学习笔记（十二）：性能与发布

Sat, 31 Jan 2026 10:00:00 +0800

写在前面

版本说明：基于 .NET 8 LTS。

最后一篇。前面 11 篇讲了 WPF 的原理和写法，本篇关注两件事——让应用跑得快、让应用能上线。这两件事在生产环境比"功能正确"更重要。

本篇之后，WPF 系列就完结。最后会给一个系列知识图谱，方便后续回顾。

本文要回答：

Freezable 冻结到底解决了什么？WPF 为什么不能 AOT / Trimming？self-contained 和 framework-dependent 怎么选？

一、性能优化的总思路

1.1 WPF 性能瓶颈的三个层级

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


1. 渲染层（GPU）
 - 复杂模板、过多视觉树节点
 - 高频动画、过度绘制
 - 大图、缓存失效

2. 布局层（CPU）
 - 复杂 Grid 嵌套
 - 频繁 InvalidateMeasure
 - 大数据未虚拟化

3. 绑定层（CPU）
 - 大量绑定、复杂 Path
 - 频繁 PropertyChanged
 - Converter 滥用

1.2 性能优化的优先级

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


高收益、低改动：
 ✅ 大数据用虚拟化
 ✅ Freeze 资源
 ✅ 避免 StackPanel 装大数据
 ✅ 优先用 RenderTransform 而不是 Width/Height 动画

中等收益：
 - 简化 ControlTemplate 嵌套
 - 减少绑定 Converter
 - 异步加载（不阻塞 UI 线程）

低收益、复杂改动：
 - 自定义 OnRender 替代控件
 - 用 SkiaSharp / Win2D
 - 手动管视觉树

二、Freezable：冻结资源

2.1 Freezable 是什么

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


Freezable 是 WPF 一种特殊类型：
 - 可变状态（默认）：可以改属性
 - 冻结状态：不可变，性能更好

继承 Freezable 的类型：
 - Brush（SolidColorBrush、LinearGradientBrush...）
 - Geometry
 - Transform
 - Pen、DashStyle
 - ImageSource（部分）
 - 3D Material

2.2 为什么冻结更快

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


var brush = new SolidColorBrush(Colors.Red);

// 不冻：WPF 必须监听 brush 的变化（万一你改 Color）
// 每次渲染都要检查
button.Background = brush;

// 冻：声明"我不会改"
brush.Freeze();
button.Background = brush;
// WPF 知道不可变 → 跳过监听 → 渲染更快
// 而且多个线程可以安全访问（线程安全）

1
2
3
4
5
6
7
8
9


性能差异：
 Freeze 可减少 WPF 对可变状态的跟踪
 → 实际收益取决于资源数量与复杂度
 → 应通过性能分析确认，不宜预设固定百分比

附加好处：
 - 冻结对象线程安全（可跨线程访问）
 - 不会触发变更通知
 - 适合不会再变化且 CanFreeze=true 的共享资源

2.3 在 XAML 里冻结

1
2
3
4
5
6
7
8


<!-- XAML 资源默认不保证被冻结；可显式请求冻结 -->
<Application xmlns:presentationOptions="http://schemas.microsoft.com/winfx/2006/xaml/presentation/options">
<Application.Resources>
 <SolidColorBrush x:Key="bg" Color="Red" presentationOptions:Freeze="True"/>
</Application.Resources>
</Application>

<!-- 带 Binding、DynamicResource 或动画的 Freezable 通常不能冻结 -->

2.4 在 C# 里冻结

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


public static readonly Brush WarningBrush = CreateFrozenBrush();

private static Brush CreateFrozenBrush()
{
 var brush = new LinearGradientBrush
 {
 StartPoint = new Point(0, 0),
 EndPoint = new Point(1, 0)
 };
 brush.GradientStops.Add(new GradientStop(Colors.Yellow, 0));
 brush.GradientStops.Add(new GradientStop(Colors.Red, 1));
 brush.Freeze(); // ← 关键
 return brush;
}

2.5 检查与解冻

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


if (brush.CanFreeze)
 brush.Freeze();

if (brush.IsFrozen)
{
 // 解冻 = 创建可变副本
 var mutable = brush.Clone();
 mutable.Opacity = 0.5;
 mutable.Freeze();
}

三、虚拟化与滚动性能

3.1 启用虚拟化

1
2
3
4


<ListBox ItemsSource="{Binding Items}"
 VirtualizingPanel.IsVirtualizing="True"
 VirtualizingPanel.VirtualizationMode="Recycling"
 VirtualizingPanel.ScrollUnit="Pixel"/>

1
2
3
4
5
6
7
8


关键属性：
 IsVirtualizing：开/关虚拟化（默认 True）
 VirtualizationMode：
 Standard：每次创建新容器
 Recycling：复用容器（推荐，性能好）
 ScrollUnit：
 Item：按 Item 滚动（默认，可能卡）
 Pixel：按像素滚动（流畅）

3.2 虚拟化的"陷阱"

嵌套破坏虚拟化

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


<!-- ❌ 外层 ScrollViewer + 内层 ListBox -->
<ScrollViewer>
 <StackPanel> <!-- StackPanel 给子无限高度 -->
 <ListBox ItemsSource="{Binding Items}"/>
 <!-- ListBox 高度被拉伸到所有 Item → 虚拟化失效 -->
 </StackPanel>
</ScrollViewer>

<!-- ✅ ListBox 自己滚动 -->
<Grid>
 <ListBox ItemsSource="{Binding Items}"/>
</Grid>

ItemsControl 默认不虚拟化

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


<!-- ❌ ItemsControl 默认用 StackPanel -->
<ItemsControl ItemsSource="{Binding Items}"/>

<!-- ✅ 改用 VirtualizingStackPanel -->
<ItemsControl ItemsSource="{Binding Items}">
 <ItemsControl.ItemsPanel>
 <ItemsPanelTemplate>
 <VirtualizingStackPanel/>
 </ItemsPanelTemplate>
 </ItemsControl.ItemsPanel>
</ItemsControl>

<!-- ✅ 或直接用 ListBox -->
<ListBox ItemsSource="{Binding Items}"/>

固定高度不会破坏虚拟化

1
2


<!-- ✅ 固定高度形成有限视口，ListBox 仍可虚拟化 -->
<ListBox Height="500" ItemsSource="{Binding Items}"/>

真正要避免的是把列表放进同方向的外层 StackPanel，或让外层 ScrollViewer 给它无限高度；这会使列表失去有限视口，可能创建全部项。

3.3 ContainerGenerator 性能

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


// 虚拟化时，容器在后台生成
// 监听 ItemContainerGenerator.StatusChanged
listBox.ItemContainerGenerator.StatusChanged += (s, e) =>
{
 var status = listBox.ItemContainerGenerator.Status;
 if (status == GeneratorStatus.ContainersGenerated)
 {
 // 容器生成完
 }
};

四、绑定优化

4.1 减少 Converter

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


<!-- ❌ Converter 滥用 -->
<TextBlock Visibility="{Binding IsVisible, Converter={StaticResource BoolToVis}}"/>

<!-- ✅ 用 DataTrigger（在 Style 里） -->
<Style TargetType="TextBlock">
 <Style.Triggers>
 <DataTrigger Binding="{Binding IsVisible}" Value="False">
 <Setter Property="Visibility" Value="Collapsed"/>
 </DataTrigger>
 </Style.Triggers>
</Style>

1
2
3
4
5
6
7
8
9


Converter 的代价：
 每次属性变化都调用 Convert
 跨语言边界（托管 → 反射）
 高频更新场景拖慢

替代方案：
 - 简单逻辑用 DataTrigger
 - 复杂逻辑用 ViewModel 暴露"加工后"的属性
 （ViewModel.IsVisibleText、ViewModel.StatusColor）

4.2 避免复杂 Path

1
2
3
4
5


<!-- ❌ 深层路径，每次都反射 -->
<TextBlock Text="{Binding User.Address.City.ZipCode}"/>

<!-- ✅ ViewModel 直接暴露扁平属性 -->
<TextBlock Text="{Binding ZipCode}"/>

4.3 OneTime 绑定

1
2
3
4


<!-- 数据几乎不变 → OneTime 性能最好 -->
<TextBlock Text="{Binding Name, Mode=OneTime}"/>

<!-- 不订阅 INPC，只绑定一次 -->

4.4 避免字符串格式化

1
2
3
4
5


<!-- ❌ 每次都格式化 -->
<TextBlock Text="{Binding Price, StringFormat=C}"/>

<!-- ✅ ViewModel 直接给字符串 -->
<TextBlock Text="{Binding PriceDisplay}"/>

4.5 异步绑定

1
2


<!-- 异步读取 CLR 属性 -->
<TextBlock Text="{Binding ExpensiveProperty, IsAsync=True}"/>

1
2
3
4
5
6
7


IsAsync 的含义：
 - 在后台线程读属性
 - 不阻塞 UI
 - 适合"很慢的属性"

注意：本质还是同步读取，只是不在 UI 线程
真正的异步要用 Task + NotifyTask（第三方库）

五、Layout 优化

5.1 简化视觉树

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


<!-- ❌ 过度嵌套 -->
<Border>
 <Grid>
 <Border>
 <StackPanel>
 <Border>
 <Button/>
 </Border>
 </StackPanel>
 </Border>
 </Grid>
</Border>

<!-- ✅ 扁平 -->
<Grid>
 <Button/>
</Grid>

5.2 用 Canvas 处理固定布局

1
2
3
4
5
6


<!-- 固定布局（不用 measure） -->
<Canvas>
 <Button Canvas.Left="10" Canvas.Top="10"/>
</Canvas>

<!-- 比 Grid 快得多 -->

5.3 延迟创建（Lazy）

1
2
3
4
5
6
7


<TabControl>
 <TabItem Header="Tab 1">
 <local:HeavyView/> <!-- TabItem 默认全部创建 -->
 </TabItem>
</TabControl>

<!-- 改：每个 Tab 内容用 ContentPresenter + 触发器延迟 -->

六、RenderOptions

6.1 CachingHint

1
2
3
4


<!-- 复杂静态内容缓存 -->
<Path Data="..." RenderOptions.CachingHint="Cache"
 RenderOptions.CacheInvalidationThresholdMaximum="2"
 RenderOptions.CacheInvalidationThresholdMinimum="0.5"/>

1
2
3
4
5


默认值是 Unspecified，不主动请求缓存。

显式 Cache：
 请求缓存平铺的 TileBrush 内容，适合缩放等场景；
 它不是给任意 UIElement 强制建立位图缓存的通用开关。

6.2 BitmapScalingMode

1
2
3
4
5
6


<!-- 位图缩放质量 -->
<Image Source="photo.jpg" RenderOptions.BitmapScalingMode="HighQuality"/>
<!-- Unspecified（默认）：使用 WPF 默认行为 -->
<!-- LowQuality：线性缩放，速度优先 -->
<!-- NearestNeighbor：最近邻（像素艺术） -->
<!-- HighQuality / Fant：高质量缩放 -->

6.3 ProcessRenderMode

1
2
3
4
5


// 强制软件渲染（GPU 渲染反而慢的场景）
RenderOptions.ProcessRenderMode = RenderMode.SoftwareOnly;

// 恢复默认：优先硬件渲染，不可用时回退到软件渲染
RenderOptions.ProcessRenderMode = RenderMode.Default;

1
2
3
4
5
6
7
8


何时用 SoftwareOnly：
 - 远程桌面（RDP）场景
 - 某些 GPU 驱动有 bug
 - 复杂 3D 在弱 GPU 上

何时不用：
 - 普通桌面应用
 - 复杂动画、特效

七、内存优化

7.1 弱事件模式

1
2
3
4
5
6
7
8
9


// ❌ 短生命周期对象订阅长生命周期事件
Application.Current.MainWindow.Closing += shortLived.Handler;
// shortLived 被持有，泄漏

// ✅ 弱事件
PropertyChangedEventManager.AddHandler(source, handler, nameof(source.Property));

// 或 Toolkit 的 WeakReferenceMessenger
WeakReferenceMessenger.Default.Register<MyMessage>(this, (r, m) => { ... });

7.2 大对象

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


// ❌ 一次性加载大列表
public ObservableCollection<Item> Items { get; } = new();
foreach (var item in Enumerable.Range(0, 100000))
 Items.Add(new Item()); // 大量分配

// ✅ 分页 / 增量加载
public ObservableCollection<Item> Items { get; } = new();
private async Task LoadMoreAsync()
{
 var batch = await _service.GetItems(skip: Items.Count, take: 100);
 foreach (var item in batch) Items.Add(item);
}

7.3 释放资源

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


// ❌ 忘记 Dispose
public MainWindow()
{
 var timer = new DispatcherTimer { Interval = TimeSpan.FromSeconds(1) };
 timer.Tick += Timer_Tick;
 timer.Start();
 // 窗口关闭，timer 仍持有窗口引用 → 泄漏
}

// ✅ 关闭时取消订阅
protected override void OnClosed(EventArgs e)
{
 _timer.Stop();
 _timer.Tick -= Timer_Tick;
 base.OnClosed(e);
}

八、性能诊断工具

8.1 Visual Studio Performance Profiler

1
2
3


CPU Usage：找 CPU 热点
Memory Usage：找内存泄漏
Application Timeline：找 UI 卡顿（WPF 专用）

8.2 WPF Performance Suite

1
2
3
4
5
6


旧工具（SDK 自带）：
 - Perforator：渲染统计
 - TraceProfiler：事件追踪
 - Visual Profiler：视觉树性能

新版本在 Windows SDK / Store 找

8.3 代码计时

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


var sw = Stopwatch.StartNew();
// ... 操作
sw.Stop();
Debug.WriteLine($"耗时：{sw.ElapsedMilliseconds} ms");

// 计算渲染帧
CompositionTarget.Rendering += (s, e) =>
{
 _frameCount++;
};

九、发布：基础概念

9.1 部署模式

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


Framework-Dependent（依赖框架）：
 - 假设用户机器已装 .NET Runtime
 - 发布包小（几 MB）
 - 用户必须自己装 .NET

Self-Contained（自包含）：
 - 把 .NET Runtime 打包进去
 - 发布包大（60~150 MB）
 - 用户无需装 .NET

Single-File（单文件）：
 - 将托管程序集等内容打进一个 exe；PDB 默认仍单独发布
 - 用户体验好（一个文件）
 - 托管程序集可直接从包中加载；需要提取的 native 文件取决于发布配置

9.2 csproj 配置

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


<PropertyGroup>
 <OutputType>WinExe</OutputType>
 <TargetFramework>net8.0-windows</TargetFramework>
 <UseWPF>true</UseWPF>

 <!-- 发布配置 -->
 <RuntimeIdentifier>win-x64</RuntimeIdentifier>
 <SelfContained>true</SelfContained>
 <PublishSingleFile>true</PublishSingleFile>
 <PublishReadyToRun>true</PublishReadyToRun>
 <IncludeNativeLibrariesForSelfExtract>true</IncludeNativeLibrariesForSelfExtract>
 <EnableCompressionInSingleFile>true</EnableCompressionInSingleFile>
</PropertyGroup>

1
2
3
4
5
6


RuntimeIdentifier：必须指定（win-x64 / win-x86 / win-arm64）
SelfContained：true 自包含 / false 框架依赖
PublishSingleFile：单文件发布
PublishReadyToRun：把程序集中的 IL 预编译为部分 native 代码，运行时仍保留 JIT
IncludeNativeLibrariesForSelfExtract：native 库也打进单文件
EnableCompressionInSingleFile：压缩单文件（体积更小，启动稍慢）

9.3 发布命令

1
2
3
4
5
6
7
8


# 自包含 + 单文件 + ReadyToRun
dotnet publish -c Release -r win-x64 --self-contained true \
 /p:PublishSingleFile=true \
 /p:PublishReadyToRun=true \
 /p:IncludeNativeLibrariesForSelfExtract=true

# 框架依赖（最小包）
dotnet publish -c Release -r win-x64 --self-contained false

9.4 体积对比

1
2
3
4
5
6
7
8


配置 体积
─────────────────────────────────────────
Framework-Dependent ~5 MB
Self-Contained ~80 MB
Self-Contained + SingleFile ~80 MB（一个文件）
Self-Contained + SingleFile + 压缩 ~50 MB
+ ReadyToRun +10 MB（提前编 IL）
+ Trimming ⚠️ WPF 不支持（见下节）

十、ReadyToRun 与 Trimming

10.1 ReadyToRun（R2R）

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


ReadyToRun = 提前编译为 native 代码（部分）

优点：
 - 启动更快（JIT 不用从 IL 编译）
 - 仍兼容反射（不是完全 AOT）

代价：
 - 体积增加 10~30%
 - 跨平台弱（必须指定 RID）

WPF 支持：
 ✅ 完全支持
 建议生产应用开启

1
2


<PublishReadyToRun>true</PublishReadyToRun>
<PublishReadyToRunComposite>true</PublishReadyToRunComposite>

10.2 Trimming

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


Trimming = 移除未使用的代码（减小体积）

WPF 的硬限制：
 ❌ WPF 不能 Trim（WPF 大量用反射）
 ❌ DependencyProperty.Register 反射注册
 ❌ XAML/BAML 解析反射
 ❌ Binding Path 反射

.NET 6+ 部分支持：
 ⚠️ 可以 trim 应用层代码（不影响 WPF 核心）
 ⚠️ 但 trim WPF 自己的代码会运行时崩

实践：
 Trimming 在 WPF 不推荐
 体积优化靠 SingleFile + 压缩

1
2
3


<!-- 不推荐 -->
<PublishTrimmed>true</PublishTrimmed>
<!-- 即使配 TrimMode=partial，风险也高 -->

10.3 NativeAOT

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


.NET 8+ 的 NativeAOT：
 - 完全 AOT 编译
 - 体积小、启动极快
 - 无 JIT、无反射（部分）

WPF 的现状：
 ❌ WPF 不支持 NativeAOT
 - DependencyProperty 注册依赖反射
 - XAML 解析依赖反射
 - 类型系统深度依赖运行时

替代方案：
 - WinUI 3：部分支持
 - Avalonia：实验性支持
 - MAUI：iOS / Android 用 AOT（不是 WPF）

 WPF 工程师：放弃 NativeAOT，用 R2R + SingleFile

十一、MSIX 打包

11.1 MSIX 是什么

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


MSIX = Windows 现代应用打包格式
 - 替代传统 MSI
 - 提供受控的安装、更新和卸载模型
 - 打包的 WPF 桌面应用通常仍是 full trust，并不等于 UWP 沙盒
 - 自动更新（从 Microsoft Store）
 - 干净卸载（不残留注册表）

适用：
 - Microsoft Store 发布
 - 企业内部署
 - 自动更新场景

11.2 打包步骤

1
2
3
4
5


1. 用 Visual Studio 的 "Windows Application Packaging Project"
2. 引用 WPF 项目
3. 配置 Package.appxmanifest
4. 生成 .msix 包
5. 签名（测试或正式证书）

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


<!-- Package.appxmanifest 关键部分 -->
<Identity Name="MyApp"
 Publisher="CN=MyCompany"
 Version="1.0.0.0"/>

<Applications>
 <Application Id="App"
 Executable="$targetnametoken$.exe"
 EntryPoint="$targetentrypoint$">
 <uap:VisualElements
 DisplayName="MyApp"
 Description="My WPF Application"
 BackgroundColor="transparent"
 Square150x150Logo="Assets\Logo.png"/>
 </Application>
</Applications>

11.3 MSIX vs 传统安装包

维度	传统 exe/msi	MSIX
安装	注册表、Program Files	由系统管理的包目录与注册信息
卸载	可能残留	干净
更新	手动	自动
权限	用户 / 管理员	UAC 友好
兼容	全部 Windows	Win10 1709+
适合	老应用	现代应用

1
2
3
4


实践建议：
 - 桌面应用首选 MSIX（如果支持）
 - 老系统兼容用传统 exe
 - 内部工具直接 dotnet publish 单文件

十二、应用清单与兼容性

12.1 app.manifest

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


<?xml version="1.0" encoding="utf-8"?>
<assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1">
 <assemblyIdentity version="1.0.0.0" name="MyApp"/>

 <!-- DPI 感知（详见第 4 篇） -->
 <application xmlns="urn:schemas-microsoft-com:asm.v3">
 <windowsSettings>
 <dpiAwareness xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">PerMonitorV2</dpiAwareness>
 <longPathAware xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">true</longPathAware>
 </windowsSettings>
 </application>

 <!-- 兼容性（声明支持的 Windows 版本） -->
 <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
 <application>
 <supportedOS Id="8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a"/> <!-- Windows 10/11 -->
 </application>
 </compatibility>
</assembly>

12.2 管理员权限

1
2


<!-- 请求管理员权限 -->
<requestedExecutionLevel level="requireAdministrator" uiAccess="false"/>

十三、自动更新

13.1 ClickOnce（旧）

1
2
3
4
5
6
7
8


特点：
 - .NET 早期技术
 - 自动更新简单
 - 部署模型和更新策略与传统安装包不同，需要按目标环境验证权限与兼容性

适用：
 - 内部工具
 - 简单应用

13.2 现代：Velopack / Squirrel

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


Velopack（推荐）：
 - 现代化、跨平台
 - 增量更新
 - GitHub Release 集成
 - 替代 Squirrel

Squirrel：
 - 经典方案
 - GitHub 出品
 - 已基本停更

使用：
 Velopack 在 csproj 集成
 发布到 GitHub Release / 自建服务器
 应用启动检查更新

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


// Velopack 示例
public partial class App : Application
{
 protected override async void OnStartup(StartupEventArgs e)
 {
 VelopackApp.Build().Run();
 base.OnStartup(e);

 // 检查更新
 var mgr = new UpdateManager("https://myserver/releases");
 var update = await mgr.CheckForUpdatesAsync();
 if (update is not null)
 {
 await mgr.DownloadUpdatesAsync(update);
 mgr.WaitExitThenApplyUpdates(update);
 }
 }
}

十四、WPF 知识图谱（系列总结）

经过 12 篇深入，WPF 的核心知识已经覆盖：

 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


┌─────────────────────────────────────────────────────────┐
│ WPF 知识图谱 │
├─────────────────────────────────────────────────────────┤
│ │
│ 基础机制（第 1~3 篇） │
│ ├─ 架构 + XAML 编译流水线 │
│ ├─ 依赖属性（11 级优先级 + 三回调链） │
│ └─ 路由事件（Tunneling/Bubbling/Direct） │
│ │
│ UI 与数据（第 4~7 篇） │
│ ├─ 布局系统（Measure/Arrange + Panel 全家桶） │
│ ├─ 数据绑定（INPC + Binding + CollectionView） │
│ ├─ 命令（ICommand + CommunityToolkit.Mvvm） │
│ └─ MVVM 工程化（DI + 导航 + 对话框） │
│ │
│ 外观与并发（第 8~10 篇） │
│ ├─ 样式与模板（Style/ControlTemplate/DataTemplate） │
│ ├─ Dispatcher 与 async/await │
│ └─ 动画与图形（保留模式 + Storyboard） │
│ │
│ 扩展与上线（第 11~12 篇） │
│ ├─ 自定义控件（UserControl/CustomControl/OnRender） │
│ └─ 性能与发布（Freezable/虚拟化/MSIX） │
│ │
└─────────────────────────────────────────────────────────┘

14.1 进阶路径

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


学完本系列，可以继续探索：

UI 框架对比：
 - WinUI 3（现代 Windows UI）
 - MAUI（跨平台）
 - Avalonia（跨平台、类 WPF）
 - Blazor Hybrid（Web 技术做桌面）

进阶主题：
 - SkiaSharp（高性能绘图）
 - Helix Toolkit（3D）
 - WebView2（嵌入式浏览器）
 - WPF + Blazor Hybrid（Razor 组件做桌面）

工程实践：
 - Prism（重量级 MVVM 框架）
 - ReactiveUI（响应式 MVVM）
 - StyleCop + Roslyn 分析器
 - XAML 热重载 + 设计时数据

发布生态：
 - Velopack（自动更新）
 - MSIX（现代打包）
 - Windows App SDK

14.2 后端工程师学 WPF 的"思维转变"

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


从命令式 → 声明式
 传统：手动改 UI（textBox.Text = ...）
 WPF：声明绑定（{Binding}），数据驱动 UI

从事件 → 命令
 传统：button.Click += handler
 WPF：Command + ViewModel

从单线程 → UI 单线程 + Dispatcher
 传统：随便多线程
 WPF：UI 必须单线程，跨线程用 Dispatcher

从绝对定位 → 两阶段布局
 传统：控件 Location
 WPF：父容器 Measure/Arrange

从渲染即画 → 保留模式
 传统：OnPaint 自己画
 WPF：描述视觉树，框架渲染

十五、小结

本文是 WPF 系列收尾，聚焦生产环境：

性能优化的三层瓶颈（渲染/布局/绑定）
Freezable 冻结（减少变更跟踪，具体收益需测量）
虚拟化（大数据列表必备，注意嵌套陷阱）
绑定优化（少 Converter、扁平 Path、OneTime）
Layout 优化（简化视觉树、Canvas、延迟创建）
RenderOptions（CachingHint、ProcessRenderMode）
内存优化（弱事件、分页加载、释放资源）
发布模式（Framework-Dependent / Self-Contained / Single-File）
ReadyToRun（WPF 完全支持）
Trimming / NativeAOT（WPF 不支持，原因：反射依赖）
MSIX 打包（现代部署）
app.manifest（DPI 感知、权限、兼容性）
自动更新（Velopack）
WPF 系列知识图谱

1
2
3
4


记住三句话：
 1. 性能优化的第一刀是虚拟化 + Freeze——简单收益大
 2. WPF 不能 AOT/Trim——历史包袱（反射 + XAML 解析）
 3. 发布默认 Self-Contained + SingleFile + ReadyToRun——用户体验最好

系列完结

WPF 学习笔记系列 12 篇到这里全部完成：

架构总览与 XAML 原理
依赖属性
路由事件
布局系统
数据绑定
命令与 CommunityToolkit.Mvvm
MVVM 工程化与依赖注入
样式与模板
多线程与 Dispatcher
动画与图形
自定义控件
性能与发布

希望这份笔记能帮到你建立系统的 WPF 知识体系。WPF 是一个"老但深"的框架——表面 API 简单，底层机制复杂。理解了底层，写代码就不再迷茫；理解了机制，调性能就有了方向。

后端工程师学 WPF 的最大障碍不是 API，而是思维模式——从"命令式"切换到"声明式"。一旦完成这个转变，WPF 反而是 .NET 生态里最优雅的 UI 框架。

继续探索，继续精进。完。

WPF 学习笔记（九）：多线程与 Dispatcher——UI 线程的真相

Sun, 25 Jan 2026 10:00:00 +0800

写在前面

版本说明：基于 .NET 8 LTS。

本篇是后端工程师最容易踩坑的一篇。在 ASP.NET Core 里，async/await 是"线程池里跑"，没有"UI 线程"概念。但在 WPF 里，所有 UI 操作必须在单个 UI 线程 上——改个 TextBox.Text 跨线程，直接抛异常。

本篇要把 WPF 的单线程模型、Dispatcher 消息循环、async/await 在 UI 上的特殊行为彻底讲清楚。

本文要回答：

为什么 UI 必须单线程？Dispatcher 到底在做什么？为什么后端的 .ConfigureAwait(false) 在 WPF 里行为不同？

一、为什么 UI 必须单线程

1.1 历史背景

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


Windows GUI 从 Win32 开始就是 STA 模型
 STA = Single-Threaded Apartment
 每个窗口有一个 UI 线程
 UI 操作只在该线程

为什么这样设计：
 1. 多线程并发改 UI → 状态不一致
 （线程 A 改 Text，线程 B 改 Visibility，渲染线程懵了）
 2. Win32 消息泵本质是"单线程队列"
 （PostMessage → 线程取消息 → 处理）
 3. COM 的 STA 模型（Office、Shell 都是 STA）

WPF 继承了这个约束：
 所有 UI 元素创建在 UI 线程
 所有 UI 操作必须在 UI 线程
 违反 → InvalidOperationException

1.2 异常演示

1
2
3
4
5
6
7
8


// 后台线程改 UI
private async void Button_Click(object sender, RoutedEventArgs e)
{
 await Task.Run(() =>
 {
 myTextBlock.Text = "Hello"; // ❌ 抛异常
 });
}

1
2
3
4
5
6


异常信息：
 "The calling thread cannot access this object because a different thread owns it."

所有继承 DispatcherObject 的对象都有"线程亲和性"
 → 创建它的线程是"owner"
 → 只有 owner 线程能访问

1.3 DispatcherObject 的"线程亲和性"

1
2
3
4
5
6
7


// WPF 几乎所有对象都是 DispatcherObject 派生
public abstract class DispatcherObject
{
 public Dispatcher Dispatcher { get; }
 public bool CheckAccess() { ... } // 当前线程是否是 owner
 public void VerifyAccess() { ... } // 不是 owner 抛异常
}

1
2
3
4
5
6
7
8


DependencyObject → DispatcherObject
UIElement → ...
FrameworkElement → ...
Control → ...
Button → ...

→ WPF 几乎所有元素都"绑定到一个 Dispatcher"
→ 跨线程访问 → 异常

二、Dispatcher：UI 线程的消息循环

2.1 Dispatcher 是什么

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


Dispatcher = UI 线程的"消息调度器"
 - 一个线程最多一个 Dispatcher
 - UI 线程的 Dispatcher 处理：
 * Win32 消息（鼠标、键盘）
 * WPF 的内部任务（layout、rendering）
 * 你 Post 的代码

工作流：
 while (true)
 {
 var work = DequeueHighestPriorityItem();
 work.Invoke();
 }

2.2 获取 Dispatcher

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


// 当前线程的 Dispatcher（如果有的话）
Dispatcher current = Dispatcher.CurrentDispatcher;

// 应用主 UI 线程的 Dispatcher（最常用）
Dispatcher ui = Application.Current.Dispatcher;

// 某个 UI 元素的 Dispatcher
Dispatcher elementDispatcher = myButton.Dispatcher;

// 只有在主 UI 线程调用 CurrentDispatcher 时，这三者通常才是同一个对象

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


CurrentDispatcher vs Application.Current.Dispatcher 区别：
 CurrentDispatcher：
 → 返回当前线程的 Dispatcher；若尚不存在，会为该线程惰性创建一个
 → 后台线程通常没有运行 Dispatcher 消息循环，排入其中的工作可能永远不执行

 Application.Current.Dispatcher：
 → Application 创建线程的 Dispatcher（常规 WPF 应用中就是主 UI 线程）
 → 推荐用法

 element.Dispatcher：
 → 元素所在线程的 Dispatcher（UI 元素就是主线程）
 → 也推荐

2.3 与 Win32 消息泵的关系

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


Dispatcher 内部就是 Win32 消息泵的包装：

 GetMessage / PeekMessage（Win32）
 ↓
 TranslateMessage / DispatchMessage（Win32）
 ↓
 WPF 接管：
 - 系统消息（鼠标、键盘）→ 路由事件
 - WPF 自定义消息 → Dispatcher 操作队列

 Dispatcher.Run() = 进入消息循环（永不返回，直到 Shutdown）

三、跨线程访问 UI

3.1 Dispatcher.Invoke 系列

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


// 同步执行
Application.Current.Dispatcher.Invoke(() =>
{
 myTextBlock.Text = "Updated";
});

// 带返回值
var result = Application.Current.Dispatcher.Invoke(() =>
{
 return myTextBox.Text;
});

// 异步（BeginInvoke，返回 DispatcherOperation）
Application.Current.Dispatcher.BeginInvoke(new Action(() =>
{
 myTextBlock.Text = "Updated";
}));

3.2 Invoke vs BeginInvoke vs InvokeAsync

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


Invoke(action)：
 - 同步阻塞
 - 等到 action 执行完才返回
 - 同一 Dispatcher 线程调用时会直接执行；跨线程调用时需留意互相等待造成的死锁

BeginInvoke(action)：
 - 异步，把 action 加入队列立即返回
 - 返回 DispatcherOperation（可等待）
 - WPF Dispatcher 的早期异步接口

InvokeAsync(action)：
 - 异步，返回可等待的 DispatcherOperation / DispatcherOperation<T>
 - 现代 API（推荐）
 - 支持 await

1
2
3
4
5


// 推荐写法
await Application.Current.Dispatcher.InvokeAsync(() =>
{
 myTextBlock.Text = "Updated";
});

3.3 死锁陷阱

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


// ❌ 真正的死锁：UI 线程同步等待后台任务，后台任务又同步 Invoke UI
private void Button_Click(object sender, RoutedEventArgs e)
{
 Task.Run(() =>
 {
 Dispatcher.Invoke(DoSomething); // 等 UI 线程执行
 }).Wait(); // UI 线程却在等后台任务
}

// ✅ 整条调用链保持异步，不阻塞 UI 线程
private async void SafeButton_Click(object sender, RoutedEventArgs e)
{
 await Task.Run(DoBackgroundWork);
 DoSomething(); // await 后回到 UI 线程
}

// ✅ 或检查是否已经在 UI 线程
if (!Dispatcher.CheckAccess())
 Dispatcher.Invoke(...);
else
 ... // 直接执行

四、async/await 在 WPF

后端工程师的关键调整点。

4.1 SynchronizationContext

1
2
3
4
5
6
7
8
9


async/await 的"上下文捕获"机制：
 await 一个 Task 前，记录当前 SynchronizationContext
 await 完成后，回到原上下文继续

不同环境的 SynchronizationContext：
 ASP.NET Core：null（无上下文）→ 任意线程池线程继续
 ASP.NET 经典：AspNetSynchronizationContext → 请求线程继续
 WPF：DispatcherSynchronizationContext → UI 线程继续
 WinForms：WindowsFormsSynchronizationContext → UI 线程继续

4.2 WPF 的 await 行为

1
2
3
4
5
6


private async void Button_Click(object sender, RoutedEventArgs e)
{
 var result = await SomeAsyncOperation();
 // ← 这里回到 UI 线程继续
 myTextBlock.Text = result; // ✅ 安全
}

1
2
3
4
5
6
7
8
9


执行流：
 1. Button_Click 在 UI 线程执行
 2. await SomeAsyncOperation()
 → 记录 SynchronizationContext（= UI 线程）
 → 线程池线程跑 SomeAsyncOperation
 3. 完成后，Post 回 UI 线程
 4. myTextBlock.Text = result 在 UI 线程

这就是为什么"后端 await 模式"在 WPF 也能用

4.3 ConfigureAwait(false)

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


// ❌ WPF 中常见反模式
private async Task LoadAsync()
{
 var data = await httpClient.GetAsync(url);
 // 后续回到 UI 线程
 var json = await data.Content.ReadAsStringAsync();
 // 又回到 UI 线程（多余的切换）
}

// ✅ 库代码用 ConfigureAwait(false)
public async Task<string> FetchAsync()
{
 var data = await httpClient.GetAsync(url).ConfigureAwait(false);
 var json = await data.Content.ReadAsStringAsync().ConfigureAwait(false);
 // 全程在后台线程
 return json;
}

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


ConfigureAwait(false) 的语义：
 - 不捕获 SynchronizationContext
 - 后续在任意线程池线程继续
 - 性能更好（避免 UI 线程切换）
 - 但后续不能直接访问 UI

什么时候用：
 - 库代码（不关心调用方是 UI 还是控制台）
 - 不需要访问 UI 的步骤

什么时候不用：
 - UI 层代码（要访问 UI）
 - WPF ViewModel 的命令（最后要更新 UI）

4.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
26
27


public partial class MainViewModel : ObservableObject
{
 [RelayCommand]
 private async Task LoadDataAsync()
 {
 IsLoading = true;
 try
 {
 // 后台线程获取数据（用 ConfigureAwait(false) 优化）
 var data = await _service.GetDataAsync().ConfigureAwait(false);

 // 回 UI 线程更新 ObservableCollection
 await Application.Current.Dispatcher.InvokeAsync(() =>
 {
 Items.Clear();
 foreach (var item in data) Items.Add(item);
 });
 }
 finally
 {
 // IsLoading 是 INPC，绑定更新要 UI 线程
 // 但 await 之前的 ConfigureAwait(false) 让我们不在 UI 线程
 // 切回去
 await Application.Current.Dispatcher.InvokeAsync(() => IsLoading = false);
 }
 }
}

1
2
3
4


观察：
 - await 默认回 UI 线程（什么都不写最简单）
 - 优化才用 ConfigureAwait(false)
 - 后台线程改 UI 必须用 Dispatcher

五、DispatcherTimer vs Task.Delay

两个看起来都能"延迟"，但完全不同。

5.1 DispatcherTimer

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


var timer = new DispatcherTimer
{
 Interval = TimeSpan.FromSeconds(1)
};
timer.Tick += (s, e) =>
{
 // 在 UI 线程触发
 myTextBlock.Text = DateTime.Now.ToString();
};
timer.Start();

1
2
3
4
5
6
7
8
9


DispatcherTimer：
 - 在 UI 线程触发 Tick
 - 优先级由 Dispatcher 控制（默认 Normal）
 - 不精确（受 UI 繁忙程度影响）
 - 可以直接访问 UI

适用：
 - 定期刷新 UI（每秒更新时钟）
 - 不需要精确定时

5.2 Task.Delay

1
2
3


await Task.Delay(1000);
// 1 秒后继续（线程池线程）
// 注意：在 WPF 中 await 后默认回 UI 线程

1
2
3
4
5
6
7
8
9


Task.Delay：
 - 基于 Task 的延迟
 - 不占用 UI 线程
 - 配合 async/await 用
 - await 后回到原 SynchronizationContext

适用：
 - 异步流程里的延迟
 - 不需要"定时触发"

5.3 区别

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


场景：每秒更新 UI

DispatcherTimer：
 - 简单
 - UI 卡顿时丢帧（不会触发）
 - UI 线程触发

Task.Delay + 循环：
 - 略复杂
 - await 前若在 UI 线程，默认会捕获上下文，循环仍在 UI 线程继续
 - 计算密集型工作仍应显式交给 Task.Run

推荐：
 - 普通定时器（时钟、UI 刷新）用 DispatcherTimer
 - 异步流程内延迟用 Task.Delay

六、跨线程访问 UI 的正确姿势

6.1 IProgress

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


private async Task ProcessAsync()
{
 var progress = new Progress<int>(p =>
 {
 // 回调在 UI 线程（Progress<T> 自动捕获 SynchronizationContext）
 progressBar.Value = p;
 });

 await Task.Run(() =>
 {
 for (int i = 0; i <= 100; i++)
 {
 ((IProgress<int>)progress).Report(i);
 Thread.Sleep(50);
 }
 });
}

1
2
3
4
5


Progress<T>：
 - 创建时捕获 SynchronizationContext
 - Report 在 UI 线程触发回调
 - 是"进度通知"的标准模式
 - 比手动 Dispatcher.Invoke 干净

6.2 CancellationToken

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


private async Task ProcessAsync(CancellationToken token)
{
 await Task.Run(async () =>
 {
 for (int i = 0; i < 1000; i++)
 {
 token.ThrowIfCancellationRequested();
 await DoWorkAsync(i);
 }
 }, token);
}

// 调用
var cts = new CancellationTokenSource();
buttonCancel.Click += (s, e) => cts.Cancel();
await ProcessAsync(cts.Token);

6.3 完整模式

 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


[RelayCommand]
private async Task LongOperationAsync(CancellationToken token)
{
 var progress = new Progress<int>(p =>
 {
 ProgressValue = p;
 });

 try
 {
 var result = await Task.Run(() => DoHeavyWork(progress, token), token);
 Result = result;
 }
 catch (OperationCanceledException)
 {
 // 用户取消
 }
}

private int DoHeavyWork(IProgress<int> progress, CancellationToken token)
{
 for (int i = 0; i <= 100; i++)
 {
 token.ThrowIfCancellationRequested();
 Thread.Sleep(50);
 progress.Report(i);
 }
 return 42;
}

七、BackgroundWorker 的现代替代

老代码用 BackgroundWorker，新代码用 Task.Run + Progress + CancellationToken。

7.1 BackgroundWorker（旧）

 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


var worker = new BackgroundWorker
{
 WorkerReportsProgress = true,
 WorkerSupportsCancellation = true
};

worker.DoWork += (s, e) =>
{
 // 后台线程
 for (int i = 0; i <= 100; i++)
 {
 if (worker.CancellationPending) { e.Cancel = true; return; }
 worker.ReportProgress(i);
 Thread.Sleep(50);
 }
};

worker.ProgressChanged += (s, e) =>
{
 // UI 线程
 progressBar.Value = e.ProgressPercentage;
};

worker.RunWorkerCompleted += (s, e) =>
{
 // UI 线程
 if (e.Cancelled) return;
 MessageBox.Show("Done");
};

worker.RunWorkerAsync();

7.2 现代等价（推荐）

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


private async Task RunWithProgressAsync(CancellationToken token)
{
 var progress = new Progress<int>(p => progressBar.Value = p);

 try
 {
 await Task.Run(() =>
 {
 for (int i = 0; i <= 100; i++)
 {
 token.ThrowIfCancellationRequested();
 ((IProgress<int>)progress).Report(i);
 Thread.Sleep(50);
 }
 }, token);

 MessageBox.Show("Done");
 }
 catch (OperationCanceledException) { }
}

1
2
3
4
5


现代优势：
 - 更简洁
 - 异常处理自然（try-catch）
 - 取消用标准 CancellationToken
 - 没有事件订阅的内存泄漏

八、Dispatcher 优先级

Dispatcher 处理任务有优先级。

8.1 优先级枚举

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


DispatcherPriority 枚举（数值从高到低）：
 Send 10（最高；跨线程 Invoke 默认使用）
 Normal 9
 DataBind 8
 Render 7
 Loaded 6
 Input 5
 Background 4
 ContextIdle 3
 ApplicationIdle 2
 SystemIdle 1
 Inactive 0（不处理）
 Invalid -1（无效值）

8.2 用例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


// 等到 UI 渲染完再执行
await Application.Current.Dispatcher.InvokeAsync(() =>
{
 // 在所有渲染任务后
}, DispatcherPriority.Loaded);

// 等到 Application Idle（空闲）
await Application.Current.Dispatcher.InvokeAsync(() =>
{
 // 应用空闲时执行
}, DispatcherPriority.ApplicationIdle);

8.3 让 UI 响应

 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


// ❌ 长循环阻塞 UI
private void ProcessData()
{
 for (int i = 0; i < 1000000; i++)
 {
 DoWork(i); // 阻塞 UI 线程
 }
}

// ✅ 切到后台线程
private async Task ProcessDataAsync()
{
 await Task.Run(() =>
 {
 for (int i = 0; i < 1000000; i++) DoWork(i);
 });
}

// ✅ 或者用 Dispatcher.Yield（不推荐，仅调试）
for (int i = 0; i < 1000000; i++)
{
 DoWork(i);
 if (i % 1000 == 0)
 await Dispatcher.Yield(DispatcherPriority.Background);
}

九、实战：可取消的进度条后台任务

9.1 ViewModel

 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
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56


public partial class MainViewModel : ObservableObject
{
 private CancellationTokenSource _cts;

 [ObservableProperty]
 private int _progress;

 [ObservableProperty]
 private bool _isRunning;

 [ObservableProperty]
 private string _status = "就绪";

 [RelayCommand]
 private async Task StartAsync()
 {
 _cts = new CancellationTokenSource();
 IsRunning = true;
 Status = "处理中...";

 var progress = new Progress<int>(p => Progress = p);

 try
 {
 var result = await Task.Run(() => DoWork(progress, _cts.Token), _cts.Token);
 Status = $"完成：{result}";
 }
 catch (OperationCanceledException)
 {
 Status = "已取消";
 Progress = 0;
 }
 finally
 {
 IsRunning = false;
 }
 }

 [RelayCommand]
 private void Cancel()
 {
 _cts?.Cancel();
 }

 private int DoWork(IProgress<int> progress, CancellationToken token)
 {
 int total = 100;
 for (int i = 0; i <= total; i++)
 {
 token.ThrowIfCancellationRequested();
 Thread.Sleep(50);
 progress.Report(i);
 }
 return 42;
 }
}

9.2 XAML

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


<Window.DataContext>
 <local:MainViewModel/>
</Window.DataContext>

<StackPanel Margin="20">
 <ProgressBar Value="{Binding Progress}" Maximum="100" Height="25" Margin="0,0,0,8"/>

 <TextBlock Text="{Binding Status}" Margin="0,0,0,8"/>

 <StackPanel Orientation="Horizontal">
 <Button Content="开始" Command="{Binding StartCommand}" Width="80" Margin="0,0,8,0"
 IsEnabled="{Binding IsRunning, Converter={StaticResource InverseBool}}"/>
 <Button Content="取消" Command="{Binding CancelCommand}" Width="80"
 IsEnabled="{Binding IsRunning}"/>
 </StackPanel>
</StackPanel>

9.3 知识点覆盖

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


✅ Task.Run 后台执行
✅ IProgress<T> 进度通知（自动 UI 线程）
✅ CancellationToken 取消
✅ RelayCommand 异步命令
✅ IsRunning 状态绑定按钮启用
✅ 异常处理（OperationCanceledException）

观察：
 - 任务期间 UI 完全响应（可拖动、可取消）
 - 进度条平滑更新（每 50ms 一次）
 - 取消立即响应（每次循环检查 token）

十、与 ASP.NET Core 的关键对比

后端工程师必读。

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


 ASP.NET Core WPF
─────────────────────────────────────────────────────────────
SynchronizationContext null（无） DispatcherSynchronizationContext
默认 await 后续 任意线程池线程 UI 线程
ConfigureAwait(false) 无意义（已无上下文） 显著优化（避免 UI 切换）
线程模型 每请求独立 单 UI 线程
跨线程访问 无"线程亲和"对象 UI 元素有亲和性
进度报告 IProgress<T> IProgress<T>（自动 UI 切换）
取消 CancellationToken CancellationToken（同样）
Timer System.Threading.Timer DispatcherTimer（UI 线程）

关键差异：
 1. ASP.NET Core 没有 UI 线程概念
 → 后端代码可以任意线程跑
 → ConfigureAwait(false) 几乎无意义

 2. WPF 的 await 默认回 UI 线程
 → 简单（不写 ConfigureAwait 就回 UI）
 → 但要小心"过度切换"（库代码用 ConfigureAwait(false) 优化）

 3. 后台代码改 UI 必须用 Dispatcher
 → 这条 ASP.NET Core 工程师最容易忘

10.1 经典迁移错误

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


// 后端思维（在 ASP.NET Core 没问题）
public async Task<string> GetAsync()
{
 var data = await httpClient.GetStringAsync(url);
 return data.Trim();
}

// 直接搬到 WPF ViewModel 没问题（await 自动回 UI）
public async Task<string> GetAsync()
{
 var data = await httpClient.GetStringAsync(url);
 return data.Trim();
}

// ❌ 但如果换 Task.Run 不 await
public string Get()
{
 var data = httpClient.GetStringAsync(url).Result; // ❌ 死锁
 return data.Trim();
}

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


.Result 在 WPF 死锁原因：
 - .Result 阻塞 UI 线程
 - httpClient 内部要回到 UI 线程（SynchronizationContext）
 - 但 UI 线程被阻塞
 - → 死锁

ASP.NET Core 不死锁：
 - 无 SynchronizationContext
 - httpClient 不需要回到原线程
 - .Result 直接拿后台结果

修复：
 - 用 await（推荐）
 - 或 ConfigureAwait(false)（库代码）

这套死锁机制的 Web 端对照（ASP.NET Core 为何不中招）、以及「类库为什么也会死锁」，详见 .NET 高并发编程全景：从异步到高性能实战的 async 死锁一节。

十一、常见陷阱

11.1 async void

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


// ❌ async void 异常会崩溃
private async void DoWork()
{
 await Task.Delay(1000);
 throw new Exception(); // 应用崩溃
}

// ✅ async Task
private async Task DoWorkAsync()
{
 await Task.Delay(1000);
 throw new Exception(); // 异常被 Task 捕获
}

// 例外：事件处理器（必须是 async void）
private async void Button_Click(...)
{
 await DoWorkAsync();
}

11.2 忘了 await

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


// ❌ fire-and-forget
[RelayCommand]
private void Save()
{
 _service.SaveAsync(); // 没 await，异常丢失
}

// ✅
[RelayCommand]
private async Task SaveAsync()
{
 await _service.SaveAsync();
}

11.3 后台线程改 ObservableCollection

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


// ❌
await Task.Run(() =>
{
 Items.Add(new Item()); // 异常
});

// ✅ 切回 UI 线程
await Application.Current.Dispatcher.InvokeAsync(() =>
{
 Items.Add(new Item());
});

// ✅ 或启用集合同步
BindingOperations.EnableCollectionSynchronization(Items, _lock);

11.4 在构造函数里 await

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


// ❌ 构造函数不能 async
public MainViewModel()
{
 await LoadDataAsync(); // 编译错误
}

// ✅ 异步初始化模式
public MainViewModel()
{
 Loaded = LoadDataAsync();
}

public Task Loaded { get; }

// 调用方
await viewModel.Loaded;

11.5 CurrentDispatcher 陷阱

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


// ❌ 在后台线程调
Task.Run(() =>
{
 Dispatcher.CurrentDispatcher.Invoke(...);
 // CurrentDispatcher 会为这个后台线程惰性创建 Dispatcher；
 // 它不是 UI Dispatcher，而且该线程没有运行消息循环
});

// ✅ 用 Application.Current.Dispatcher
Task.Run(() =>
{
 Application.Current.Dispatcher.Invoke(...);
});

十二、小结

本文深入 WPF 的多线程模型：

UI 单线程硬约束的历史与必要性
Dispatcher 的角色（消息循环 + 任务调度）
DispatcherObject 的线程亲和性
Invoke / BeginInvoke / InvokeAsync 的差异与死锁陷阱
SynchronizationContext 与 WPF 的 await 行为
ConfigureAwait(false) 在 WPF 的语义
DispatcherTimer vs Task.Delay
IProgress + CancellationToken 模式
BackgroundWorker 的现代替代
Dispatcher 优先级
实战：可取消进度条后台任务
与 ASP.NET Core 的关键差异

1
2
3
4


记住三句话：
 1. UI 单线程是硬约束——后台线程改 UI 必须用 Dispatcher
 2. await 默认回 UI 线程（DispatcherSynchronizationContext），库代码用 ConfigureAwait(false) 优化
 3. 后端工程师最常踩的坑：.Result 在 WPF 会死锁（ASP.NET Core 不会）

下一篇进入 WPF 的图形与动画——保留模式渲染、Timeline、Storyboard、动画占用机制。

深入 .NET Stream：从 byte[] 拉取到 Pipelines 推回，一次抽象的演进史

Wed, 07 Jan 2026 10:00:00 +0800

写在前面

Stream 从 .NET 1.0 延续至今，API 随异步模型和内存抽象演进：同步数组重载、TAP 异步、Span<byte> / Memory<byte>，以及面向高吞吐协议处理的 System.IO.Pipelines。这些扩展反映需求演进，不应简单归结为原始设计失败。

把 Stream 的所有坑摊开看，背后其实就是同一个设计张力的不同投影：

Stream 用统一抽象覆盖文件、网络、内存、加密和压缩；高吞吐协议处理还需要池化、多段缓冲区与显式背压，这正是 Pipelines 补充而非全面替代 Stream 的地方。

理解了这层张力，就能看清 .NET 流式 API 二十年的演进：每一层补丁（Span、Memory、ValueTask、Pipelines）都是在重新回答"统一抽象到底要做到什么程度"。本文围绕这条主线把 Stream 从底层机制到选型陷阱彻底讲透。

一、Stream 是什么：抽象基类的雄心与代价

1.1 统一 IO 抽象

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


public abstract class Stream : MarshalByRefObject, IAsyncDisposable, IDisposable
{
 public abstract bool CanRead { get; }
 public abstract bool CanWrite { get; }
 public abstract bool CanSeek { get; }
 public abstract long Length { get; }
 public abstract long Position { get; set; }

 public abstract int Read(byte[] buffer, int offset, int count);
 public abstract void Write(byte[] buffer, int offset, int count);
 public abstract long Seek(long offset, SeekOrigin origin);
 public abstract void SetLength(long value);
 public abstract void Flush();
}

1
2
3
4
5
6
7
8
9


设计意图：
 让"读文件 / 读网络 / 读内存 / 读加密"用同一套 API
 → 业务代码只依赖 Stream，不依赖具体实现
 → 可以层层包装（装饰器模式）

代价：
 → 抽象被迫提供所有方法，但每个子类都不一定能实现
 → CanRead / CanWrite / CanSeek 标志位遍布 API
 → 不支持的操作直接抛 NotSupportedException

1.2 四维能力（实际只有三维常用）

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


能力 属性 典型实现
─────────────────────────────────────────────────
Read CanRead FileStream / NetworkStream / MemoryStream
Write CanWrite FileStream / NetworkStream / MemoryStream
Seek CanSeek FileStream ✅ / NetworkStream ❌ / MemoryStream ✅
Timeout CanTimeout NetworkStream ✅ / FileStream ❌

CanSeek = false 时：
 - Position / Length / SetLength / Seek 都抛 NotSupportedException
 - Position 是"游标"概念，对网络流没意义

CanTimeout = true 时：
 - ReadTimeout / WriteTimeout 控制读写超时（毫秒）
 - 实际效果因实现而异（FileStream 在 Windows 上有 native 重叠 IO）

1.3 一个 Stream 可以"什么都不支持"

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


public class NullStream : Stream // 实际叫 Stream.Null
{
 public override bool CanRead => true;
 public override bool CanWrite => true;
 public override bool CanSeek => true;
 public override long Length => 0;
 public override long Position { get; set; }

 public override int Read(byte[] buf, int off, int count) => 0; // EOF
 public override void Write(byte[] buf, int off, int count) { /* 丢弃 */ }
 public override long Seek(long off, SeekOrigin org) => off;
 public override void Flush() { }
 public override void SetLength(long v) { }
}

Stream.Null 是"黑洞"——读立刻 EOF，写什么都不存。这种"无所不接"的抽象，让 Stream 可以做单元测试替身。

二、最坑的"暗契约"：Read 不保证读满

这是新手最容易踩的雷，也是 Stream 抽象的"原罪"。

2.1 反模式：以为一次 Read 能读满

1
2
3
4
5
6
7


// ❌ 高风险写法
public async Task<byte[]> ReadNAsync(Stream s, int n)
{
 byte[] buf = new byte[n];
 int read = await s.ReadAsync(buf, 0, n); // ⚠️ read 可能 < n
 return buf; // ⚠️ 后半段可能是 0
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


为什么 Read 可能返回少于请求？
 - FileStream：通常能读满（除非到 EOF）
 - NetworkStream：可能 1 字节就返回！
 * TCP 是字节流，每次 Read 看到的是"当前缓冲区到达的数据"
 * 没有"凑够 N 字节"的概念
 * 如果对方写 4 字节后 sleep，下次 Read 就只有 4 字节

 - CryptoStream：可能解一帧就返回
 - GZipStream：可能解一 chunk 就返回

→ 契约：Read 返回"实际读到的字节数"，可能是 0（EOF）到 count

2.2 正确做法：循环到 N 或 EOF

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


public static async Task<int> ReadExactAsync(Stream s, byte[] buf, int offset, int count)
{
 int total = 0;
 while (total < count)
 {
 int read = await s.ReadAsync(buf, offset + total, count - total);
 if (read == 0) break; // EOF
 total += read;
 }
 return total;
}

// .NET 7+ 已经原生提供；异步重载可接收 CancellationToken：
await s.ReadExactlyAsync(buf); // 读满，否则抛 EndOfStreamException
await s.ReadAtLeastAsync(buf, 100); // 至少 100 字节

1
2
3
4
5
6
7


ReadExactly 的实现：
 .NET 7 引入的便利 API
 替代手写循环（手写循环是 .NET 头号反模式之一）

注意：ReadExactly 在网络流上"卡住"直到读满或 EOF
 → 必须配合 CancellationToken
 → 否则恶意对端可以让调用永久阻塞

2.3 Read 返回 0 的意义

1
2
3
4
5
6
7
8


对非空缓冲区：0 通常表示 EOF（流结束）
1~count = 实际读到
异常 = IO 错误

注意：
 - NetworkStream 上对端关连接 → Read 返回 0
 - 永远不会"Read 返回 0 然后又读到数据"
 - 收到 0 后再调 Read 还是 0

三、API 演进史：从 byte[] 到 PipeReader

每一代 .NET 都在补 Stream 的洞。

3.1 第一代：同步 byte[] API（.NET 1.0）

1
2
3


byte[] buf = new byte[1024];
int read = stream.Read(buf, 0, 1024);
stream.Write(buf, 0, read);

1
2
3
4


问题：
 - 同步阻塞 → 高并发下线程爆炸
 - byte[] 必须分配 → GC 压力
 - offset + count 三参数 → 容易越界

3.2 第二代：APM 异步（.NET 1.1+）

1
2


stream.BeginRead(buf, 0, 1024, callback, state);
// 在 callback 里调 EndRead 拿到字节数

1
2
3
4


问题：
 - 回调地狱
 - 状态对象装箱
 - 异常处理复杂

3.3 第三代：TAP 异步（.NET 4.5）

1

int read = await stream.ReadAsync(buf, 0, 1024);

1
2
3


问题：
 - 仍然 byte[] 分配
 - Task<int> 装箱（每个 await 一个 Task 对象）

3.4 第四代：Span / Memory（.NET Core 2.1+）

1
2
3
4
5
6
7
8
9


// 同步版本
int read = stream.Read(buf.AsSpan(0, 1024));

// 异步版本（基于 ValueTask）
int read = await stream.ReadAsync(buf.AsMemory(0, 1024));

// stackalloc 友好
Span<byte> stackBuf = stackalloc byte[256];
stream.Read(stackBuf);

1
2
3
4
5
6
7
8


改进：
 - Span 零分配
 - ValueTask<int> 避免每次 await 创建 Task
 - 可以用 stackalloc

遗留：
 - 仍然要"主动拉"（pull）
 - 仍然要循环到 N 字节

3.5 第五代：ReadExactly / ReadAtLeast（.NET 7+）

1
2
3
4
5
6
7


static async Task ReadFrameAsync(
 Stream stream, Memory<byte> buffer, CancellationToken ct)
{
 await stream.ReadExactlyAsync(buffer, ct);
 await stream.ReadAtLeastAsync(
 buffer, 100, throwOnEndOfStream: false, cancellationToken: ct);
}

3.6 第六代：Pipelines（.NET Core 2.1+，命名空间 System.IO.Pipelines）

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


PipeReader reader = PipeReader.Create(stream);
try
{
 while (true)
 {
 ReadResult result = await reader.ReadAsync();
 ReadOnlySequence<byte> buffer = result.Buffer;
 SequencePosition consumed = ProcessProtocol(buffer);
 reader.AdvanceTo(consumed, buffer.End);

 if (result.IsCompleted && buffer.Slice(consumed).IsEmpty)
 break;
 }
}
finally
{
 await reader.CompleteAsync();
}

1
2
3
4
5
6
7
8


革命性：
 1. 不用自己分配 buffer（Pipe 内部池化）
 2. Pipe 管理缓冲区；协议解析器仍需循环并保留不完整帧
 3. 多段连续内存（ReadOnlySequence<byte>）
 4. 背压（Pipe 满了写不动）
 5. 减少应用层不必要的复制（不代表整个 I/O 路径零拷贝）

ASP.NET Core / Kestrel / SignalR 全部用 Pipelines

四、同步 vs 异步：按工作负载选择 FileStream 选项

这是另一个高频坑。

4.1 默认句柄按同步方式打开

1
2
3
4


// 看起来是异步
using var fs = new FileStream("data.bin", FileMode.Open);
byte[] buf = new byte[4096];
int read = await fs.ReadAsync(buf, 0, 4096);

1
2
3
4
5
6
7
8
9


实际行为：
 - 默认构造函数没有设置 `FileOptions.Asynchronous`
 - 异步重载仍可调用，但具体实现与成本因操作系统和运行时版本而异
 - 不要用“假异步”概括所有平台

为什么？
 - Windows 文件 IO 默认是同步的
 - 要真正异步需要 FILE_FLAG_OVERLAPPED + 完成端口
 - 是否值得异步打开，要看并发度、访问模式和平台

4.2 真异步：FileOptions.Asynchronous

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


// ✅ 真异步
using var fs = new FileStream(
 "data.bin",
 FileMode.Open,
 FileAccess.Read,
 FileShare.Read,
 bufferSize: 4096,
 options: FileOptions.Asynchronous // ← 关键
);

int read = await fs.ReadAsync(buf, 0, 4096);
// Windows 可使用 overlapped I/O + IOCP；Unix 实现由运行时决定

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


FileOptions.Asynchronous 的效果：
 - Windows：内部用 OVERLAPPED + IOCP
 - Linux/Unix：不能笼统声称使用 io_uring；.NET 运行时的 io_uring 支持长期仍是独立规划项
 - 实际线程占用和收益依平台、文件系统与运行时实现而变

FileSteam 静态方法：
 File.OpenRead("...") // 没开 Asynchronous
 File.Open("...", FileMode) // 没开

 → 需要异步句柄语义时，显式使用 `FileOptions.Asynchronous` 或 `FileStreamOptions.Options`

4.3 性能对比

1

不存在脱离磁盘、文件系统、平台和并发模型的固定“6 倍”结果。请分别基准同步顺序 I/O、异步并发 I/O，并同时观察吞吐、延迟、线程池队列和 CPU。

4.4 同步 ReadAsync 反而慢

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


// 真异步下，单线程顺序读：
await fs.ReadAsync(buf);
await fs.ReadAsync(buf);
await fs.ReadAsync(buf);
// 比同步：
fs.Read(buf);
fs.Read(buf);
fs.Read(buf);
// 慢一点（每次有 IOCP 唤醒开销）

// 并发 I/O 是否受益需要在目标平台测量

五、装饰器模式：Stream 的灵魂

Stream 是 GoF《设计模式》里 Decorator（装饰器）的教科书案例。

5.1 经典装饰器组合

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


// 三层包装：加密 + 压缩 + 文件
using var fs = new FileStream("data.gz.enc", FileMode.Create);
using var cs = new CryptoStream(fs, aes.CreateEncryptor(), CryptoStreamMode.Write);
using var gz = new GZipStream(cs, CompressionMode.Compress);

byte[] data = Encoding.UTF8.GetBytes("Hello, World!");
gz.Write(data, 0, data.Length);

// 数据流：
// Write → gz 压缩 → cs 加密 → fs 落盘

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


图示：
 ┌─────────────────────┐
 │ GZipStream │
 │ - 压缩 │
 └──────────┬──────────┘
 ▼
 ┌─────────────────────┐
 │ CryptoStream │
 │ - 加密 │
 └──────────┬──────────┘
 ▼
 ┌─────────────────────┐
 │ BufferedStream │
 │ - 缓冲 │
 └──────────┬──────────┘
 ▼
 ┌─────────────────────┐
 │ FileStream │
 │ - 落盘 │
 └─────────────────────┘

5.2 装饰器的"自动 dispose 链"

1
2
3
4
5
6
7


using var fs = new FileStream(...);
using var gz = new GZipStream(fs, ...);
// gz.Dispose() 内部会调用 fs.Dispose()
// 所以只 using 外层就够

// 但很多人不知道这点
// 容易在 finally 里手动 dispose 所有层

5.3 装饰器的所有权陷阱

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


// 假设你有一个"共享底层流"
using var fs = new FileStream(...);

// 包装两个装饰器，都接管 fs
using var cs1 = new CryptoStream(fs, enc1, Write);
using var cs2 = new CryptoStream(fs, enc2, Write);

cs1.Write(...); // 内部调 fs.Write
cs2.Write(...); // 也调 fs.Write！
// 实际写入是混乱的（fs 是有状态的）

// 正确做法：每个底层流只对应一个装饰器链

5.4 BufferedStream：什么时候有用

1
2
3
4
5
6
7
8
9


using var fs = new FileStream(...);
using var bs = new BufferedStream(fs, 8192); // 8KB 缓冲

// FileStream 是否启用托管缓冲取决于构造参数和运行时实现
// NetworkStream 自身不增加托管缓冲；Socket 缓冲大小由平台和配置决定
// 是否再包 BufferedStream 应按读写粒度和目标 Stream 实测

// 对 CryptoStream / GZipStream 的大量小读写，外层缓冲可能减少下游调用
// 但装饰器顺序会改变语义，仍应按完整链路验证

六、CopyTo / CopyToAsync：被低估的 API

6.1 自实现 vs 内置

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


// ❌ 手写循环
public async Task CopyAsync(Stream src, Stream dst)
{
 byte[] buf = new byte[8192];
 int read;
 while ((read = await src.ReadAsync(buf, 0, 8192)) > 0)
 await dst.WriteAsync(buf, 0, read);
}

// ✅ 内置（已经做了优化）
await src.CopyToAsync(dst, bufferSize: 8192);

6.2 CopyTo 的实现细节

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


// 简化版
public virtual async Task CopyToAsync(Stream dest, int bufferSize, CancellationToken ct)
{
 byte[] buffer = ArrayPool<byte>.Shared.Rent(bufferSize);
 try
 {
 int read;
 while ((read = await ReadAsync(buffer, ct)) > 0)
 await dest.WriteAsync(buffer.AsMemory(0, read), ct);
 }
 finally
 {
 ArrayPool<byte>.Shared.Return(buffer);
 }
}

1
2
3
4
5


内置的优势：
 - 基础实现复用池化缓冲区，降低每次调用的数组分配；异步状态和具体子类仍可能分配
 - 自适应 bufferSize
 - Stream 重写时有优化路径（如 MemoryStream → MemoryStream 直接拷贝）
 - 取消支持

6.3 FileStream → FileStream 的最优写法

1
2
3
4
5


// 通用且正确；具体 Stream 子类可以重写 CopyToAsync 优化
await src.CopyToAsync(dst);

// 不要假设 FileStream → FileStream 会自动改用 Windows CopyFileEx；
// 需要操作系统文件复制语义时，应直接选择相应文件 API 并验证元数据/覆盖行为。

七、Pipelines：Stream 的接班人

7.1 为什么需要 Pipelines

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


Stream 抽象的根本问题：
 1. 应用必须分配 buffer（byte[]）
 2. 应用必须循环 Read
 3. 应用必须处理"读不满"的情况
 4. 没有统一的高低水位背压协议；不同 Stream 的阻塞/缓冲行为各异
 5. 单段 buffer（数据可能跨段）

 → 写一个高性能 HTTP 服务器，光是处理"读满 N 字节"就要 100 行代码

Pipelines 重新设计：
 1. Pipe 内部管理 buffer（池化）
 2. Pipe 自动累积数据
 3. 调用方一次拿到"已经够多"的数据
 4. Pipe 满了写不动（背压）
 5. ReadOnlySequence<byte> 支持多段

7.2 PipeReader / PipeWriter

1
2
3
4
5
6
7
8
9


var pipe = new Pipe(new PipeOptions(
 pool: ArrayPool<byte>.Shared,
 readerScheduler: PipeScheduler.ThreadPool,
 writerScheduler: PipeScheduler.ThreadPool,
 pauseWriterThreshold: 1024 * 1024, // 写暂停阈值（背压）
 resumeWriterThreshold: 512 * 1024)); // 写恢复阈值

PipeWriter writer = pipe.Writer;
PipeReader reader = pipe.Reader;

7.3 协议解析示例

 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


// 解析"4 字节长度 + N 字节 body"协议
async Task ProcessAsync(PipeReader reader)
{
 while (true)
 {
 ReadResult result = await reader.ReadAsync();
 ReadOnlySequence<byte> buffer = result.Buffer;

 while (TryReadMessage(ref buffer, out var message))
 {
 ProcessMessage(message);
 }

 // 告诉 reader：消费到哪，下次从哪开始
 reader.AdvanceTo(buffer.Start, buffer.End);

 if (result.IsCompleted) break;
 }
}

bool TryReadMessage(ref ReadOnlySequence<byte> buffer, out ReadOnlySequence<byte> message)
{
 if (buffer.Length < 4) { message = default; return false; }

 Span<byte> lengthBytes = stackalloc byte[4];
 buffer.Slice(0, 4).CopyTo(lengthBytes);
 int length = BitConverter.ToInt32(lengthBytes);

 if (buffer.Length < 4 + length) { message = default; return false; }

 message = buffer.Slice(4, length);
 buffer = buffer.Slice(4 + length);
 return true;
}

1
2
3
4
5


对比 Stream 版本：
 - 没有手动 buffer 分配
 - 没有手动"读满 4 字节"循环
 - 处理"半个消息"自动等下次数据
 - 多段 Sequence 天然支持

7.4 Stream 与 Pipe 的桥接

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


// 从 Stream 创建 PipeReader
PipeReader reader = PipeReader.Create(stream, new StreamPipeReaderOptions(
 bufferSize: 4096,
 leaveOpen: false));

// 从 Stream 创建 PipeWriter
PipeWriter writer = PipeWriter.Create(stream, new StreamPipeWriterOptions(
 leaveOpen: false));

// 或者反过来：把 Pipe 当 Stream 用
Stream stream = pipe.Writer.AsStream();

1
2
3
4
5


ASP.NET Core 的请求体就是 PipeReader：
 HttpContext.Request.BodyReader : PipeReader
 HttpContext.Response.BodyWriter : PipeWriter

 → 不再是 Stream，而是 Pipeline

八、常见误用清单

8.1 不 Dispose 流

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


// ❌ 流泄漏
public byte[] Read(string path)
{
 var fs = new FileStream(path, FileMode.Open);
 var ms = new MemoryStream();
 fs.CopyTo(ms);
 return ms.ToArray(); // fs 和 ms 都没 Dispose
}

// ✅ using
public byte[] Read(string path)
{
 using var fs = new FileStream(path, FileMode.Open);
 using var ms = new MemoryStream();
 fs.CopyTo(ms);
 return ms.ToArray();
}

8.2 异步方法不 await

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


// ❌ 火并忘记（fire and forget）
public void BadWrite(Stream s, byte[] data)
{
 s.WriteAsync(data, 0, data.Length); // ⚠️ 没 await
 // 方法立即返回，写还没完成
}

// ✅ await 或显式处理
public async Task WriteAsync(Stream s, byte[] data)
{
 await s.WriteAsync(data);
}

8.3 不理解 Asynchronous 的平台差异

1
2
3
4
5
6
7
8


// 默认句柄按同步方式打开；异步重载的实现成本依平台而异
using var fs = File.OpenRead("data.bin"); // 默认 options
await fs.ReadAsync(buf); // 实际是线程池阻塞

// ✅ 真异步
using var fs = new FileStream("data.bin", FileMode.Open, FileAccess.Read,
 FileShare.Read, 4096, FileOptions.Asynchronous);
await fs.ReadAsync(buf);

8.4 不用 ArrayPool

 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


// ❌ 每次 new
public async Task<byte[]> ReadAsync(Stream s)
{
 byte[] buf = new byte[4096]; // ⚠️ GC 压力
 using var ms = new MemoryStream();
 int read;
 while ((read = await s.ReadAsync(buf)) > 0)
 ms.Write(buf, 0, read);
 return ms.ToArray();
}

// ✅ ArrayPool
public async Task<byte[]> ReadAsync(Stream s)
{
 byte[] buf = ArrayPool<byte>.Shared.Rent(4096);
 try
 {
 using var ms = new MemoryStream();
 int read;
 while ((read = await s.ReadAsync(buf.AsMemory(0, 4096))) > 0)
 ms.Write(buf, 0, read);
 return ms.ToArray();
 }
 finally
 {
 ArrayPool<byte>.Shared.Return(buf);
 }
}

// ✅✅ CopyToAsync（最简）
public async Task<byte[]> ReadAsync(Stream s)
{
 using var ms = new MemoryStream();
 await s.CopyToAsync(ms);
 return ms.ToArray();
}

8.5 信任 CanSeek

1
2
3
4
5
6
7
8
9


// ❌ 假设 stream 可 Seek
stream.Position = 0;
stream.Read(...);

// ✅ 检查
if (stream.CanSeek)
 stream.Position = 0;
else
 throw new InvalidOperationException("Stream is not seekable");

8.6 CryptoStream 不 FlushFinalBlock

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


// ❌ 加密数据不完整
using var cs = new CryptoStream(ms, enc, CryptoStreamMode.Write);
cs.Write(data, 0, data.Length);
// 没有 cs.FlushFinalBlock() 或 Dispose → AES 填充没写

// ✅ Dispose 自动 flush
using (var cs = new CryptoStream(ms, enc, CryptoStreamMode.Write))
{
 cs.Write(data, 0, data.Length);
} // ← Dispose 触发 FlushFinalBlock

九、性能基准

9.1 Read 模式对比

 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
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62


[MemoryDiagnoser]
public class StreamBench
{
 private MemoryStream _stream;

 [GlobalSetup]
 public void Setup()
 {
 var data = new byte[1_000_000];
 new Random().NextBytes(data);
 _stream = new MemoryStream(data);
 }

 [Benchmark]
 public int ReadAll_Array()
 {
 _stream.Position = 0;
 byte[] buf = new byte[4096];
 int total = 0;
 int read;
 while ((read = _stream.Read(buf, 0, buf.Length)) > 0) total += read;
 return total;
 }

 [Benchmark]
 public async Task<int> ReadAllAsync_Array()
 {
 _stream.Position = 0;
 byte[] buf = new byte[4096];
 int total = 0;
 int read;
 while ((read = await _stream.ReadAsync(buf, 0, buf.Length)) > 0) total += read;
 return total;
 }

 [Benchmark]
 public async Task<int> ReadAllAsync_Pooled()
 {
 _stream.Position = 0;
 byte[] buf = ArrayPool<byte>.Shared.Rent(4096);
 try
 {
 int total = 0;
 int read;
 while ((read = await _stream.ReadAsync(buf.AsMemory(0, 4096))) > 0) total += read;
 return total;
 }
 finally
 {
 ArrayPool<byte>.Shared.Return(buf);
 }
 }

 [Benchmark]
 public async Task<int> ReadAll_CopyToAsync()
 {
 _stream.Position = 0;
 using var ms = new MemoryStream();
 await _stream.CopyToAsync(ms, 4096);
 return (int)ms.Length;
 }
}

1

这段基准使用 `MemoryStream`，主要测量 API、状态机和复制开销，不能代表磁盘或网络 I/O。不要在缺少 CPU、运行时版本、完整 BenchmarkDotNet 报告和误差时给出“典型结果”；应在目标 Stream 类型和并发模型上重新测量。

十、Stream 子类速查

 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


按用途分类：

 文件：
 FileStream - 文件 IO（默认 buffered）
 FileStream(FileOptions.Asynchronous) - 真异步
 UnmanagedMemoryStream - 内存映射文件 / 非托管内存

 网络：
 NetworkStream - Socket 包装
 SslStream - SSL/TLS 加密层
 AuthenticatedStream - 基类，可继承做认证

 内存：
 MemoryStream - byte[] 包装
 ReadOnlyMemory<byte> 可通过自定义 Stream 或第三方适配器暴露；BCL 没有 ReadOnlyMemoryStream 类型
 RecyclableMemoryStream - Microsoft.IO.RecyclableMemoryStream 库，池化版

 管道：
 AnonymousPipeServerStream / AnonymousPipeClientStream - 父子进程
 NamedPipeServerStream / NamedPipeClientStream - 命名管道

 装饰器：
 BufferedStream - 缓冲
 CryptoStream - 加密
 GZipStream / DeflateStream / BrotliStream - 压缩

 其他：
 Stream.Null - 黑洞
 IsolatedStorageFileStream - 沙盒存储

十一、选型决策

11.1 读文件

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


默认：
 using var fs = new FileStream(path, FileMode.Open, FileAccess.Read,
 FileShare.Read, 4096, FileOptions.Asynchronous);

 → 并发异步读取时评估 Asynchronous；单个顺序文件不一定更快
 → 简单一次性读取：File.ReadAllBytesAsync（内部就是上面的封装）

需要 seek：
 ✅ FileStream 默认支持

需要内存映射：
 MemoryMappedFile.CreateFromFile(...)

11.2 写文件

1
2
3
4
5
6
7
8
9


默认：
 using var fs = new FileStream(path, FileMode.Create, FileAccess.Write,
 FileShare.None, 4096, FileOptions.Asynchronous);

 → 加 BufferedStream 收益不大（FileStream 已有 buffer）
 → FileOptions.WriteThrough 用于关键数据（绕过 OS 缓存，直接落盘）

追加：
 File.AppendAllTextAsync / AppendAllBytesAsync

11.3 网络 IO

1
2
3
4
5
6


服务器：
 Socket → NetworkStream → 用 PipeReader 包装
 → 高性能场景直接用 Pipelines API

客户端：
 HTTP 客户端优先使用 HttpClient；只有实现自定义 TCP 协议时才直接使用 Socket/NetworkStream

11.4 压缩 + 加密

1
2
3


写（从应用到文件）：GZipStream → CryptoStream → FileStream
读（从文件到应用）：FileStream → CryptoStream → GZipStream
注意 dispose 顺序（外层先 dispose，自动级联）

十二、小结

本文讲了 Stream 抽象从 .NET 1.0 到 9 的演进：

Stream 的"统一抽象"雄心：用基类覆盖所有 IO，代价是 CanXxx 标志遍布
最大的暗契约：Read 不保证读满，循环到 N 字节是基本功
API 六代演进：同步 → APM → TAP → Span/Memory → ReadExactly → Pipelines
FileStream 的异步语义依平台和打开选项而变；并发异步场景可显式评估 FileOptions.Asynchronous
装饰器模式：GZipStream(CryptoStream(FileStream)) 的级联与 dispose
CopyToAsync 内部已经用 ArrayPool + Span 优化，优先用
Pipelines 是 Stream 在高吞吐协议处理场景的补充：池化 buffer + 背压 + 多段 Sequence
ASP.NET Core 内部已经从 Stream 迁移到 PipeReader/Writer
6 类常见误用：不 Dispose / 不 await / 不开 Async / 不用 Pool / 信任 CanSeek / 不 Flush
子类速查与选型决策

1
2
3
4


记住三句话：
 1. Stream 是"拉"模式 + "同步"基础，Pipelines 是"推"模式 + 背压原生
 2. FileStream 是否使用 Asynchronous 要按平台、并发度和访问模式测量
 3. Stream.Read 返回值永远不能假设"读满"——这是抽象的代价

写文件或网络代码时，先保证短读、取消、释放和所有权正确，再依据 profiling 选择 FileOptions.Asynchronous、池化缓冲区、CopyToAsync 或 Pipelines；不要把这些选项机械叠加。

参考资料

深入 .NET Memory：Span 之后，为什么还需要一个 Memory？

Mon, 05 Jan 2026 10:00:00 +0800

写在前面

.NET 高性能编程里常同时出现 Span<T> 和 Memory<T>。两者都能表示一段连续内存并避免不必要的数据复制；包装本身通常不分配，但装箱、ToArray() 和底层所有者仍可能分配。异步边界也是二者的重要分工点。

这就是 Memory<T> 存在的全部动机——

Span<T> 是受 ref-safety 约束的同步视图；Memory<T> 是可存储、可由异步操作持有的内存描述。二者都能在不复制底层数据的情况下切片，但都不拥有数据生命周期。

理解这层关系，比记住一堆 API 重要。本文围绕这条主线，把 Memory<T> 从底层布局到使用陷阱彻底讲透。

一、回到 Span：极致性能的代价

要看懂 Memory，先看 Span 解决了什么、付出了什么。

1.1 没有 Span 之前

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


// 想对"一段连续数据"做处理，但来源五花八门：
void ProcessArray(byte[] arr, int offset, int len) { ... }
void ProcessString(string s, int offset, int len) { ... }
void ProcessPointer(IntPtr ptr, int len) { ... }

// 调用方：
ProcessArray(buffer, 10, 5);
ProcessString(text, 1, 3);

// 问题：
// - 每种来源要写一份重复代码
// - 调用方需要传 (array, offset, length) 三元组，容易出错
// - string 内部是 UTF-16，byte[] 是字节， IntPtr 是非托管，三者之间不能互通

1.2 Span 的设计：内存的"通用切片"

Span<T> 的内部其实就是两个字段：

1
2
3
4
5


public readonly ref struct Span<T>
{
 private readonly ref T _pointer; // 对内存的引用（byref）
 private readonly int _length;
}

1
2
3
4
5
6
7


关键点：
 1. ref T _pointer：不是普通指针，是"指向 T 的引用"（managed pointer）
 → 既能指向托管数组、也能指向 stackalloc、还能指向 native heap
 → GC 知道它在引用什么，不会被错判回收
 2. int _length：长度

 Span<T> 的具体大小和布局属于运行时实现细节，不应写入协议或持久化格式

1.3 ref struct 的枷锁

Span<T> 是 ref struct。以下是常见限制；较新的 C# 已放宽部分规则，具体以项目语言版本为准：

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


❌ 不能作为 class 的字段
❌ 不能装箱（box） → 不能作为 object
❌ 不能跨 await / yield
❌ 在旧语言版本中不能实现接口
❌ 不能用于未声明允许 ref struct 的泛型参数
❌ 不能被 lambda 捕获

为什么这么严？
 - ref T _pointer 是"内部指针"
 - 一旦允许装箱，就可能逃逸到堆
 - 一旦逃逸到堆，引用的目标（可能是 stackalloc 的栈内存）可能已经失效
 → 引用悬空 → GC 灾难 → 类型安全崩塌

 所以 ref struct 必须"留在栈上"，编译期阻止任何逃逸。

1.4 痛点：写异步代码时处处碰壁

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


public async Task ProcessAsync(byte[] buffer)
{
 Span<byte> span = buffer.AsSpan();

 // ❌ 编译错误：Span 不能作为 lambda 字段
 await Task.Run(() => {
 // ... span ...
 });

 // ❌ 编译错误：Span 不能跨 await
 await DoSomethingAsync();
 Console.WriteLine(span.Length);

 // ❌ 编译错误：Span 不能作为字段
 // class Holder { public Span<int> Data; }
}

异步 I/O 经常需要把缓冲区保留到操作完成。普通 byte[] 并非天然有问题；只有高频或大对象分配造成可观测 GC 压力时，池化才可能带来收益。

需要一个能描述同一底层缓冲区、又可由异步操作安全持有的类型——这就是 Memory<T>。

二、Memory 的设计：可装箱的"内存护照"

2.1 一句话定义

Memory<T> 是可以存入字段、由异步操作持有，并能按需取得 Span<T> 视图的普通结构体。它可以装箱，但装箱会产生分配，通常不应作为卖点。

2.2 概念模型与当前实现

1
2
3
4
5
6
7


// 用于理解的简化模型；私有字段属于运行时实现细节，不是公共契约
public readonly struct Memory<T>
{
 private readonly object _object; // 内存来源（可能是 T[]、string、MemoryManager<T>）
 private readonly int _index; // 起始偏移
 private readonly int _length; // 长度
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


和 Span 的核心差别：
 Span<T>：ref T _pointer ← GC 直接跟踪
 Memory<T>：object _object ← 通过对象间接引用

为什么这样设计？
 - 不持有 ref，所以 Memory 是普通 struct（不是 ref struct）
 - 可以装箱、可以跨 await、可以作为字段
 - 但 Span 暂时拿不到 → 需要"提取"

 Span 怎么提取？
 Span<T> span = memory.Span; ← 这个 getter 内部做"安全提取"

2.3 为什么 Memory 不直接持有 ref

1
2
3
4
5
6
7


假设 Memory<T> 持有 ref T _pointer：
 - Memory 是 struct，可以装箱
 - 装箱后 ref T 留在堆上
 - 如果原数据是 stackalloc → 装箱后栈释放 → ref 悬空 → 崩溃

→ Memory 设计上就不允许持有 ref，只能持有 object
→ 真要拿 Span 时，从 object 中提取，提取时编译器/运行时知道这是同步操作，安全

2.4 三种合法的 _object 类型

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


Memory<T>._object 只可能是以下几种（default(Memory<T>) 时为 null）：

1. T[] 数组
 - new int[100].AsMemory()
 - GC 知道这是托管堆上的数组，安全

2. string（仅当 T 为 char）
 - "hello".AsMemory()
 - string 不可变 → ReadOnlyMemory<char>

3. MemoryManager<T>（自定义）
 - 例如 MemoryManager<char> 包装 native 内存
 - 自定义 Pin() 让 GC 知道何时 pin

4. null（表示空 Memory 或 default）

1
2
3
4
5
6
7
8
9


// 三种典型构造方式
byte[] arr = new byte[100];
Memory<byte> m1 = arr.AsMemory(); // _object = arr

string s = "hello";
ReadOnlyMemory<char> m2 = s.AsMemory(); // _object = s

// 自定义（不常见）
// MemoryManager<T> 的示例见 4.3；CreateFromPinnedArray 要求数组已由调用方固定

三、Memory 与 Span 的转换：一次"安全握手"

3.1 Memory → Span

1
2


Memory<byte> memory = new byte[1024];
Span<byte> span = memory.Span; // ← 提取

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


这一步是"零拷贝"的：
 - 内部根据 _object 类型生成 Span
 - 数组：span = new Span<T>((T[])_object, _index, _length)
 - string：span = ref Unsafe.AsRef(in s.GetFirstChar()) + offset
 - MemoryManager：调用 MemoryManager.GetSpan()

为什么这次"提取"是安全的？
 - 提取发生在栈上
 - 拿到的 Span<T> 不能逃逸（ref struct 约束）
 - 一旦 Span 用完，对象引用还在 Memory 里持有

3.2 Span → Memory：不能直接转

1
2


Span<byte> span = stackalloc byte[100];
Memory<byte> memory = span; // ❌ 编译错误！

为什么不行？因为 Span 可能指向栈内存（stackalloc），如果转成 Memory 装箱到堆上，栈帧结束后引用悬空。

但如果是数组-backed 的 Span，可以从原数组重新构造（零拷贝）：

1
2
3
4
5


byte[] arr = new byte[100];
Span<byte> span = arr;
Memory<byte> memory = new Memory<byte>(arr); // 从原数组构造，不拷贝

// span.ToArray() 也能得到 Memory 可用的数据，但 ⚠️ 会拷贝一份

注：MemoryMarshal.AsMemory 存在，但签名是 ReadOnlyMemory<T> → Memory<T>（去掉只读性），并没有接收 Span<T> 的重载；标准库里不存在 Span → Memory 的直接转换 API。

3.3 Memory 的 Slice：返回 Memory

1
2
3
4
5
6


Memory<byte> mem = new byte[100];
Memory<byte> slice = mem.Slice(10, 20);

// 内部就是：
// return new Memory<T>(_object, _index + 10, 20);
// 仍然不持 ref，仍然可以装箱/跨 await

而 Span 的 Slice：

1
2
3
4
5


Span<byte> span = mem.Span;
Span<byte> slice = span.Slice(10, 20);

// 内部是：return new Span<T>(ref _pointer[10], 20);
// 仍然是 ref struct

3.4 转换成本对比

操作	成本
`Memory<T>.Span` 提取	几纳秒（一次方法调用 + 类型判断）
`Memory<T>.Slice`	16 字节 struct 创建
`Span<T>.Slice`	16 字节 struct 创建
`Memory<T>.ToArray()`	拷贝整个数组（O(n)）
`Memory<T>.Pin()`	创建 MemoryHandle，pin 对象

四、Memory 的三种来源

4.1 来自托管数组

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


byte[] buffer = new byte[4096];
Memory<byte> mem = buffer.AsMemory();

// 切片
Memory<byte> slice = mem.Slice(0, 1024);

// 跨 await
await ProcessAsync(slice);

async Task ProcessAsync(Memory<byte> data)
{
 // 在 await 前后都能用
 Span<byte> span = data.Span;
 span[0] = 0xFF;
 await Task.Yield();
 Console.WriteLine(span[0]); // 0xFF
}

4.2 来自字符串（仅 char）

1
2
3
4
5
6
7
8


string text = "Hello, World!";
ReadOnlyMemory<char> mem = text.AsMemory();

ReadOnlyMemory<char> word = mem.Slice(7, 5);
Console.WriteLine(word.ToString()); // "World"

// 跨 await 安全
await ProcessAsync(word);

1
2
3
4


注意：
 - string 是不可变的 → ReadOnlyMemory<char>
 - 不能改成 Memory<char>
 - 想要可变字符串用 StringBuilder 或 char[]

4.3 来自 MemoryManager（自定义）

MemoryManager<T> 是抽象类，让你包装"非标准内存"为 Memory<T>：

 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
38
39


using System.Buffers;
using System.Runtime.InteropServices;

public sealed unsafe class NativeMemoryManager : MemoryManager<byte>
{
 private byte* _ptr;
 private readonly int _length;

 public NativeMemoryManager(int length)
 {
 _ptr = (byte*)NativeMemory.Alloc((nuint)length);
 _length = length;
 }

 public override Span<byte> GetSpan() => new(_ptr, _length);

 public override MemoryHandle Pin(int elementIndex = 0)
 {
 if ((uint)elementIndex > (uint)_length)
 throw new ArgumentOutOfRangeException(nameof(elementIndex));
 return new MemoryHandle(_ptr + elementIndex, default, this);
 }

 public override void Unpin() { /* native 内存不需要 pin */ }

 protected override void Dispose(bool disposing)
 {
 if (_ptr is not null)
 {
 NativeMemory.Free(_ptr);
 _ptr = null;
 }
 }
}

// 用法：
using var manager = new NativeMemoryManager(4096);
Memory<byte> mem = manager.Memory;
// mem 只能在 manager.Dispose() 之前使用

1
2
3
4
5
6
7


MemoryManager<T> 的常见应用：
 - 包装 native 内存（malloc、mmap）
 - 包装 unmanaged 集合
 - 包装内存映射文件
 - 包装 GC pin 的对象

ASP.NET Core、Pipelines 内部都用 MemoryManager 包装底层缓冲区。

五、IMemoryOwner：所有权管理

5.1 为什么需要"所有者"

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


问题：Memory<T> 是 struct，不持有"释放"概念
 谁该释放底层 buffer？

场景：
 - 你从 ArrayPool 租了一个 buffer
 - 多个方法共享 Memory<byte>
 - 用完应该归还给 Pool

 Memory<byte> 本身没有 Return() 方法
 → 需要"所有者"对象负责归还

5.2 IMemoryOwner 接口

1
2
3
4


public interface IMemoryOwner<T> : IDisposable
{
 Memory<T> Memory { get; }
}

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


谁实现：
 - MemoryPool<T>.Shared.Rent() 返回 IMemoryOwner<T>
 - 自定义实现（包装 ArrayPool）

使用模式：
 using var owner = MemoryPool<byte>.Shared.Rent(1024);
 Memory<byte> mem = owner.Memory;

 // 传给其他方法（不需要释放责任）
 await ProcessAsync(mem);

 // using 自动释放（归还给 Pool）

5.3 IMemoryOwner 的实现示例

 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


using System.Buffers;
using System.Runtime.CompilerServices;

public sealed class ArrayPoolOwner<T> : IMemoryOwner<T>
{
 private T[]? _array;
 private readonly ArrayPool<T> _pool;

 public ArrayPoolOwner(T[] array, ArrayPool<T> pool)
 {
 _array = array;
 _pool = pool;
 }

 public Memory<T> Memory => _array ?? throw new ObjectDisposedException(nameof(ArrayPoolOwner<T>));

 public void Dispose()
 {
 var array = Interlocked.Exchange(ref _array, null);
 if (array is not null)
 _pool.Return(array, RuntimeHelpers.IsReferenceOrContainsReferences<T>());
 }
}

// 用法：
public IMemoryOwner<byte> GetBuffer(int size)
{
 var array = ArrayPool<byte>.Shared.Rent(size);
 return new ArrayPoolOwner<byte>(array, ArrayPool<byte>.Shared);
}

1
2
3
4
5


设计哲学：
 - Memory<T> = "使用权"（可以读、可以切片、可以传递）
 - IMemoryOwner<T> = "所有权"（谁负责释放）

 类似 C++ 的 unique_ptr / shared_ptr 模式

六、MemoryPool 与 ArrayPool：池化是关键

6.1 为什么池化

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


每次 new byte[4096] 的代价：
 1. 分配（堆上找空间）
 2. GC 跟踪
 3. 触发 GC 时回收
 4. 总大小约 85,000 字节及以上的对象通常进入 LOH；阈值和回收行为应以目标运行时为准

 - Web 服务器每秒 1000 请求 × 每请求 4KB buffer = 约 4MB/s 短命对象分配
 - 这会增加 GC 压力；是否以及何时触发 Gen2 GC 取决于 GC 模式、堆预算、存活对象和内存压力

池化的核心：
 - 租一个 buffer（Rent）：池里有就用，没有就 new
 - 用完归还（Return）：放回池，下次复用
 - 降低分配率，但池和新建数组仍由 GC 管理

6.2 ArrayPool：池化的底层

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


// 租
byte[] buffer = ArrayPool<byte>.Shared.Rent(4096);
// 注意：实际返回的数组可能比请求的大（向上取整）
// 长度看 buffer.Length，不是 4096

try
{
 // 用 buffer
 int read = await stream.ReadAsync(buffer, 0, 4096);
}
finally
{
 // 归还
 ArrayPool<byte>.Shared.Return(buffer);

 // 敏感数据需要清理时使用 clearArray: true；同一数组只能归还一次
}

1
2
3
4
5
6
7
8


ArrayPool.Shared 的实现：
 - 每个桶（bucket）对应一种大小的数组
 - 线程本地缓存 + 全局共享
 - 具体桶大小和缓存策略属于运行时实现细节，不应作为应用契约

注意：
 - 不能保存对归还后的数组的引用（你已不再"拥有"它）
 - 不能假设 Rent 的长度正好等于请求长度

6.3 MemoryPool：池化的 Memory 包装

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


// MemoryPool<T> 是 ArrayPool<T> 的"Memory 化"包装
using IMemoryOwner<byte> owner = MemoryPool<byte>.Shared.Rent(4096);
Memory<byte> mem = owner.Memory;

// mem.Length 可能 > 4096（实际数组大小）
// 切片到精确大小
Memory<byte> exact = mem.Slice(0, 4096);

await ProcessAsync(exact);

// using 自动归还

1
2
3
4
5


实际差别：
 - ArrayPool<byte>.Rent() → byte[] （要自己管 finally）
 - MemoryPool<byte>.Rent() → IMemoryOwner<byte> （using 即可）

 选择依据是 API 是否需要显式所有权，不是简单的新旧关系

6.4 池化的坑

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


// 坑 1：使用了归还后的数组
byte[] buf = ArrayPool<byte>.Shared.Rent(100);
ArrayPool<byte>.Shared.Return(buf);
buf[0] = 1; // ⚠️ buf 已不属于你，可能被别人覆盖

// 坑 2：在 using 之后还使用 Memory
async Task BadAsync()
{
 Memory<byte> mem;
 using (var owner = MemoryPool<byte>.Shared.Rent(100))
 {
 mem = owner.Memory; // 拿到引用
 } // ← owner 已 Dispose，buffer 已归还！
 mem.Span[0] = 1; // ⚠️ 未定义行为
}

// 坑 3：多线程同时 Rent + Return 同一数组
// 需要协议保证只在使用期间持有

// 坑 4：忘记 Return 会让数组长期离开池并增加后续分配压力；
// 数组最终仍可由 GC 回收，不属于不可回收的原生内存泄漏

七、实战场景

7.1 高性能 IO：Stream.ReadAsync(Span) vs ReadAsync(Memory)

 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


// ❌ 同步 Span 版本：不能跨 await
public byte[] ReadAll(Stream stream)
{
 using var ms = new MemoryStream();
 Span<byte> buf = stackalloc byte[4096];
 int read;
 while ((read = stream.Read(buf)) > 0)
 {
 ms.Write(buf.Slice(0, read));
 }
 return ms.ToArray();
}

// ✅ 异步 Memory 版本
public async Task<byte[]> ReadAllAsync(Stream stream)
{
 using var ms = new MemoryStream();
 using var owner = MemoryPool<byte>.Shared.Rent(4096);
 Memory<byte> buf = owner.Memory;

 int read;
 while ((read = await stream.ReadAsync(buf)) > 0)
 {
 ms.Write(buf.Span.Slice(0, read));
 }
 return ms.ToArray();
}

1
2
3
4
5
6


Stream.ReadAsync 的演进：
 .NET Framework：ReadAsync(byte[], offset, count)
 .NET Core 2.1+：Stream 的 ReadAsync(Memory<byte>) 虚方法（返回 ValueTask<int>）
 .NET Standard 2.1+：原生支持

 异步 API 优先使用 Memory 重载；是否零分配取决于具体 Stream 实现和操作是否同步完成

7.2 文本解析器：避免 LOH

 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
38
39
40
41


// 大文件逐行解析（避免一次性 ReadAllText）
public async IAsyncEnumerable<(int Line, string Text)> ParseLinesAsync(
 Stream stream,
 [EnumeratorCancellation] CancellationToken ct = default)
{
 using var owner = MemoryPool<byte>.Shared.Rent(64 * 1024);
 Memory<byte> buf = owner.Memory;

 int buffered = 0;
 int lineNo = 0;

 while (true)
 {
 if (buffered == buf.Length)
 throw new InvalidDataException("Line exceeds the 64 KiB buffer.");

 int read = await stream.ReadAsync(buf.Slice(buffered), ct);
 if (read == 0)
 {
 if (buffered > 0)
 yield return (++lineNo, Encoding.UTF8.GetString(buf.Span[..buffered]));
 break;
 }
 buffered += read;

 // 找换行
 var data = buf.Slice(0, buffered);
 int idx;
 while ((idx = data.Span.IndexOf((byte)'\n')) >= 0)
 {
 lineNo++;
 var line = data.Slice(0, idx);
 yield return (lineNo, Encoding.UTF8.GetString(line.Span));
 data = data.Slice(idx + 1);
 }

 // 剩余的移到 buf 开头
 data.Span.CopyTo(buf.Span);
 buffered = data.Length;
 }
}

7.3 协议解析：Memory 切片传递

 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
38
39
40
41
42


// 解析二进制协议（如 MessagePack / Protobuf）
public sealed class ProtocolReader : IDisposable
{
 private readonly Stream _stream;
 private readonly IMemoryOwner<byte> _owner;
 private Memory<byte> _buffer;

 public ProtocolReader(Stream stream, int bufferSize = 4096)
 {
 _stream = stream;
 _owner = MemoryPool<byte>.Shared.Rent(bufferSize);
 _buffer = _owner.Memory;
 }

 public async Task<ReadOnlyMemory<byte>> ReadMessageAsync()
 {
 // 读 header（4 字节长度）
 await ReadExactAsync(_buffer.Slice(0, 4));
 int length = BitConverter.ToInt32(_buffer.Span.Slice(0, 4));

 // 读 body
 if (length < 0 || length > _buffer.Length - 4)
 throw new InvalidOperationException("Message too large");

 var body = _buffer.Slice(4, length);
 await ReadExactAsync(body);
 return body;
 }

 private async Task ReadExactAsync(Memory<byte> dst)
 {
 int total = 0;
 while (total < dst.Length)
 {
 int read = await _stream.ReadAsync(dst.Slice(total));
 if (read == 0) throw new EndOfStreamException();
 total += read;
 }
 }

 public void Dispose() => _owner.Dispose();
}

7.4 ASP.NET Core 内部的 Memory

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


ASP.NET Core 大量用 Memory<T>：
 - HttpContext.Request.Body : Stream，内部用 PipeReader
 - PipeReader 读出 ReadOnlySequence<byte>（一堆 Memory 拼接）
 - Response.Body.WriteAsync(ReadOnlyMemory<byte>)
 - SignalR 传输用 Memory<byte>

System.IO.Pipelines（Pipe / PipeReader / PipeWriter）：
 - 微软的"高性能 IO 抽象"
 - 替代 Stream 的"读一点写一点"模式
 - 内部全部 Memory<T> + IMemoryOwner<T>

八、ReadOnlyMemory 与可变性

1
2
3
4
5
6
7
8
9


Memory<byte> mem = new byte[100];
ReadOnlyMemory<byte> rom = mem; // 隐式转换

// ReadOnlyMemory 不能改
rom.Span[0] = 1; // ❌ 编译错误

// 但底层是同一个数组！
mem.Span[0] = 1;
Console.WriteLine(rom.Span[0]); // 1

1
2
3
4
5
6
7
8


观察：
 - ReadOnlyMemory<T> ≠ 不可变数据
 - 只是你"看不到"修改权限
 - 实际数据可能被另一个 Memory 引用修改

真正不可变的：
 - ImmutableArray<T>
 - 用 ToArray() 拷贝出来的副本

九、常见陷阱与最佳实践

9.1 持有 Memory 实际持有大数组

1
2
3
4
5
6
7
8
9


// 危险：Memory 是"切片"，但底层对象是整个数组
byte[] big = new byte[10_000_000];
Memory<byte> small = big.AsMemory(0, 10);

// small 看起来只有 10 字节，但 big 不能被 GC 回收！
return small; // small 存活期间会保留整个大数组；这是内存保留，不是不可回收泄漏

// 解决：用 ToArray()（如果数据真的小）
return small.ToArray();

1
2
3
4


Memory<T>.Pin() 也会 pin 整个数组：
 var handle = mem.Pin();
 // 在 handle Dispose 之前，整个底层数组被 GC pin
 // 不能移动、不能回收

9.2 跨 Method边界传递 Span

1
2
3
4
5


// ✅ 同步处理应优先接受 Span：编译器会阻止它逃逸
public void Process(Span<byte> data) { ... }

// 异步方法或需要把缓冲区存入字段时再使用 Memory
public Task ProcessAsync(Memory<byte> data) { ... }

9.3 用 ReadOnlyMemory 表达契约

1
2
3
4
5
6


// 表达"我只读不改"的契约
public Task<int> ParseAsync(ReadOnlyMemory<byte> data);

// 调用方既能传 Memory 也能传 ReadOnlyMemory
Memory<byte> m = ...;
await ParseAsync(m); // 隐式转换

9.4 避免 Memory 装箱

1
2
3
4
5
6


// Memory 是 struct，但装箱到 object 仍然是性能损失
object boxed = (object)mem; // ⚠️ 装箱
async Task<object> GetBoxedAsync() => mem; // ⚠️ 装箱

// 直接用 Memory<T>，不要用 object
async Task<Memory<byte>> GetAsync() => mem;

9.5 验证生命周期

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


public async Task BadAsync()
{
 Memory<byte> mem;
 using (var owner = MemoryPool<byte>.Shared.Rent(100))
 {
 mem = owner.Memory;
 // ❌ 把 mem 注册到回调，回调在 using 之后执行
 RegisterCallback(() => {
 mem.Span[0] = 1; // 已归还的 buffer！
 });
 }
}

// ✅ 正确：所有使用都在 using 范围内
public async Task GoodAsync()
{
 using var owner = MemoryPool<byte>.Shared.Rent(100);
 Memory<byte> mem = owner.Memory;
 await ProcessAsync(mem); // 整个 await 都在 using 范围内
}

十、MemoryMarshal：不安全边界

MemoryMarshal 提供"破坏封装"的低级操作，只在性能关键路径上用。

10.1 AsBytes：把 Memory 当 byte 看

1
2
3
4
5
6
7


int[] ints = new int[] { 1, 2, 3 };
Memory<int> mi = ints;

Span<byte> mb = MemoryMarshal.AsBytes(mi.Span);
// mb 是 12 字节，包含 ints 的原始字节

// 用途：序列化、CRC、二进制协议

10.2 Cast：类型重新解释

1
2
3
4
5
6


Memory<byte> bytes = new byte[16];
Span<int> ints = MemoryMarshal.Cast<byte, int>(bytes.Span);
// ints 现在是 4 个 int，指向同一块内存

// 结果长度按总字节数 / sizeof(TTo) 计算；末尾不足一个 TTo 的字节不会出现在结果 Span 中
// 这里 byte (1) → int (4)：16/4 = 4 个 int

10.3 TryGetArray：拿到原数组引用

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


Memory<byte> mem = new byte[100];

if (MemoryMarshal.TryGetArray(mem, out ArraySegment<byte> seg))
{
 // seg.Array 是原数组
 // seg.Offset 是偏移
 // seg.Count 是长度

 // 用途：调用旧 API（如 Stream.Read(byte[], offset, count)）
}

1
2
3
4
5
6


TryGetArray 失败的场景：
 - Memory 来自 string（仅 char）
 - Memory 来自 MemoryManager<T>
 - 没有底层托管数组

→ 失败时需要 fallback：拷贝到临时数组

10.4 CreateFromPinnedArray：包装已固定的数组

1
2
3
4
5


byte[] arr = GC.AllocateUninitializedArray<byte>(100, pinned: true);
// 该 API 不会替你执行 pin；数组必须已由调用方固定
Memory<byte> mem = MemoryMarshal.CreateFromPinnedArray(arr, 0, 100);

// 用途：与 native 代码互操作（P/Invoke）

十一、性能基准

用 BenchmarkDotNet 看 Span vs Memory vs Array：

 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


// 基准测试代码
[MemoryDiagnoser]
public class MemBench
{
 private byte[] _data = new byte[1024];

 [Benchmark]
 public int SumArray()
 {
 int sum = 0;
 for (int i = 0; i < _data.Length; i++) sum += _data[i];
 return sum;
 }

 [Benchmark]
 public int SumSpan()
 {
 int sum = 0;
 foreach (var b in _data.AsSpan()) sum += b;
 return sum;
 }

 [Benchmark]
 public int SumMemory()
 {
 int sum = 0;
 foreach (var b in _data.AsMemory().Span) sum += b;
 return sum;
 }
}

1

不要在没有 CPU、运行时版本、BenchmarkDotNet 输出和统计误差的情况下给出“典型结果”。JIT 可能对三种循环做出相同或不同优化；应在目标运行时运行该基准，并检查均值、误差、反汇编与分配列。

十二、小结

本文从 Span<T> 的"栈枷锁"出发，系统讲了 Memory<T>：

Memory<T> 的内部布局：object + index + length（不持 ref）
为什么这样设计：可装箱、可跨 await、可作为字段
三种来源：T[] 数组、string、MemoryManager
与 Span 的转换：Memory.Span 提取、不能反向
IMemoryOwner<T> 的所有权语义
ArrayPool<T> 与 MemoryPool<T> 的池化机制
实战场景：异步 IO、文本解析、协议解析、ASP.NET Core 内部
常见陷阱：持有切片但底层数组泄露、生命周期错位、装箱
MemoryMarshal 的不安全操作

1
2
3
4


记住三句话：
 1. Span 是受 ref-safety 约束的同步视图，Memory 是可存储、可异步持有的描述
 2. Memory<T>.Span 是一次"安全握手"，提取后 Span 仍然不能逃逸
 3. 池化用于解决已经测量到的分配压力，同时必须严格遵守所有权和租约

写异步 I/O 或解析器时，先选清晰、正确的所有权模型；只有 profiling 显示缓冲区分配是瓶颈时，再引入 ArrayPool<T> 或 MemoryPool<T>。

参考资料

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

Thu, 27 Nov 2025 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。

一次请求，按本文模型拆成十个阶段（编号 0–9）：

 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 或本地解析器缓存命中通常很快；未命中时，递归解析器可能继续查询权威 DNS，耗时受缓存状态、网络路径和解析链影响，不能固定写成一个范围。

优化：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 / 连接池让后续请求复用已经建立的连接，避免重复支付 TCP 和 TLS 握手。TLS 1.3 会减少完整握手往返；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）、可选的鉴权前置。TLS 是否在此终止、到上游是否重新加密，取决于信任边界和部署配置，不能默认上游一定走明文。

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

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

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

包到内核了。Kestrel 使用操作系统的异步/事件驱动 I/O 机制，并利用 System.IO.Pipelines 的池化缓冲区减少分配和不必要的复制，再把请求交给 ASP.NET Core 管线。异步 I/O 避免在等待网络时长期占用请求线程，但业务代码仍可能因同步阻塞、锁竞争或 CPU 密集工作占住线程。

这一跳的关键是避免在线程上同步等待慢 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 → 对端应用。

延迟 = 网络往返 + 两端序列化 + 对端处理 + 可能的代理成本。代理会增加数据路径、CPU 和排队成本，但没有适用于所有环境的固定“每 hop 2–5ms”。Istio 官方基准明确指出，延迟取决于协议、连接数、请求率、负载、worker 数和启用的功能；应在自己的拓扑和策略下测 p50/p99。

优化：

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

第 9 跳：序列化 + 返回

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

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

把全程延迟叠起来

下面只是展示如何列预算的示例假设，不是可直接套用的基准。真实系统要用 trace 分阶段测量，并分别观察 p50、p95 和 p99：

跳	热请求	冷启动 / 缓存未命中
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
下游服务	取决于 RTT 与对端处理	取决于 RTT、握手与对端处理
序列化 + 返回	~1ms	~1ms
合计	按各阶段实测相加	按各阶段实测相加

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

全链路可观测

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

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

小结

一次请求可以拆成十个阶段（编号 0–9）：DNS → TCP/TLS → LB → Nginx → Kestrel → 中间件 → Redis → DB →（下游服务）→ 序列化返回。不是每个部署都包含全部阶段。
总延迟 = 各阶段之和，先抓实测大头：远程 I/O 和网络 RTT 经常占主要部分，但 CPU、锁竞争和排队在高负载下同样可能成为瓶颈。
杠杆最大的两处：缓存命中（直接省掉 DB 那一跳）+ 连接复用（省掉握手那两跳）。
微服务多一层通信成本：RTT、序列化、对端处理和代理都会进入预算，能安全并行的独立调用不要无谓串行。
排障靠全链路 trace：traceId 贯穿所有跳，是"慢在哪"的答案。

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

参考资料

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

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

Sun, 23 Nov 2025 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）；
从 CPU 缓存到远程 I/O 会跨越多个数量级；“微秒是分水岭”只是一种帮助记忆的说法，不是严格分类。

记住这种数量级跨度，比记住任何一个具体数字都重要。

关于这张表的出处和精度：它来自 Jeff Dean 早期演讲中广泛传播的一组经典数值，给你的是历史数量级示例而非现代硬件规格。CPU、内存和存储的绝对值与比例都会随平台变化；真正长期有用的是“先辨认跨层访问的数量级，再测目标系统”。完整来源与演进见第十节。

二、把 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 流水线会付出预测失败代价。在某些基准里，先排序能让后续分支更可预测，但排序本身有成本；只有重复扫描或数据量、分布满足条件时才可能更快，不能当成通用优化。
结构体布局 把经常一起用的字段放一起、紧凑排列（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 应以实际线路测量，不能断言必然从 20 ms 起。

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

1
2
3
4
5
6


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

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

这就解释了为什么批量（batching）常常有效：把许多次独立往返合并，能降低往返和协议开销；代价是等待凑批、单批变大以及失败重试粒度变粗，因此并非越大越好。

六、一次 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 往往远慢于 CPU 操作；异步 I/O 的价值是等待期间释放线程去处理其他工作，而不是因为线程本身是“纳秒级资源”。
 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
GC 暂停	从亚毫秒到秒级都有可能，取决于运行时、堆规模、代际和 GC 模式，应以 trace/指标为准

数据层

操作	典型量级
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）	增加代理处理与排队；数值随协议、连接、负载、worker 和功能变化，需实测
经 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 模式下，一个请求会经过客户端和服务端 Envoy。Istio 官方基准没有给出一个可脱离测试条件复用的固定税率，而是按协议、请求率、连接、负载、代理 worker 和 mTLS 等条件展示 p90/p99。Ambient 用共享 ztunnel 和按需 waypoint 避免 per-Pod sidecar；Cilium 则让更多 L3/L4 工作走 eBPF 数据路径。选型应复现目标环境，而不是套用固定毫秒数。

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

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

一次 DB 查询 ≈ 若干次内存访问 + 可能的一次磁盘 IO；
一次同机房 gRPC ≈ 1 个数据中心 RTT + 两端序列化 + 两端处理；
一次穿 Service Mesh 的调用 ≈ 上一条 + 两端代理、策略、遥测和排队成本；
一次跨 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 版；
它们是量级参考，不是精确值。CPU 微架构、内存拓扑、SSD 队列深度、网络路径和软件栈都会改变结果。抓层次关系并在目标平台复测，而不是死记绝对值或固定比例；
要测自己的系统。生产里的真实数字，永远来自你自己的监控：看 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、ztunnel 与 waypoint 延迟图）
Performance Comparison of Service Mesh Frameworks — arXiv（mTLS 下各 mesh 延迟对比）

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

小结

一张历史基准表：从 L1 缓存到跨洲网络跨越约 8 个数量级，用于建立直觉，不是现代设备规格表；
人化直觉：把 1 ns 当 1 秒，CPU 读主存约等一分多钟，等磁盘约数月，等跨洲网络约数年；
CPU↔内存：差 200 倍，缓存层次和数据本地性是一切优化的根基；
磁盘：HDD/SSD/NVMe 差三个量级，“随机 vs 顺序"是永恒命题，WAL/LSM/Kafka 都是把随机转顺序；
网络：距离与介质传播速度给出 RTT 下限；小请求常由 RTT 主导，批量可以减少往返，但要权衡凑批等待与失败粒度；
HTTP 请求 = 几个 RTT + 服务端处理，连接复用省掉的就是那 2 个握手 RTT；
现实操作量级：Redis、DB、RPC 的延迟要结合部署、负载和尾延迟观察；Kubernetes 与 Service Mesh 数据路径尤其需要在自己的 CNI、策略和并发下测量；
8 条决策：缓存分层、异步并发、批量、数据本地性、顺序写、有依据的超时、正视微服务调用成本、压缩的权衡；
方法论：抓数量级而非绝对值，看 p99 而非平均，用封底估算做设计判断。

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

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

Fri, 21 Nov 2025 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、ASH 以及相关历史视图属于 Oracle Diagnostics Pack 的能力。使用前先核对数据库版本、版本授权和 CONTROL_MANAGEMENT_PACK_ACCESS 配置；没有相应许可时，改用动态性能视图、Statspack 等已获许可的工具，不能因为命令可执行就默认有权使用。

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 查看，部分样本会进入 AWR 历史数据；两者都受 Diagnostics Pack 许可约束。

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 redo 刷盘；可能与提交过频、存储延迟或日志路径负载有关，需继续分解
- 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 开头的条件；只查 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 是否入普通 B-tree 索引	全部键列都为 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 子查询:现代优化器往往能把它改写为半连接，但复杂相关子查询或估算失准时仍可能产生差计划。先看执行计划，再考虑等价地改写为 JOIN 或 EXISTS；改写时注意重复行和 NULL 语义。
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 的 direct-path insert 可配合 APPEND，NOLOGGING 仅在满足条件的操作上减少 redo，并会影响介质恢复和 Data Guard 可恢复性；使用后必须按备份与容灾策略处理，不能把它当成通用开关。
顺序键通常减少随机页访问，但可能形成热点:自增主键 / 序列有利于局部性，却可能在高并发下让最右侧叶块或页成为竞争点；应以目标数据库和负载实测为准。

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

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`	`ATTACH PARTITION` / `DETACH PARTITION`	`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：定位瓶颈与榨干性能

Tue, 25 Feb 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
21


关键指标解读：

 指标 主要观察点
 ─────────────────────────────────────────────────────────────
 cpu-usage 是否长期接近已分配 CPU 上限，并与吞吐/延迟同步恶化
 time-in-gc 与自身基线相比是否持续升高，是否对应暂停与尾延迟
 alloc-rate 单位吞吐分配量是否上升，而不只看绝对速率
 gen-0/1/2-gc-count 看单位时间增量及代际结构；频率必须结合堆大小和负载解释
 gc-heap-size 完整 GC 后的存活集是否持续增长；增长本身不等于泄漏
 threadpool-queue-length 队列是否持续积压且完成速率跟不上进入速率
 exception-count 异常速率是否偏离业务基线，尤其是被捕获后继续运行的异常
 working-set 是否逼近容器/主机限制，以及回收后能否回落

不要把 60%、10 条队列或“几分钟一次 Gen 2”当作通用告警线。阈值应由 SLO、
容量上限和同类负载基线推导，并在压测中验证。

诊断思路：
 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


.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；后台 GC 可让部分标记工作与应用并发，但仍有暂停阶段

性能优化重点是降低不必要的分配和长期存活对象，并观察暂停时间而非只数 Gen 2 次数。
完整 GC 通常更昂贵，但后台 Server GC 不等于从头到尾都停止所有托管线程。

5.2 Workstation GC vs Server GC

runtimeconfig.json 中可这样配置：

1
2
3
4
5
6


{
 "configProperties": {
 "System.Runtime.GC.Server": true,
 "System.Runtime.GC.Concurrent": true
 }
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


 Workstation GC Server GC
──────────────────────────────────────────────────────────
堆数量 通常 1 个 多个堆并行回收；数量由运行时、CPU/容器限制和配置决定
线程 少 多（每核 GC 线程）
吞吐量 低 高
内存占用 小 大（多堆）
适用 客户端、单核 服务器、多核、高并发

ASP.NET Core Web SDK 项目通常启用 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 高并发编程全景：从异步到高性能实战

Sun, 23 Feb 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 能以较少线程维持大量并发连接的重要条件之一；实际容量还取决于协议、负载、下游依赖、内存和硬件，不能由 async 单独推导固定并发数

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 → 不会形成典型的 UI 上下文死锁
 但通用类库仍不应假设调用方没有上下文

3.7 async 死锁

async 最经典的坑：在带同步上下文的环境里，用 .Result / .Wait() 同步阻塞一个未完成的 Task，会永久卡死。

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


// WinForms / WPF / 老 ASP.NET（有 SynchronizationContext）才触发

private void Button_Click(object sender, EventArgs e) // UI 线程
{
 // ❌ 同步等异步方法 → 死锁，永远走不到下一行
 var data = GetDataAsync().Result;
 textBox1.Text = data;
}

private async Task<string> GetDataAsync()
{
 var json = await _httpClient.GetStringAsync(url);
 return Parse(json);
}

1
2
3
4
5
6
7
8


死锁怎么形成的：
 1. UI 线程调 .Result，把自己堵住等 Task 完成
 2. GetDataAsync 跑到 await 返回，注册"完成后回 UI 线程"的延续
 3. HTTP 数据回来了，想在 UI 线程上跑延续（Parse 那段）
 4. 但 UI 线程还被 .Result 堵着，腾不出手
 5. 延续等 UI 线程 → Task 永远完不成 → .Result 永远等

 根因：调用方占着"唯一能跑完这个 Task 的线程"去等它

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


// 解法一：一路 async 到顶（推荐）
private async void Button_Click(object sender, EventArgs e)
{
 var data = await GetDataAsync(); // 不堵 UI 线程
 textBox1.Text = data;
}

// 解法二：库代码一律 ConfigureAwait(false)
// 完成后不回原上下文，用线程池线程续跑 → 调用方即使阻塞也不会死锁
private async Task<string> GetDataAsync()
{
 var json = await _httpClient.GetStringAsync(url).ConfigureAwait(false);
 return Parse(json);
}

捕获的是"上下文"，不是"线程"

await 完到底回哪？常见误解是"回到原线程"——错。await 捕获的是 SynchronizationContext（优先），没有则退到 TaskScheduler，从来不是线程 ID。延续最终跑在哪个线程，看那个上下文怎么调度：

环境	await 时 SyncContext.Current	默认 await	ConfigureAwait(false)
WinForms / WPF（UI 线程上 await）	UI 的 SyncContext，绑单一 UI 线程	回 UI 线程	丢线程池
老 ASP.NET（非 Core）	AspNetSynchronizationContext	回请求上下文	丢线程池
ASP.NET Core / 一般控制台代码	通常为 null	通常在线程池调度延续	通常在线程池调度延续

“回到原线程"只在 UI 场景才成立——UI 的 SyncContext 绑死单一 UI 线程，“回到这个 context"就等于"回到 UI 线程”。这是大家口中"await 完回到原线程"唯一真正成立的场景。

1
2
3
4
5
6
7


最易踩的坑：
 决定回不回的，是 await 那一刻 SyncContext.Current 是什么
 跟"在哪种程序里"无关

 哪怕在 WinForms 程序里，只要 await 是在线程池线程上发起的
 （比如 Task.Run 里面），SyncContext.Current 就是 null
 → 延续照样丢线程池，不回 UI

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


// 一段代码同时验证"线程"和"上下文"两件事
var t1 = Environment.CurrentManagedThreadId;
var ctx = SynchronizationContext.Current?.GetType().Name;
await Task.Delay(100);
var t2 = Environment.CurrentManagedThreadId;
Console.WriteLine($"线程 {t1}→{t2}（同? {t1 == t2}），上下文 = {ctx ?? "null"}");

// 控制台： 上下文通常为 null；t1 可能等于或不等于 t2，不能依赖
// WinForms UI 线程： t1 == t2，上下文 WindowsFormsSynchronizationContext
// 老 ASP.NET： 上下文 AspNetSynchronizationContext（串行、会阻塞）

类库为什么也会死锁：看宿主，不看项目类型

一个高频疑问：我这是个类库项目，哪来的同步上下文？类库自己确实不安装任何 SynchronizationContext，但它被谁调用，就继承谁的上下文。SynchronizationContext 是调用线程的属性，不是项目类型的属性：

实际宿主	调用线程上的 SyncContext	类库里的 async 死锁？
老 ASP.NET 站点	AspNetSynchronizationContext	会
WinForms / WPF	UI SyncContext	会（UI 线程阻塞时）
控制台 / ASP.NET Core	通常为 null	不会形成典型的上下文互等，但同步阻塞仍可能造成线程池饥饿或其他锁死
单元测试	取决于测试框架	某些框架会安装自定义上下文，不能一概而论

同一份类库代码、一行不改：控制台直接调 → 不死锁；被老 ASP.NET 加载执行 → 死锁。这正好解释了经典的"开发机正常、上线才炸”——开发时在控制台/单测里没 SyncContext 不重现，一上 ASP.NET 宿主就中招，往往压测才暴露。

1
2
3
4
5
6


怎么实锤就是 SyncContext 死锁？
 在 await 前打印 SynchronizationContext.Current?.GetType().FullName

 抓到 System.Web.AspNetSynchronizationContext → 实锤
 打印出 null 却仍卡死 → 别的问题
 （线程池饥饿 / 假异步 / 回调没回来），别错怪 SyncContext

为什么 ASP.NET Core 不中招

ASP.NET Core 默认不安装请求级 SynchronizationContext，await 完成后延续通常在线程池上续跑，不依赖“原请求线程”，因此不会形成典型的 UI 上下文互等。此时 ConfigureAwait(false) 通常不会带来可观的上下文切换收益，但通用类库可用它声明不依赖调用方上下文。

但别因此就敢在 ASP.NET Core 里乱写 .Result：不会死锁，但会耗尽线程池（见下）。

现代 .NET 的"伪死锁"

ASP.NET Core 不会因默认请求上下文形成那一种经典死锁，但代码仍可能因普通锁、资源循环等待或自定义调度器真正死锁；同步阻塞异步还会造成线程池饥饿，使请求堆积、响应飙升。

1
2
3
4


规则（所有环境通用）：
 ✓ async 方法一路 async 到顶，别中途 .Result / .Wait() / .GetAwaiter().GetResult()
 ✓ 不需要调用方上下文的通用类库可使用 ConfigureAwait(false)；应用/UI 代码则按是否需要回到上下文决定
 ✗ 别图省事把异步包成同步，迟早要还

3.8 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）

Fri, 21 Feb 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 工具，基本工作流相近；受操作系统转储格式、运行时版本和可用诊断 API 影响，支持的转储类型与命令细节并非完全相同。

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 概念和命令，但调试器宿主、原生栈支持及个别命令能力不同。下面列的是常见交集，使用时仍应以当前工具的 help 为准。

 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（图形化，工具链丰富）
通用命令：dumpheap、gcroot、syncblk、pe 等 SOS 命令有较大交集，但能力会随宿主、平台和运行时版本变化
四大场景：内存泄漏、CPU 飙高、死锁、崩溃的抓取和分析
最佳组合：Linux 生产抓 dump → 拷到 Windows 图形化分析

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

Linux 性能诊断速查手册

Wed, 18 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 使用率。与逻辑 CPU 数比较只能作为线索；还要结合 vmstat 的 r/b、CPU 利用率和 I/O 指标判断。

wa（iowait）：表示 CPU 空闲期间存在未完成块 I/O 的时间比例。高值值得继续调查，但低值不能排除 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 — 不可中断睡眠中的任务数；持续非零提示有阻塞，应继续定位等待源
# 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


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

# 关键指标：
# %util — 设备处理 I/O 的时间比例；对并行设备/虚拟设备不能直接当作饱和度
# await — I/O 从提交到完成的平均时间，需与设备类型和业务基线比较
# r/s — 每秒读次数
# w/s — 每秒写次数
# rkB/s — 每秒读速度（KB）
# wkB/s — 每秒写速度（KB）
# aqu-sz（旧版可能显示 avgqu-sz）— 平均队列长度，需结合并发能力和延迟判断

不存在跨 HDD、SSD、NVMe、RAID 和云盘都适用的固定阈值。用业务正常期基线对比 await、队列、吞吐、IOPS 与尾延迟，再关联到进程和具体请求。

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


# 测试顺序读速度
sudo hdparm -Tt /dev/sda

# 生产磁盘不要直接用 dd 做写入基准。优先在隔离测试卷上使用 fio，
# 明确文件路径、容量、块大小、队列深度、读写比例、direct I/O 和运行时间，
# 并确认测试文件不会覆盖业务数据。不同参数的结果不能直接横向比较。

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% — 探测包未获响应的比例；中间路由器可能限速 ICMP，需看后续各跳和端到端结果
# 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 应用
jcmd <PID> GC.heap_info
jcmd <PID> GC.class_histogram | 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


# Fedora / 当前 RHEL 系发行版
sudo dnf 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

Performance on 纪伟的个人博客

Python 编程基础与工程实践（十）：性能分析、构建与交付

1. 先定义性能问题

2. 正确测量小段代码

3. 用 cProfile 找热点

4. 从算法和数据结构开始

5. 惰性处理与内存占用

6. 用 tracemalloc 定位 Python 分配

7. 解释器、扩展与并行策略

8. 构建 wheel 与源码发行包

9. 发布库与部署应用是两件事

10. 安全发布

11. 部署后的性能闭环

12. 系列总结

参考资料

Python 编程基础与工程实践（八）：线程、进程、asyncio 与 GIL

1. 并发、并行和异步不是同义词

2. 默认 CPython 的 GIL 到底保证什么

3. Python 3.14 的自由线程构建

4. 线程：适合阻塞 I/O 和同步库

5. 进程：隔离地址空间并利用多核

6. Python 3.14 的子解释器执行器

7. asyncio：协作式并发

8. 不要阻塞事件循环

9. 超时、取消和清理

10. 背压与有界并发

11. 如何做选择

12. 小结

参考资料

线程安全的本质：从 CPU 缓存到内存模型，锁到底在保证什么

写在前面

一、三种"不安全"：原子性、可见性、有序性

数据竞争 ≠ 竞态条件

二、硬件层：为什么"看见"这么难

缓存层级：慢的不是运算，是搬运

缓存一致性：它保证的比你想的少

x86 和 ARM：强序与弱序

别忘了第二个重排来源：编译器

三、内存模型：语言和程序员的合同

四、语言层：同一问题的五种答案

.NET：基线很弱，实现很强，文档没跟上

Java：JSR-133，语言级内存模型的标杆

C++：把选择权全部给你，代价是全归你管

Go：只给最强档，附赠一句忠告

Rust：把线程安全搬进类型系统

五种答案对照

五、工具层：C# 的同步原语与屏障语义

lock / Monitor：互斥 + 获取/释放语义

Interlocked：原子操作 + 强同步排序

volatile：半个屏障，三个"不保证"

64 位撕裂：一个跨语言的经典坑

线程 API 自带屏障

原语对照表

六、贯穿案例：双检锁的三次重生

版本 1：无 volatile 的 DCL——为什么错

版本 2：加 volatile 的 DCL——为什么对

版本 3：static readonly 与 Lazy<T>——为什么过时

七、同步的代价：争用与 false sharing

八、为什么你的单元测试测不出来

九、边界与取舍：四种并发策略

小结

参考资料

epoll 的前世今生：从 select/poll 的性能困局到 io_uring 的挑战

一、故事的起点：一个线程伺候一个连接

二、第一代多路复用：select（1983，4.2BSD）

三、poll：去掉了 1024，但没去根

四、同时代的另一条路：kqueue 与 /dev/poll

五、epoll 登场（Linux 2.5.44，2002）

六、钻进内核：红黑树、就绪链表与回调链路

七、LT vs ET：两种触发模式，两种哲学

八、epoll 的演进史：API 与标志位

九、实战：一个 epoll echo server

十、epoll 的陷阱与坑

十一、谁在用 epoll（后端视角）

十二、终章：io_uring 的挑战（2019，Linux 5.1）

十三、小结

WinForms 学习笔记（六）：线程与 async——UI 线程、Invoke 与死锁

写在前面

一、单 UI 线程模型

二、Control.Invoke / BeginInvoke：回到 UI 线程

3. 用 `cProfile` 找热点

6. 用 `tracemalloc` 定位 Python 分配

7. `asyncio`：协作式并发

版本 3：`static readonly` 与 `Lazy<T>`——为什么过时