一、来自现实的灵魂拷问

去年公司电商大促时，我们的实时库存系统突然出现超卖现象。经过48小时不眠不休的排查，罪魁祸首竟是Parallel.ForEach循环中的共享变量竞争问题——在八核服务器上运行的结果比单线程还离谱。这个血淋淋的案例告诉我们：并行计算的准确性从来不是理所当然的。

二、定时炸弹实验室（错误示范）

// 危险！存在数据竞争的并行累加示例
using System.Threading.Tasks;

int sum = 0;
Parallel.For(0, 10000, i => {
    sum += 1; // 这是定时炸弹！
});
Console.WriteLine($"理论值:10000，实际值:{sum}");

执行这个代码十次，你会发现输出像抽奖一样在9800-10050之间随机跳动。每个线程都在同时读取旧值→计算新值→写回变量的危险舞蹈中踩踏彼此。

三、五大必杀技解决数据竞争

3.1 互斥锁的正确打开方式

// 加锁的正确姿势
object lockObj = new object();
int safeSum = 0;
Parallel.For(0, 10000, i => {
    lock(lockObj) {
        safeSum += 1;
    }
});

虽然锁能保证准确性，但我们实测发现：在8核CPU上效率比单线程还低20%。这说明简单粗暴的全局锁绝对不是最佳方案。

3.2 原子操作的秘密武器

// 原子自增的正确用法
int atomicSum = 0;
Parallel.For(0, 10000, i => {
    Interlocked.Increment(ref atomicSum);
});

Interlocked类的原子操作比锁快3倍以上，但仅支持基本数值类型。对于复杂对象，还是得用其他方法。

3.3 本地存储的智慧

// 线程本地存储范例
int finalSum = 0;
Parallel.For(0, 10000, 
    () => 0, // 初始化局部值
    (i, state, local) => {
        return local + 1;
    },
    local => {
        Interlocked.Add(ref finalSum, local);
    });

这个版本在8核环境下的执行时间比带锁版本快7倍！通过将中间结果存储在本地变量，最大限度减少全局访问次数。

3.4 安全集合的正确选择

// 使用线程安全集合的示例
using System.Collections.Concurrent;

var safeBag = new ConcurrentBag<int>();
Parallel.For(0, 10000, i => {
    safeBag.Add(i);
});
Console.WriteLine($"安全集合数量:{safeBag.Count}");

Concurrent命名空间下的集合天生线程安全，但要注意它们的迭代器并不是快照式的，遍历时集合可能仍在修改。

3.5 伪共享的隐形杀手

// 避免缓存行竞争的写法
[StructLayout(LayoutKind.Explicit)]
struct Counter {
    [FieldOffset(64)] public int first;
    [FieldOffset(128)] public int second;
}

var counter = new Counter();
Parallel.Invoke(
    () => { for(int i=0;i<1000;i++) Interlocked.Increment(ref counter.first); },
    () => { for(int i=0;i<1000;i++) Interlocked.Increment(ref counter.second); }
);

通过结构体布局强制两个变量处于不同的CPU缓存行，在我们的Xeon服务器上测试，性能提升达40%——这解释了为什么有些看似线程安全的代码仍然跑得慢。

四、并行计算的正确打开姿势

4.1 任务分解要智慧

把计算任务想象成切蛋糕——每一块都应该独立完整。比如图像处理中按行划分区域，比随机点划分更容易保证数据独立性。

4.2 状态管理四象限

只读状态 可写状态
值类型 无需保护（完美） 本地变量+聚合
引用类型 深拷贝或不可变对象 同步锁或线程安全容器

4.3 监控与调试神器

使用Visual Studio的并行堆栈窗口（Debug → Windows → Parallel Stacks）可以实时观察各线程状态，快速定位卡在锁上的线程。

五、从业务场景看技术选型

在物流路径优化项目中，我们对比了三种方案：

  1. 带锁的并行计算：开发快但性能差
  2. Actor模型（通过Akka.NET）：学习成本高但吞吐量优秀
  3. 数据流（TPL Dataflow）：灵活性最佳

最终选用数据流方案，通过定义处理管道实现了比纯PLINQ快2倍的性能，同时保持了代码的可读性。

六、血的教训总结

在金融计价系统重构时，我们曾因为未考虑Decimal类型的原子性而损失了6小时交易数据。这次事故教会我们：

  • 任何共享状态都需书面证明其线程安全性
  • 压力测试要覆盖从单核到最大核数的所有情况
  • 监控系统必须包含竞态检测指标

七、通向光明的技术路线

建议的演进路径：

  1. 优先使用Parallel类内置的本地聚合
  2. 无法避免共享状态时用Interlocked
  3. 复杂逻辑考虑并发集合
  4. 性能敏感场景验证缓存行对齐
  5. 终极方案使用数据流或Actor模型