ConcurrentDictionary 不保证顺序？从原理到方案彻底搞懂

前几天在 code review 时，看到新同事在并发处理模块里写了一行注释：“并确保按键顺序处理（因为 ConcurrentDictionary 不保证键的排序）”。注释本身没毛病，但问题是他紧接着就直接 foreach 遍历字典，然后拿去处理——输出顺序恰好乱得一塌糊涂。这也怪不得他，因为大多数人对字典的直觉是“先来后到”，而 ConcurrentDictionary 的底层设计恰恰不给你这个保证。

这个话题本身很小，但它背后藏着一串值得掰开揉碎的问题：为什么 ConcurrentDictionary 不保证顺序？如果业务真的需要按键顺序处理，有哪些靠谱方案？各方案的性能差多少？什么时候应该放弃字典换队列？这篇文章就把这条链路完整拆一遍，代码和结论都能直接抄。

1. 一行注释引发的顺序问题：从复现开始

1.1 先还原一个典型的“字典暂存”场景

我当时的项目背景大致是这样：服务里有几十个采集线程，各自抓取一批订单数据，抓到后先按订单号写进一个共享的 ConcurrentDictionary 暂存，等一批任务全部结束后，再统一推给下游处理器。下游处理器有一个硬性要求：必须按订单号的字典序逐个处理。

代码写出来大概是这个形态：

csharp复制var results = new ConcurrentDictionary<string, TaskResult>();

Parallel.For(0, 5000, i =>
{
    var orderId = $"ORD-{i:D6}";
    results[orderId] = FetchOrder(orderId);
});

// 处理阶段
foreach (var pair in results)
{
    Process(pair.Key, pair.Value);
}

问题的关键显然在最后这个 foreach。看起来像是按订单号输出，实际上这个遍历顺序完全不可控。你可能跑第一次发现前几个还是乱序的，换个数据量、换台机器，顺序可能又不一样了。

1.2 复现一次乱序输出

为了让问题更直观，我做了个最简单的复现：并发写入 100 个键，然后打印枚举结果的部分片段。键名是 "TASK-0000" 到 "TASK-0099"，写入顺序故意用并发打乱，最后看枚举输出：

csharp复制var dict = new ConcurrentDictionary<string, int>();
var tasks = Enumerable.Range(0, 100).Select(i => Task.Run(() =>
{
    var key = $"TASK-{i:D4}";
    dict[key] = i;
}));

Task.WaitAll(tasks.ToArray());

foreach (var pair in dict)
{
    Console.WriteLine(pair.Key);
}

输出结果里，TASK-0042 可能出现在最前面，TASK-0001 可能落到中间甚至末尾，而且多次运行的结果不一样。如果你在此基础上加了一个批处理任务，等于每次处理顺序都在变化。

这个测试足以说明问题：ConcurrentDictionary 的枚举顺序不仅不是插入顺序，而且在并发写入场景下，连“稳定乱序”都算不上，可能每次运行都不同。那“确保按键顺序处理”这件事，就需要在代码层面显式做，而不是赌字典的遍历行为。

2. ConcurrentDictionary 注定无序：哈希表结构决定了这一点

2.1 存储位置由哈希值决定，和插入先后没有关系

要理解 ConcurrentDictionary 为什么不保证顺序，得先看它的底层结构。它的本质是一张哈希表，内部维护了一个桶数组。插入一个键值对时，先对键算哈希码，再用哈希码定位到某个桶，然后在这个桶里追加节点。

所以一个键存储在哪个桶里，完全由它的 GetHashCode() 结果决定，跟它是什么时候写入的没有任何关系。如果说 List<T> 像收银台排队，后来的人站队尾，枚举时从头到尾，自然有序；那哈希表更像是快递分拨中心，每个包裹按目的地被扔进对应的滑道，你无法通过“哪个包裹先到”来预测它在库房里的排列位置。

这就是 ConcurrentDictionary 无序的根本原因：不是它故意打乱，而是它的数据结构就没有维护“插入顺序”这个信息。

2.2 并发写入的条纹锁机制，让顺序更加不可预测

ConcurrentDictionary 为了保证线程安全，内部不是用一把大锁锁全部数据，而是把桶数组分成若干段，每段对应一把锁，也就是常见的条纹锁（striped lock）机制。写入时，先根据键的哈希码定位到桶，再获得对应分段的锁，然后执行插入或更新。

这个过程意味着，两个线程即使按顺序调用写入，实际落到桶里的时间可能是交错的，而且哈希值不同的键本来就会被分到不同桶。最终遍历时，枚举器是从头到尾逐个桶依次访问的，顺序自然由“桶的分布情况”决定，而不是“写入的先后”。

更隐蔽的一点是：哈希表在元素数量超过阈值时会扩容。扩容会重建整个桶数组，把已有元素重新哈希、重新分配位置。也就是说，同一个字典在扩容前后枚举顺序都可能发生变化。你上一次跑的顺序，和扩容后的顺序完全是两回事。

2.3 枚举的弱一致性

ConcurrentDictionary 的枚举器还有一个特性：弱一致性。枚举过程中，如果有其他线程往字典里写入新数据，新数据可能会出现在枚举结果里，也可能不会，这取决于它被插入到已经遍历过的桶还是尚未遍历的桶。

所以如果你在“一边写入、一边遍历”的模式下依赖顺序，结果本身就是个不定值。这个话题具体到代码上，就是下面这种写法要格外小心：

csharp复制foreach (var pair in dict)
{
    // 如果同时有别的线程在写 dict，遍历结果是不确定的
}

结论很清楚：ConcurrentDictionary 的设计目标是高并发的键值存取，从来没有承诺过有序遍历。官方文档说得很直白，枚举顺序不保证。业务上一旦出现了“按键顺序处理”的需求，就必须自己想办法，而不是靠遍历行为碰运气。

3. 最直接的解法：读取时按 Key 排序，但要避开两个坑

3.1 最小改动方案：写完快照再 OrderBy

如果数据量不大，最省事的方案就是在消费前把所有键值对取出来，按业务键做一次排序。这种做法改动最小，逻辑也直观：

csharp复制// 先把字典转成数组，相当于拍个快照
var snapshot = results.ToArray();

// 再按业务键排序处理
foreach (var pair in snapshot.OrderBy(p => p.Key, StringComparer.Ordinal))
{
    Process(pair.Key, pair.Value);
}

这里有两个细节值得说。第一，先 ToArray() 再排序，是为了避免在排序过程中字典还在持续变化。虽然 ToArray() 本身也是弱一致的，但在“写入阶段结束、消费阶段开始”这种常见模型下，它足够真实。第二，排序比较器一定要指定 StringComparer.Ordinal，不要依赖默认字符串比较，否则很容易踩到文化差异的坑。

3.2 第一个坑：默认字符串比较会随环境变化

如果键是字符串，OrderBy(p => p.Key) 默认会使用 Comparer<string>.Default，它会根据当前系统的文化规则来比较字符串。同一个 "ORDER-2" 和 "ORDER-10"，在某种文化环境下是一回事，在另一种环境下可能就变了。订单号、任务号这类键通常应该按字符的 Unicode 码位排序，而不是按区域语言的排序规则。

所以我的习惯是，只要排序对象是字符串业务键，一律显式写 StringComparer.Ordinal。虽然代码长了一点，但行为是确定的，不会换个服务器就变顺序。

3.3 第二个坑：数字型字符串的自然排序

举个例子，业务键是 "task-9" 和 "task-10"。按 Ordinal 排序，"task-10" 会排在 "task-9" 前面，因为在 ASCII 码里 '1' 小于 '9'。很多业务期望的却是 task-9 在前，task-10 在后。

面对这种键，最稳的处理是不要用字符串比较，而是在定义键时就把数字部分单独存成 int 或 long 字段，排序时按数字排。如果键结构已经固定没法改，就需要写一个自定义的自然排序比较器，或者在生成键时就做前导零填充，比如把 "task-9" 写成 "task-0009"。这个细节看似不起眼，但真出问题时排查效率非常低。

3.4 直接排序的适用边界

这个方案最大的优点是简单、不改变原有并发结构，适合数据量在几万条以内、并且是“批量写入完成后集中消费”的场景。缺点是每次消费都要做一次 O(n log n) 的排序，如果数据量很大、消费频繁，排序成本会直线上升。另外它需要一次性取出所有数据，内存占用也偏高。

如果你只有 100 条、1000 条数据，这个方案完全够用，没必要为了顺序引入更复杂的数据结构。但如果你有几十万甚至上百万条，且每次处理都要全量排序，那就要往下看其他方案了。

4. 天生有序的方向：SortedDictionary 和不可变有序字典的取舍

4.1 用 SortedDictionary 加锁：写时排序，读时直接有序

如果业务的核心诉求就是“按 key 顺序遍历”，可以考虑把存储结构直接换成有序字典 SortedDictionary<TKey, TValue>。它的内部实现是平衡树，键在树中天然有序，遍历时直接按序输出，不需要每次排序。

但 SortedDictionary 不是线程安全的，多个线程同时写入就会出问题。最简单的做法是加一个独立的锁对象来保护所有写操作和需要一致性的读操作：

csharp复制private readonly object _gate = new();
private readonly SortedDictionary<string, TaskResult> _results = new(StringComparer.Ordinal);

public void Add(string key, TaskResult value)
{
    lock (_gate)
    {
        _results[key] = value;
    }
}

public KeyValuePair<string, TaskResult>[] TakeSnapshot()
{
    lock (_gate)
    {
        return _results.ToArray();
    }
}

消费方拿到的数组本身就是按 key 有序的，直接 foreach 即可。这个方案在写入频率不高、数据量几万级别内非常舒服，代码依然很简单。代价是并发写入时会有一点全局锁竞争，和 ConcurrentDictionary 的高写入吞吐肯定没法比。不过在真实业务里，很多“批量暂存”场景的写入量根本到不了瓶颈，用锁完全没问题。

遍历的时候这里要特别注意：SortedDictionary 的枚举器同样不允许在枚举过程中修改集合。如果你打算直接 foreach 处理，而其他线程还在写入，那大概率会抛异常。所以上面示例中我干脆提供了 TakeSnapshot()，先拍快照再遍历，这样既拿到了有序数据，又避开了枚举期间被修改的问题。

4.2 用 ImmutableSortedDictionary：无锁读，写时 CAS

如果你追求读操作完全无锁，写操作又不像 ConcurrentDictionary 那样频繁，ImmutableSortedDictionary 是个很有意思的折中方案。它的特点是每次写入都会生成一个新实例，旧实例保持不变，因此读操作不需要任何锁，天然线程安全。配合 ImmutableInterlocked 可以做无锁的原子更新：

csharp复制using System.Collections.Immutable;

private ImmutableSortedDictionary<string, TaskResult> _results =
    ImmutableSortedDictionary<string, TaskResult>.Empty.WithComparer(StringComparer.Ordinal);

public void Add(string key, TaskResult value)
{
    ImmutableInterlocked.AddOrUpdate(
        ref _results,
        key,
        value,
        (_, old) => value);
}

读取时直接遍历 _results，得到的键值对天然有序。这个方案在“读多写少”的场景下很香，读操作没有任何锁竞争，而且并发升级时依赖 CAS 循环，不用手动加锁。

但它也有痛点：每次写入都要重建一部分树结构，如果同一个 key 被频繁更新，或者写入量很大，分配和比较的额外开销会越来越明显。另外一个容易忽略的地方是，ImmutableInterlocked.AddOrUpdate 的 updateValueFactory 内部不要做太重的工作，否则 CAS 循环会把这个逻辑执行很多次。

4.3 ConcurrentDictionary 加有序索引行不行？

还有一种思路：数据主体继续用 ConcurrentDictionary，同时额外维护一个有序的键集合，比如 SortedSet<string>。写入时既写字典也写集合，读取时遍历有序集合去字典取值。

这个思路理论上可行，但实现起来有坑：字典写入和索引更新这两个动作很难做到原子一致。就算你用 TryAdd 判定唯一性，再更新 SortedSet，中间也可能被其他线程打断，导致索引集合与字典内容出现偏差。要保证严格一致，还是得加锁，那就回到了 SortedDictionary 加锁的方案。

所以我个人不太推荐这种“双写结构”，除非你能接受索引的弱一致，并且写代码的人有足够经验处理边界情况。一般项目里为了这个需求引入双写维护成本，性价比不高。

5. 顺序处理的正解：Channel 与 PriorityQueue 的适用边界

5.1 先想清楚：你要的是按键排序，还是到达顺序

很多时候，业务说的“按键顺序处理”其实有两种完全不同的诉求。一种是真的按 key 排序，比如订单号字典序遍历；另一种是按消息到达的先后顺序处理，也就是 FIFO。后者在并发采集场景里非常常见：多个生产者线程按顺序把结果写入，消费端希望按入队顺序逐条处理。

如果需求是后者，那么 ConcurrentDictionary 加排序就不是正解，天然有序的队列才是。System.Threading.Channels 里的 Channel 是 .NET 里做生产者消费者队列很顺手的选择：

csharp复制var channel = Channel.CreateUnbounded<TaskResult>(new UnboundedChannelOptions
{
    SingleReader = true,
    SingleWriter = false
});

// 生产者线程写入
await channel.Writer.WriteAsync(result);

// 消费端按 FIFO 顺序读取
await foreach (var result in channel.Reader.ReadAllAsync())
{
    Process(result);
}

Channel 的写入顺序就是读取顺序，完全可控，而且吞吐量相当高。如果你的业务不需要按键排序，只需要按提交顺序，用队列能省掉所有排序逻辑。

5.2 按键排序出队：PriorityQueue 的稳定性和坑

另一种需求是：你在存储阶段没法保证键顺序，但消费时希望每次取出当前最小的 key 来处理，同时还能继续追加数据。这种情况可以用 .NET 6 引入的 PriorityQueue。

csharp复制var queue = new PriorityQueue<TaskResult, string>(StringComparer.Ordinal);

queue.Enqueue(result, result.Key);

while (queue.TryDequeue(out var result, out _))
{
    Process(result);
}

这里有个很容易踩的坑：PriorityQueue 内部是堆结构，堆不是稳定排序。如果两条元素有相同的优先级，出队顺序并不保证和入队顺序一致。更常见的坑是优先级相同的情况——比如一个批次里有多条消息共享同一个 key，你希望它们按到达顺序处理，但堆结构会把这个顺序打乱。

解决办法是不要让优先级裸用 key，而是把唯一序列号也拼进去，比如用一个 (Key, Seq) 的复合优先级：

csharp复制long _seq;
var queue = new PriorityQueue<TaskResult, (string Key, long Seq)>();

long seq = Interlocked.Increment(ref _seq);
queue.Enqueue(result, (result.Key, seq));

因为 ValueTuple 的默认比较逻辑是先比 Key，再比 Seq，这样既保证了按键排序，又保证了同 key 下按序号出队。这个细节很重要，我在实际项目里被坑过一次，堆排序的“同优先级不稳定”特性，足够让一批本该按序处理的任务出现乱序。

5.3 队列加字典的组合模式：既要顺序又要去重

真实业务里还有一个常见组合：既要按顺序处理，又希望同一个 key 不能重复处理。这种场景下字典和队列的分工就非常清晰——字典管状态，队列管顺序。

csharp复制var state = new ConcurrentDictionary<string, byte>();
var channel = Channel.CreateUnbounded<TaskResult>();

// 生产者
if (state.TryAdd(result.Key, 0))
{
    await channel.Writer.WriteAsync(result);
}

// 消费者
await foreach (var result in channel.Reader.ReadAllAsync())
{
    Process(result);
}

这个模式的好处是，TryAdd 保证了同一个 key 只进队一次，Channel 保证了先到的 key 先出队。但要注意，如果业务允许 key 被更新后重试，就需要给消息加版本号，在消费端判断版本，而不是简单依赖入队去重。否则消息一旦因为异常被丢弃，之后所有同 key 更新都会被挡在队列外。

6. 实测对比与我的最终组合方案

6.1 我本机跑过的一组量级数据

为了给选型一个参考，我在 .NET 8、8 核 CPU 的机器上简单压过一组数据：用 8 个线程并发写入 100 万条字符串键值对，然后做消费。方案之间的绝对数值在不同硬件上差异很大，但量级关系有参考价值：

最直观的结论是：ConcurrentDictionary 的写入吞吐确实最高，但它不解决顺序问题，额外排序的成本需要计入总耗时；SortedDictionary 的写入因为锁和平衡树维护，吞吐明显下降，但消费端省去了排序时间。

6.2 按业务特征选型

我把选型逻辑整理成一个决策表，写代码前先对号入座：