System.Threading.Tasks.Dataflow中MaxDegreeOfParallelism是尽力限制还是硬上限？

你遇到的这个情况其实很典型——MaxDegreeOfParallelism确实是一个「尽力而为」的软限制，而非严格的硬约束，不过你的测试代码本身也存在测量时序上的问题，导致观测到了明显超出设置值的并行数。

为什么会观测到超出maxDegreeOfParallelism的数值？ #

1. 测试代码的测量时序漏洞 #

你的代码里，进入TransformBlock委托后立刻标记concurrentlyConsuming[x] = true，但并行度统计是在获取信号量之后才执行的。这里存在一个时间窗口：在你标记任务为运行态，到抢到信号量完成统计的这段时间里，可能已经有更多任务被调度执行并标记为运行态了。

举个例子：假设max值是100，第100个任务刚标记自己为running，还没抢到信号量，这时候第101、102个任务已经被调度并完成了running标记，等第100个任务抢到信号量统计时，就会数到102个运行中的任务。

2. Dataflow的调度逻辑：「尽力限制」而非「严格阻塞」 #

MaxDegreeOfParallelism的设计目标是控制同时执行的委托数量上限，但它的实现依赖于.NET的任务调度器（默认是ThreadPoolTaskScheduler）。当调度器有可用线程时，Dataflow可能会短暂让超过设置值的任务开始执行——比如当某个任务刚进入等待状态（比如你的Task.Delay），调度器可能会提前调度新任务，这时候就会出现瞬时的并行数超出情况。

不过这种超出非常短暂，Dataflow会快速调整回来，不会持续保持超过设置值的并行度。

如何正确测量实际并行度？ #

如果想准确测量TransformBlock的实际并行执行数量，可以调整测量逻辑：用线程安全的计数器在委托开始时递增、结束时递减，同时记录计数器的最大值，避免信号量带来的时序延迟问题。

修改后的示例代码：

using System.Threading.Tasks.Dataflow;
using var cts = new CancellationTokenSource();
Console.CancelKeyPress += (_, _) => cts.Cancel();
var cancellationToken = cts.Token;
var messageCount = 10_000;
var maxDegreeOfParallelism = 100;
int currentParallelism = 0;
int maxObservedParallelism = 0;
var lockObj = new object();
const int maxDelayMs = 10;

var consumeMessageBlock = new TransformBlock<int, int>(async x => {
    int current;
    lock (lockObj)
    {
        current = ++currentParallelism;
        if (current > maxObservedParallelism)
            maxObservedParallelism = current;
    }
    try
    {
        await Task.Delay(Random.Shared.Next(0, maxDelayMs), cancellationToken);
        return current;
    }
    finally
    {
        lock (lockObj)
        {
            --currentParallelism;
        }
    }
}, new ExecutionDataflowBlockOptions {
    CancellationToken = cancellationToken,
    MaxDegreeOfParallelism = maxDegreeOfParallelism,
});

var output = new List<int>();
var collectOutput = new ActionBlock<int>(output.Add);
consumeMessageBlock.LinkTo(collectOutput, new DataflowLinkOptions { PropagateCompletion = true });

for (var i = 0; i < messageCount; i++)
    await consumeMessageBlock.SendAsync(i, cancellationToken);

consumeMessageBlock.Complete();
await collectOutput.Completion;

Console.WriteLine($"最大观测并行度：{maxObservedParallelism}");
Console.WriteLine($"是否超出设置值：{maxObservedParallelism > maxDegreeOfParallelism}");

用这种方式测量，你会发现maxObservedParallelism基本不会超过设置值，偶尔的微小超出也是任务调度中的瞬时现象，属于Dataflow设计的正常范畴。

总结 #

• MaxDegreeOfParallelism是软约束，Dataflow会尽力控制并行度不超过设置值，但受任务调度器特性影响，可能出现短暂、微小的超出。
• 你的原始测试代码因为测量时序问题，放大了这种瞬时超出的现象，调整逻辑后就能更准确反映Dataflow的实际并行控制能力。

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