在C#中，多任务调度和并行处理并不是简单地开启多个线程就能解决所有问题。任务粒度过小会导致上下文切换开销剧增，共享状态保护不当又会引入竞态条件甚至死锁。工程上真正需要的是在正确性和吞吐量之间找到平衡，因此从调度模型选择到同步机制设计再到并发度控制，每一步都值得仔细推敲。
一、多任务调度模型的选择：Thread、ThreadPool与Task
早期的C#多线程开发大量直接使用Thread类，但手动创建线程的成本很高，每个线程默认占用约1MB栈空间，频繁创建和销毁会拖垮性能。更合理的做法是让线程池复用工作线程，于是ThreadPool成为轻量级选择。不过ThreadPool的任务排队机制比较原始，无法方便地获取返回值、组合多个任务或处理异常。
Task在ThreadPool之上做了更高层次的抽象，它表示一个可能异步完成的工作单元。通过Task.Run可以把委托提交到线程池，通过async/await可以以同步代码的风格编写异步逻辑。Task还内置了状态管理、异常传播和取消支持，这使得它成为C#多任务调度的首选。例如下面的代码展示了从一个同步方法逐步改造为异步方法的过程：
// 同步版本，可能阻塞UI线程
public string FetchData()
{
using var client = new HttpClient();
return client.GetStringAsync("https://api.ipipp.com/data").Result;
}
// Task异步版本，不会阻塞调用线程
public async Task<string> FetchDataAsync()
{
using var client = new HttpClient();
return await client.GetStringAsync("https://api.ipipp.com/data");
}
需要注意的是，async/await解决的更多是异步等待而非CPU并行。如果某个操作以IO为主，例如访问数据库或调用远程服务，异步模型能显著提升系统吞吐量，因为它不会让线程傻等IO完成。但如果操作是CPU密集型的计算，async/await并不会自动分配多个核心，此时还需要结合Task.Run或Parallel类来真正实现并行。
另外，在编写异步方法时要避免async void，除了事件处理器之外，异步方法应返回Task或Task<T>，这样调用方才可以等待完成并捕获异常。对于类库代码，还建议在await之后使用ConfigureAwait(false)，避免不必要的上下文切换。
二、竞态条件、死锁与数据一致性处理
多个任务同时访问共享数据时，如果没有同步保护，就可能出现竞态条件。典型表现是程序偶发结果错误，且难以稳定复现。例如下面这段代码启动100个任务对同一个计数器执行自增操作：
private static int counter = 0;
public static async Task RunAsync()
{
var tasks = new List<Task>();
for (int i = 0; i < 100; i++)
{
tasks.Add(Task.Run(() =>
{
for (int j = 0; j < 1000; j++)
{
counter++;
}
}));
}
await Task.WhenAll(tasks);
Console.WriteLine(counter); // 期望100000，实际可能小于该值
}
counter++不是原子操作，它包含读取、加一、写回三步。多个线程可能同时读到相同值，导致部分自增丢失。解决这类问题最简单的办法是使用Interlocked.Increment，它基于CPU原子指令实现无锁自增。如果涉及更复杂的复合操作，则需要使用lock或Monitor来保护临界区。
private static readonly object syncLock = new object();
private static int counter = 0;
public static void SafeIncrement()
{
lock (syncLock)
{
counter++;
}
}
锁虽然能保证正确性，但使用不当会造成死锁。常见场景是两个任务互相等待对方释放锁，例如任务A持有lock1并请求lock2，任务B持有lock2并请求lock1。避免死锁的关键是统一加锁顺序、尽量缩短临界区、使用超时机制。Monitor.TryEnter可以设置等待超时，从而避免无限等待。
对于集合类型的高并发读写，手动加锁往往效率不高。C#提供了System.Collections.Concurrent命名空间下的线程安全集合，例如ConcurrentDictionary、ConcurrentQueue和ConcurrentBag。这些集合内部实现了细粒度锁或无锁算法，可以在大多数场景下安全地代替普通集合加锁。而Channel<T>则适合生产者-消费者模型，它把任务投递和消费解耦，能够自然实现背压控制。
var channel = Channel.CreateBounded<int>(new BoundedChannelOptions(100)
{
FullMode = BoundedChannelFullMode.Wait
});
await channel.Writer.WriteAsync(42);
int value = await channel.Reader.ReadAsync();
除了共享内存模型，还可以通过消息传递的方式避免共享状态。每个任务只处理自己的数据，通过不可变对象或数据副本传递信息。函数式风格的并行设计能从根本上减少竞态发生的概率，尤其适合数据流或管道式处理。
三、并发度控制与工程化调优
并行度并不是越高越好。如果同时运行的任务数量超过CPU核心数很多，线程池会频繁切换上下文，反而降低总体吞吐量。对于CPU密集型计算，通常把并发度设置为Environment.ProcessorCount或略低于该值。Parallel.For和Parallel.ForEach可以通过ParallelOptions.MaxDegreeOfParallelism限制最大并行度。
var options = new ParallelOptions
{
MaxDegreeOfParallelism = Environment.ProcessorCount
};
Parallel.ForEach(dataList, options, item =>
{
ProcessItem(item);
});
当任务列表很大且每个任务都涉及IO操作时，直接使用Task.WhenAll一次性发起所有请求可能导致连接池耗尽或远程服务过载。此时更适合使用SemaphoreSlim进行限流，分批执行任务。下面是一个简单的限流模板：
public static async Task ProcessWithLimitAsync(IEnumerable<string> urls, int maxConcurrency)
{
using var semaphore = new SemaphoreSlim(maxConcurrency);
var tasks = urls.Select(async url =>
{
await semaphore.WaitAsync();
try
{
await DownloadAsync(url);
}
finally
{
semaphore.Release();
}
});
await Task.WhenAll(tasks);
}
异常处理同样影响调度的健壮性。多个任务并行执行时，Task.WhenAll会抛出AggregateException，内部包含所有失败任务的异常。可以通过遍历InnerExceptions来逐个记录，或者使用Task.WhenAll配合try-catch捕获并处理。取消操作则依赖CancellationToken，任务在关键节点检查IsCancellationRequested并主动退出，调用方通过CancellationTokenSource.Cancel发出取消信号。
using var cts = new CancellationTokenSource();
cts.CancelAfter(TimeSpan.FromSeconds(5));
try
{
await LongRunningWorkAsync(cts.Token);
}
catch (OperationCanceledException)
{
Console.WriteLine("任务被取消");
}
在实际项目中，还可以借助System.Threading.Channels构建流水线，将数据依次经过多个处理阶段，每个阶段独立控制并发度。对于需要持续产出数据的场景，可以使用IAsyncEnumerable结合await foreach实现异步流，这样消费者可以在数据产生时立即处理，而不必等待全部数据返回。这些机制共同构成了C#多任务调度和并行处理的工程化基础。
总之，处理好多任务调度和并行处理问题，核心在于理解Task和线程池的工作方式，严格管理共享状态，并合理限制并发度。配合取消、异常处理和限流策略，可以让应用在保证正确性的同时充分利用多核资源，避免线程饥饿和资源耗尽等常见的并发陷阱。
C#多任务调度并行处理Task Parallel Library修改时间：2026-09-24 19:10:09