在一次线上接口性能异常的排查中，我们遇到了一个非常典型但又常被忽视的问题 ——

在多线程任务中并发操作 Dictionary，导致 CPU 飙升并触发 Dictionary.FindEntry 的热点。

本文将完整复现问题背景、分析原因，并给出最终可落地的解决方案，帮助你避免类似的踩坑。

---

🧩 一、问题背景

线上某接口突然出现大量 CPU 占用过高的告警，通过 dump 分析后，发现大量线程卡在：

System.Collections.Generic.Dictionary.FindEntry

如下图所示（简化后）：

Dictionary<TKey, TValue>.FindEntry
OrderMainService.QueryPrice
UnifiedPriceService.GetUnifiedPrice
Task.Run(...)
...

进一步追踪代码，发现在一个方法内创建了多个 Task.Run，并在任务中同时对同一个字典 unifiedPriceMap 进行 Add、ContainsKey、索引访问 等操作：

var unifiedPriceMap = new Dictionary<SupplierTypeEnum, T3EstimatePriceResultDtoModel>();

taskList.Add(Task.Run(() =>
{
    unifiedPriceMap.Add(SupplierTypeEnum.XieHua, model);
}));

taskList.Add(Task.Run(() =>
{
    unifiedPriceMap.Add(SupplierTypeEnum.JuZi, model);
}));

看似简单，却埋下了灾难的种子。

---

🔥 二、问题分析：并发写 Dictionary 会导致结构损坏

.NET 中 Dictionary<TKey, TValue> 不是线程安全的。

只要有多个线程同时向同一个 Dictionary 写入，就会出现：

• buckets 与 entries 同时被多个线程修改
• entry 链表被截断
• next 索引形成闭环
• FindEntry 死循环
• Dictionary 内部结构损坏
• CPU 迅速飙升

其中 FindEntry 高 CPU 正是最典型的表现。

也就是 dump 中看到的这个热点：

Dictionary<TKey, TValue>.FindEntry

✔ 为什么读写会冲突？

为了添加新元素，Dictionary 会：

1. 计算 hash
2. 修改 bucket
3. 修改 entry 数组
4. 修改 entry.next
5. 扩容时对整个结构整体重排

在多线程写入时，同时执行上述步骤，非常容易造成：

• bucket 指针错链
• next 指针循环
• entries 覆盖
• 甚至内部 Resize 时数组损坏

最终导致 CPU 占用不断攀升。

这正是你观察到的现象。

---

🛠 三、解决方案

根据实际情况，可以用三种方式解决该问题。

---

✅ 方案一：使用 ConcurrentDictionary（最简单、最安全）

最推荐的方案，只需一行代码即可修复所有并发问题：

var unifiedPriceMap = new ConcurrentDictionary<SupplierTypeEnum, T3EstimatePriceResultDtoModel>();

写入方式：

unifiedPriceMap[SupplierTypeEnum.XieHua] = model;

优点：

• 原生线程安全
• 无需加锁
• 性能表现稳定
• 完全规避 Dictionary 结构损坏问题

这是最通用、最易落地的方案。

---

✅ 方案二：加锁保护 Dictionary（性能更高）

如果你的字典 Key 很少（如供应商就几个），加锁反而更高效：

var locker = new object();
var unifiedPriceMap = new Dictionary<SupplierTypeEnum, T3EstimatePriceResultDtoModel>();

taskList.Add(Task.Run(() =>
{
    var value = service.GetUnifiedPrice(...);

    lock(locker)
    {
        unifiedPriceMap[SupplierTypeEnum.XieHua] = value;
    }
}));

优点：

• Dictionary 性能极高
• 加锁范围很小（只包含写入）

缺点：

• 比 ConcurrentDictionary 稍微麻烦一些

---

❌ 方案三（不推荐）：每个 Task 使用局部变量，最后合并

可行，但代码复杂，不够优雅。

---

🎯 四、经验总结

1. Dictionary 只能在单线程下写、并发读

只要多线程写，100% 会出问题，迟早都崩。

2. ConcurrentDictionary 是并发写字典的标准解决方案

现代 .NET 并发场景下，应优先使用它。

3. 如果写入频次不高，用 lock 更快

对小数据量、固定 Key 来说，加锁的性能甚至比 ConcurrentDictionary 更高。

4. FindEntry 热点是字典结构损坏的第一现场

只要 dump 看到 Dictionary.FindEntry 高 CPU，基本可以断定是并发写 Dictionary。

---

🧭 五、结语

这次问题看似简单，但却是 .NET 项目中非常高频、又极易被忽略的典型并发 bug。

并发写 Dictionary = 不定时炸弹

只要做到：

• 并发写 → 用 ConcurrentDictionary 或 lock
• 单线程写、多线程读 → 用 Dictionary

你就能完全规避这类性能事故。