.NET 8 风控引擎 Dictionary 并发死循环 CPU 100% 卡死的 5 天复盘:ConcurrentDictionary + ImmutableDictionary + dotnet-dump 实战 + 9 条并发集合纪律

2026 年 2 月,我们一个 .NET 8 实时风控服务 risk-engine 出了个诡异问题:某天上午 10:23 开始,某个 Pod 的 CPU 突然飙到 100% 并卡死,所有请求堆积,5 分钟后 K8s 把它 OOMKilled 重启,服务恢复 30 分钟后又出现下一个 Pod 同样症状。整整一天反复 8 次,核心业务断断续续不可用。最后定位到根因是普通 Dictionary<K,V> 在多线程并发读写下进入了死循环——这个坑在 .NET Framework 时代就有,但很多人以为现代 .NET 已经"安全",实际上 Dictionary 至今仍然不是线程安全的,并发写时内部 bucket linked list 可能成环,导致后续 Get 操作进入无限循环。

5 天的排查让我们彻底搞清楚了 .NET 集合类的并发安全边界,以及为什么 ConcurrentDictionary 不是"万能解药"。修法是所有共享字典必须用 ConcurrentDictionary + 严格审计 lock-free 编程的隐性陷阱。这篇是完整复盘,涵盖 Dictionary 死循环的根因、CPU 100% 的诊断流程、ConcurrentDictionary 的工作原理、AddOrUpdate 的原子性边界、以及落地的《.NET 并发集合使用纪律》。如果你的 .NET 服务还有 static Dictionary 或 singleton Dictionary 在多线程访问,这篇能帮你提前避坑。

事故的代价摊在前面:风控引擎不可用导致 8 次反复 30 分钟 × 平均影响 = 累计约 4 小时业务降级,期间漏判风险事件 1247 笔(后续人工复核耗时 18 人时),业务侧累计补救 + 客户解释成本约 12 万元,加上排查 5 天 × 3 人(约 120 人时,折算 5 万),总成本 17 万。换来的认知本应在 2008 年 .NET 多线程编程入门课就建立——"Dictionary 不是线程安全的"——但因为这是个 14 年前的陈年知识,新一代工程师不少都没踩过,直到真死循环时才想起来。

背景:这个风控服务

事故时间线:5 天定位

因果链:为什么 Dictionary 会成环

把这次 CPU 100% 死循环的根因画成因果链,可以看清楚为什么"看起来没事"的代码在生产爆炸:

这张图最关键的洞察是"并发数据结构损坏"和"应用 bug"完全不同——应用 bug 通常崩在那一行抛异常,你能看 stack trace 定位;数据结构损坏是"内存状态不一致",程序仍然在跑,只是无限循环,没有异常、没有崩溃,只有 CPU 100%。这种症状对应"无限循环"是 .NET 多线程编程的经典坑,知道的人能秒猜,不知道的人查一周。

第一反应:"加机器抗一下"

事故第一天 SRE 的判断是"流量异常+某个 Pod 出问题,加机器就行"。把 Pod 从 12 个扩到 24 个,反正 K8s 重启快,业务影响小。但这并没有解决根因,只是把发病频次稀释——后来发现 Pod 数翻倍,事故还是每天 8 次,只是每个 Pod 的发病间隔变长。

这次给我的教训是"加机器"是症状级的临时止血,不能代替根因排查。任何"频次降低但仍然出现"的故障,都意味着根因没有解决,只是被掩盖。这次扩容反而让我们多花了一天才意识到"这不是流量问题"——因为流量翻倍后症状没消失,排除了"流量"这个怀疑方向。

真凶:Dictionary 的 hash bucket linked list 成环

.NET 的 Dictionary<K,V> 内部实现是开链法散列表(separate chaining):

// .NET 8 Dictionary 简化的内部结构
private struct Entry
{
    public uint HashCode;
    public int Next;         // 下一个 entry 的索引,-1 表示链尾
    public TKey Key;
    public TValue Value;
}

private int[] _buckets;      // 桶数组,存的是 Entry 数组下标
private Entry[] _entries;    // entry 数组
private int _count;

public bool TryGetValue(TKey key, out TValue value)
{
    uint hashCode = (uint)key.GetHashCode();
    int i = _buckets[hashCode % _buckets.Length] - 1;

    // 沿着 linked list 找
    while (i >= 0)
    {
        ref Entry entry = ref _entries[i];
        if (entry.HashCode == hashCode && entry.Key.Equals(key))
        {
            value = entry.Value;
            return true;
        }
        i = entry.Next;    // 关键:如果 Next 形成环, 这里无限循环
    }

    value = default;
    return false;
}

问题就在 i = entry.Next 这一步。正常情况下,沿着 Next 链表走到 -1 就结束。但当并发写入触发 Resize() 时,内部 _buckets 和 _entries 数组要扩容 + rehash,期间所有 entry 的 Next 字段都要重新计算。如果一个读线程在扩容过程中"看到"了部分更新的状态,沿着旧 Next 指针走,可能走到一个已经被 rehash 到不同 bucket 的 entry,而那个 entry 的新 Next 又指回前面的位置——形成环。

一旦成环,任何后续对该 bucket 的 TryGetValue 都会进入无限 while 循环,CPU 100%。关键是这个状态是永久的——不像 deadlock 会触发超时检测,无限循环不会自己解除,只能重启进程。

用 dotnet-dump 抓现场

定位这个问题的关键工具是 dotnet-dump:

# 抓 dump
dotnet-dump collect -p <pid>

# 分析 dump
dotnet-dump analyze risk-engine.dmp

# 在 analyze REPL 里看所有线程的 stack
> threads
> clrstack -all

# 看到大量线程都卡在这里:
0:000> clrstack
OS Thread Id: 0x3a4
Child SP IP Call Site
0000007b... System.Collections.Generic.Dictionary`2[...].TryGetValue(...)
0000007b... RiskEngine.RuleCache.GetRule(...)
0000007b... RiskEngine.Evaluator.Evaluate(...)

看到 100+ 个线程全卡在 Dictionary.TryGetValue,但没有任何线程在写 Dictionary,且 stack 看起来"正常"(没有锁等待、没有异常),这就是"数据结构损坏导致无限循环"的典型特征。stack 上看不到 bug,要看堆数据才能确认 bucket 成环:

# 在 dump 里找到 Dictionary 实例
> !dumpheap -type Dictionary
> !do <dictionary_addr>
# 看 _entries 数组
> !dumparray <entries_array_addr>
# 检查 Next 字段是否形成环
# 比如发现 entries[42].Next = 87, entries[87].Next = 42 — 成环!

这个排查流程很慢,我们 Day 3 抓 dump,Day 4 才分析出环。原因是没有人一开始就怀疑 Dictionary 并发问题——风控团队代码 review 时所有 Dictionary 都被认为"只在 startup 写一次,运行时只读"是安全的。直到 Day 5 才发现某个新加的"规则热更新"功能在背后偶发写 Dictionary。

修法 1:ConcurrentDictionary 改造

最直接的修法是所有共享 Dictionary 改成 ConcurrentDictionary:

// 错误:多线程访问普通 Dictionary
public class RuleCache
{
    private static readonly Dictionary<string, Rule> _cache = new();

    public Rule GetRule(string id) => _cache.TryGetValue(id, out var r) ? r : null;

    public void UpdateRule(string id, Rule rule) => _cache[id] = rule;
}

// 正确:ConcurrentDictionary
public class RuleCache
{
    private static readonly ConcurrentDictionary<string, Rule> _cache = new();

    public Rule GetRule(string id) => _cache.TryGetValue(id, out var r) ? r : null;

    public void UpdateRule(string id, Rule rule) => _cache[id] = rule;
}

ConcurrentDictionary 的内部实现是 lock-free + striped lock(细粒度锁数组),并发读写都安全且性能损失很小。读操作完全 lock-free,写操作只锁住对应 bucket 的细粒度锁。

修法 2:AddOrUpdate 的原子性陷阱

但 ConcurrentDictionary 不是"万能解药"。它的单个操作是原子的,但复合操作不是:

// 错误:看似 atomic 实际不是
if (!_cache.ContainsKey(id))
{
    _cache.TryAdd(id, NewRule());  // 两个线程可能同时进入
}

// 正确:用 GetOrAdd 一次完成
var rule = _cache.GetOrAdd(id, _ => NewRule());

// 错误:并发增减计数
_cache[id] = _cache[id] + 1;  // 不是原子!

// 正确:用 AddOrUpdate
_cache.AddOrUpdate(id, 1, (k, oldValue) => oldValue + 1);

关键原则:组合操作必须用 ConcurrentDictionary 提供的 GetOrAdd / AddOrUpdate / TryUpdate 这些原子方法,而不是手动拼接 ContainsKey + TryAdd。这是 ConcurrentDictionary 使用最常见的坑,改造时一定要 review 每个使用点。

修法 3:不可变集合 + 整体替换

对于"加载一次,运行时只读"的场景,更优雅的方案是用 ImmutableDictionary + 整体替换引用:

public class RuleCache
{
    private static volatile ImmutableDictionary<string, Rule> _cache =
        ImmutableDictionary<string, Rule>.Empty;

    public Rule GetRule(string id) =>
        _cache.TryGetValue(id, out var r) ? r : null;

    // 热更新:整体重新加载
    public void Reload(IEnumerable<Rule> rules)
    {
        var newCache = rules
            .ToImmutableDictionary(r => r.Id, r => r);
        // 一次原子替换引用
        _cache = newCache;
    }
}

这种模式的优点:

• 读操作完全 lock-free,性能等同普通 Dictionary
• 写操作是"整体替换",不存在"部分更新"的中间状态
• volatile 关键字保证替换的可见性
• 适合"加载一次 + 偶发热更新"的场景(规则缓存、配置缓存)

缺点是每次更新都要重建整个 dictionary,如果数据量大且更新频繁,内存压力大。所以这种模式适合"大字典 + 低频更新",高频更新还是用 ConcurrentDictionary。

.NET 集合类并发安全速查

最后一行特别要注意——ReadOnlyDictionary 是个"语法层面的只读包装",底层还是普通 Dictionary,如果有别人持有原 Dictionary 的引用并写入,ReadOnlyDictionary 一样会损坏。这个坑很多人不知道,以为加了 ReadOnly 就安全。

诊断流程 SOP:CPU 100% 卡死怎么查

事故后我们沉淀了一套"生产环境 CPU 100% 单线程卡死"的诊断 SOP,任何 .NET 服务出现类似症状都按这个流程走:

这套 SOP 最关键的判断点是"单核还是多核 100%"。单核 100% 几乎一定是某个线程进入无限循环——CPU 计算是单线程不可分的,一个无限 while 循环只会吃满一个核;多核 100% 通常是 CPU 密集计算或大量线程都在忙(GC / 反序列化 / 加密等)。这个区分能 30 秒内排除掉一大半可能性,让排查直奔重点。

另一个诊断利器是 dotnet-trace,它可以在不中断服务的情况下抓取 CPU profile:

# 抓 30 秒 CPU profile
dotnet-trace collect -p <pid> --duration 00:00:30 --providers Microsoft-DotNETCore-SampleProfiler

# 用 PerfView 或 dotnet-trace 自带的 convert 转成可视化格式
dotnet-trace convert trace.nettrace --format speedscope

# 在 https://www.speedscope.app/ 打开, 看 flame graph
# 如果某个函数占 99% CPU 时间, 那就是无限循环位置

dotnet-trace 的好处是低开销,可以在生产环境运行,不像 dotnet-dump 会暂停进程。组合使用:先 dotnet-trace 找热点函数 → 再 dotnet-dump 抓那个函数的栈和堆数据 → 确认根因。

立的《.NET 并发集合使用纪律》

• 任何 static / singleton 的集合必须用 Concurrent 版本。不要假设"只在 startup 写一次"安全——后续可能有人加热更新代码。
• 多线程访问的字典一律用 ConcurrentDictionary,加锁包装的普通 Dictionary 性能更差且容易遗漏。
• 组合操作必须用 ConcurrentDictionary 提供的原子方法(GetOrAdd / AddOrUpdate / TryUpdate),不要手动拼接。
• "加载一次 + 偶发更新"场景用 ImmutableDictionary + volatile 引用,读性能最好。
• ReadOnlyDictionary 不是线程安全,只是语法层只读包装,小心使用。
• 代码 review 必查"static 集合 + 多线程访问",这是最常见的并发 bug 来源。
• 生产环境监控 CPU 100% 单线程卡死,这通常是"无限循环"信号,大概率是并发数据结构损坏。
• 遇到 CPU 100% 卡死 + 没有异常先抓 dotnet-dump,看所有线程 stack,卡在某个 Dictionary 操作就是这个坑。

关于"代码 review 漏过"的反思

事故复盘最让团队震惊的不是"为什么 Dictionary 会成环",而是"为什么我们的 code review 没拦住这段代码"。事后追溯,那段"规则热更新"代码的 PR 是 3 个月前合的,有 2 个 reviewer,都没提"static Dictionary + 多线程写"的问题。原因是:

• 那个 PR 是"加一个热更新功能",代码本身简洁(就 20 行)
• reviewer 没去看"这个 Dictionary 是怎么被读的"——只看到了写
• 团队普遍以为 "Dictionary 在 startup 后不会变" 是常识,没人意识到这次 PR 打破了这个假设

这是典型的"局部 review 看不到全局风险"问题。修法是给团队加一条 review checklist:任何修改 static 字段的 PR,reviewer 必须确认"这个字段是否会被多线程访问",如果是必须用 Concurrent 版本或明确加锁。这条 checklist 看起来僵硬,但能拦下 90% 的并发 bug。

给读者的几条自查清单

1. 你的 .NET 服务有没有 static Dictionary / private static Dictionary?用 grep 全文搜一遍。
2. 找到的 static Dictionary,确认是不是只在 startup 写一次?有没有热更新、缓存刷新、定时任务在写?
3. 多线程访问的 Dictionary,改成 ConcurrentDictionary,或者用 lock 包装,或者用 ImmutableDictionary。
4. ConcurrentDictionary 的"组合操作"是否用了 GetOrAdd / AddOrUpdate 这些原子方法,而不是手动 ContainsKey + Add?
5. 生产环境有没有"CPU 100% 卡死然后被 OOMKilled"的监控?这是无限循环的典型信号。
6. 团队的 code review checklist 里有没有"static 字段 + 多线程"这一条?没有就加上。
7. dotnet-dump / dotnet-trace 用过吗?生产环境异常没有 stack trace 的诊断必备工具。

更深一层:.NET 并发编程的"陈年常识"

这次事故让我反思一个更深的问题:".NET 集合不是线程安全"是 2008 年就有的常识,为什么 2026 年我们还会踩?根本原因是知识在团队里的"代际衰减"。.NET Framework 时代踩过这坑的工程师知道这条铁律,但他们大多已经离职或转岗;新一代工程师入职时通过 ASP.NET Core 学 .NET,直接接触现代化的 DI / async / await 抽象,没有机会接触"裸的 Dictionary 并发"这种底层问题。

这种"代际衰减"在任何长存技术栈里都会发生——Java 也有(HashMap 并发死循环是经典面试题,但年轻工程师真的没踩过),C++ 更甚。对抗代际衰减的唯一方法是"显式传承":把陈年坑写进团队 wiki + 新人 onboarding 必读 + 定期复盘讲座。代码 review 是一种传承形式,但只能传承"能看到的代码",看不到的隐性知识(比如"static Dictionary 在多线程下会成环")必须靠主动传承。

另一个心得:".NET 现代化"让很多并发问题被框架屏蔽,但底层规则没变。ASP.NET Core 默认的 DI scoped lifetime + async/await 抽象让大部分应用代码"自动"线程安全,工程师容易产生"现代 .NET 不会有并发问题"的错觉。但只要有 static 字段、singleton 服务、自己写的缓存,并发问题立刻回归。框架的抽象是有边界的,边界之外仍然是"裸 .NET",仍然要遵守 .NET 的基础并发规则。

修法 4:细粒度 lock 包装(妥协方案)

有些场景不方便直接换 ConcurrentDictionary——比如 Dictionary 暴露在 public API 上,调用方拿到的就是 IDictionary<K,V>。这种情况下可以用 ReaderWriterLockSlim 包装:

public class ThreadSafeRuleCache
{
    private readonly Dictionary<string, Rule> _cache = new();
    private readonly ReaderWriterLockSlim _lock = new(LockRecursionPolicy.NoRecursion);

    public Rule GetRule(string id)
    {
        _lock.EnterReadLock();
        try
        {
            return _cache.TryGetValue(id, out var r) ? r : null;
        }
        finally
        {
            _lock.ExitReadLock();
        }
    }

    public void UpdateRule(string id, Rule rule)
    {
        _lock.EnterWriteLock();
        try
        {
            _cache[id] = rule;
        }
        finally
        {
            _lock.ExitWriteLock();
        }
    }
}

这种方案的优点是兼容现有 API,缺点是性能比 ConcurrentDictionary 差 5-10 倍(因为 reader-writer lock 在高并发下 contention 严重,ConcurrentDictionary 的 striped lock 粒度更细)。我们 benchmark 实测:在 8 核机器上,10 万并发读 + 1000 并发写场景,ConcurrentDictionary 吞吐 280 万 ops/sec,ReaderWriterLockSlim 包装的 Dictionary 只有 32 万 ops/sec。除非有特殊兼容需求,优先选 ConcurrentDictionary。

性能 benchmark:四种方案对比

事故后我们做了一次完整 benchmark,场景是"30 万规则缓存 + 8000 QPS 读 + 偶发后台更新":

从 benchmark 数据看几个关键洞察:ConcurrentDictionary 的读性能只比裸 Dictionary 慢 25%,但绝对安全;ImmutableDictionary 读性能接近裸 Dictionary,但写操作贵 6 个数量级(因为要 ToImmutableDictionary 重建整个字典)。所以选型核心是"读写比例":99% 读 + 1% 写选 ImmutableDictionary,90% 读 + 10% 写选 ConcurrentDictionary,50/50 也用 ConcurrentDictionary。绝大多数业务场景的读写比例都在 90/10 以上,所以默认推荐 ConcurrentDictionary。

事故的扩散范围审计

事故止血后,我们做了一次全公司 .NET 项目的"并发集合审计",扫了 28 个 .NET 服务,发现:

• 17 个服务有 static Dictionary / singleton Dictionary
• 其中 9 个确实只在 startup 写,5 个有偶发后台更新,3 个有高频更新
• 5 个偶发更新的服务里,有 3 个曾经发生过"CPU 偶发抖动"但没人定位过——疑似同样的 Dictionary 死循环但被 K8s 重启掩盖了
• 把这 8 个有并发风险的服务全改成 ConcurrentDictionary 后,后续 3 个月再没出现过类似抖动

这次审计的价值远超修一个 bug——它把"隐性的全公司风险"显式化。如果不是这次事故触发审计,那 3 个偶发抖动的服务可能还会继续抖动几年,每次都靠 K8s 重启自愈,谁也不知道是 Dictionary 死循环。这是事故复盘最被低估的价值:"同类问题扫雷"。

总结

这次事故的代价是 1 天 8 次反复降级 + 17 万元直接损失 + 5 天 3 人排查工时。换来的是一套完整的 .NET 并发集合使用纪律 + 全公司 8 个潜在风险服务的修复 + 团队对"陈年常识代际衰减"的深刻认知。最有价值的产出不是修复一个 bug,而是把"分布式系统组件级并发"这件事重新拉回团队视野。

如果你的 .NET 团队还在用普通 Dictionary 做共享缓存,把这篇甩给同事看,大概率能拦下未来某个凌晨的事故告警。.NET 集合类并发安全的边界是 14 年前就划好的,违反它的代价是 CPU 100% 死循环——这个代价不打折。任何"我们的 Dictionary 只在 startup 写"的论断,都要追问"3 个月后会不会有人加热更新代码",历史经验是必然会有。

跨语言对照:Java HashMap 也有同样问题

.NET 的 Dictionary 死循环坑在 Java 圈也有完全对称的版本——HashMap 在 JDK 7 及之前的多线程并发写下,resize 操作会形成 linked list 环,后续 get 进入无限循环 CPU 100%。这是 Java 面试经典题。JDK 8 把 HashMap 内部从 linked list 改成红黑树,环形问题消失,但并发写仍然不安全——数据丢失、节点错位、size 字段不准都可能发生。Java 圈的正解是 ConcurrentHashMap,跟 .NET 的 ConcurrentDictionary 一一对应。

这种跨语言对照说明"集合并发安全"是分布式系统编程的底层规律,不分语言。Python 的 dict 因为 GIL 看起来"线程安全",但只是单操作原子,复合操作仍然要 lock;Go 的 map 并发读写会触发 fatal error(运行时直接 panic),用 sync.Map 才安全;Rust 直接用类型系统强制保证(Arc<Mutex<HashMap>> 或 DashMap)。每个语言的具体表现不同,但底层规则一致:共享可变状态在多线程下必须用专门的并发数据结构。

Rust 的设计哲学最激进——它用所有权 + Send/Sync trait 让"非线程安全的数据结构跨线程使用"在编译期就报错,根本不给运行时踩坑的机会。这种"用类型系统消灭运行时错误"的思路代表了 systems language 的未来方向。.NET 和 Java 都在往这个方向走(C# 的 nullable reference types / Java 的 record / pattern matching),但内存安全和并发安全的强保证仍然是 Rust 的核心差异化优势。这次 .NET Dictionary 死循环事故如果在 Rust 里发生,代码根本无法编译——编译器会直接告诉你 "HashMap 不是 Sync,不能放在 static 里跨线程访问"。这种"编译期防御"比任何运行时检查都更彻底。

事故落幕几周后,我跟团队架构师讨论一个更深的问题:为什么 .NET 在设计时不把 Dictionary 直接做成线程安全的?微软的设计哲学很清晰——"线程安全"不是免费的,如果默认所有集合都线程安全,单线程场景会承担不必要的同步成本。把选择权留给工程师:单线程用 Dictionary,多线程用 ConcurrentDictionary,Immutable 场景用 ImmutableDictionary。这种设计哲学要求工程师"知道自己在干什么",在大多数现代抽象走向"默认安全"的趋势下,显得有点"反潮流"。但这正是 .NET 作为 systems language 的特性——不替你做决定,但要求你做对决定。这种哲学有好有坏,对老手是"灵活高效",对新手是"容易踩坑"。这次事故就是新手踩老坑的典型案例。

最后一句给所有写 .NET 多线程代码的同学:每次你写下 static Dictionary 这一行时,在心里默念一句"我能保证它永远只被单线程访问吗"——如果答案有任何不确定,立刻改成 ConcurrentDictionary。这一秒的犹豫,可能省下未来某个深夜的 P0 事故。.NET 并发安全的红线是清晰的,只是需要每个工程师在每一行代码上都记得它。这次复盘之后,我们团队把这条红线印在了所有新人的 onboarding checklist 第一页——希望你的团队不需要等到事故才把它写上去。每一行 static Dictionary 都是一颗定时炸弹,把它换成 ConcurrentDictionary 只需要 10 秒,但能省下未来某天凌晨被叫醒查 CPU 100% 的几小时。这笔账无论怎么算,都极其划算。

—— 别看了 · 2026