io密集型任务应使用async/await配合原生异步api，避免thread.sleep或task.run包裹同步io；cpu密集型任务应限制并发数，优先用parallel类或plinq，避免盲目多线程。
IO密集型任务：等磁盘、等网络、CPU闲着，别用Thread.Sleep硬扛
IO密集型任务的本质是“CPU在等”——等文件读完、等HTTP响应回来、等数据库返回结果。此时CPU利用率可能只有5%～20%，但用户觉得“卡”，是因为线程被File.ReadAllText或HttpClient.GetStringAsync这种同步调用**阻塞住了**，整个线程挂起，啥也干不了。
常见错误现象：
• 界面假死（WinForms/WPF中点了按钮没反应）
• 吞吐量上不去，加10个线程反而更慢（线程堆积+上下文切换开销）
• Task.Run(() => File.ReadAllBytes(...)) 包裹同步IO——这是伪异步，白费线程池资源
- ✅ 正确做法：全程用
async/await+ 原生异步API（如File.ReadAllTextAsync、HttpClient.GetAsync、SqlCommand.ExecuteReaderAsync） - ✅ 并发控制：用
Task.WhenAll同时发起多个IO请求，而不是串行等待 - ⚠️ 注意：不要用
Task.Run包裹同步IO方法——它只是把阻塞搬进线程池，没解决本质问题
var tasks = new List<Task<string>>();
foreach (var url in urls)
{
tasks.Add(httpClient.GetStringAsync(url)); // 真异步，不占线程
}
var results = await Task.WhenAll(tasks); // 一次性并发等待全部完成
CPU密集型任务：算得飞起、CPU跑满，别盲目开100个线程
CPU密集型任务（比如图像灰度转换、JSON深度解析、蒙特卡洛模拟）几乎不等IO，CPU持续100%运转。这时候如果开远超CPU核心数的线程（例如16核机器启200个Task.Run），线程频繁切换反成瓶颈，性能不升反降。
常见错误现象：
• CPU使用率100%，但实际吞吐量比单线程还低
• Parallel.ForEach 里做短耗时计算（如每项只花0.1ms），调度开销压倒收益
• 在ASP.NET Core中用Task.Run处理大量计算——抢走线程池线程，影响请求处理
- ✅ 正确做法：用
Parallel.For/Parallel.ForEach或PLINQ（如.AsParallel().Select(...)），它们会自动按核心数调度 - ✅ 更精细控制：指定
MaxDegreeOfParallelism = Environment.ProcessorCount - ⚠️ 注意：避免在短循环体中用
async——CPU任务不需要异步，加了await反而引入状态机开销
Parallel.ForEach(data, new ParallelOptions
{
MaxDegreeOfParallelism = Environment.ProcessorCount
}, item =>
{
// 纯CPU计算，无await，无IO
item.ProcessHeavy();
});
怎么快速判断你的任务属于哪一类？看这三点
不用猜，直接观察运行时表现：
- 打开任务管理器 → 看“CPU使用率”：长期稳定在95%+？大概率是CPU密集型
- 看“磁盘活动”或“网络发送/接收”：IO图标狂闪，但CPU平缓？IO密集型
- 加一行日志：
Console.WriteLine($"Thread: {Thread.CurrentThread.ManagedThreadId}");，如果同一任务反复打印不同线程ID且CPU低 → 异步IO；如果总是一个线程ID且CPU爆表 → CPU密集
补充经验法则：
• 文件复制、日志写入、API聚合、DB查询 → IO密集型
• 图像缩放、密码哈希（SHA256）、数值积分、正则全文匹配 → CPU密集型
混合场景怎么办？拆开处理，别混在同一个async方法里
真实业务常是“先取数据（IO），再算结果（CPU）”。如果全塞进一个async方法并用Task.Run包CPU部分，容易导致线程池饥饿（尤其在Web服务中）。
- ✅ 推荐模式：IO部分用
await，CPU部分用Task.Run（但限制并发数） - ✅ 更优解：IO完成后，把数据发给专用CPU工作队列（如
Channel<t></t>+ 独立Task消费者） - ⚠️ 高危操作：在
async方法里写Task.Run(() => { Thread.Sleep(1000); })——这是典型“异步包装同步阻塞”，毫无意义
最容易被忽略的一点：ASP.NET Core默认线程池大小有限（约数万），但它的**IO线程是I/O Completion Port驱动的，近乎无限**；而CPU任务挤占的是同一线程池。所以IO密集型可放心并发，CPU密集型必须节制——这不是建议，是线程池资源约束下的硬边界。
