现在的 Web 应用，面对的早已不是几十个用户，而是成千上万的并发请求。用户希望接口响应快，系统希望资源用得省，运维希望服务稳得住。这背后，ASP.NET Core 依赖的是一套以线程池为核心的执行模型，而 Task Parallel Library（TPL），正是这套模型的地基。
TPL 的意义不在于“并发很炫”，而在于：让你在不碰线程、不写锁的情况下，也能写出高性能的异步代码。理解它，基本就理解了 ASP.NET Core 为什么能扛并发。
什么是 TPL？
TPL 是 .NET 中 System.Threading.Tasks 命名空间下的一整套并发抽象，其中最重要的角色就是 Task。它把线程创建、调度、回收这些复杂又容易出错的事情，全部交给运行时处理，开发者只需要关心“要做什么”，而不是“用几个线程做”。
在 ASP.NET Core 里，TPL 并不是一个“你可以选择用不用”的工具，而是框架本身的运行基础。每一个 HTTP 请求，最终都是由线程池中的线程来执行的。如果这个线程在访问数据库或调用远程接口时被阻塞住，那它就什么都干不了。
而 TPL 的异步模型，可以让线程在等待 I/O 的这段时间里立刻回到线程池，去服务别的请求。这一点，是 ASP.NET Core 能支撑高并发的关键。
TPL 在 ASP.NET Core 中的核心应用场景
1. 控制器中的 async/await
最常见、也是最基础的用法，就是在控制器里使用 async/await：
public async Task<IActionResult> GetUsers()
{
var users = await _userService.GetUsersAsync();
return Ok(users);
}
这段代码看起来和同步没什么区别，但本质上完全不同。只要 GetUsersAsync 是真正的异步 I/O 调用，请求线程在等待数据库返回时就会被释放。这种写法，既不浪费线程，又保持了代码的可读性。
2. 服务层和数据访问层必须“全异步”
很多性能问题，其实不是出在控制器，而是“上面 async，下面同步”。控制器已经是异步的，但服务层或仓储层偷偷用了同步 API，线程照样被堵住。
正确的方式，是从控制器到数据库，全链路异步：
public async Task<List<User>> GetUsersAsync()
{
return await _context.Users.ToListAsync();
}
EF Core 提供的 ToListAsync、FirstOrDefaultAsync 等方法，底层已经和 TPL 集成好了，只要你用对方法，线程就不会被阻塞。
3. 并行执行互不依赖的任务
当一个请求里需要同时做几件互不相关的事情，比如查用户信息、查订单列表，这时就可以并行执行：
public async Task<IActionResult> Dashboard()
{
var usersTask = _userService.GetUsersAsync();
var ordersTask = _orderService.GetOrdersAsync();
await Task.WhenAll(usersTask, ordersTask);
return Ok(new { Users = usersTask.Result, Orders = ordersTask.Result });
}
Task.WhenAll 的好处是：总耗时等于最慢的那个任务，而不是所有任务时间之和。
需要注意的是，并行并不等于无限制并发。比如数据库连接池是有限的，滥用并行反而可能拖垮系统。
4. 正确对待 CPU 密集型任务
ASP.NET Core 非常擅长处理 I/O 密集型任务，但对 CPU 密集型任务并不友好，比如复杂计算、加密、图像处理。
如果你确实需要在请求中做这类事情，可以考虑：
await Task.Run(() => PerformHeavyCalculation());
但一定要记住：不要用 Task.Run 去包数据库、HTTP 或文件 I/O。这些操作本身就有异步 API，用 Task.Run 只会多创建线程，反而更慢。
5. 后台任务的正确姿势
有些事情并不适合放在请求里，比如定时发送通知、清理日志、同步数据。这类任务应该交给后台服务来做：
public class NotificationWorker : BackgroundService
{
protected override async Task ExecuteAsync(CancellationToken stoppingToken)
{
while (!stoppingToken.IsCancellationRequested)
{
await SendNotificationsAsync();
await Task.Delay(5000, stoppingToken);
}
}
}
BackgroundService 和 ASP.NET Core 的宿主生命周期是绑定的，应用关闭时会收到取消信号，能保证任务优雅退出，比“控制器里偷偷开 Task”靠谱得多。
常见误区与陷阱
最常见的错误，就是把异步代码“写成同步”。比如在异步方法里调用 .Result 或 .Wait()，这会直接阻塞线程，在高并发下极容易把线程池耗光。
另一个坑是“即发即忘”。像 Task.Run(() => SendEmail()) 这种写法，既不保证成功，也无法感知失败，应用一重启，任务就没了。
还有人喜欢在控制器里用 Parallel.For，但这个 API 是为纯 CPU 计算设计的，会疯狂占线程，非常不适合 Web 请求场景。
最佳实践
在 ASP.NET Core 中使用 TPL，可以记住几个简单但非常重要的原则：
端到端异步，永远不要只 async 一半； 优先使用框架和库自带的异步方法； 多个独立任务可以用 Task.WhenAll 提升整体响应速度； 任何形式的阻塞调用，都是并发杀手； 后台任务交给 BackgroundService，不要自己“造轮子”。
TPL 与传统多线程的差异
TPL 的优势不在于“更复杂”，而在于“更省心”。
什么时候不该用 TPL？
并不是所有代码都适合异步。纯内存计算、极短的同步逻辑，用 async 反而会增加状态机开销。
另外，在控制器里直接跑 CPU 密集型任务，通常都是设计问题，应该拆出去做后台处理。至于那些没法改造的老同步 API，用 Task.Run 包一层虽然能用，但一定要评估成本。
结语
TPL 是 ASP.NET Core 能跑得快、扛得住的核心原因之一。它并不是让单个请求变快，而是让系统在高并发下更合理地使用线程资源。
真正掌握 TPL，意味着你不只是会写 async/await，而是开始用“系统视角”思考性能和并发问题。这一步，往往就是普通开发者和成熟架构思维之间的分水岭。
