C#控制台应用使用Parallel.For处理大数据时运行一段时间后间歇性挂起

• 基于C#实现的控制台应用，通过Parallel.For处理海量行程配对数据
• 运行过程中出现间歇性挂起，表现为CPU使用率大幅下降，故障固定出现在负责配对逻辑的For循环段，性能分析显示故障时段CPU未执行应用相关运算
• 故障触发与内存水位强相关：内存使用率超过90%时必然出现异常

故障关联核心代码 #

feasiblePairs22222 = new List<Pair>();
Pair[] tempPair = new Pair[tripListSize];
Parallel.For(0, tripListSize, tri=>  {
   var PairingStack = new Stack<List<Trip>>();
   var firstElement = new List<Trip>();

    firstElement.Add(Program.tripList[tri]);
    PairingStack.Push(firstElement);

    while (PairingStack.Count > 0)
    {
        var tempPairing11 = PairingStack.Pop();
        int start = tempPairing11[tempPairing11.Count - 1].index;
        int startTime = tempPairing11[0].departureTime;
        foreach (Trip candidToAdd in twoTripMatchable[start])
        {
                if (candidToAdd.araivalTime - startTime > Program.WorkingTimeLimit) { continue; }
                if (candidToAdd.departureTime - tempPairing11[tempPairing11.Count - 1].araivalTime > 30) { continue; }
                var newPairing = new List<Trip>();
                newPairing.AddRange(tempPairing11);
                newPairing.Add(candidToAdd);
                PairingStack.Push(newPairing);

                int workingTime = 0;
                foreach (Trip currentTrip in newPairing) { workingTime = workingTime + currentTrip.Duration; }
                if (workingTime <= 180) { continue; }
                newPairing.ForEach(o => o.isCovered++);

            lock (tempPair)
                {
                    tempPair[tri] = new Pair();
                    tempPair[tri].PairTrips = newPairing.ToArray();
                    feasiblePairs22222.Add(tempPair[tri]);
                }
            }                        
        }
});

• 内存压力触发GC长停顿：代码段存在海量短生命周期引用类型分配，每次循环迭代都会创建List<Trip>对象、做全列表复制、转成数组，快速消耗内存。当内存水位超过90%时，CLR会触发Full GC的Stop-The-World停顿，冻结所有托管线程，直接表现为应用挂起、CPU使用率下降，和实测的内存阈值触发特征完全吻合。
• 无效全局锁导致并行度丧失：lock(tempPair)锁的是数组对象引用，所有并行线程抢同一把锁。其中tempPair[tri]的写入完全是线程安全的——每个循环迭代对应的tri是唯一专属值，不存在多线程读写同一下标的情况，根本不需要加锁；剩下的对非线程安全feasiblePairs22222的并发Add操作，也因为全局锁变成了串行执行，大幅拉低并行效率，在GC停顿时进一步放大系统卡顿感。
• 无界内存膨胀放大压力：PairingStack没有设置深度、大小上限，每匹配到一个符合规则的行程对，就会把复制出来的完整列表压入栈，无上限的内存申请会快速把系统内存推到高水位线，更早触发GC停顿。

• 降低GC分配压力：
  • 复用临时数组缓冲区，替换所有循环内的new List<Trip>()分配，对列表复制做批量优化，减少短生命周期对象的生成量；优化工作时长计算逻辑，在生成新配对时直接基于上一个配对的总时长累加新加入行程的时长，避免每次全量遍历列表累加数值。
  • 移除tempPair[tri]写入时的多余锁逻辑，消除完全无意义的锁竞争。
• 优化并发结果收集逻辑：
  • 把全局共享的非线程安全List<Pair>替换为ConcurrentBag<Pair>，或者给每个并行分区分配独立的结果列表，循环结束后再做列表合并，把锁粒度从全局降低到分区级别，彻底消除锁竞争。
• 增加栈内存的保护逻辑：
  • 给PairingStack设置最大深度、最大栈元素数量限制，避免单迭代内无限制申请内存，防止内存水位无意义上涨。
• 优化GC触发体验：
  • 对长时运行的批处理应用，启用服务器GC模式，降低Full GC的单次停顿时长；在内存水位到达阈值前，主动将已生成的有效配对结果刷入磁盘或持久化存储，避免内存打满后被动触发GC停顿。

内容的提问来源于stack exchange，提问作者mehdi fallahi