ASP.NET Core依赖注入性能优化：什么时候该用AddTransient而不是AddScoped？

ASP.NET Core依赖注入性能优化：什么时候该用AddTransient而不是AddScoped？

在构建高性能的ASP.NET Core应用时，我们常常将目光聚焦于数据库查询优化、缓存策略或是异步编程。然而，一个同样关键却容易被忽视的性能杠杆，就隐藏在Startup.cs或Program.cs的服务注册代码里——依赖注入（DI）生命周期的选择。特别是AddTransient和AddScoped之间的抉择，远不止是“请求内共享”与“每次都新建”那么简单。对于追求极致性能的高级开发者和架构师而言，这更像是一场在内存分配、垃圾回收（GC）压力与线程安全之间进行的精密权衡。选错了，你的应用可能在低负载下运行良好，一旦面临高并发，就会暴露出内存泄漏或性能瓶颈。今天，我们就抛开基础概念，直接从性能剖面切入，探讨如何做出最明智的生命周期决策。

1. 性能视角下的生命周期本质：内存与GC的故事

要做出正确的选择，首先得理解不同生命周期在运行时是如何影响内存和垃圾回收器的。这不是抽象的理论，而是直接影响应用响应时间和可伸缩性的实际因素。

1.1 实例创建与销毁的底层开销

每次调用AddTransient注册的服务，容器在解析时都会执行一次new操作。这个过程的成本取决于服务本身的构造复杂度：它依赖了多少其他服务？构造函数里有没有耗时的初始化逻辑（如读取大文件、建立网络连接）？

// 一个看似简单的瞬时服务，可能隐藏着依赖树
services.AddTransient<IReportGenerator, PdfReportGenerator>();
// PdfReportGenerator 可能依赖 IDataFetcher, ITemplateEngine, IFontService...
// 每次解析，这整棵树都可能被重新实例化。

相反，AddScoped服务在一个作用域（通常是HTTP请求）内是单例的。这意味着，无论你在一个Controller的构造函数、多个Action方法，或是通过中间件多次请求同一个服务，拿到的都是同一个实例。关键在于，这个实例的生命周期与作用域绑定。请求结束时，.NET运行时知道可以安全地释放该作用域内所有Scoped服务实例占用的内存。

从纯内存分配频率看，Transient显然更高。但这一定意味着性能更差吗？不一定。如果服务是极度轻量级、无状态的（例如一个纯粹的数学计算器ICalculator），new一个对象的开销微乎其微，甚至可能低于从某个内部字典中查找并返回现有Scoped实例的开销。问题在于，我们应用中的服务很少如此“纯粹”。

1.2 垃圾回收（GC）压力：隐形的性能杀手

这才是Transient滥用可能引发严重性能问题的核心。.NET的垃圾回收器（GC）负责自动管理内存，但它不是免费的。频繁的、短生命周期对象的创建与销毁，会导致GC被频繁触发，尤其是Gen 0（第0代）回收。

考虑一个场景：一个处理订单的API端点，内部使用了10个不同的Transient服务。每个请求都会创建10个新对象，请求处理完毕，这10个对象就变成了待回收的垃圾。在每秒处理1000个请求（RPS）的高并发下，每秒就会产生10,000个短命对象。GC为了回收这些内存，不得不更频繁地工作，这会消耗宝贵的CPU时间片，导致应用整体吞吐量下降和响应时间波动。

注意：GC压力在性能剖析工具（如.NET Counters、Application Insights）中可能表现为较高的“GC暂停时间”（% Time in GC）或频繁的“Gen 0 Collections”。这是排查因生命周期选择不当导致性能问题的重要指标。

而Scoped服务，由于其生命周期与请求对齐，这些对象通常会存活得稍长一些（整个请求处理期间），并且在同一请求内被复用。这显著减少了单位时间内新对象的分配数量，从而降低了GC的频率和压力。对于具有中等或较高初始化成本的服务，使用Scoped几乎是性能上的必选项。

让我们用一个简单的表格对比两种生命周期在性能维度的关键差异：