一、异常现象初现

当我们在C#中使用Parallel.ForEach配合自定义Partitioner时，偶尔会遇到这样的错误提示：
csharp System.InvalidOperationException: Partitioner was consumed
这个看似简单的异常信息背后，隐藏着并行计算中微妙的设计哲学。上周在优化一个图像处理算法时，我就曾在这个问题上耗费了两个小时——明明相同的代码在测试环境运行良好，到了生产环境却频繁抛出异常。

二、异常的本质原因

通过反编译.NET Core源码，我们发现Partitioner内部维护着一个bool m_hasNoElements的状态标志。当出现以下情况时会触发异常：

1. 分区器重复使用：大多数Partitioner实现都是"一次性"的，特别是动态分区器（DynamicPartitioner），它们在遍历完成后会标记自己为"已消耗"状态。

2. 并发修改集合：在枚举过程中如果原始数据源被修改，例如：
   csharp var list = new List<int> { 1, 2, 3 }; var partitioner = Partitioner.Create(list); Parallel.ForEach(partitioner, item => { list.Add(item * 2); // 危险操作！ });

3. 自定义分区器实现错误：覆盖GetDynamicPartitions方法时未正确处理空集合情况。

三、实战解决方案

方案1：正确复用分区器

csharp
// 错误做法
var partitioner = Partitioner.Create(source);
Parallel.ForEach(partitioner, ...);
Parallel.ForEach(partitioner, ...); // 第二次使用抛出异常

// 正确做法
var partitioner1 = Partitioner.Create(source);
var partitioner2 = Partitioner.Create(source); // 创建新实例

方案2：处理动态集合

对于可能变化的集合，推荐使用不可变集合：
csharp var immutableList = source.ToImmutableArray(); var partitioner = Partitioner.Create(immutableList);

方案3：自定义分区器的最佳实践

csharp
public class SafePartitioner : Partitioner
{
private readonly IList _items;

public SafePartitioner(IList<T> items) => _items = items;

public override IList<IEnumerator<T>> GetPartitions(int partitionCount)
{
    var partitions = new IEnumerator<T>[partitionCount];
    for (int i = 0; i < partitionCount; i++)
    {
        partitions[i] = CreateEnumerator(i, partitionCount);
    }
    return partitions;
}

private IEnumerator<T> CreateEnumerator(int partitionIndex, int partitionCount)
{
    // 每个分区获取独立枚举器
    for (int i = partitionIndex; i < _items.Count; i += partitionCount)
    {
        yield return _items[i];
    }
}

}

四、底层机制揭秘

通过分析.NET Core 3.1源码，我们发现Partitioner的内部状态机转换过程：

1. 初始化阶段：supportsDynamicPartitions标志设为true
2. 首次调用GetDynamicPartitions：创建DynamicPartitionerEnumerator内部类
3. 枚举完成后：m_sourceDepleted标志被置为true
4. 再次尝试枚举：检查到m_sourceDepleted立即抛出异常

这种设计确保了线程安全，但要求开发者必须理解其"一次性"特性。在.NET 6中这个机制有所优化，会提供更清晰的错误信息。

五、性能优化技巧

1. 静态分区优于动态分区：对于已知长度的集合，优先使用Partitioner.Create的重载方法指定分区策略：
   csharp // 更好的性能表现 Partitioner.Create(source, EnumerablePartitionerOptions.NoBuffering);

2. 合理设置分区大小：通过实验找到最佳分区大小：
   csharp var rangePartitioner = Partitioner.Create(0, 1000000, 10000);

3. 监控分区效率：使用ParallelOptions配合CancellationToken：
   csharp var options = new ParallelOptions { MaxDegreeOfParallelism = Environment.ProcessorCount - 1, CancellationToken = cancellationToken };

六、经验总结

在实际项目中处理这类异常时，我们需要建立三个认知维度：

1. 生命周期管理：将Partitioner视为像DbContext一样的需要严格管理生命周期的对象

2. 线程安全边界：明确区分只读操作和修改操作的执行上下文

3. 性能权衡：在分区粒度和开销之间找到平衡点，通常每个分区处理1000-10000个元素比较理想

记住：并行计算中的异常往往比同步代码更难以复现，良好的日志记录和单元测试覆盖至关重要。建议在使用Partitioner的关键路径添加如下诊断代码：
csharp Debug.Assert(partitioner.GetPartitions(1).Count > 0, "分区器初始化异常");

通过理解这些底层原理，我们不仅能解决问题，更能写出真正线程安全的高性能并行代码。