Concurrency on 纪伟的个人博客

深入 .NET 锁家族：lock、SemaphoreSlim、ReaderWriterLockSlim 与 SpinLock 的选型边界

Fri, 07 Aug 2026 10:00:00 +0800

写在前面

《线程安全的本质》回答了"锁到底在保证什么"——互斥、获取/释放语义与 happens-before。但工程里的下一个问题往往是选型：这里该用 lock 还是 SemaphoreSlim？读多写少要不要上 ReaderWriterLockSlim？SpinLock 到底有没有用武之地？

这篇按"先问要不要锁 → 默认选择 → 特定场景的替代"组织：lock/Monitor 是默认答案，Interlocked、SemaphoreSlim、ReaderWriterLockSlim、SpinLock、Mutex 各自回答一个 lock 回答不了的问题。示例基于 .NET 10 / C# 14，涉及 System.Threading.Lock（.NET 9+）时单独标注。

前置：知道什么是临界区和数据竞争即可；锁的内存模型语义见《线程安全的本质：从 CPU 缓存到内存模型，锁到底在保证什么》，本文不重复。

一、先问要不要锁

锁清单变长的第一步，往往是"什么都上锁"。先过三道筛子：

1. 能不能不共享？ 局部状态、每次请求新建的对象天然无竞争；Channel<T> 也可以把流程组织成“发送后不再由生产者访问”的所有权转移。注意 Channel<T> 只传递引用，并不会替你禁止双方继续访问同一可变对象，所有权约定仍要由程序保证。

2. 能不能不可变？ 不可变对象、快照替换（通过 Volatile.Read/Volatile.Write 或 Interlocked.Exchange 发布整个引用）能让读者始终看到完整快照，只剩多个写者之间可能需要协调。

3. 单变量能不能用 Interlocked 解决？ 官方最佳实践建议：对简单的状态变更，考虑使用 Interlocked，而不是完整的 lock 临界区。计数器、进度值、状态标志翻转通常都适合这一类原子操作；具体会生成什么机器指令取决于体系结构和 JIT，不能一概描述成“单条带 lock 前缀的指令”。

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


private int _completed; // 计数：一条原子指令
Interlocked.Increment(ref _completed);

private int _max; // lock-free max：CAS 循环
public void Observe(int value)
{
 int current;
 do
 {
 current = _max;
 if (value <= current) return;
 }
 while (Interlocked.CompareExchange(ref _max, value, current) != current);
}

CAS 循环的边界：失败即自旋重试，竞争激烈时浪费 CPU；只适合"简单状态、快进快出"的场景。复合不变量（两个字段必须一起变）就该上锁了。

二、lock / Monitor：默认选择

lock 语句不是新东西，它就是 Monitor 的语法糖——编译产物等价于：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


object gate = new object();
bool lockTaken = false;
try
{
 Monitor.Enter(gate, ref lockTaken);
 // 临界区
}
finally
{
 if (lockTaken) Monitor.Exit(gate);
}

注意 Enter 位于 try 内部——自 C# 4 起编译器就这样展开，ref lockTaken 重载存在的意义正是消除"Enter 成功但还没进入 try"时锁泄漏的窗口。

几个被反复问到的语义：

可重入：同一线程可以多次 Enter 不阻塞，但必须等次数地 Exit，其他等待线程才会解除阻塞——所以"锁内调用会再次拿同一把锁的方法"不会自锁死，但也容易掩盖设计问题。
线程亲和：谁拿谁放。A 线程进入后，B 线程调用 Monitor.Exit 会抛 SynchronizationLockException。
竞争行为：文档只承诺"阻塞直到释放"；“先自旋一会儿再挂起"是 CoreCLR 的实现细节（syncblk.cpp 中按处理器数自适应自旋），不是可以依赖的合同——写代码时按"可能阻塞、可能自旋"两种情况都正确来设计。

.NET 9+ 的 System.Threading.Lock 提供专用锁类型：lock 语句遇到它会编译成 using (x.EnterScope())，API 面包括 Enter/Exit/TryEnter 和 IsHeldByCurrentThread 属性。官方建议 .NET 9 起新代码优先用它。语义上它同样可重入；但"线程在持有 Lock 时退出，行为未定义"是文档明说的——别指望它拯救泄漏的锁。

锁对象的选择比锁类型更容易踩坑：

1
2
3
4
5
6
7


// ❌ lock(this)：外部代码也可能锁这个实例，锁不再私有
// ❌ lock(typeof(Foo))：每个应用域一个 Type 实例，跨代码共享
// ❌ lock("my-lock")：字符串驻留，字面量全局共享
// ❌ lock(42)：值类型过不了编译（CS0185：lock 语句要求引用类型）；
// 绕开 lock 直接调 Monitor.Enter(42) 才会踩装箱——每次实参装箱成不同对象，
// Exit 时抛 SynchronizationLockException
private readonly object _gate = new(); // ✅ 私有、只读、专用

原则一句话：锁对象必须私有、专用、生命周期明确。C# 13+ 直接用 private readonly Lock _gate = new(); 更好。

三、lock 里的 await：为什么编译器直接拒绝

1
2
3
4
5
6


private readonly object _gate = new();

lock (_gate)
{
 await Task.Delay(100); // CS1996: lock 语句体内不能 await
}

这不是编译器保守，而是线程亲和与异步续体不匹配：Monitor 锁由线程持有，await 之后的续体却可能在另一个线程上运行。假如手工把 Monitor.Enter 跨过 await，原锁不会因为挂起而自动释放，其他线程仍会被挡住；续体换线程后再调用 Exit 还会抛 SynchronizationLockException，从而造成锁泄漏。

上例的 _gate 是普通 object，当前 .NET 10 SDK 对这种跨 await 的写法报 CS1996。锁表达式换成 System.Threading.Lock 也不能跨 await；不过它可以出现在 async 方法中，只要整个 lock 作用域里没有 await。手动 Enter/Exit 虽可编译，类型文档仍明确要求两者之间不能出现 await。

因此，需要让互斥范围跨过 await 时，必须改用一个“不绑定线程”的原语——这就轮到 SemaphoreSlim。

四、SemaphoreSlim：BCL 中可 await 的互斥方案

SemaphoreSlim 本义是信号量，initialCount: 1 时它就是一把可异步的互斥锁：

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


private readonly SemaphoreSlim _gate = new(1, 1);

public async Task<Document> LoadAsync(string path, CancellationToken ct)
{
 await _gate.WaitAsync(ct);
 try
 {
 return await LoadAndParseAsync(path, ct); // await 也安全：信号量无线程亲和
 }
 finally
 {
 _gate.Release();
 }
}

选型视角的要点：

无线程亲和：Wait 和 Release 可以由不同线程调用（信号量的文档明说"不强制线程身份”）——这正是它能跨 await 存活的原因。
maxCount > 1 就是限流器：连接池上限、并发导入数、客户端节流——new SemaphoreSlim(8, 8) 允许至多 8 个并发进入，这是 lock 给不了的语义。
顺序无保证：多个等待者被唤醒的顺序不保证 FIFO（文档原话）；当前实现里 async 等待者按 FIFO 链表释放，但那是实现细节，不要依赖。
Release 是同步方法：BCL 里没有 SemaphoreSlim.ReleaseAsync；好在 Release() 本身不阻塞，直接在 finally 里同步调用即可。
Dispose 的边界：Dispose 不与其他成员并发使用，文档要求等所有其他操作结束后再调用。不要把 Dispose 当成“唤醒等待者”的关闭信号：当前 runtime 实现不会替在途的 WaitAsync 完成、取消或设置异常。正确的关闭顺序是先发出取消信号并等待使用者退出，最后再 Dispose；调用已经 Dispose 的实例则会抛 ObjectDisposedException。

它为什么"轻量"：内部基于 Monitor 和自旋，不创建内核对象（只有在访问 AvailableWaitHandle 时才惰性创建内核句柄）。跨进程同步它做不到——那是内核信号量 Semaphore 的事（见第八节）。

五、ReaderWriterLockSlim：读多写少才考虑

读操作不互相互斥、只和写互斥——ReaderWriterLockSlim（下称 RWLS）表达这个语义：

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


private readonly ReaderWriterLockSlim _rw = new(); // 默认 LockRecursionPolicy.NoRecursion
private readonly Dictionary<string, Config> _cache = new();

public Config Get(string key)
{
 _rw.EnterReadLock();
 try
 {
 return _cache[key];
 }
 finally
 {
 _rw.ExitReadLock();
 }
}

它最有特色也最容易用错的是可升级读锁：“先读检查，必要时升级为写"这一 check-then-act 竞态的标准解法：

 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


public Config GetOrCreate(string key)
{
 _rw.EnterUpgradeableReadLock();
 try
 {
 if (_cache.TryGetValue(key, out var cached))
 return cached;

 _rw.EnterWriteLock(); // 升级：不放弃读权限的前提下拿写锁
 try
 {
 // 持有 upgradeable read 期间，其他写者无法进入；这里无需再次检查。
 cached = CreateConfig(key); // 必须快速且不阻塞
 _cache[key] = cached;
 return cached;
 }
 finally
 {
 _rw.ExitWriteLock();
 }
 }
 finally
 {
 _rw.ExitUpgradeableReadLock();
 }
}

这个示例假设 CreateConfig 是快速的内存计算。不要在写锁里执行磁盘、网络 I/O；如果加载过程需要 await，应改用 Task/Lazy<Task<T>> 去重、异步缓存等设计，而不是让线程亲和的 RWLS 跨越异步等待。

规则要点（都有文档背书）：

同一时刻至多一个线程处于可升级模式——因此默认 NoRecursion 策略下升级不会死锁，这是官方推荐默认策略的原因之一。
持读锁时直接 EnterWriteLock 会抛 LockRecursionException，不是死锁：文档把这个模式判为"极易死锁"直接禁止，异常消息会指引你改用 upgradeable。
Enter/Exit 严格配对：多退一次或退没进过的模式都会抛 SynchronizationLockException。
当前公平策略会照顾写者：有写者排队时会阻止新读者进入，以平衡读写双方；官方也明确保留未来调整公平策略的可能，不要把精确唤醒顺序当成合同。

什么时候不用它：读临界区很短时，普通 lock 的开销常常更低（读写锁的簿记本身就是成本）——官方没有给出 RWLS 与 lock 的通用性能结论，社区基准则普遍显示短临界区下 lock 占优，写多读少时更是纯亏。另一个常被忽略的替代：ConcurrentDictionary 内部用细粒度锁实现"读无锁、写按桶加锁”，缓存类场景往往比一把大 RWLS 更好。决策顺序：先用 ConcurrentDictionary 这类结构 → 读临界区确实长且读写比悬殊 → 再考虑 RWLS → 压测说话。RWLS 实现了 IDisposable，宿主对象结束使用且确认已无持有者或等待者后，也应将它 Dispose。

六、SpinLock：几乎不该出现在业务代码

SpinLock 只回答一个问题：临界区经过测量确实很短，而且自旋成本低于阻塞与唤醒成本时，自旋等待可能更便宜。不存在通用的“几十纳秒”阈值，结果取决于处理器、竞争强度和临界区内容。文档给出的使用条件相当苛刻：

1
2
3


private SpinLock _lock = new SpinLock(enableThreadOwnerTracking: true);
// 注意：SpinLock 是 struct——绝不能声明为 readonly 字段，
// 传参必须 by ref；误拷贝会产生两把"各自独立"的锁

持有它期间应避免的操作几乎排除了所有业务代码：阻塞、调用可能阻塞的代码、再持有别的锁、动态分发、调用不受自己控制的代码、分配内存。官方定位是"叶子级锁"——数据结构内部（无锁栈、缓冲池）经 profiling 证明后使用。两个细节：

Exit(Boolean useMemoryBarrier) 重载：传 false 会省略通常由退出操作提供的内存屏障，不能再按普通锁的发布语义理解；默认 Exit() 等价于传 true。除非在底层代码中已经证明内存顺序正确，否则保持默认。
无 abandonment 检测：没进就 Exit 会腐蚀内部状态（文档原话 corrupt）；线程持锁退出也无任何提示。线程所有权跟踪（构造参数 true）只帮助调试非持有者 Exit 的问题。

选型建议一句话：在想到 SpinLock 之前，先想 Interlocked；两者都不行，大概率你要的是普通 lock。

七、跨进程：Mutex 与内核 Semaphore

前面所有锁都活在进程内。跨进程互斥需要内核对象：

Mutex——“比 Monitor 消耗更多系统资源，但可以跨应用域边界、支持多种等待、可以同步不同进程中的线程”。下面是 Windows 上单实例应用的简化写法：

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


using var mutex = new Mutex(
 initiallyOwned: true,
 name: @"Local\MyApp.SingleInstance",
 out bool createdNew);

if (!createdNew)
{
 // 已有实例在运行（Local\ 前缀 = 每会话一个；Global\ = 全机器）
 return 0;
}

try
{
 RunApplication();
}
finally
{
 // Dispose 负责释放句柄，ReleaseMutex 才是放弃当前线程的所有权。
 mutex.ReleaseMutex();
}

Mutex 同样可重入、有线程亲和（非持有者 Release 抛异常）。它独有的语义是遗弃（abandonment）：线程终止而未释放时，mutex 被标记为遗弃，下一个获取它的线程收到 AbandonedMutexException——注意此时它已经持有该 mutex、必须照常释放。遗弃不是普通异常：它意味着持锁线程死在临界区中间，受保护的数据可能不一致，正确动作是校验完整性或直接进入安全路径，而不是重试。官方还有一条反向建议：如果无法保证 Exit 一定被调用，改用 Mutex——它在线程终止时由系统自动释放（尽管以遗弃为代价）。

Semaphore（内核版）——可在 Windows 上通过命名系统信号量实现跨进程计数限流；Unix 类系统不支持命名 Semaphore，跨平台方案需要另选 IPC 机制。它与 SemaphoreSlim 一样无线程亲和，但没有遗弃概念：信号量无主，线程退出只是少了一次 Release、计数变低，不会像 Mutex 那样抛 AbandonedMutexException。命名对象还要注意名字冲突与抢注风险；Windows 上可通过 System.Threading.AccessControl 包提供的 SemaphoreAcl/MutexAcl 在创建时设置 ACL。

八、死锁规避工具箱

四个来源、四类解法（消灭共享的四种并发策略见《线程安全的本质》第九节，UI 线程死锁场景见《WinForms 学习笔记（六）：线程与 async——UI 线程、Invoke 与死锁》）：

死锁来源	解法
锁顺序不一致	全局规定锁的获取顺序；一把锁能解决的不要用两把
临界区内等待外部事件	临界区里不做阻塞等待、不发请求、不调回调
无法预知的交叉	`Monitor.TryEnter(gate, TimeSpan.FromMilliseconds(300))` 拿不到就放弃并记录——官方最佳实践给出的死锁探测手段
async 等待链	不持锁 await；`SemaphoreSlim` 的等待也要能被 `CancellationToken` 取消

TryEnter 的超时不是"重试一下"用的——失败意味着可能已经死锁，正确的动作是告警并放弃这次操作，而不是睡 100ms 再来：

1
2
3
4
5
6
7


if (!Monitor.TryEnter(_gate, TimeSpan.FromMilliseconds(300)))
{
 _log.Warn("Potential deadlock detected: gate not acquired in 300ms");
 throw new TimeoutException("无法在预算内获得锁，疑似死锁");
}
try { /* 临界区 */ }
finally { Monitor.Exit(_gate); }

九、选型决策表

场景	首选	理由
保护复合不变量（多字段一致性）	`lock` / `Lock`（.NET 9+）	互斥语义完整、默认正确的那个选择
单变量原子更新	`Interlocked`	一条指令，无锁开销
async 方法内的互斥	`SemaphoreSlim(1,1)` + `WaitAsync`	BCL 自带、可跨 await 的常用方案
限制并发数 N	`SemaphoreSlim(N,N)`	信号量本义
读多写少、读临界区长	`ReaderWriterLockSlim`（先对比 `ConcurrentDictionary`）	读并行；短临界区不划算
极短临界区、叶子级数据结构	`SpinLock`（profiling 之后）	省上下文切换；禁忌多
跨进程互斥 / 单实例	命名 `Mutex`	内核对象；处理 `AbandonedMutexException`
Windows 跨进程计数限流	命名 `Semaphore`	内核信号量；Unix 不支持命名 `Semaphore`
生产者-消费者、流水线	`Channel<T>`	不是锁，是转移所有权——优先考虑

最后一行是提醒：选型表的上一级问题是"要不要锁"（第一节）。《.NET 高并发编程全景》里减少争用的手段（细粒度锁、无锁结构、并发集合），价值都高于换一把更快的锁。

十、验证与观测

锁选对没有，最终要靠数字：

争用观测。Monitor.LockContentionCount（.NET Core 3.0+）统计进程中 Monitor（包括锁定普通对象的 lock）发生争用的次数；不要把它理解成所有同步原语的统一计数器。dotnet-counters 里对应指标在 .NET 9+ 为 dotnet.monitor.lock_contentions，.NET 8 及以下显示为 Monitor Lock Contention Count：

1

dotnet-counters monitor --process-id <pid> --counters System.Runtime

争用计数不为零不是错误——它是信号：持续增长且伴随吞吐停滞，才值得投入优化（减少临界区、降低粒度、换结构）。

正确性验证。并发单测很难捕捉竞态，至少做到：用并行压力（Parallel.For + 随机延迟）反复冲击不变量断言；用 CancellationToken 注入取消验证 finally 配对；对可升级读锁专门测试“等待已有读者退出后升级，并在持有期间阻止其他写者”；对 SemaphoreSlim 专门测试关闭时的在途等待。

性能验证。换锁前后的基准用真实负载形态（读写比、临界区长度、核数）跑，BenchmarkDotNet 的并发场景要多线程压，单线程 micro-benchmark 说明不了争用行为。

总结

lock 是默认答案，其余每个原语都只回答一个 lock 回答不了的问题：Interlocked 答"单变量"，SemaphoreSlim 答"async 和并发数"，RWLS 答"读并行"，SpinLock 答"经测量确实极短的叶子级临界区"，Mutex 答"跨进程互斥"，命名 Semaphore 答"Windows 跨进程计数"。
锁对象要私有专用，lock(this)/Type/字符串/值类型都是事故；锁不能跨过 await，需要异步互斥时通常改用 SemaphoreSlim.WaitAsync。
选型顺序是倒过来的：先消灭共享，再消灭锁；留下的每一把锁，都应该能说出它独有语义的用武之地。

参考资料

微软官方文档：

源码与实现细节：

C# 原生互操作与设备 SDK（六）：回调、原生线程与事件

Thu, 23 Jul 2026 10:00:00 +0800

设备 SDK 常通过回调上报图像到达、运动完成、报警和连接变化。注册成功只完成了第一步：原生库可能在任意线程、任意时刻调用函数指针，并继续使用注册时传入的上下文。委托被 GC 回收、设备句柄已关闭、缓冲区已失效或异常穿过 ABI 边界，都可能导致进程级崩溃。

本文建立回调的完整生命周期，并用非托管函数指针（C# 9/.NET 5 起可用）在 .NET 10 环境下演示一条可验证的实现路径。

1. 先读清原生回调契约

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


#include <stddef.h>
#include <stdint.h>

typedef void (*device_event_callback)(
 void* context,
 int32_t event_code,
 const uint8_t* payload,
 size_t payload_length);

int32_t device_register_callback(
 device_handle handle,
 device_event_callback callback,
 void* context);

int32_t device_unregister_callback(device_handle handle);

头文件之外还要确认：

回调使用哪种调用约定；
SDK 是同步回调还是由内部线程异步回调；
是否可能并发、重入或在注销期间继续进入；
payload 只在本次回调有效，还是可由调用者释放；
注销返回时是否保证所有在途回调结束；
关闭设备句柄前必须执行什么顺序。

2. 使用函数指针表达精确 ABI

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


using System.Runtime.CompilerServices;
using System.Runtime.InteropServices;

internal static partial class DeviceNative
{
 [LibraryImport("device_sdk", EntryPoint = "device_register_callback")]
 internal static unsafe partial int RegisterCallback(
 nint handle,
 delegate* unmanaged[Cdecl]<nint, int, byte*, nuint, void> callback,
 nint context);

 [LibraryImport("device_sdk", EntryPoint = "device_unregister_callback")]
 internal static partial int UnregisterCallback(nint handle);
}

delegate* unmanaged[Cdecl]<...> 表达的是非托管函数指针，参数顺序与原生 typedef 一一对应。若 SDK 不是 cdecl，两侧必须同时改为真实调用约定。

3. 用 UnmanagedCallersOnly 暴露静态入口

实例方法带有隐含的 this，不能直接作为普通 C 回调。可以暴露一个静态入口，把实例放在 context 中：

 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


using System.Runtime.CompilerServices;
using System.Runtime.InteropServices;
using System.IO;
using System.Threading.Channels;

internal static class DeviceCallbackBridge
{
 [UnmanagedCallersOnly(CallConvs = new[] { typeof(CallConvCdecl) })]
 public static unsafe void OnEvent(
 nint context,
 int eventCode,
 byte* payload,
 nuint payloadLength)
 {
 try
 {
 var handle = GCHandle.FromIntPtr(context);
 if (handle.Target is not DeviceEventSink sink)
 {
 return;
 }

 if (payloadLength > sink.MaxPayloadLength ||
 (payload == null && payloadLength != 0))
 {
 CallbackFailureLog.Write(
 new InvalidDataException("Invalid callback payload"));
 return;
 }

 int length = checked((int)payloadLength);
 byte[] copy = new ReadOnlySpan<byte>(payload, length).ToArray();
 sink.TryPublish(new NativeDeviceEvent(eventCode, copy));
 }
 catch (Exception exception)
 {
 CallbackFailureLog.Write(exception);
 }
 }
}

public sealed record NativeDeviceEvent(int Code, byte[] Payload);

public sealed class DeviceEventSink
{
 private readonly Channel<NativeDeviceEvent> _events =
 Channel.CreateBounded<NativeDeviceEvent>(64);

 public DeviceEventSink(nuint maxPayloadLength)
 {
 if (maxPayloadLength == 0 || maxPayloadLength > int.MaxValue)
 {
 throw new ArgumentOutOfRangeException(nameof(maxPayloadLength));
 }

 MaxPayloadLength = maxPayloadLength;
 }

 public nuint MaxPayloadLength { get; }

 public ChannelReader<NativeDeviceEvent> Events => _events.Reader;

 public bool TryPublish(NativeDeviceEvent deviceEvent) =>
 _events.Writer.TryWrite(deviceEvent);
}

internal static class CallbackFailureLog
{
 public static void Write(Exception exception)
 {
 try
 {
 Console.Error.WriteLine(exception);
 }
 catch
 {
 // 回调边界不能因诊断失败再次抛出。
 }
 }
}

这里使用有界通道，队列已满时 TryWrite 会失败；生产代码应记录丢弃计数或根据事件类型采用受控降载策略，不能静默假装事件已经处理。

UnmanagedCallersOnly 方法必须是静态方法，签名只能使用本系列（三）定义的 blittable 类型。异常绝不能穿过原生边界；回调入口要捕获全部异常，并把故障写入不再抛出的最小日志通道。

示例立即复制 payload，因为没有契约允许回调返回后继续读取该指针。最大长度由创建 DeviceEventSink 时结合设备数据模型配置，避免损坏的 SDK 值触发超大分配，又不武断限制合法图像或波形大小。

4. 上下文句柄必须活到最后一次回调结束

注册时用普通 GCHandle 保持托管对象可达。这里固定的是对象的生命周期，不是内存地址；默认 GCHandleType.Normal 仍允许 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
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43


public sealed unsafe class CallbackRegistration : IDisposable
{
 private readonly nint _device;
 private GCHandle _context;
 private bool _registered;

 public CallbackRegistration(nint device, DeviceEventSink sink)
 {
 _device = device;
 _context = GCHandle.Alloc(sink);

 int status = DeviceNative.RegisterCallback(
 device,
 &DeviceCallbackBridge.OnEvent,
 GCHandle.ToIntPtr(_context));

 if (status != 0)
 {
 _context.Free();
 throw new DeviceSdkException("device_register_callback", status);
 }

 _registered = true;
 }

 public void Dispose()
 {
 if (!_registered)
 {
 return;
 }

 int status = DeviceNative.UnregisterCallback(_device);
 if (status != 0)
 {
 throw new DeviceSdkException("device_unregister_callback", status);
 }

 // 只有 SDK 保证注销返回后无在途回调，才能在这里释放。
 _context.Free();
 _registered = false;
 }
}

如果注销不等待在途回调，这个简化版本不安全。需要增加计数/屏障，或调用 SDK 提供的同步停止函数，按“停止产生新回调 → 等待已有回调退出 → 释放 context → 关闭设备”的顺序执行。

异常路径也要设计：如果注销失败，立即释放 GCHandle 可能形成悬空上下文；无限保留则泄漏。应根据厂商契约决定重试、强制停止或把会话转入不可恢复状态，而不是在 finally 中盲目释放。

5. 回调线程不等于 UI 线程

相机或运动控制 SDK 常从内部原生线程调用。回调中应只做有界、非阻塞工作：

复制必要数据和时间戳；
写入 Channel<T>、无界风险受控的队列或专用调度器；
立即返回，让 SDK 线程继续工作；
在消费者侧解析、记录、更新状态并切换到 UI Dispatcher。

不要在回调里等待 UI、获取长时间持有的业务锁、同步调用关闭设备，或执行不可控的磁盘/网络 I/O。否则不仅丢帧，还可能与 SDK 内部锁形成死锁。锁与死锁的通用机制见《线程安全的本质：从 CPU 缓存到内存模型，锁到底在保证什么》。

6. 委托回调仍然可用，但必须扎根

旧 API 或不适合函数指针的场景可以声明委托：

1
2
3
4
5
6


[UnmanagedFunctionPointer(CallingConvention.Cdecl)]
internal unsafe delegate void DeviceEventCallback(
 nint context,
 int eventCode,
 byte* payload,
 nuint payloadLength);

如果原生代码只在一次同步调用期间使用委托，可在调用后用 GC.KeepAlive(callback) 保证其活到调用结束。如果原生库保存函数指针，就必须把委托存入与注册同寿命的字段，不能只依赖局部变量、GC.KeepAlive 或“目前 GC 还没发生”。

7. 回调测试要覆盖时间窗口

至少验证：

注册失败时 context 不泄漏；
回调在工作线程、并发和重入时仍正确；
空载荷、最大载荷和非法长度受到保护；
回调处理异常不会越过 ABI；
注销与回调竞争时没有 use-after-free；
关闭设备后不会再向已释放队列或 UI 发布；
多次启动/停止不会重复注册。

模拟原生线程的测试应主动随机化回调时序，而不是只在单线程中顺序调用入口。

总结

回调是一段跨线程、跨 GC、跨 ABI 的长期租约。函数签名正确只是起点；托管目标、委托或 GCHandle 必须保持到最后一次回调结束，载荷要在有效期内复制，异常不能穿过边界，耗时工作应转移到托管队列。

下一篇用 SafeHandle 管理设备句柄，让关闭时机和调用期间的存活保证进入类型系统。

参考资料

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

半导体设备软件（六）：实时性、并发与异常恢复

Tue, 21 Apr 2026 10:00:00 +0800

设备软件所说的实时，不是单纯“平均很快”，而是围绕截止时间给出可预测响应。硬件级高速触发、毫秒到秒级模块协调和分钟级 Recipe 任务的时间尺度不同，必须采用不同控制策略。

1. 先给实时性分级

硬实时任务一旦错过截止时间就可能造成不可接受的后果，因此必须证明最坏情况能够满足时限；软实时任务允许偶发超时，但延迟分布和超时后果仍要可测、可控。设备控制架构应先判断任务属于哪一类，再决定由专用硬件、实时控制器还是通用操作系统承担。

安全急停和高速伺服通常由专用硬件、驱动器或实时控制器负责；上位机适合流程协调、界面和数据处理。把所有控制都塞进通用操作系统进程，容易受垃圾回收、调度和 I/O 抖动影响。

需求应写成最大延迟、抖动和超时后的安全行为，而不是“尽快”。只有定义截止时间，才能决定功能应放在哪一层。

2. 并发围绕资源组织

线程多不等于吞吐高。相机、机械手、腔体和数据库都有容量与互斥约束。推荐用消息、任务队列或 Actor 式所有权，让一个状态由一个明确主体修改，减少共享可变状态。

无法避免锁时，要固定加锁顺序、缩短临界区，并把外部 I/O 移出锁。超时不能直接释放仍在被硬件使用的资源。

3. 超时只是“我不再等了”

网络请求超时后，对方可能已经执行；运动等待超时后，轴也可能仍在移动。调用方必须通过查询、幂等键或事务状态消除不确定性，不能立刻重发物理动作。

重试适合短暂通信故障，不适合所有失败。限位、校验不通过和安全联锁属于确定性错误，盲目重试只会延迟诊断。

4. 恢复从检查点开始

任务应在晶圆交接、工艺开始和结果提交等关键点持久化状态。崩溃后先盘点硬件与晶圆，再将持久状态和现场事实对账。无法确认是否加工过的晶圆要进入隔离流程。

恢复策略通常分为自动重试、受控回退、人工确认和报废/隔离。选择依据是动作可逆性、重复执行风险与产品价值。

5. 用故障注入验证

拔网线、延迟响应、丢帧、重启进程和模拟传感器异常，比只跑正常用例更能发现竞态。测试要检查最终物理状态、数据唯一性和恢复时间，而不只看程序有没有抛异常。

总结

实时性围绕截止时间和可预测性设计，并发提升资源利用率，恢复处理不可避免的不确定性。三者需要统一的状态、资源和幂等语义，否则“异步化”只会让错误更难复现。

参考资料

SEMI：GEM300 Tutorial Overview

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 学习笔记（九）：多线程与 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、动画占用机制。

分布式系统学习笔记（三）：分布式锁

Mon, 17 Mar 2025 10:00:00 +0800

写在前面

本文讲分布式锁——多个服务/节点之间如何互斥访问共享资源。它有几种经典实现（数据库、Redis、Zookeeper、etcd），各有优劣。理解它们的差异，才能在不同场景选对方案。

一、为什么需要分布式锁

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


单机：用 lock / Mutex / 信号量（进程内）

分布式：多个进程/机器要互斥
 单机锁管不到其他机器
 需要一个"全局可见"的锁

典型场景：
 - 防止重复操作（下单、扣库存、发券）
 - 限流（全局 QPS）
 - 选主（只一个节点执行定时任务）
 - 资源独占（同时只一个能改配置）

1
2
3
4
5
6
7


分布式锁的必要条件：
 ✓ 互斥（Mutual Exclusion）— 任意时刻只有一个客户端持有
 ✓ 避免死锁 — 持有者崩溃，锁要能自动释放
 ✓ 可重入（可选）— 同一持有者可重复获取
 ✓ 高可用 — 锁服务不能单点
 ✓ 高性能 — 加锁/解锁要快
 ✓ 公平性（可选）— 按请求顺序获取

二、实现方式对比

1
2
3
4
5
6


方式 一致性 性能 可靠性 复杂度 适用
──────────────────────────────────────────────────────────
数据库 强 中 中 低 简单场景
Redis 弱(AP) 极高 中 低 高并发、容忍偶尔失效
Zookeeper 强(CP) 中 高 中 强一致、可靠
etcd 强(CP) 高 高 中 云原生、K8s

三、数据库实现

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


-- 方式一：唯一索引（加锁 = 插入，解锁 = 删除）
INSERT INTO locks(resource, owner, expire_at) VALUES('order:123', 'uuid', NOW()+10s);
-- 插入成功 = 获取锁；唯一冲突 = 被占
DELETE FROM locks WHERE resource='order:123' AND owner='uuid';

-- 方式二：悲观锁（SELECT ... FOR UPDATE）
BEGIN;
SELECT * FROM account WHERE id=1 FOR UPDATE; -- 加行锁
-- 业务
COMMIT;

1
2
3


优点：简单，不用引入新组件
缺点：性能差（DB 是瓶颈）、过期清理麻烦、FOR UPDATE 占连接
适用：并发不高、已有数据库、不想引入 Redis/ZK

四、Redis 实现

1
2
3
4
5
6
7
8


# 加锁：SET key value NX EX（原子）
SET lock:order:123 <owner_uuid> NX EX 10
# NX：不存在才设置（互斥）
# EX 10：10 秒过期（防死锁）
# 返回 OK = 获取成功；nil = 已被占

# 解锁：必须验证 owner 再删（Lua 保证原子）
# 否则可能删掉别人的锁

1
2
3
4
5
6


-- 解锁脚本（原子）
if redis.call('get', KEYS[1]) == ARGV[1] then
 return redis.call('del', KEYS[1])
else
 return 0
end

Redis 锁的问题

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


问题1：业务执行超过锁过期时间
 锁到期自动释放，别的客户端拿到锁 → 两个客户端同时执行
 解决：看门狗续期（定时延长过期时间）
 Redisson 框架自带看门狗

问题2：Redis 主从切换丢锁
 主节点加锁成功 → 还没同步到从 → 主挂了 → 从升主（没锁数据）→ 别人能加锁
 可评估 Redlock（向多个独立 Redis 实例加锁，多数成功才算成功），但它不能消除客户端暂停和租约过期后的并发执行风险

问题3：Redlock 的争议
 Martin Kleppmann 质疑基于租约且缺少 fencing token 的锁能否保护严格正确性
 因为 GC 停顿、时钟漂移可能导致锁失效
 Redis 作者 antirez 反驳（认为实际够用）

1
2
3
4
5


Redis 锁的定位：
 ✓ 高性能、高并发
 ✗ 仅凭租约不能阻止“旧持有者暂停后恢复”继续写入，这不是贴一个 AP 标签就能完整解释的
 适用：对偶尔失效容忍的场景（如限流、防重复提交）
 不适用：绝对不能错的场景（如扣款、扣库存）→ 用 ZK/etcd

五、Zookeeper 实现

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


ZK 锁基于「临时顺序节点」+ Watch：

1. 创建顺序临时节点 /lock/node-0001, /lock/node-0002 ...
2. 判断自己是不是序号最小的
 - 是 → 获得锁
 - 否 → 监听前一个节点（只监听前一个，避免羊群效应）
3. 前一个节点删除（释放锁）→ 自己被唤醒 → 成为最小 → 获得锁
4. 持有者崩溃 → 临时节点自动删除 → 后继者被唤醒

特点：
 ✓ 强一致（ZAB 共识）
 ✓ 公平锁（顺序节点）
 ✓ 会话失效自动释放（临时节点）
 ✓ 会话失效时临时节点自动删除
 ✗ 长时间暂停或网络隔离可能导致会话过期；旧客户端恢复后仍需 fencing token 或下游条件写阻止陈旧操作
 ✗ 性能不如 Redis（CP，要多数确认）

1
2
3


羊群效应（Herd Effect）：
 ✗ 所有等待者都监听同一个节点 → 释放时全部唤醒抢锁 → 惊群
 ✓ 改进：每个等待者只监听「前一个」节点 → 顺序唤醒

六、etcd 实现

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


etcd 锁基于 Lease（租约）+ 事务（TXN）+ Revision（全局递增版本）：

1. 创建带 Lease 的 key（Lease 保活，崩溃自动过期）
2. 在锁前缀下创建候选 key，并按创建 Revision 判断自己是否最小
 - 是 → 获得锁
 - 否 → 监听前一个 key
3. 类似 ZK 的顺序等待

特点（类似 ZK）：
 ✓ 强一致（Raft）
 ✓ Lease 自动过期（防死锁）
 ✓ 比 ZK 更轻量、性能更好、云原生标配
 K8s 的分布式锁多用 etcd（或基于 etcd 的 leader election）

1
2
3
4
5
6
7
8
9


// etcd 分布式锁示例（Go concurrency 包）
m, err := concurrency.NewSession(client)
if err != nil { return err }
defer m.Close()

l := concurrency.NewMutex(m, "/lock/order/123")
if err := l.Lock(ctx); err != nil { return err }
defer func() { _ = l.Unlock(context.Background()) }()
// 业务

七、共识锁与 Redis 租约锁的关键区别

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


Redis 主从复制上的租约锁：
 返回"加锁成功"时，可能主从还没同步
 极端情况下锁可能失效（但你以为成功）
 → 快，但不可靠

ZK / etcd 共识协调：
 返回"加锁成功"时，数据已通过共识写入多数节点
 对锁记录提供线性一致的创建与排序语义
 → 更适合协调，但客户端暂停、会话过期和下游写入仍需 fencing token/版本校验

选择：
 严格正确性场景 → 共识协调 + fencing token/数据库条件写 + 幂等与审计
 容忍租约偶尔重叠、追求低延迟 → 可评估 Redis 租约锁

八、使用建议

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


场景 推荐
──────────────────────────────────────────────────
高并发、容忍偶尔失效（限流） Redis
防重复提交、幂等 Redis
扣库存、扣款等关键写入 数据库约束/条件更新为最终防线；协调服务配合 fencing token
选主（Leader Election） ZK / etcd
配置/资源互斥 etcd（云原生）/ ZK

通用建议：
 优先用成熟框架（Redisson、curator、etcd concurrency）
 别自己造轮子（边界情况极多）
 锁要设过期时间 + 校验 owner；严格场景给每次持有分配单调递增 fencing token，由下游拒绝旧 token
 业务要考虑"锁失效"的兜底（幂等）

九、小结

必要条件：互斥、防死锁、高可用、（可选）可重入/公平
数据库锁：简单但性能差，适合低并发
Redis 锁（AP）：极高性能，但不绝对可靠；Redlock 有争议
Zookeeper 锁（CP）：顺序临时节点，强一致公平锁
etcd 锁（CP）：Lease + 事务，云原生首选
本质：CP 锁可靠慢，AP 锁快但可能假成功；按业务对可靠性的要求选

下一篇讲分布式事务——跨服务/数据库如何保证一致性。

操作系统学习笔记（三）：Reactor 与 Proactor 模式

Wed, 05 Mar 2025 10:00:00 +0800

写在前面

上一篇讲了 I/O 模型（epoll、AIO）。但 epoll 只是底层机制，要变成一个能用的网络服务器，需要一套设计模式把"事件分发"和"业务处理"组织起来——这就是 Reactor 和 Proactor。Netty、Nginx、Redis、Kestrel 都基于这些模式。

一、Reactor 模式

1.1 核心思想

Reactor = 基于同步 I/O 多路复用的事件驱动模式。

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


核心组件：
 1. Reactor（事件分发器）
 用 epoll/select 监听所有 fd，事件就绪时分发给对应 Handler

 2. Acceptor（接收器）
 处理新连接（accept）

 3. Handler（处理器）
 处理具体连接的读写、业务

流程：
 Reactor 监听 → 新连接来了，Acceptor 接收 → 注册到 Reactor
 → 数据来了，Reactor 通知 Handler → Handler 读写+处理

1
2
3
4


关键特征（同步）：
 I/O 操作（read/write）还是由 Handler 同步执行
 Reactor 只负责"通知就绪"，不做实际 I/O
 本质是「事件来了 → 你自己去读」

1.2 三种 Reactor 实现

单 Reactor 单线程

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


 一个线程，一个 Reactor 干所有事：
 accept、read、业务处理、write 全在一个线程

 ┌─────────────────┐
 │ Reactor（1线程） │
 │ accept + IO + 业务 │
 └─────────────────┘

 代表：Redis 6.0 之前

 优点：极简，无线程同步问题
 缺点：一个连接的慢操作卡死所有连接
 无法利用多核

单 Reactor 多线程

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


 Reactor（1线程）只负责 accept + 读写分发
 业务处理交给线程池

 ┌──────────┐ ┌──────────────┐
 │ Reactor │────→│ 业务线程池 │
 │ accept+IO │ │ 多线程处理 │
 └──────────┘ └──────────────┘

 优点：业务多线程，利用多核
 缺点：Reactor 单线程仍是瓶颈（所有 I/O 集中）
 Handler 和业务线程间要同步

主从 Reactor 多线程（最常用）

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


 MainReactor 专门 accept 新连接
 SubReactor（多个）处理已建立连接的读写
 业务可选交给线程池

 ┌────────────┐
 │ MainReactor │ accept
 └─────┬──────┘
 │ 新连接分发
 ┌─────▼──────┐ ┌──────────┐ ┌──────────┐
 │ SubReactor │ │SubReactor │ │SubReactor │ 各自 epoll 处理 IO
 └────────────┘ └──────────┘ └──────────┘

 代表：Netty 等多 Reactor 框架。Nginx 的 master 主要负责配置与 Worker 生命周期，连接通常由 Worker 接受和处理

 优点：充分利用多核，accept 和 IO 分离，吞吐高
 这是高性能服务器的标准架构

二、Nginx 的 Reactor 架构

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


Nginx = 多进程 Reactor 版（与 Netty 的主从 Reactor 不同）：

 Master 进程
 │ 读取配置、管理 Worker 生命周期（不处理连接）
 │
 Worker 进程 ×N（通常 = CPU 核数）
 各 Worker 从共享监听 socket 上 accept 新连接
 每个 Worker 自己的 epoll + Reactor
 独立处理连接的读写、业务

 特点：
 多进程 Worker → 较强的故障隔离；共享状态和连接接受协调仍可能使用原子操作或锁
 每个 Worker 一个 Reactor（单线程事件循环）
 共享统计、限流等状态可放在共享内存中，并按模块需要使用同步机制

三、Redis 的事件模型

1
2
3
4
5
6
7
8


Redis 6.0 之前：单 Reactor 单线程
 一个线程跑事件循环 + 命令执行
 为什么快：内存数据结构、事件循环和较少的线程间协调；仍会发生系统调用与调度

Redis 6.0+：单 Reactor + IO 多线程
 经典执行路径主要由主线程串行处理命令；Redis 新版本的部分 I/O、后台任务和模块可使用其他线程
 网络 read/write 用多线程（IO 瓶颈在多核上并行）
 本质：IO 用 Reactor 多线程，业务仍串行

四、Proactor 模式

Proactor = 基于异步 I/O 的事件驱动模式。

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


核心区别（对比 Reactor）：

Reactor（同步）：
 事件就绪 → 通知 Handler → Handler 自己 read（同步拷贝）
 "数据来了，你自己读"

Proactor（异步）：
 发起异步 read → 内核读完+拷贝完 → 通知 Handler 处理
 "数据我已经读好了，你直接用"

Proactor 流程：
 1. 发起 aio_read（异步，立即返回）
 2. Handler 继续干别的
 3. 内核完成（等数据+拷贝）→ 通知
 4. Handler 拿到的数据已就绪，直接处理

1
2
3


关键特征（异步）：
 I/O 操作由内核完成，Handler 只处理就绪的数据
 本质是「我帮你读好了，告诉你」

五、Reactor vs Proactor

1
2
3
4
5
6
7
8


 Reactor Proactor
──────────────────────────────────────────────────────
I/O 模型 同步（epoll） 异步（IOCP/io_uring）
I/O 谁做 Handler 自己 内核做
通知时机 数据就绪 数据已拷贝完
实现复杂度 简单 复杂
OS 支持 Linux epoll 成熟 Windows IOCP 成熟 / Linux io_uring 逐渐成熟
代表 Nginx/Netty/Redis Windows IOCP、Boost.Asio

1
2
3
4
5
6
7


为什么主流还是 Reactor：
 Linux 早期异步 I/O 接口适用范围有限
 io_uring（2019）才让 Linux 有了高性能异步 I/O
 epoll + Reactor 已足够高效，生态成熟
 Windows 用 Proactor（IOCP）

 io_uring 扩展了完成通知式设计的选择，但框架仍可能采用 Reactor、Proactor 或混合架构

六、实际框架对应

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


框架/系统 模式 底层
──────────────────────────────────────────────────────
Nginx 多进程 Reactor epoll
Redis Reactor（IO 多线程） epoll
Netty（Java） 主从 Reactor 多线程 epoll/IOCP
libuv（Node.js） Reactor epoll/kqueue/IOCP
Kestrel（.NET） Reactor epoll/IOCP + Pipelines
Tomcat NIO Reactor epoll/IOCP
Boost.Asio 可 Reactor/Proactor io_uring/IOCP
Windows IOCP Proactor IOCP

七、.NET 的 Kestrel 怎么对应

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


Kestrel 是 ASP.NET Core 的服务器，Transport 层是 Reactor：

 Transport（传输层）— Reactor 模式
 基于 epoll（Linux）/ IOCP（Windows）
 用 System.IO.Pipelines 处理网络数据
 接收连接、读取字节流

 应用层 — async/await
 看似 Proactor 风格（await 不阻塞）
 但底层 Transport 是 Reactor（事件就绪通知）
 await 在等数据时释放线程，数据就绪后继续

 所以 Kestrel = Reactor（底层）+ 异步编程模型（上层）
 这也是为什么 Kestrel 跨平台性能都强

八、小结

Reactor：同步 I/O 多路复用 + 事件分发，“数据来了你自己读”
- 单 Reactor 单线程（Redis 6.0 前）
- 单 Reactor 多线程
- 主从 Reactor 多线程（Netty）、多进程 Reactor（Nginx）—— 高性能标配
Proactor：异步 I/O，“我帮你读好了”
- Windows IOCP、Linux io_uring
主流是 Reactor，因为 Linux epoll 成熟；io_uring 普及后 Proactor 会更多
Kestrel = Reactor 底层 + async/await 上层

下一篇讲零拷贝技术（sendfile/mmap/splice）——高性能网络 I/O 的另一块拼图。

操作系统学习笔记（二）：进程、线程与协程

Mon, 03 Mar 2025 10:00:00 +0800

写在前面

本文讲清三个执行单元：进程、线程、协程。它们的本质区别是什么、开销差多少、各自适合什么场景。理解了这些，才能理解为什么 Go 用协程、Nginx 用多进程、Java 用线程池。

一、进程（Process）

1.1 什么是进程

1
2
3
4
5
6
7
8
9


进程 = 程序的一次运行实例，是资源分配的基本单位

每个进程有：
 - 独立的虚拟地址空间（代码、数据、堆、栈）
 - 独立的页表
 - 文件描述符表、信号处理、工作目录等
 - PID（进程ID）

 隔离性极强：A 进程崩了不影响 B 进程

1.2 创建与开销

1
2
3
4
5
6


// Linux 创建进程
pid_t pid = fork(); // 复制当前进程
if (pid == 0) {
 // 子进程
 execl("/bin/program", "program", NULL); // 执行新程序
}

1
2
3
4
5
6
7
8


fork 的开销（很大）：
 - 复制页表（写时复制 COW 优化，但仍有开销）
 - 分配新的内核栈、task_struct
 - 拷贝文件描述符、信号表等
 - 大约 几百微秒 ~ 几毫秒

 进程间通信（IPC）也贵：管道、消息队列、共享内存、Socket
 因为地址空间独立，数据要跨边界拷贝

二、线程（Thread）

2.1 什么是线程

1
2
3
4
5
6
7
8
9


线程 = 进程内的执行单元，是 CPU 调度的基本单位

同一进程的多个线程：
 ✓ 共享地址空间（代码、堆、全局变量）
 ✓ 共享文件描述符
 ✗ 各自有独立的栈、寄存器、PC（程序计数器）

 创建比进程轻量，通信比进程快（共享内存，不用跨边界）
 但共享带来并发问题：需要锁

2.2 用户线程 vs 内核线程

1
2
3
4
5
6
7
8
9


内核线程：
 由操作系统内核管理、调度
 能被内核看到、能多核并行
 .NET/Java 的线程默认是内核线程（1:1 模型）

用户线程（绿色线程/M:N）：
 由用户态运行时管理（Go、Erlang）
 内核看不到，M 个用户线程映射到 N 个内核线程
 创建极轻量，调度在用户态完成

2.3 线程的开销

1
2
3
4
5
6
7


创建线程和上下文切换都不是固定常数，会受操作系统、CPU、调度、NUMA 和负载影响
 - 保存/恢复寄存器
 - 切换内核栈
 - TLB/缓存失效（隐性开销最大）

线程栈上限或保留空间常见为 MB 量级，但实际提交的物理内存、默认值和增长方式因平台与运行时而异
 所以"一个连接一个线程"撑不住 C10K

三、进程 vs 线程

1
2
3
4
5
6
7
8
9


 进程 线程
─────────────────────────────────────────────────
地址空间 独立 共享
创建开销 通常较大 通常较小
通信 贵（IPC） 便宜（共享内存）
切换开销 大 小
并发问题 无（隔离） 有（需锁）
崩溃影响 只影响自己 整个进程崩
多核利用 能 能

1
2
3
4
5
6
7
8
9


为什么 Nginx 选多进程：
 Worker 进程独立，一个崩了不影响其他
 Worker 之间大部分请求状态相互隔离，但共享内存区、accept 协调等路径仍可能使用原子操作或锁
 配合事件驱动，单进程抗万级并发

为什么 Java/.NET 传统用多线程：
 线程比进程轻量
 共享内存通信方便
 但要小心锁和线程安全

四、协程（Coroutine）

4.1 什么是协程

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


协程是由语言或运行时调度的轻量级并发任务；具体实现并不都等同于“用户态线程”

特点：
 ✓ 通常可在较少的内核线程上承载大量并发任务
 ✓ 通常比操作系统线程占用更少资源
 ✓ 任务间切换通常不需要每次进入内核调度
 ✗ 栈与状态保存方式依实现而异：goroutine 使用可增长栈，async 任务通常编译为状态机
 ✗ 调度方式也依实现而异，既有 await/yield 协作让出，也有运行时抢占

 代表：Go goroutine、Kotlin coroutine、Python async/await、Rust async

4.2 协程的优势

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


创建成本：
 线程：需要内核调度实体和较大的栈地址空间
 协程：通常由语言运行时管理，可使用较小且可增长的栈

 Go 程序可以承载大量 goroutine，但上限仍受栈增长、调度、文件描述符和业务资源约束
 同数量的内核线程通常成本更高，但不能脱离工作负载给出固定容量结论

切换成本：
 线程切换通常需要内核调度；同进程线程不会更换地址空间
 协程切换通常由运行时在用户态调度，但遇到系统调用、抢占和工作窃取时成本会变化

4.3 协程的两种实现

1
2
3
4
5
6
7
8
9


1. 有栈协程（Stackful）
 每个协程有自己的栈
 可在任意位置挂起（抢占友好）
 代表：Go goroutine、Lua coroutine

2. 无栈协程（Stackless）
 基于状态机（编译器转换）
 只能在特定点挂起（await 点）
 代表：C# async/await、Rust async、C++20 coroutine、Python async/await

五、调度模型

5.1 抢占式 vs 协作式

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


抢占式调度（内核线程）：
 内核按时间片强制切换
 一个线程卡死不影响其他
 .NET/Java 线程、操作系统进程

协作式调度（协程）：
 协程主动让出 CPU（await / yield）
 一个协程不让出，其他协程饿死
 Go 调度器既使用安全点，也从 Go 1.14 起支持异步抢占；纯 async/await 任务通常在 await 点让出

 若在事件循环中执行运行时无法感知的阻塞调用，可能卡住承载该任务的线程及其上的其他任务

5.2 Go 的 GMP 模型

1
2
3
4
5
6
7
8
9


Go goroutine 的调度（M:N）：
 G = Goroutine（用户协程）
 M = Machine（内核线程）
 P = Processor（逻辑处理器，持有可运行 G 的本地队列）

 N 个 G 在 M 个 M 上跑，M 个 M 绑定到 P（通常 = CPU 核数）
 P 的本地队列 + 全局队列 + 工作窃取（work stealing）

 效果：goroutine 创建极轻，调度高效，自动负载均衡多核

5.3 .NET 线程池

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


.NET 用内核线程 + 线程池：
 池化复用线程，避免频繁创建销毁
 按需增长（IO 密集型增长快）
 async/await 在线程池线程上跑，等待时释放线程

 对比 Go：
 Go 用协程（M:N），轻量
 .NET 用线程 + async（线程少，靠异步等 I/O 时不占线程）

 思路不同，目标都是高并发：
 Go：协程够轻，开很多协程
 .NET：不依赖海量线程，等待 I/O 时释放线程

六、上下文切换

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


上下文切换 = 保存当前执行状态、恢复另一个的状态

进程切换：最贵
 切换地址空间（页表）→ TLB 失效 → 内存访问变慢

线程切换：中等
 同进程内，地址空间不变，TLB 不全失效
 但仍进内核、保存寄存器

协程切换：最便宜
 通常由语言运行时完成，不必每次进入内核调度
 具体保存状态和缓存影响取决于协程实现

 因而协程常适合大规模 I/O 并发，但可承载数量仍受栈、任务状态、连接和业务内存约束

七、如何选择

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


场景 推荐
──────────────────────────────────────────────────────
需要强隔离（如浏览器站点隔离） 多进程
CPU 密集并行计算 线程池 / 协程池
高并发 I/O（万级连接） 协程 / 事件驱动（epoll）
语言原生支持协程（Go） goroutine
语言原生 async（C#/JS） async/await
传统多线程代码 线程 + 锁（但要小心）

通用建议：
 I/O 密集 → 协程或异步（不阻塞）
 CPU 密集 → 多线程/多进程（多核并行）

八、小结

进程：资源分配单位，独立地址空间，隔离强但开销大
线程：CPU 调度单位，共享地址空间，轻量但要锁
协程：用户态轻量线程，创建/切换极便宜，适合高并发
调度：抢占式（线程）vs 协作式（协程，不能阻塞）
Go GMP：M:N 调度 + 工作窃取；.NET：线程池 + async/await
选择：I/O 密集用协程/异步，CPU 密集用多线程多核并行

下一篇讲 Reactor / Proactor 模式——I/O 模型如何变成实际的网络框架。

操作系统学习笔记（一）：I/O 模型全解

Sat, 01 Mar 2025 10:00:00 +0800

写在前面

本文是操作系统底层系列第一篇，系统讲清楚 5 种 I/O 模型：阻塞、非阻塞、多路复用、信号驱动、异步。理解这些是理解 Nginx、Redis、Netty、Kestrel 为什么快的根基。

之前在 Nginx 系列聊过 epoll，这里从操作系统层面把整个 I/O 模型体系讲全。

一、I/O 的本质

1.1 为什么要懂 I/O 模型

1
2
3
4
5
6
7
8
9


许多 I/O 密集型程序的大量时间用于等待网络或磁盘
此时瓶颈往往不在业务计算本身

I/O 慢的根本：
 CPU 指令与缓存命中：常见为纳秒量级
 DRAM、网络和存储：从几十纳秒到毫秒以上，跨度取决于介质、距离、队列和负载

所以高效程序的核心：不让 CPU 陪 I/O 等
不同 I/O 模型 = 不同的"等待方式"

1.2 用户空间与内核空间

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


操作系统分两层：
 用户空间（User Space）— 应用程序运行的地方
 内核空间（Kernel Space）— 操作系统内核，能直接碰硬件

应用不能直接读写硬件（网卡、磁盘），必须通过「系统调用」请求内核代劳。

一次 read() 的流程：
 1. 应用调用 read()（系统调用）
 2. 切换到内核态
 3. 内核等数据到达网卡/磁盘
 4. 内核把数据从内核缓冲区拷贝到用户缓冲区
 5. 切换回用户态，应用拿到数据

两个阶段：
 阶段1：等待数据就绪（数据从硬件到内核缓冲区）—— 慢，主要耗时
 阶段2：数据拷贝（内核缓冲区 → 用户缓冲区）—— 快

1
2
3


所有 I/O 模型的区别，就在于「应用如何处理这两个阶段」：
 阶段1（等数据）：阻塞？轮询？被通知？
 阶段2（拷贝）：谁拷贝？什么时候拷？

二、阻塞 I/O（Blocking I/O）

最传统的模型。应用调用 read() 后，一直阻塞到数据读完。

1
2


// 应用代码
int n = read(fd, buf, size); // 阻塞在这，直到数据读完

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


时间线：
 应用 read() ──阻塞─────────────────────── 拿到数据
 │
 内核 等数据就绪 ──── 拷贝数据 ─→
 （阶段1） （阶段2）

 阶段1、阶段2 都阻塞应用线程

问题：一个线程只能等一个 fd
 1万个连接 = 1万个线程傻等
 这就是 C10K 问题的根源

三、非阻塞 I/O（Non-blocking I/O）

应用调用 read()，如果数据没就绪，立即返回错误（EAGAIN），不阻塞。

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


// 设置 fd 为非阻塞
fcntl(fd, F_SETFL, O_NONBLOCK);

// 循环轮询
while (1) {
 int n = read(fd, buf, size);
 if (n == -1 && errno == EAGAIN) {
 // 数据没就绪，干点别的，待会儿再问
 continue;
 }
 // 有数据了
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


时间线：
 应用 read()→EAGAIN read()→EAGAIN read()→数据 拿到数据
 （立即返回） （立即返回） （拷贝）
 │
 内核 等数据就绪 ──── 拷贝 ─→

 阶段1 不阻塞（轮询），但阶段2（拷贝）仍阻塞

问题：轮询浪费 CPU（空转）
 不停 read 大部分返回 EAGAIN，CPU 全耗在询问上
 很少单独用，通常配合多路复用

四、I/O 多路复用（select / poll / epoll）

一个线程同时监控多个 fd，谁有数据就处理谁。这是高并发的核心。

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


// epoll 用法（简化）
int epfd = epoll_create1(0);

// 注册关心的 fd
epoll_ctl(epfd, EPOLL_CTL_ADD, fd1, &event);
epoll_ctl(epfd, EPOLL_CTL_ADD, fd2, &event);

// 等待（阻塞，直到有 fd 就绪）
int n = epoll_wait(epfd, events, max, -1);
// n = 就绪的 fd 数量，只返回有数据的
for (i = 0; i < n; i++)
 handle(events[i]); // 处理（read 时阶段2仍阻塞）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


时间线：
 应用 epoll_wait() ──阻塞（等任意fd就绪）──→ 返回就绪 → read（拷贝）
 │
 内核 监听fd1,fd2... fd2数据到 → 通知 → 拷贝

 阶段1：交给内核多路复用，应用只等通知（不轮询）
 阶段2：read 拷贝时仍阻塞（但很快）

 1个线程管理上万 fd，谁就绪处理谁
 Nginx / Redis 的核心

select / poll / epoll 对比

1
2
3
4
5
6
7
8


 select poll epoll
────────────────────────────────────────────────────────────────
固定集合上限 受 FD_SETSIZE 限制 无固定集合上限 无固定集合上限
每次调用 传全部 fd 传全部 fd 只 epoll_wait
等待成本 遍历全部 fd O(n) 遍历全部 O(n) 通常随就绪事件数增长
返回结果 全部 fd（再遍历） 全部（再遍历） 只返回就绪的
数据结构 位图 数组 红黑树+就绪链表
适用 连接少 连接多 连接多+活跃少（最佳）

（epoll 细节见 Nginx 系列第四篇，这里不重复。）

五、信号驱动 I/O（Signal-driven）

应用告诉内核"fd 有数据时给我发信号"，然后去干别的。数据就绪时内核发 SIGIO 信号。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


// 开启信号驱动
fcntl(fd, F_SETFL, O_ASYNC);
fcntl(fd, F_SETOWN, getpid()); // 信号发给当前进程

// 注册信号处理函数
signal(SIGIO, handler);

// 应用继续干别的，数据就绪时 handler 被调用
void handler(int sig) {
 read(fd, buf, size); // 此时数据已就绪，拷贝很快
}

1
2
3
4
5
6
7
8
9


时间线：
 应用 注册信号 → 干别的 ... 被信号打断 → read（拷贝）
 ↑SIGIO
 内核 等数据就绪 ─── 发信号 ─→ 拷贝

 阶段1：不阻塞，靠信号通知
 阶段2：read 仍阻塞

 用得少（信号处理复杂、队列溢出问题），UDP 场景偶有使用

六、异步 I/O（提交与完成分离）

前 4 种模型，阶段2（数据拷贝）都还是要应用自己 read。异步 I/O 让内核连拷贝都做完，再通知应用。

1
2
3
4
5
6


// POSIX AIO 接口示意；glibc 在普通文件上通常借助线程实现，不能等同于内核原生异步 I/O
struct aiocb cb = { .aio_fildes = fd, .aio_buf = buf, .aio_nbytes = size };
aio_read(&cb); // 立即返回，内核自己去等+拷贝

// 应用继续干别的
// 内核完成（等数据 + 拷贝）后，发信号/回调通知

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


时间线：
 应用 aio_read() → 立即返回，干别的 ... → 通知（数据已在 buf）
 ↑
 内核 等数据就绪 ─── 拷贝到 buf ─→ 通知

 提交调用通常快速返回，完成后再通知应用；具体路径是否真正异步取决于接口、文件类型、内核与驱动
 这是完成通知式模型；底层工作由内核、驱动或实现线程协作完成

Linux 的 AIO：
 - glibc POSIX AIO：对普通文件通常由用户态线程池模拟
 - Linux native AIO：接口和适用文件类型有限
 - io_uring（Linux 5.1+）：统一的提交/完成队列接口；是否走异步路径及安全边界取决于操作和内核版本
 Windows IOCP：成熟的高性能异步 I/O

七、五种模型对比

1
2
3
4
5
6
7


 阶段1(等数据) 阶段2(拷贝) 是否真异步
──────────────────────────────────────────────────────
阻塞 I/O 阻塞 阻塞 否
非阻塞 I/O 轮询(不阻塞) 阻塞 否
I/O 多路复用 阻塞(等通知) 阻塞 否
信号驱动 I/O 信号通知 阻塞 否
异步 I/O 内核完成 内核完成 是 ✓

1
2
3
4
5
6


前 4 种本质都是「同步 I/O」——阶段2（拷贝）都要应用自己干
第 5 种描述的是完成通知式异步；实际实现可能由内核、驱动或用户态线程协作完成

 Reactor 模式（Nginx/Redis/Netty）= 用 I/O 多路复用 + 同步处理
 Proactor 模式（Windows IOCP） = 用异步 I/O
 （详见本系列 Reactor/Proactor 篇）

八、概念澄清：同步/异步 vs 阻塞/非阻塞

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


这两个维度容易混，区分清楚：

阻塞 vs 非阻塞（调用方的行为）：
 阻塞 — 调用后线程挂起，直到有结果
 非阻塞 — 调用立即返回（没有结果就返回错误）

同步 vs 异步（结果如何获取）：
 同步 — 调用方主动去拿结果（read 自己拷贝数据）
 异步 — 被调用方做完后通知调用方（内核拷贝完通知）

组合：
 同步阻塞 = read()（最传统）
 同步非阻塞 = 非阻塞 read() 轮询
 异步 = aio_read()（被通知）

 异步完成通常通过回调、事件、Future 或完成队列等机制交付结果

九、小结

I/O 两阶段：等数据就绪（慢）+ 数据拷贝（快）
5 种模型：
- 阻塞：简单，一连接一线程
- 非阻塞：轮询，浪费 CPU
- 多路复用：一线程管多 fd，高并发核心（select/poll/epoll）
- 信号驱动：用得少
- 异步 I/O：提交与完成分离（如 io_uring/IOCP），具体执行路径依实现而定
关键认知：不要仅凭 API 名称判断是否阻塞；应区分提交、等待、数据传输和完成通知
概念：阻塞/非阻塞是调用行为，同步/异步是结果获取方式

下一篇讲进程、线程、协程的本质与调度。

.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，讲解如何用火焰图定位性能瓶颈。

数据库系列（六）：锁与并发控制 — 从行锁到死锁检测

Sun, 12 Jan 2025 10:00:00 +0800

写在前面

承接前一篇 MVCC，本文继续讨论并发控制——但聚焦锁。MVCC 解决"读写并发"，锁解决"写写并发"。

本文要回答：

行锁到底是怎么实现的？SQL Server 为什么会"锁升级"？InnoDB 的 Gap Lock 到底锁了什么？PostgreSQL 怎么用 Advisory Lock 做分布式锁？

一、锁粒度层级

1.1 多层级的锁

1
2
3
4
5
6
7
8
9


数据库 → 表 → 页 / Extent → 行

层级关系：
 上层加意向锁（IS/IX），下层加实际锁（S/X）
 → 加行锁前，先在表上加意向锁

为什么不直接锁行？
 - 防止"表级操作（DROP TABLE）"看不到正在进行的行锁
 - 意向锁是一种"快速检测冲突"的机制

1.2 锁模式矩阵

锁模式	含义	兼容
S（Shared）	共享锁，读用	与 S、IS 兼容
X（Exclusive）	排他锁，写用	与所有锁互斥
IS（Intent Shared）	意向共享	与 IS、IX、S 兼容
IX（Intent Exclusive）	意向排他	与 IS、IX 兼容

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


兼容性矩阵（行级 / 表级）：
 S X IS IX
 S ✅ ❌ ✅ ❌
 X ❌ ❌ ❌ ❌
 IS ✅ ❌ ✅ ✅
 IX ❌ ❌ ✅ ✅

关键观察：
 - S 和 X 互斥（读和写不能同时）
 - X 和任何锁互斥（写需要独占）
 - IS 和 IX 互相兼容（意向只是"标记"，不实际锁定）
 - S 和 IX 不兼容（表级 S 锁阻止 IX，因为 IX 暗示有行级 X 锁）

二、SQL Server 的锁体系

SQL Server 是四家里锁体系最复杂的，因为它不依赖 MVCC（默认情况下），用锁解决所有并发。

2.1 多粒度锁

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


SQL Server 锁粒度：
 - RID（行 ID，堆表）
 - KEY（索引键，clustered/nonclustered）
 - PAGE（页）
 - EXTENT（区，8 页）
 - HoBT（堆或 B 树）
 - TABLE（表）
 - FILE（文件）
 - DATABASE（数据库）

→ SQL Server 会自动选择锁粒度（行/页/表），称为"动态锁"

2.2 锁升级（Lock Escalation）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


SQL Server 会在一条语句获取大量行锁或键锁时尝试锁升级：
 - 常见目标是整张表
 - 表配置为 LOCK_ESCALATION = AUTO 且已分区时，也可能升级到分区（HoBT）

约 5000 个锁是一次重要的升级检查触发点，不是保证升级的固定阈值；
是否成功还受冲突锁、内存压力和后续检查影响。

问题：
 - 升级后锁范围变大，并发变差
 - "我的 SELECT 突然阻塞了所有写入" 这种诡异问题

1
2
3
4
5
6
7
8
9


-- 查看锁
SELECT * FROM sys.dm_tran_locks
WHERE resource_database_id = DB_ID();

-- 禁用表锁升级
ALTER TABLE t SET (LOCK_ESCALATION = DISABLE);

-- 升级到 partition 而非 table
ALTER TABLE t SET (LOCK_ESCALATION = AUTO);

2.3 其他三家的对比

1
2
3
4
5
6


Oracle、InnoDB 和 PostgreSQL 通常不会像 SQL Server 那样把大量行锁自动升级为表锁。
但三者的行锁表示和资源消耗并不相同，不能据此推导出“持有任意数量的锁都没有成本”。

代价：
 - Oracle / PG 内存占用高（每行锁一个 entry）
 - 但并发性更好

三、InnoDB 的行锁三档

InnoDB 的锁是四家里最精巧的，因为它要同时支持 RR（防幻读）和高并发。

3.1 三种行锁

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


Record Lock（记录锁）：
 锁定索引上的一条记录
 WHERE id = 5 → 锁 id=5 的索引节点

Gap Lock（间隙锁）：
 锁定索引上的"区间"，但不含端点
 WHERE id > 5 AND id < 10 → 锁 (5, 10) 间隙
 防止其他事务在这个区间 INSERT

Next-Key Lock（Next-Key = Record + Gap）：
 锁定"一条记录 + 该记录之前的间隙"
 WHERE id BETWEEN 5 AND 10 → 锁 (3, 5], (5, 8], (8, 10] 等多个 Next-Key

3.2 加锁规则（RR 隔离级别下）

下面以 InnoDB、Repeatable Read、主键索引范围扫描和给定样例数据为前提说明概念。实际锁集合还会受执行计划、访问路径、数据分布与 MySQL 版本影响，应结合 EXPLAIN 和 performance_schema.data_locks 验证，不能只根据 SQL 文本机械推断。

1
2
3
4
5
6
7


InnoDB RR 下的加锁规则（基于《MySQL 实战 45 讲》）：

1. 原则 1：基本单位是 Next-Key Lock
2. 原则 2：查找过程中访问到的对象才加锁
3. 优化 1：唯一索引等值查询，命中记录 → 退化为 Record Lock
4. 优化 2：等值查询，向右遍历到最后一个不满足条件的值 → Next-Key 退化为 Gap Lock
5. 唯一索引范围查询：会访问到不满足条件的第一个值

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


示例表：id (1, 5, 10, 15, 20)，主键

场景 1：等值命中唯一索引
 SELECT * FROM t WHERE id = 10 FOR UPDATE;
 → 锁 id=10 的 Record Lock（不锁间隙）

场景 2：等值未命中唯一索引
 SELECT * FROM t WHERE id = 7 FOR UPDATE;
 → 锁 (5, 10) 的 Gap Lock（防止插入 7）

场景 3：范围查询
 SELECT * FROM t WHERE id >= 10 AND id < 15 FOR UPDATE;
 → 锁 id=10 的 Record Lock + (10, 15] 的 Next-Key Lock（含 15 这条记录）

场景 4：SELECT * FROM t WHERE id > 10 FOR UPDATE;
 → 锁 (10, 15], (15, 20], (20, +∞]

3.3 唯一索引 vs 非唯一索引的差异

1
2
3
4
5
6


唯一索引等值命中 → Record Lock（窄）
非唯一索引等值命中 → Next-Key（多个 Gap）

为什么？
 - 唯一索引：相同值只能有一个，不需要防止"再插一个相同值"
 - 非唯一索引：可能有多条相同值记录，需要锁定间隙防止幻读

3.4 RC 级别下

1
2
3
4
5


RC 级别下，InnoDB 的普通索引扫描通常只加 Record Lock：
 - 一般不使用 Gap Lock / Next-Key Lock
 - 外键约束检查、重复键检查等场景仍可能使用间隙锁
 - 不防幻读
 - 并发性更好

四、PostgreSQL 的锁

4.1 表级锁

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


LOCK TABLE t IN {MODE} MODE;

模式（强度递增）：
 ACCESS SHARE ← SELECT 自动加
 ROW SHARE ← SELECT FOR UPDATE/SHARE 自动加
 ROW EXCLUSIVE ← INSERT/UPDATE/DELETE 自动加
 SHARE UPDATE EXCL ← VACUUM 自动加
 SHARE ← CREATE INDEX 自动加
 SHARE ROW EXCL ← 手动
 EXCLUSIVE ← 手动
 ACCESS EXCLUSIVE ← ALTER/DROP/TRUNCATE 自动加

4.2 行级锁

1
2
3
4
5
6
7
8
9


PG 行级锁类型：
 FOR UPDATE ← 排他，允许其他事务读，阻止写
 FOR NO KEY UPDATE ← 排他（弱），允许其他 FOR KEY SHARE
 FOR SHARE ← 共享
 FOR KEY SHARE ← 共享（弱）

PG 行锁不存独立结构，记录在行的 xmax：
 - 优点：节省内存（不限制锁数量）
 - 缺点：检查冲突需要读行（多版本查询）

4.3 Advisory Lock（应用层分布式锁）

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


-- 会话级 Advisory Lock
SELECT pg_advisory_lock(12345); -- 申请锁
SELECT pg_advisory_unlock(12345); -- 释放

-- 事务级 Advisory Lock（事务结束自动释放）
SELECT pg_advisory_xact_lock(12345);

-- 非阻塞尝试
SELECT pg_try_advisory_lock(12345); -- 返回 true/false

-- 双 int 参数版本（支持 8 字节 key）
SELECT pg_advisory_lock(id1, id2);

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


应用场景：
 - 应用层分布式锁（避免引入 Redis / ZooKeeper）
 - 跨服务协调（多个服务连同一 PG）
 - 任务调度（多个 worker 抢任务）

优势：
 - 与业务事务原子性一致（事务级）
 - 不需要额外基础设施
 - 自动释放（连接断开 / 事务结束）

劣势：
 - 只能在 PG 内有效
 - 不适合跨数据库场景

五、Oracle 的锁

5.1 DML 锁

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


Oracle 行锁：
 - 通过 ITL（块的事务槽）实现
 - 锁信息存在数据块头部，不存独立结构
 - 不会"锁升级"

锁模式：
 - RX（Row Exclusive）：INSERT/UPDATE/DELETE
 - RS（Row Shared）：SELECT FOR SHARE
 - SRX（Shared Row Exclusive）：手工声明
 - S（Shared）：手工声明
 - X（Exclusive）：手工声明

5.2 DDL 锁

1
2
3
4


DDL 操作时锁定 schema 对象：
 - Exclusive DDL Lock：CREATE/ALTER/DROP 时，完全独占
 - Share DDL Lock：CREATE PROCEDURE 等，允许其他 DDL 但不允许 DROP
 - Breakable Parse Lock：缓存依赖关系

5.3 Oracle 没有锁升级

1
2
3
4


Oracle 设计哲学：
 - 数据块中的 ITL 记录访问该块的事务信息，行头再指向相应事务槽
 - 一个事务在同一数据块修改多行时可以共享一个 ITL 槽，并不是“一行一个 ITL entry”
 - 通常不会把大量行锁自动升级为表锁，但仍有 ITL、Undo 和事务管理成本

六、SELECT FOR UPDATE 家族

6.1 标准语法

1
2
3
4
5
6


-- 标准
SELECT * FROM t WHERE id = 1 FOR UPDATE;
-- 加 X 锁，其他事务读可（MVCC），写不行

SELECT * FROM t WHERE id = 1 FOR SHARE;
-- 加 S 锁，其他事务可以读，但不能写

6.2 NOWAIT / SKIP LOCKED

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


-- NOWAIT：拿不到锁立即报错
SELECT * FROM t WHERE id = 1 FOR UPDATE NOWAIT;
-- 错误：ORA-00054 / Lock wait timeout exceeded

-- SKIP LOCKED：跳过被锁的行（不阻塞）
SELECT * FROM t WHERE id IN (1, 2, 3) FOR UPDATE SKIP LOCKED;
-- 假设 id=2 被锁，返回 id=1 和 id=3

-- 用途：任务队列
SELECT * FROM task_queue WHERE status = 'pending'
FOR UPDATE SKIP LOCKED LIMIT 10;
-- 多个 worker 同时取任务，互不阻塞

1
2
3
4
5


支持情况：
 - Oracle：NOWAIT ✅ / SKIP LOCKED ✅
 - SQL Server：NOWAIT ✅（WITH NOWAIT）/ SKIP LOCKED ✅（READPAST）
 - MySQL：NOWAIT ✅（8.0+）/ SKIP LOCKED ✅（8.0+）
 - PostgreSQL：NOWAIT ✅ / SKIP LOCKED ✅

6.3 锁列（FOR UPDATE OF）

1
2
3


-- 联合查询时只锁特定表
SELECT * FROM orders o JOIN users u ON o.uid = u.id
FOR UPDATE OF o; -- 只锁 orders 行，不锁 users

七、死锁

7.1 死锁场景

1
2
3
4
5
6
7
8
9


事务A 事务B
BEGIN; BEGIN;
UPDATE t SET v=1 WHERE id=1; UPDATE t SET v=1 WHERE id=2;
 -- 持有 id=2 锁
UPDATE t SET v=1 WHERE id=2;
-- 等待 id=2 锁 UPDATE t SET v=1 WHERE id=1;
 -- 等待 id=1 锁

→ 死锁！双方互相等待

7.2 检测机制

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


Wait-For Graph（等待图）：
 - 数据库维护一个"事务等待关系图"
 - 检测图中是否有环
 - 有环 → 死锁
 - 选择"代价最小"的事务回滚（victim）

各家实现：
 - Oracle：自动检测并报告 ORA-00060，通常回滚触发死锁的语句；事务能否继续取决于应用如何处理
 - SQL Server：死锁监视器通常从约 5 秒间隔开始，频繁发生时可缩短到约 100 毫秒；受 `DEADLOCK_PRIORITY` 和回滚成本等因素影响选择 victim
 - MySQL InnoDB：自动检测，立即回滚（默认 deadlock_detect=ON）
 - PostgreSQL：自动检测，默认 1 秒间隔

7.3 如何避免死锁

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


1. 固定加锁顺序
 - 所有事务按相同顺序加锁（如按主键升序）
 - 避免环

2. 缩短事务
 - 持锁时间短，降低死锁概率
 - 不要在事务中调用外部 API

3. 用 NOWAIT + 重试
 - 拿不到锁立即失败
 - 应用层捕获错误后重试

4. 用 SKIP LOCKED
 - 任务队列场景，跳过被锁任务

5. 控制并发度
 - 同一资源并发不要太高

八、悲观锁 vs 乐观锁

8.1 悲观锁（Pessimistic）

1
2
3
4
5
6
7
8


假设冲突必然发生，提前加锁
 SELECT * FROM t WHERE id = 1 FOR UPDATE;
 -- 加锁后才修改
 UPDATE t SET v = ... WHERE id = 1;
 COMMIT;

适合：写冲突频繁
代价：持锁期间其他事务阻塞

8.2 乐观锁（Optimistic）

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


假设冲突很少，提交时检测

实现：版本号 / 时间戳字段
 CREATE TABLE t (id INT, v INT, version INT);

 -- 读
 SELECT id, v, version FROM t WHERE id = 1;
 -- 假设读到 version = 10

 -- 写（带版本检查）
 UPDATE t SET v = v + 1, version = version + 1
 WHERE id = 1 AND version = 10;
 -- 影响行数 = 0 → 说明版本变了 → 冲突
 -- 应用层重试

适合：读多写少、冲突少
代价：失败时需要重试

8.3 选型建议

1
2
3
4
5
6
7
8
9


冲突频繁、重试代价高且临界区很短时，可以优先评估悲观锁；
冲突少、读多写少或不希望长时间持锁时，可以优先评估乐观锁。
不存在适用于所有系统的固定“20%”分界线，应通过压测观察吞吐、尾延迟和失败重试成本。

业务场景：
 - 库存扣减：悲观（必然冲突）
 - 用户更新资料：乐观（极少冲突）
 - 抢购：悲观 + 队列
 - 投票计数：乐观 + 重试

九、常见锁问题排查

9.1 MySQL

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


-- 看当前事务
SELECT * FROM information_schema.innodb_trx;

-- 看锁（8.0+）
SELECT * FROM performance_schema.data_locks;
SELECT * FROM performance_schema.data_lock_waits;

-- 死锁日志
SHOW ENGINE INNODB STATUS\G

-- 锁等待超时
SHOW VARIABLES LIKE 'innodb_lock_wait_timeout';

9.2 PostgreSQL

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


-- 看锁
SELECT l.locktype, l.relation::regclass, l.pid, l.mode, l.granted, a.query
FROM pg_locks l
JOIN pg_stat_activity a ON l.pid = a.pid
WHERE NOT l.granted;

-- 看等待链
SELECT * FROM pg_stat_activity WHERE wait_event_type = 'Lock';

-- 杀会话
SELECT pg_terminate_backend(pid);

9.3 Oracle

1
2
3
4
5
6
7
8
9


-- 看锁
SELECT s.sid, s.serial#, l.type, l.mode_held, o.object_name
FROM v$lock l
JOIN v$session s ON l.sid = s.sid
JOIN dba_objects o ON l.id1 = o.object_id
WHERE l.type = 'TM';

-- 杀会话
ALTER SYSTEM KILL SESSION 'sid,serial#';

9.4 SQL Server

1
2
3
4
5


-- 看阻塞
SELECT * FROM sys.dm_exec_requests WHERE blocking_session_id <> 0;

-- 看锁
SELECT * FROM sys.dm_tran_locks WHERE request_status = 'WAIT';

十、小结

本文学习了锁与并发控制：

锁粒度层级：DB → 表 → 页 → 行
锁模式矩阵：S/X/IS/IX 的兼容性
SQL Server 的锁升级机制（约 5000 个锁会触发一次升级检查，但不是固定保证）
InnoDB 的三档锁：Record / Gap / Next-Key
InnoDB RR 下的加锁规则
PostgreSQL 的 Advisory Lock（应用层分布式锁）
Oracle 的 ITL 实现行锁
SELECT FOR UPDATE 家族（NOWAIT / SKIP LOCKED）
死锁的 Wait-For Graph 检测
悲观锁 vs 乐观锁

1
2
3
4


记住三句话：
 1. MVCC 解决读写并发，锁解决写写并发
 2. SQL Server 有显式的锁升级机制；其他数据库通常不做同类升级，但锁的表示与成本各不相同
 3. InnoDB 的 Next-Key Lock 是"为了 RR 防幻读"的代价

下一篇进入日志与崩溃恢复：ARIES 协议、WAL、Checkpoint、崩溃恢复流程，以及四大数据库的日志实现差异。

数据库系列（五）：MVCC 与隔离级别 — 为什么数据库不再读阻塞写

Fri, 10 Jan 2025 10:00:00 +0800

写在前面

承接事务主题，本文深入 ACID 中的 I——隔离性。MVCC（多版本并发控制）是现代数据库读写并发的核心机制，它让"读不阻塞写、写不阻塞读"成为可能。

本文要回答：

为什么 SQL 标准定义的四个隔离级别，各家数据库实现的行为却不一样？为什么 MySQL 要区分快照读与当前读，而 PostgreSQL Repeatable Read 依靠固定快照也不会出现经典幻读？为什么 PostgreSQL 表会膨胀？

一、并发问题：标准定义的四种异常

SQL 标准定义了四种并发异常，按严重程度递减：

1.1 脏读（Dirty Read）

1
2
3
4
5
6
7
8
9


事务 A 读到了事务 B 未提交的修改。

时间线：
 T1: 事务B：UPDATE balance SET bal = bal - 100 WHERE id=1; (未提交)
 T2: 事务A：SELECT bal FROM balance WHERE id=1; → 读到 -100 后的值
 T3: 事务B：ROLLBACK;
 → A 读到了"从未存在"的值

几乎所有现代数据库都默认不允许脏读。

1.2 不可重复读（Non-repeatable Read）

1
2
3
4
5
6
7


事务 A 同一行读两次，结果不同（其他事务已提交）。

时间线：
 T1: 事务A：SELECT bal FROM balance WHERE id=1; → 1000
 T2: 事务B：UPDATE balance SET bal = 900 WHERE id=1; COMMIT;
 T3: 事务A：SELECT bal FROM balance WHERE id=1; → 900
 → A 两次读结果不同

1.3 幻读（Phantom Read）

1
2
3
4
5
6
7


事务 A 同一查询两次，结果集行数不同（其他事务插入/删除了匹配行）。

时间线：
 T1: 事务A：SELECT * FROM users WHERE age > 18; → 10 行
 T2: 事务B：INSERT INTO users (age) VALUES (20); COMMIT;
 T3: 事务A：SELECT * FROM users WHERE age > 18; → 11 行
 → A 多了一行"幻影"

1.4 丢失更新（Lost Update）

1
2
3
4
5
6
7
8
9


两个事务都基于读到的旧值更新，后写的覆盖前写的。

 T1: 事务A：读 bal = 1000
 T2: 事务B：读 bal = 1000
 T3: 事务A：写 bal = 1000 + 100 = 1100
 T4: 事务B：写 bal = 1000 + 200 = 1200
 → A 的更新丢失

SQL 标准没列这个，但所有数据库都要处理。

1.5 异常矩阵

隔离级别	脏读	不可重复读	幻读	丢失更新
Read Uncommitted	✅	✅	✅	✅
Read Committed（RC）	❌	✅	✅	✅
Repeatable Read（RR）	❌	❌	✅	✅
Serializable	❌	❌	❌	❌

二、MVCC 基本原理

2.1 朴素的锁方案

1
2
3
4
5
6
7


读：加共享锁 S
写：加排他锁 X
S-X 互斥，X-X 互斥

问题：写事务持有 X 锁期间，所有读都被阻塞
 - 长事务写入 → 大量 SELECT 等待
 - 实际不可用

2.2 MVCC 思路

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


核心：每行有多个版本，每个事务看到自己"快照"

UPDATE 不修改原行，而是：
 1. 把原行标记为"旧版本"
 2. 写入新行（新版本）
 3. 不同事务根据"可见性规则"看到不同版本

 事务A（开始早）→ 看到旧版本
 事务B（开始晚）→ 看到新版本

→ 读和写不冲突！
→ 性能远高于锁方案

2.3 MVCC 的代价

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


代价 1：存储膨胀
 - 旧行版本不能立即删
 - 等到所有"可能看到旧行"的事务结束后才能清理
 - PostgreSQL 这点尤其严重（详见第 7 节）

代价 2：写放大
 - 一次 UPDATE = 写一行 + 标记旧行 + 更新索引
 - 比直接"原地改"成本高

代价 3：长事务问题
 - 长事务持有"旧版本"，导致 Undo/WAL 不能清理
 - 拖累整个实例

三、四种 MVCC 实现

四家的 MVCC 实现思路类似（多版本 + 可见性判断），但具体机制不同。

3.1 Oracle：Undo Segment + SCN

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


核心机制：
 - 每行有"块头 ITL（事务槽）"，记录最后修改它的事务
 - Undo Segment 存"旧版本"
 - SCN（System Change Number）：全局递增的事务编号

可见性判断：
 - 事务开始时记录一个"快照 SCN"
 - 读行时：
 - 行的 ITL SCN ≤ 快照 SCN → 可见
 - 行的 ITL SCN > 快照 SCN → 不可见，去 Undo Segment 找旧版本
 - 一直往回找，直到找到 ≤ 快照 SCN 的版本

1
2
3
4
5
6
7
8


查询流程：
 SELECT balance FROM accounts WHERE id = 1;

 1. 读到当前行的 balance = 900，ITL SCN = 200
 2. 我的快照 SCN = 150
 3. 200 > 150 → 不可见
 4. 通过 ITL 找到 Undo Segment 中 SCN = 100 的旧版本 balance = 1000
 5. 100 ≤ 150 → 可见，返回 1000

3.2 MySQL InnoDB：Undo Log + ReadView

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


核心机制：
 - 每行隐藏两个列：DB_TRX_ID（最后修改事务 ID）、DB_ROLL_PTR（指向 Undo 链）
 - Undo Log 中存旧版本，通过 DB_ROLL_PTR 串成链
 - ReadView：事务开始时创建的"快照"

ReadView 内容：
 - m_ids：当前活跃（未提交）事务 ID 列表
 - min_trx_id：m_ids 最小值
 - max_trx_id：下一个要分配的事务 ID
 - creator_trx_id：创建 ReadView 的事务 ID

可见性判断：
 - 行的 trx_id < min_trx_id → 该事务已提交 → 可见
 - 行的 trx_id >= max_trx_id → 该事务在我之后开始 → 不可见
 - 行的 trx_id 在 m_ids 中 → 该事务未提交 → 不可见
 - 行的 trx_id == creator_trx_id → 自己改的 → 可见
 - 否则 → 可见

1
2
3
4
5
6
7


RC vs RR 的实现差异：
 - Read Committed：每条 SELECT 都创建新 ReadView
 → 总是看到最新已提交数据
 → 但同一事务内同一行可能看到不同值（不可重复读）
 - Repeatable Read：事务内只创建一次 ReadView（第一次读时）
 → 整个事务看到的数据快照一致
 → 不会发生不可重复读

3.3 PostgreSQL：xmin/xmax + clog

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


核心机制：
 - 每行有 xmin（创建事务 ID）和 xmax（删除/更新事务 ID）
 - 没有独立 Undo，旧行就留在 Heap 里
 - clog（commit log）：记录每个事务的状态（committed/aborted/in-progress）

可见性判断：
 - 行的 xmin 已提交且 < 当前快照 → 可见
 - 行的 xmax 已提交且 ≤ 当前快照 → 已被删除，不可见
 - 复杂规则见 PostgreSQL 源码 HeapTupleSatisfiesMVCC

特点：
 - 不需要 Undo Log
 - 旧 tuple 直接留在 heap 中（"表膨胀"）
 - VACUUM 后台清理

3.4 SQL Server：RCSI / SI（基于 TempDB）

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


核心机制：
 - 行版本存在 TempDB（不是本表）
 - 两种模式：
 RCSI（Read Committed Snapshot Isolation）：
 - Read Committed 默认走行版本
 - 每条语句一个快照
 SI（Snapshot Isolation）：
 - 类似 RR，整个事务一个快照
 - 需要应用显式启用

启用：
 ALTER DATABASE mydb SET READ_COMMITTED_SNAPSHOT ON; -- RCSI
 ALTER DATABASE mydb SET ALLOW_SNAPSHOT_ISOLATION ON; -- SI

注意：
 - SQL Server 默认 RC 是"读加 S 锁"，不是 MVCC
 - 启用 RCSI 后才变成 MVCC 行为

3.5 四家对比

维度	Oracle	SQL Server	MySQL InnoDB	PostgreSQL
旧版本存放	Undo Segment	TempDB	Undo Log	Heap 内
事务标识	SCN	TID	DB_TRX_ID	xmin/xmax
清理机制	SMON 自动	TempDB 自动	Purge Thread	autovacuum
默认隔离级别	Read Committed	Read Committed	Repeatable Read	Read Committed
事务级快照下的重复查询	Oracle 的 SERIALIZABLE 使用事务快照	SQL Server SI 使用事务快照	RR 快照读使用事务快照	RR 使用事务快照

四、幻读与 Next-Key Lock

4.1 MySQL InnoDB 的 RR：为什么能防幻读

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


InnoDB 在 RR 级别下，普通 SELECT 用 MVCC（快照读），不会幻读
但 UPDATE/DELETE/SELECT FOR UPDATE 用当前读，要靠锁防幻读

Next-Key Lock = Gap Lock + Record Lock

示例：
 表：id (1, 5, 10, 15, 20)
 索引：id 主键

 事务A：SELECT * FROM t WHERE id BETWEEN 5 AND 15 FOR UPDATE;
 → 锁住 id ∈ [5, 15] 的所有行（Record Lock）
 → 同时锁住 (15, 20) 之间的"间隙"（Gap Lock）
 → 防止其他事务插入 id ∈ (10, 15) 或 (15, 20)

 事务B：INSERT INTO t VALUES (12);
 → 阻塞（Gap Lock 拦截）

1
2
3
4


Gap Lock 的副作用：
 - 锁范围比"实际行"大
 - 高并发插入场景容易死锁
 - 唯一索引等值查询会"退化"（不需要 Gap Lock）

4.2 PostgreSQL 的 RR：固定快照不会出现幻读

1
2
3
4
5
6
7
8
9


PG 的 RR 基于事务级 MVCC 快照：
 - 整个事务使用同一个快照
 - 重复执行同一查询不会看到其他事务后来提交的新行
 - 因此它比 SQL 标准要求的 RR 更强，不会出现幻读
 - 但仍可能出现写偏斜等序列化异常

 事务A：SELECT * FROM t WHERE id > 10; → 3 行
 事务B：INSERT INTO t VALUES (15); COMMIT;
 事务A：SELECT * FROM t WHERE id > 10; → 仍是 3 行（B 的新行对 A 的事务快照不可见，无幻读）

1
2
3
4


PG 怎么避免更广义的序列化异常？
 → 用 Serializable 级别（SSI 实现）
 → 通过谓词读依赖（内部以 SIReadLock 等形式跟踪）和冲突检测
 → 冲突事务可能被中止，应用必须重试

4.3 SQL Server：SI 也使用事务级快照

1
2
3
4
5
6
7


SI（Snapshot Isolation）：类似 PG 的 RR
 - 不会不可重复读
 - 同一事务重复查询不会看到后来提交的新行，因此不会出现经典幻读
 - 写冲突时报错（需要重试）
 - 但它不等同于 Serializable，仍需防范写偏斜等异常

要防幻读 → Serializable

五、Serializable 的"真假"

5.1 真 Serializable vs SSI

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


Serializable：
 - 并发结果等价于某个串行执行顺序
 - 可以通过严格两阶段锁、SSI 等不同机制实现
 - 性能和冲突代价取决于实现与工作负载，不能概括为“几乎不用”

SSI（Serializable Snapshot Isolation）：
 - PostgreSQL 9.1+ 使用该方案；SQL Server 的 Snapshot Isolation 不是 SSI
 - 基于 MVCC + 冲突检测
 - 避免长期持有范围锁，但需要跟踪读写依赖
 - 高冲突场景仍可能频繁中止事务，性能取决于工作负载

5.2 各家 Serializable 实现

数据库	实现	性能
Oracle	快照一致性 + 冲突检测，冲突时可能报 ORA-08177	取决于冲突率与重试成本
SQL Server	范围锁	并发性可能受范围锁影响
MySQL InnoDB	2PL + Next-Key Lock	并发性可能受间隙锁影响
PostgreSQL	SSI	避免阻塞式范围锁，但冲突事务可能回滚

5.3 实践建议

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


默认隔离级别选择：
 - Oracle / SQL Server / PG → Read Committed（默认）
 - MySQL InnoDB → Repeatable Read（默认）

需要"严格串行化"：
 - 高一致性场景（金融）→ Serializable
 - 否则 RC/RR 已经够用

PG SSI 用法：
 SET default_transaction_isolation = 'serializable';
 -- 业务代码需要重试机制（写冲突会报错）

六、Read Committed 的细节差异

6.1 Oracle / PG 的 RC：语句级快照

1
2
3
4
5
6


每条 SELECT 创建一个新快照，看到当时最新已提交数据。

 事务A：
 SELECT * FROM t WHERE id = 1; -- 假设看到 value = 100
 [其他事务改并提交 value = 200]
 SELECT * FROM t WHERE id = 1; -- 看到 value = 200

6.2 MySQL InnoDB 的 RC：与 Oracle/PG 类似

1
2
3
4


InnoDB 在 RC 级别下：
 - 每条 SELECT 创建新 ReadView
 - 普通索引扫描通常不使用 Gap Lock/Next-Key Lock，但外键约束检查和重复键检查等场景仍会使用间隙锁
 - 不能防不可重复读

6.3 SQL Server 默认 RC：基于锁

1
2
3
4
5
6
7
8


SQL Server 默认 RC 是"读加 S 锁"：
 - SELECT 期间持 S 锁
 - 写事务被阻塞
 - 不是 MVCC

启用 RCSI 后变成 MVCC（语句级快照）：
 ALTER DATABASE mydb SET READ_COMMITTED_SNAPSHOT ON;
 -- 这是 SQL Server 性能优化关键步骤

七、PostgreSQL 表膨胀与 VACUUM

7.1 为什么 PG 会膨胀

1
2
3
4
5
6
7


PG 没有 Undo Segment，旧 tuple 留在 heap：
 UPDATE → 插入新 tuple + 标记旧 tuple xmax
 旧 tuple 仍在 heap 中，占用空间

 长期高频 UPDATE：
 原表 1GB → 实际有效数据 200MB + 死 tuple 800MB
 → 性能下降（扫描慢、缓存命中率低）

7.2 autovacuum

1
2
3
4
5
6
7


PG 自动清理死 tuple 的后台进程：
 - 默认启用
 - 每 N 行变更触发一次 VACUUM
 - 关键参数：
 autovacuum_vacuum_threshold = 50（基础行数）
 autovacuum_vacuum_scale_factor = 0.2（变更比例）
 → 满足条件：50 + 表行数 × 0.2

1
2
3
4
5
6
7
8
9


-- 手动触发
VACUUM ANALYZE accounts; -- 普通 VACUUM + 更新统计
VACUUM FULL accounts; -- 锁表 + 重写表（回收磁盘空间，慢）
REINDEX TABLE accounts; -- 重建索引

-- 监控
SELECT relname, n_live_tup, n_dead_tup
FROM pg_stat_user_tables
WHERE n_dead_tup > 10000;

7.3 长事务的危害

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


PG 长事务的连锁问题：
 1. 旧 tuple 不能被 VACUUM 清理（事务可能还要看到）
 2. clog 不能截断
 3. 复制槽（replication slot）可能阻塞 WAL 删除
 4. 表空间持续膨胀

排查：
 SELECT pid, age(now(), xact_start) AS duration, query
 FROM pg_stat_activity
 WHERE state = 'idle in transaction';

 → 长事务杀掉：SELECT pg_terminate_backend(pid);

八、常见问题排查

8.1 死锁

1
2
3
4
5


-- MySQL 看最近一次死锁
SHOW ENGINE INNODB STATUS\G

-- PostgreSQL 看日志
-- 默认会记录：ERROR: deadlock detected

8.2 锁等待

1
2
3
4
5
6


-- MySQL 看锁等待
SELECT * FROM information_schema.innodb_trx;
SELECT * FROM performance_schema.data_locks;

-- PostgreSQL 看锁
SELECT * FROM pg_locks WHERE NOT granted;

8.3 长事务

1
2
3
4
5
6
7
8
9


-- MySQL
SELECT * FROM information_schema.innodb_trx
WHERE TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) > 60;

-- PostgreSQL
SELECT pid, xact_start, query
FROM pg_stat_activity
WHERE state IN ('active', 'idle in transaction')
ORDER BY xact_start;

九、小结

本文学习了 MVCC 与隔离级别：

四种并发异常：脏读、不可重复读、幻读、丢失更新
MVCC 的核心：多版本 + 可见性判断
四家 MVCC 实现：Oracle Undo、InnoDB ReadView、PG xmin/xmax、SQL Server TempDB
隔离级别实现差异：InnoDB RR 的快照读与锁定读机制不同；PostgreSQL RR 的固定快照不会出现幻读，但仍非 Serializable
Serializable 的不同实现：传统 2PL、快照冲突检测与 SSI
PostgreSQL 的表膨胀与 VACUUM 机制
长事务的危害

1
2
3
4


记住三句话：
 1. RC 是语句级快照，RR 是事务级快照，Serializable 保证结果等价于串行（可由 2PL 或 SSI 实现）
 2. PG 没有独立 Undo 段，旧 tuple 留在 heap → 应保持 autovacuum 有效并持续监控
 3. MySQL InnoDB 默认 RR + Next-Key Lock 防幻读，但代价是死锁风险

下一篇进入锁与并发控制：从行锁到死锁检测，深入 InnoDB 的 Record/Gap/Next-Key 三档锁、SQL Server 的锁升级、PostgreSQL 的 Advisory Lock。

Redis 学习笔记（三）：分布式锁

Tue, 19 Nov 2024 10:00:00 +0800

写在前面

本文是 Redis 学习笔记系列的第三篇，深入分布式锁的实现原理、常见问题和 .NET 实战封装。前置知识：缓存实战（第二篇）。

一、为什么需要分布式锁

1.1 单机锁的问题

1
2
3
4
5
6
7


单机环境：
 lock (obj) { ... } — Monitor
 SemaphoreSlim — 信号量
 Mutex — 互斥体

这些锁只在当前进程内有效。
部署多个实例后，各进程的锁互不影响，无法保证互斥。

1.2 分布式场景

1
2
3
4
5
6
7
8


场景：多个订单服务实例，防止同一笔订单被重复处理。

实例 A：处理订单 12345
实例 B：也收到订单 12345 的请求

如果用单机锁，A 和 B 各自加锁成功 → 重复处理

需要一把跨进程、跨机器的锁 → 分布式锁

1.3 分布式锁的要求

1
2
3
4
5


1. 互斥性 — 任意时刻只有一个客户端持有锁
2. 可重入 — 同一线程/进程可以重复获取同一把锁
3. 有限租期 — 持有者宕机后锁最终过期；业务超出租期时仍需续期或 fencing 保护
4. 高性能 — 加锁/解锁要快
5. 高可用 — 锁服务不能成为单点故障

二、Redis 实现分布式锁

2.1 基本原理

1
2
3
4
5
6
7


加锁：SET lock_key unique_value NX EX 30
 NX — key 不存在才设置（保证互斥）
 EX — 过期时间（防止死锁）
 unique_value — 客户端唯一标识（防止误删别人的锁）

解锁：Lua 脚本（原子操作）
 先判断 value 是否匹配 → 匹配才删除

2.2 为什么解锁要用 Lua 脚本

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


不用 Lua 脚本的问题：

1. 客户端 A 执行 GET lock_key → 返回 "A"
2. 客户端 A 判断 value == "A" → 是我的锁
3. 【此时锁恰好过期，Redis 自动删除】
4. 客户端 B 执行 SET lock_key "B" NX → 成功
5. 客户端 A 执行 DEL lock_key → 删了 B 的锁！

Lua 脚本保证"判断 + 删除"是原子操作：

if redis.call("get", KEYS[1]) == ARGV[1] then
 return redis.call("del", KEYS[1])
else
 return 0
end

2.3 基础实现

1
2
3
4
5


# 加锁
SET lock:order:12345 "client-uuid-abc" NX EX 30

# 解锁（Lua 脚本）
EVAL "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end" 1 lock:order:12345 "client-uuid-abc"

三、锁续期

3.1 问题：业务没处理完锁就过期了

1
2
3
4
5
6
7


设置锁过期时间 30 秒，但业务处理需要 40 秒：

1. 客户端 A 加锁（30 秒）
2. A 开始处理业务（预计 40 秒）
3. 30 秒后锁自动过期
4. 客户端 B 加锁成功
5. A 处理完业务，释放了 B 的锁 → 严重问题！

3.2 解决：看门狗机制

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


看门狗（Watchdog）：后台线程定期延长锁的过期时间。

工作方式：
 - 加锁成功后，启动看门狗线程
 - 每隔 lock_time / 3 检查一次
 - 如果锁还持有（value 匹配），重置过期时间
 - 如果业务处理完成，看门狗停止续期

示例：
 锁过期时间 30 秒
 看门狗每 10 秒续期一次
 业务处理 40 秒：
 0s 加锁（30s 过期）
 10s 续期（30s 过期）
 20s 续期（30s 过期）
 30s 续期（30s 过期）
 40s 业务完成，主动释放锁，看门狗停止

四、可重入锁

4.1 问题：同一线程多次加锁

1
2
3


方法 A 加锁 → 调用方法 B → 方法 B 也加同一把锁

如果锁不可重入，方法 B 等待方法 A 释放 → 死锁

4.2 实现：Hash + 计数器

1
2
3
4
5
6
7
8
9


# 加锁（可重入）
# key = lock name, field = client_id, value = 重入次数
HSET lock:order:12345 "client-uuid-abc" 1
# 重入时计数 +1
HINCRBY lock:order:12345 "client-uuid-abc" 1

# 解锁时计数 -1
HINCRBY lock:order:12345 "client-uuid-abc" -1
# 计数归零时删除 key

五、.NET 实战封装

5.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
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


public interface IDistributedLock : IDisposable
{
 Task<bool> TryAcquireAsync(TimeSpan timeout);
 Task ReleaseAsync();
}

public class RedisDistributedLock : IDistributedLock
{
 private readonly IDatabase _db;
 private readonly string _lockKey;
 private readonly string _lockValue;
 private readonly TimeSpan _expiry;
 private bool _disposed;

 // Lua 解锁脚本（只删自己的锁）
 private static readonly LuaScript UnlockScript = LuaScript.Prepare(
 @"if redis.call('get', @key) == @value then
 return redis.call('del', @key)
 else
 return 0
 end");

 public RedisDistributedLock(
 IDatabase db, string lockKey, TimeSpan expiry)
 {
 _db = db;
 _lockKey = lockKey;
 _lockValue = Guid.NewGuid().ToString(); // 唯一标识
 _expiry = expiry;
 }

 public async Task<bool> TryAcquireAsync(TimeSpan timeout)
 {
 var deadline = DateTime.UtcNow + timeout;
 var retryDelay = TimeSpan.FromMilliseconds(50);

 while (DateTime.UtcNow < deadline)
 {
 var acquired = await _db.StringSetAsync(
 _lockKey, _lockValue, _expiry, When.NotExists);

 if (acquired)
 return true;

 await Task.Delay(retryDelay);
 }

 return false; // 超时未获取到锁
 }

 public async Task ReleaseAsync()
 {
 await _db.ScriptEvaluateAsync(UnlockScript,
 new { key = (RedisKey)_lockKey, value = _lockValue });
 }

 public void Dispose()
 {
 if (!_disposed)
 {
 ReleaseAsync().GetAwaiter().GetResult();
 _disposed = true;
 }
 }
}

5.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


public class OrderService
{
 private readonly IConnectionMultiplexer _redis;

 public OrderService(IConnectionMultiplexer redis) => _redis = redis;

 public async Task ProcessOrderAsync(string orderId)
 {
 var db = _redis.GetDatabase();
 var lockKey = $"lock:order:{orderId}";

 await using var @lock = new RedisDistributedLock(
 db, lockKey, TimeSpan.FromSeconds(30));

 // 尝试获取锁，最多等 5 秒
 var acquired = await @lock.TryAcquireAsync(TimeSpan.FromSeconds(5));

 if (!acquired)
 {
 throw new InvalidOperationException($"获取订单 {orderId} 的锁失败");
 }

 // 获取锁成功，处理业务
 await DoProcessOrder(orderId);

 // 离开 using 块时自动释放锁
 }
}

5.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
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
91
92
93
94
95
96
97
98


public class RedisDistributedLockWithWatchdog : IDistributedLock
{
 private readonly IDatabase _db;
 private readonly string _lockKey;
 private readonly string _lockValue;
 private readonly TimeSpan _expiry;
 private readonly TimeSpan _renewInterval;
 private CancellationTokenSource? _cts;
 private bool _disposed;

 private static readonly LuaScript UnlockScript = LuaScript.Prepare(
 @"if redis.call('get', @key) == @value then
 return redis.call('del', @key)
 else
 return 0
 end");

 private static readonly LuaScript RenewScript = LuaScript.Prepare(
 @"if redis.call('get', @key) == @value then
 return redis.call('expire', @key, @ttl)
 else
 return 0
 end");

 public RedisDistributedLockWithWatchdog(
 IDatabase db, string lockKey, TimeSpan expiry)
 {
 _db = db;
 _lockKey = lockKey;
 _lockValue = Guid.NewGuid().ToString();
 _expiry = expiry;
 _renewInterval = TimeSpan.FromTicks(expiry.Ticks / 3);
 }

 public async Task<bool> TryAcquireAsync(TimeSpan timeout)
 {
 var deadline = DateTime.UtcNow + timeout;
 var retryDelay = TimeSpan.FromMilliseconds(50);

 while (DateTime.UtcNow < deadline)
 {
 var acquired = await _db.StringSetAsync(
 _lockKey, _lockValue, _expiry, When.NotExists);

 if (acquired)
 {
 StartWatchdog();
 return true;
 }

 await Task.Delay(retryDelay);
 }

 return false;
 }

 private void StartWatchdog()
 {
 _cts = new CancellationTokenSource();
 _ = Task.Run(async () =>
 {
 while (!_cts.Token.IsCancellationRequested)
 {
 try
 {
 await Task.Delay(_renewInterval, _cts.Token);

 await _db.ScriptEvaluateAsync(RenewScript,
 new
 {
 key = (RedisKey)_lockKey,
 value = _lockValue,
 ttl = (int)_expiry.TotalSeconds
 });
 }
 catch (OperationCanceledException) { break; }
 }
 }, _cts.Token);
 }

 public async Task ReleaseAsync()
 {
 _cts?.Cancel();

 await _db.ScriptEvaluateAsync(UnlockScript,
 new { key = (RedisKey)_lockKey, value = _lockValue });
 }

 public void Dispose()
 {
 if (!_disposed)
 {
 ReleaseAsync().GetAwaiter().GetResult();
 _cts?.Dispose();
 _disposed = true;
 }
 }
}

这段代码用于解释租约续期思路，并非完整生产实现。生产代码还应监控续期任务异常、检查 Lua 返回值、处理网络分区与进程暂停，并优先使用经过验证的锁库；对高风险写操作还需配合 fencing token 或存储层条件写。

六、RedLock 算法

6.1 单节点锁的问题

1
2
3
4
5
6
7


Redis 主从复制场景：
 1. 客户端 A 在 Master 加锁成功
 2. Master 还没同步到 Slave 就宕机了
 3. Slave 被提升为 Master（锁数据丢失）
 4. 客户端 B 加锁成功 → 两把锁同时存在！

RedLock：在多个独立的 Redis 实例上加锁，多数成功才算成功。

RedLock 的故障模型和时钟假设长期存在争议。即使成功获取锁，客户端暂停超过租期后仍可能与新持有者并发执行；对数据库写入、设备控制等高风险资源，应优先使用存储系统提供的条件写或单调递增 fencing token 拒绝旧持有者，而不是把 Redis 锁当作强一致性证明。

6.2 RedLock 流程

1
2
3
4
5
6
7


假设 5 个独立的 Redis 节点：

1. 记录开始时间
2. 依次向 5 个节点加锁（SET NX EX，很快）
3. 计算加锁耗时
4. 如果在 N/2+1（即 3）个节点加锁成功，且耗时 < 锁有效期 → 加锁成功
5. 失败则向所有节点释放锁

6.3 .NET 使用 RedLock.net

1

dotnet add package RedLock.net.SERedis

 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


// 注册 RedLockFactory
builder.Services.AddSingleton<RedLockFactory>(sp =>
{
 var connection = sp.GetRequiredService<IConnectionMultiplexer>();
 return RedLockFactory.Create(connection);
});

// 使用
public class OrderService
{
 private readonly RedLockFactory _lockFactory;

 public OrderService(RedLockFactory lockFactory) => _lockFactory = lockFactory;

 public async Task ProcessOrderAsync(string orderId)
 {
 var resource = $"lock:order:{orderId}";
 var expiry = TimeSpan.FromSeconds(30);
 var wait = TimeSpan.FromSeconds(5);
 var retry = TimeSpan.FromMilliseconds(200);

 await using var redLock = await _lockFactory.CreateLockAsync(
 resource, expiry, wait, retry);

 if (redLock.IsAcquired)
 {
 await DoProcessOrder(orderId);
 }
 else
 {
 throw new InvalidOperationException("获取锁失败");
 }
 }
}

七、分布式锁注意事项

7.1 锁过期时间设置

1
2
3
4
5
6
7


太短：业务没处理完锁就过期了 → 失去互斥保护
太长：客户端宕机后锁很久才释放 → 其他客户端等待太久

建议：
 - 根据业务最大执行时间设置（通常是秒级）
 - 加上看门狗续期机制
 - 一般设置 10-30 秒

7.2 锁粒度

1
2
3
4
5
6
7


粒度太粗：锁整个业务 → 并发度低
粒度太细：锁太多 key → 管理复杂、性能开销大

建议：锁到具体业务实体
 lock:order:12345 — 锁一个订单
 lock:inventory:SKU001 — 锁一个 SKU 的库存
 lock:user:phone:13800138000 — 锁一个手机号的发送频率

7.3 锁的释放

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


一定要在 finally 中释放锁：

try
{
 var acquired = await @lock.TryAcquireAsync(timeout);
 if (acquired)
 {
 await DoWork();
 }
}
finally
{
 await @lock.ReleaseAsync(); // 无论如何都释放
}

或者用 using/await using 自动释放

八、小结

本文学习了分布式锁：

为什么需要分布式锁
Redis 分布式锁原理（SET NX EX + Lua 解锁）
锁续期（看门狗机制）
可重入锁
.NET 实战封装（基础锁、带看门狗的锁）
RedLock 算法和 RedLock.net
锁的注意事项（过期时间、粒度、释放）

下一篇将学习持久化、高可用和运维。

Go 学习笔记（五）：并发编程

Mon, 30 Sep 2024 10:00:00 +0800

写在前面

本文是 Go 学习笔记系列的第五篇，介绍 Go 的并发编程。并发是 Go 的核心优势，goroutine + channel 的模型简洁而强大。前置知识：接口与错误处理（第四篇）。

一、goroutine

1.1 启动 goroutine

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


// 普通函数调用（同步）
doSomething()

// 加 go 关键字启动 goroutine（异步）
go doSomething()

// 匿名函数启动
go func() {
 fmt.Println("goroutine 中执行")
}()

1.2 goroutine 基本示例

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


func main() {
 // 启动多个 goroutine
 go func() {
 for i := 0; i < 3; i++ {
 fmt.Println("goroutine A:", i)
 }
 }()

 go func() {
 for i := 0; i < 3; i++ {
 fmt.Println("goroutine B:", i)
 }
 }()

 // 问题：main 函数结束后所有 goroutine 都会被终止
 // 输出可能什么都看不到，因为 main 先退出了
}

1.3 等待 goroutine 结束

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


import "sync"

func main() {
 var wg sync.WaitGroup

 for i := 0; i < 5; i++ {
 wg.Add(1) // 计数器 +1
 go func(id int) {
 defer wg.Done() // 计数器 -1
 fmt.Printf("worker %d 完成\n", id)
 }(i)
 }

 wg.Wait() // 阻塞直到计数器归零
 fmt.Println("所有 worker 完成")
}

版本边界：Go 1.22 起，使用 go 1.22 或更高语言版本的模块会为 for 循环的每次迭代创建独立变量。为兼容旧模块、让参数传递更直观，示例仍显式传入 i。

1.4 goroutine 特点

1
2
3
4


- 极轻量：初始栈只有 2KB（可动态增长），比线程轻得多
- 非阻塞：goroutine 的调度由 Go 运行时管理，不依赖 OS 线程
- 数量：轻松创建数万个 goroutine
- 调度：GMP 模型（Goroutine-Machine-Processor），由运行时自动调度

二、channel

channel 是 goroutine 之间通信的管道，Go 的并发哲学：不要通过共享内存来通信，而要通过通信来共享内存。

2.1 创建和使用

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


// 创建 channel
ch := make(chan int) // 无缓冲 channel
ch := make(chan int, 10) // 带缓冲 channel，容量10

// 发送数据
ch <- 42

// 接收数据
value := <-ch

// 接收并判断是否关闭
value, ok := <-ch
if !ok {
 fmt.Println("channel 已关闭")
}

// 关闭 channel
close(ch)

2.2 无缓冲 channel

1
2
3
4
5
6
7
8
9


// 无缓冲 channel：发送和接收必须同时就绪（同步）
ch := make(chan string)

go func() {
 ch <- "hello" // 发送后阻塞，直到有人接收
}()

msg := <-ch // 阻塞，直到有数据
fmt.Println(msg) // hello

无缓冲 channel 也叫同步 channel，发送和接收是握手操作。

2.3 带缓冲 channel

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


// 带缓冲 channel：缓冲区满之前发送不阻塞
ch := make(chan int, 3) // 容量3

ch <- 1 // 不阻塞
ch <- 2 // 不阻塞
ch <- 3 // 不阻塞
// ch <- 4 // 阻塞，缓冲区满了

fmt.Println(len(ch)) // 3（当前缓冲区中的元素数）
fmt.Println(cap(ch)) // 3（容量）

v1 := <-ch // 1
v2 := <-ch // 2

2.4 关闭 channel

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


ch := make(chan int, 5)

// 生产者发送完数据后关闭
ch <- 1
ch <- 2
ch <- 3
close(ch)

// 消费者用 range 遍历（自动在 close 后退出）
for v := range ch {
 fmt.Println(v) // 1 2 3
}

// 注意：
// - 只有发送方应该关闭 channel
// - 关闭后不能再发送（panic）
// - 关闭后仍可以接收（返回零值和 false）
// - 不需要关闭的 channel 就不要关（GC 会回收）

2.5 单向 channel

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


// 只发送（生产者）
func producer(ch chan<- int) {
 for i := 0; i < 5; i++ {
 ch <- i
 }
 close(ch)
}

// 只接收（消费者）
func consumer(ch <-chan int) {
 for v := range ch {
 fmt.Println(v)
 }
}

func main() {
 ch := make(chan int, 5)
 go producer(ch)
 consumer(ch)
}

三、select

select 同时监听多个 channel，类似 switch 但专门用于 channel 操作。

3.1 基本用法

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


ch1 := make(chan string)
ch2 := make(chan string)

go func() {
 time.Sleep(1 * time.Second)
 ch1 <- "来自 ch1"
}()

go func() {
 time.Sleep(2 * time.Second)
 ch2 <- "来自 ch2"
}()

// 哪个先就绪就执行哪个
for i := 0; i < 2; i++ {
 select {
 case msg1 := <-ch1:
 fmt.Println(msg1)
 case msg2 := <-ch2:
 fmt.Println(msg2)
 }
}

3.2 超时控制

1
2
3
4
5
6


select {
case result := <-ch:
 fmt.Println("收到:", result)
case <-time.After(3 * time.Second):
 fmt.Println("超时了")
}

3.3 非阻塞操作

1
2
3
4
5
6


select {
case msg := <-ch:
 fmt.Println("收到:", msg)
default:
 fmt.Println("没有数据，做其他事")
}

四、sync 包

4.1 Mutex — 互斥锁

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


import "sync"

type SafeCounter struct {
 mu sync.Mutex
 m map[string]int
}

func (c *SafeCounter) Inc(key string) {
 c.mu.Lock()
 defer c.mu.Unlock()
 c.m[key]++
}

func (c *SafeCounter) Get(key string) int {
 c.mu.Lock()
 defer c.mu.Unlock()
 return c.m[key]
}

// 使用
counter := SafeCounter{m: make(map[string]int)}
counter.Inc("hello")
fmt.Println(counter.Get("hello")) // 1

4.2 RWMutex — 读写锁

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


type Cache struct {
 mu sync.RWMutex
 data map[string]string
}

// 写操作用写锁（互斥）
func (c *Cache) Set(key, value string) {
 c.mu.Lock()
 defer c.mu.Unlock()
 c.data[key] = value
}

// 读操作用读锁（共享，多个读者可以同时读）
func (c *Cache) Get(key string) string {
 c.mu.RLock()
 defer c.mu.RUnlock()
 return c.data[key]
}

RWMutex 允许多个读者并发，但维护成本高于 Mutex。它是否更快取决于临界区长度、竞争度和读写比例，应以基准测试决定。

4.3 sync.Once — 只执行一次

1
2
3
4
5
6
7
8
9


var once sync.Once
var instance *Config

func GetConfig() *Config {
 once.Do(func() {
 instance = loadConfig() // 无论多少 goroutine 调用，只执行一次
 })
 return instance
}

4.4 sync.Map — 并发安全的 Map

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


var m sync.Map

// 写入
m.Store("name", "张三")
m.Store("age", 25)

// 读取
val, ok := m.Load("name")
if ok {
 fmt.Println(val) // 张三
}

// 遍历
m.Range(func(key, value any) bool {
 fmt.Println(key, value)
 return true // 返回 false 停止遍历
})

// 删除
m.Delete("age")

sync.Map 主要针对“某个键只写一次、读很多次”或“不同 goroutine 操作互不相交的键”等场景。其他负载通常更适合类型安全的普通 map 配合锁，具体仍应基准测试。

五、context

context 用于在 goroutine 之间传递取消信号、超时、截止时间和请求级别的值。

5.1 取消（WithCancel）

 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


import "context"

func worker(ctx context.Context, id int) {
 for {
 select {
 case <-ctx.Done():
 fmt.Printf("worker %d 收到取消信号，退出\n", id)
 return
 default:
 fmt.Printf("worker %d 工作中...\n", id)
 time.Sleep(500 * time.Millisecond)
 }
 }
}

func main() {
 ctx, cancel := context.WithCancel(context.Background())

 go worker(ctx, 1)
 go worker(ctx, 2)

 time.Sleep(2 * time.Second)
 cancel() // 通知所有 worker 退出

 time.Sleep(1 * time.Second) // 等待 worker 退出
}

5.2 超时（WithTimeout）

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


func doWork(ctx context.Context) error {
 // 模拟耗时操作
 select {
 case <-time.After(5 * time.Second):
 return nil
 case <-ctx.Done():
 return ctx.Err() // context deadline exceeded
 }
}

func main() {
 // 3秒超时
 ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)
 defer cancel()

 if err := doWork(ctx); err != nil {
 fmt.Println("操作失败:", err) // context deadline exceeded
 }
}

5.3 传值（WithValue）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


func main() {
 // 传请求级别的值（如 trace_id）
 ctx := context.WithValue(context.Background(), "traceID", "abc-123")

 handleRequest(ctx)
}

func handleRequest(ctx context.Context) {
 traceID := ctx.Value("traceID")
 fmt.Println("traceID:", traceID) // abc-123
}

WithValue 只用于请求级别的跨函数传值（trace_id、user_id 等），不要用来传可选参数。

5.4 context 使用规则

1
2
3
4
5


- 不要把 context 放在结构体里，作为函数第一个参数传递
- 传递 context 给子函数，子函数可以随时被取消
- context.WithValue 的 key 建议用自定义类型，避免冲突
- 函数接收 context 时，不要传 nil，用 context.TODO() 代替
- cancel() 要 defer 调用，避免资源泄漏

六、常见并发模式

6.1 Worker Pool（工作池）

 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


func workerPool(jobs <-chan int, results chan<- int, id int) {
 for job := range jobs {
 fmt.Printf("worker %d 处理任务 %d\n", id, job)
 results <- job * 2
 }
}

func main() {
 jobs := make(chan int, 10)
 results := make(chan int, 10)

 // 启动3个 worker
 for w := 1; w <= 3; w++ {
 go workerPool(jobs, results, w)
 }

 // 发送5个任务
 for j := 1; j <= 5; j++ {
 jobs <- j
 }
 close(jobs)

 // 收集结果
 for r := 1; r <= 5; r++ {
 fmt.Println("结果:", <-results)
 }
}

6.2 Pipeline（管道模式）

 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


// 阶段1：生成数据
func generate(nums ...int) <-chan int {
 out := make(chan int)
 go func() {
 for _, n := range nums {
 out <- n
 }
 close(out)
 }()
 return out
}

// 阶段2：平方
func square(in <-chan int) <-chan int {
 out := make(chan int)
 go func() {
 for n := range in {
 out <- n * n
 }
 close(out)
 }()
 return out
}

func main() {
 // 组装管道：生成 → 平方 → 输出
 ch := square(square(generate(2, 3, 4)))
 for v := range ch {
 fmt.Println(v) // 16, 81, 256
 }
}

6.3 Fan-out / Fan-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


// Fan-out：多个 goroutine 从同一个 channel 读取（每个输入只被一个 worker 取走）
input := generate(1, 2, 3, 4, 5)
ch1 := square(input)
ch2 := square(input)

// Fan-in：合并多个 channel 到一个
func merge(cs ...<-chan int) <-chan int {
 out := make(chan int)
 var wg sync.WaitGroup

 for _, c := range cs {
 wg.Add(1)
 go func(ch <-chan int) {
 defer wg.Done()
 for v := range ch {
 out <- v
 }
 }(c)
 }

 go func() {
 wg.Wait()
 close(out)
 }()
 return out
}

七、小结

本文学习了 Go 的并发编程：

goroutine（轻量级协程，go 关键字启动）
channel（goroutine 间通信，无缓冲 vs 带缓冲）
select（多路复用、超时控制）
sync 包（Mutex、RWMutex、WaitGroup、Once、sync.Map）
context（取消、超时、传值）
常见并发模式（Worker Pool、Pipeline、Fan-out/Fan-in）

下一篇将学习标准库与工程实践，包括 HTTP 服务、数据库操作和单元测试。

Concurrency on 纪伟的个人博客

深入 .NET 锁家族：lock、SemaphoreSlim、ReaderWriterLockSlim 与 SpinLock 的选型边界

写在前面

一、先问要不要锁

二、lock / Monitor：默认选择

三、lock 里的 await：为什么编译器直接拒绝

四、SemaphoreSlim：BCL 中可 await 的互斥方案

五、ReaderWriterLockSlim：读多写少才考虑

六、SpinLock：几乎不该出现在业务代码

七、跨进程：Mutex 与内核 Semaphore

八、死锁规避工具箱

九、选型决策表

十、验证与观测

总结

参考资料

C# 原生互操作与设备 SDK（六）：回调、原生线程与事件

1. 先读清原生回调契约

2. 使用函数指针表达精确 ABI

3. 用 UnmanagedCallersOnly 暴露静态入口

4. 上下文句柄必须活到最后一次回调结束

5. 回调线程不等于 UI 线程

6. 委托回调仍然可用，但必须扎根

7. 回调测试要覆盖时间窗口

总结

参考资料

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

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

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

小结

参考资料

半导体设备软件（六）：实时性、并发与异常恢复

1. 先给实时性分级

2. 并发围绕资源组织

3. 超时只是“我不再等了”

4. 恢复从检查点开始

5. 用故障注入验证

总结

参考资料

7. `asyncio`：协作式并发

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