前段时间,在群里潜水的时候,看见有个群友的报错日志是这样的:
An unhandled exception was thrown by the application. System.OutOfMemoryException: Exception of type 'System.OutOfMemoryException' was thrown.at System.Threading.Thread.StartInternal()at Microsoft.Extensions.Logging.Console.ConsoleLoggerProvider..ctor(IOptionsMonitor`1 options)at …at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteRuntimeResolver.VisitCache(ServiceCallSite callSite, RuntimeResolverContext context, ServiceProviderEngineScope serviceProviderEngine, RuntimeResolverLock lockType)at …at Microsoft.Extensions.DependencyInjection.ServiceProviderServiceExtensions.GetService[T](IServiceProvider provider)at Microsoft.Extensions.Logging.LoggerFactory.Create(Action`1 configure)at xxxxxxx. <>c__DisplayClass2_0.<AddXxxDbContext>b__0(DbContextOptionsBuilder builder)at Microsoft.Extensions.DependencyInjection.EntityFrameworkServiceCollectionExtensions.CreateDbContextOptions[TContext](IServiceProvider applicationServiceProvider, Action`2 optionsAction)at …
嗯……内存满了?是在构建 ConsoleLoggerProvider 的时候报的异常?是由依赖注入容器产生的?再上层是 AddXxxDbContext?
好吧,看来一定是位没研究过 EFCore 源码也没看过与本文类似内容的仁兄……我甚至能反推出他写的代码:
public class Startup
{public void ConfigureServices(IServiceCollection services){services.AddDbContext<MyDbContext>(options =>{// ...options.UseLoggerFactory(LoggerFactory.Create(b => b.AddConsole().AddDebug()));});// ...}// ...
}
C#
看,这个调用堆栈是不是对上味儿了。
接下来我将介绍这个bug产生的原因,并带各位看官一窥 DbContext、DbContextOptions、EFCore内部类的大致生命周期。
本文所有知识均基于 EFCore 3.1 版本,EFCore 5.0 对这部分几乎没有改动。
另外,如果有兴趣调试 EFCore 的源码,可以 clone 下来某个 release 版本,然后保留 EFCore/Abstractions/Analyzers/Relational/SqlServer 这几个项目,然后开一个自己的命令行或者单元测试项目,就可以尽情遨游 EFCore 的源码了。
读代码前,请储备一定量的英文知识和自信。很多代码的意思都写在变量名和函数名上了,大部分源代码读起来并不是什么很难的事情:)
谁实例化了 DbContext?
常见有两种方式来构建 DbContext,一种是直接拿来 new 一个,构造函数传入 DbContextOptions 或者什么都不传入;一种是在 ASP.NET Core 中常用的 services.AddDbContext<...>(...)
,然后通过某个服务的构造函数或者 IServiceProvider
取得该 DbContext 实例。后者要求该 DbContext 只实现一个构造函数,该构造函数只接受一个参数 DbContextOptions<MyDbContext>
。
关于后一种构造方式,我们将父依赖注入容器称为 Application ServiceProvider。
首先需要明确的一点是,DbContext 的构造是由父依赖注入容器实现的。而构造函数要求检测仅仅是 EFCore 那个拓展函数进行的检查。
我们先来看各个 AddDbContext
的核心操作函数吧。
public static IServiceCollection AddDbContext<TContextService, TContextImplementation>([NotNull] this IServiceCollection serviceCollection,[CanBeNull] Action<IServiceProvider, DbContextOptionsBuilder> optionsAction,ServiceLifetime contextLifetime = ServiceLifetime.Scoped,ServiceLifetime optionsLifetime = ServiceLifetime.Scoped)where TContextImplementation : DbContext, TContextService
{Check.NotNull(serviceCollection, nameof(serviceCollection));if (contextLifetime == ServiceLifetime.Singleton){optionsLifetime = ServiceLifetime.Singleton;}if (optionsAction != null){CheckContextConstructors<TContextImplementation>();}AddCoreServices<TContextImplementation>(serviceCollection, optionsAction, optionsLifetime);serviceCollection.TryAdd(new ServiceDescriptor(typeof(TContextService), typeof(TContextImplementation), contextLifetime));return serviceCollection;
}
C#
Copy
在这里可以看到:
我们可以修改
DbContextOptions
和DbContext
的生命周期为 Singleton 或者 Transient,而不是默认的 Scoped当检测到对
DbContextOptionsBuilder
的调用时,会检查构造函数是否符合要求TContextImplementation
是被构造的 DbContext 实例类型,直接由该依赖注入容器构造
而 AddCoreServices
函数则是将 DbContextOptions
实例注入容器。
private static void AddCoreServices<TContextImplementation>(IServiceCollection serviceCollection,Action<IServiceProvider, DbContextOptionsBuilder> optionsAction,ServiceLifetime optionsLifetime)where TContextImplementation : DbContext
{serviceCollection.TryAdd(new ServiceDescriptor(typeof(DbContextOptions<TContextImplementation>),p => CreateDbContextOptions<TContextImplementation>(p, optionsAction),optionsLifetime));serviceCollection.Add(new ServiceDescriptor(typeof(DbContextOptions),p => p.GetRequiredService<DbContextOptions<TContextImplementation>>(),optionsLifetime));
}
C#
Copy
在这里可以看到:
容器中可能具有很多个
DbContextOptions
实例,可以通过IEnumerable<DbContextOptions>
拿到全部;这一设计是由于一个依赖注入容器中可以加入多个DbContext
类型对于每一个特性类型的 DbContext (以下写为 MyDbContext),都会有一个
DbContextOptions<MyDbContext>
与之对应我们在构造函数处用到的
DbContextOptionsBuilder
和Microsoft.Extensions.Options
其实没什么关系,不能用IOptions<TOptions>
拿到,只是恰巧都叫XxxxxxOptions
而已每次新构造 DbContextOptions 实例时,都会使用传入的
Action<IServiceProvider, DbContextOptionsBuilder>
函数;此时第一个参数显然是当前的依赖注入容器,例如发生 HTTP 请求时HttpContext.RequestService
的容器 Scope;或者 DbContextOptions 单例注入时,IHost.Services
这种容器根实际构建结果是由
CreateDbContextOptions
函数创造的
那么再来看看 CreateDbContextOptions
的实现。
private static DbContextOptions<TContext> CreateDbContextOptions<TContext>([NotNull] IServiceProvider applicationServiceProvider,[CanBeNull] Action<IServiceProvider, DbContextOptionsBuilder> optionsAction)where TContext : DbContext
{var builder = new DbContextOptionsBuilder<TContext>(new DbContextOptions<TContext>(new Dictionary<Type, IDbContextOptionsExtension>()));builder.UseApplicationServiceProvider(applicationServiceProvider);optionsAction?.Invoke(applicationServiceProvider, builder);return builder.Options;
}
C#
Copy
可以看到,DbContextOptionsBuilder.UseApplicationServiceProvider
实际上是被执行过的,并且恰好指向父依赖注入容器。
此时会发现,我们在单元测试时,不创建依赖注入容器而直接实例化 DbContext 的时候,是没有这一步的。这就是为什么两者有时表现不同,例如直接实例化 Builder 拿到 Options,并且没有 UseLoggerFactory
和 UseApplicationServiceProvider
时,它不会有日志输出。至于日志那部分是怎么构建的呢,暂且按下不表。
而我们会看到网上有些文章说,因为某某原因,选择 services.AddEntityFrameworkSqlServer()
然后 options.UseInternalServiceProvider(..)
的,其实是将两个依赖注入容器合二为一了。具体好坏,还是使用者自行定夺。
DbContext 实例化时做了些什么?
看到上面那个图了吗。我们会发现,原来 EFCore 的内部容器也是分 Singleton 和 Scoped 的。
先来看看 DbContext 的这样一个 private 成员属性 InternalServiceProvider。
private IServiceProvider InternalServiceProvider
{get{CheckDisposed();if (_contextServices != null){return _contextServices.InternalServiceProvider;}if (_initializing){throw new InvalidOperationException(CoreStrings.RecursiveOnConfiguring);}try{_initializing = true;var optionsBuilder = new DbContextOptionsBuilder(_options);OnConfiguring(optionsBuilder);if (_options.IsFrozen&& !ReferenceEquals(_options, optionsBuilder.Options)){throw new InvalidOperationException(CoreStrings.PoolingOptionsModified);}var options = optionsBuilder.Options;_serviceScope = ServiceProviderCache.Instance.GetOrAdd(options, providerRequired: true).GetRequiredService<IServiceScopeFactory>().CreateScope();var scopedServiceProvider = _serviceScope.ServiceProvider;var contextServices = scopedServiceProvider.GetService<IDbContextServices>();contextServices.Initialize(scopedServiceProvider, options, this);_contextServices = contextServices;DbContextDependencies.InfrastructureLogger.ContextInitialized(this, options);}finally{_initializing = false;}return _contextServices.InternalServiceProvider;}
}
C#
Copy
可以观察到如下事实:
除了外部的
DbContextOptions
实例,内部可能也会用OnConfiguring
函数修改这个 Options,这样保证了两者的配置都会被应用;当使用DbContextPool
时,内部函数是不能修改配置的DbContext 的每个执行指令都是在内部容器的一个 Service Scope 中执行
每次创建 Service Scope 之后,会取出其中 Scoped 服务
IDbContextServices
,并将这个 DbContext 实例和 DbContextOptions 保存进这个 Service Scope内部容器的获取是由
ServiceProviderCache.Instance.GetOrAdd(options, providerRequired: true)
操作的;此时拿到的一般都是内部容器的根容器
这个 ServiceProviderCache
的源码处于 src\EFCore\Internal\ServiceProviderCache.cs
。
在解析 GetOrAdd
函数之前,我们需要了解这样一个结构:IDbContextOptionsExtension
。这个结构具有几个基本功能:
向依赖注入容器注册依赖服务
验证当前
IDbContextOptions
是否正确配置,是否具有冲突告诉 EFCore 该拓展是否提供数据库底层功能(即 Database Provider,例如提供 SQL Server 相关依赖、数据库连接信息等)
提供调试信息、日志片段(就是初始化 DbContext 时出现的类似
initialized 'MyDbContext' using provider 'Microsoft.EntityFrameworkCore.SqlServer' with options:...
的地方添加的)实现函数
long GetServiceProviderHashCode()
,当这个 EFCore 插件包括某些不太方便通过 Scoped 服务修改的 Singleton 信息时(例如 SensitiveDataLoggingEnabled),这里应该返回一个与这些配置有关的值,同时保证:对于相同的配置,返回相同的值;对于不同的配置,返回不同的值。
例如 DbContextOptionsBuilder 中很多函数都是修改 CoreOptionsExtension
完成的。
再看看 EFCore 的内部容器中有哪些类,其对应生命周期是什么样的。此处建议参考 src/EFCore/Infrastructure/EntityFrameworkServicesBuilder.cs
。这个代码文件中规定了每个类的生命周期,以及是否可以注册多个。
可以注意到,有这样一些类有着对应的生命周期:
Singleton:
- IDatabaseProvider
- IDbSetFinder
- IModelCustomizer
- ILoggingOptions
- IMemoryCacheScoped:
- IInterceptors
- ILoggerFactory
- IModel
- IDbContextServices
- IChangeTrackerFactory
- IDiagnosticsLogger<>
- IQueryCompiler
- IQueryContextFactory
- IAsyncQueryProvider
- ICurrentDbContext
- IDbContextOptions
接下来看拿到内部容器的逻辑。
public virtual IServiceProvider GetOrAdd([NotNull] IDbContextOptions options, bool providerRequired)
{var coreOptionsExtension = options.FindExtension<CoreOptionsExtension>();var internalServiceProvider = coreOptionsExtension?.InternalServiceProvider;if (internalServiceProvider != null){ValidateOptions(options);var optionsInitializer = internalServiceProvider.GetService<ISingletonOptionsInitializer>();if (optionsInitializer == null){throw new InvalidOperationException(CoreStrings.NoEfServices);}if (providerRequired){optionsInitializer.EnsureInitialized(internalServiceProvider, options);}return internalServiceProvider;}if (coreOptionsExtension?.ServiceProviderCachingEnabled == false){return BuildServiceProvider().ServiceProvider;}var key = options.Extensions.OrderBy(e => e.GetType().Name).Aggregate(0L, (t, e) => (t * 397) ^ ((long)e.GetType().GetHashCode() * 397) ^ e.Info.GetServiceProviderHashCode());return _configurations.GetOrAdd(key, k => BuildServiceProvider()).ServiceProvider;(IServiceProvider ServiceProvider, IDictionary<string, string> DebugInfo) BuildServiceProvider(){... 此处省略}
}
C#
Copy
嗯,这个逻辑很好盘,而且 99.99% 的情况下大家都只使用了默认配置,即:通过 GetServiceProviderHashCode
函数来计算哈希值,然后从 ServiceProviderCache
内部的一个缓存表中取得之前创建的容器,或者构建一个新的容器。
我们可能会发现,第一次使用 DbContext 的时候,加载时间很长;经过两三秒才能实例化完成;第二次使用的时候,基本上就是瞬间实例化成功了。但我们通过在上层依赖注入容器的 AddDbContext
处做手脚,或者通过重写 OnConfiguring
函数,更改了 DbContextOptions
之后,或者实例化另一个不同类型的 DbContext,又会花很久时间才能实例化成功。应证了上面的说法。
如果每次构建 DbContext 实例时都创建一个全新的内部容器,这样会有大量的性能浪费。
那么我们再来观察一下 DbContextOptionsBuilder
有哪些方法。
- UseSqlServer / UseNpgSql / UseInMemoryDatabase
- Use第三方插件1/2/3
- EnableDetailedErrors
- UseInternalServiceProvider
- EnableSensitiveDataLogging
- EnableServiceProviderCaching
- ConfigureWarnings
- UseMemoryCache
- ReplaceService
--- 一条朴实无华的分割线 ---
- UseModel
- UseLoggerFactory
- UseApplicationServiceProvider
- UseQueryTrackingBehavior
- AddInterceptors
CoreOptionsExtension
的 long GetServiceProviderHashCode()
会包括 IMemoryCache
、SensitiveDataLoggingEnabled
、DetailedErrorsEnabled
、WarningsConfiguration
、通过 ReplaceService
修改的那些服务。
可以注意到,其中有些控制的是 Singleton 服务或者决定了实例化的结果,例如 UseMemoryCache
、UseSqlServer
、ReplaceService
,如果每次拿到的 DbContextOptions
实例中的 IMemoryCache
或者数据库类型不一样,那么此时肯定需要构建一个新的依赖注入容器。而有些东西控制的是 Scoped 服务,例如 UseLoggerFactory
、UseModel
、数据库连接字符串,在一般场景下是不需要重新构建容器的。
也就是说,如果不动态改变分割线上方的那些状态,并且你使用的第三方插件编写很科学,是不会每次都构建新的内部容器的。
内部容器如何取得 ILoggerFactory?
内部的服务当然是从内部容器构建的了。
先以 ILoggerFactory
为例,看看为什么 EFCore 能拿到父容器的 ILoggerFactory
。
回到上面 EntityFrameworkServicesBuilder
,我们可以看到一行
TryAdd<ILoggerFactory>(p => ScopedLoggerFactory.Create(p, null));
C#
Copy
转到这个函数,我们可以看到
public static ScopedLoggerFactory Create([NotNull] IServiceProvider internalServiceProvider,[CanBeNull] IDbContextOptions contextOptions)
{var coreOptions= (contextOptions ?? internalServiceProvider.GetService<IDbContextOptions>())?.FindExtension<CoreOptionsExtension>();if (coreOptions != null){if (coreOptions.LoggerFactory != null){return new ScopedLoggerFactory(coreOptions.LoggerFactory, dispose: false);}var applicationServiceProvider = coreOptions.ApplicationServiceProvider;if (applicationServiceProvider != null&& applicationServiceProvider != internalServiceProvider){var loggerFactory = applicationServiceProvider.GetService<ILoggerFactory>();if (loggerFactory != null){return new ScopedLoggerFactory(loggerFactory, dispose: false);}}}return new ScopedLoggerFactory(new LoggerFactory(), dispose: true);
}
C#
Copy
即:先看 CoreOptionsExtension
中是否有之前 optionsBuilder.UseLoggerFactory
指定的;如果没有,再到 ApplicationServiceProvider
中找一个 ILoggerFactory
;再如果真的没有,就不用了。
回顾开头的内存溢出问题:为什么呢?
DbContextOptions
未经修改的默认生命周期是 Scoped,也就是在父容器中每次实例化一个 DbContextOptions
,就会调用一次 LoggerFactory.Create(b => b.AddConsole())
,并且并没有照顾到它的 Dispose。而 ConsoleLoggerProvider
每次会建立一个新的线程去输出日志,没有被回收,于是……内存就在一次又一次请求中消耗殆尽了。
再回过来想想,既然能调用到父容器的 ILoggerFactory
,他又为什么会用 LoggerFactory.Create
呢?……一定是 Microsoft.EntityFrameworkCore
开头的日志被父容器的设置禁用了,所以没有输出。
如何把玩其他内部服务?
观察到 DbContext
实现了 IInfrastructure<IServiceProvider>
这一接口,这个接口要求保存一个 IServiceProvider
的实例,而其实现直接指向了 InternalServiceProvider
这一私有属性。
那先谈谈这个 IInfrastructure<IServiceProvider>
接口的作用吧。这个接口同时在 DbSet<T>
和 DatabaseFacade
中也有实现。在 Microsoft.EntityFrameworkCore.Infrastructure.AccessorExtensions
中,我们有一个针对这个接口的拓展函数 TService GetService<TService>([NotNull] this IInfrastructure<IServiceProvider> accessor)
。
也就是说,我们在引入 Microsoft.EntityFrameworkCore.Infrastructure
命名空间之后,可以通过 DbContext.GetService<T>()
来拿到一部分服务。
其进一步的查找逻辑为:先在 EFCore 内部直接使用的依赖注入容器(即 InternalServiceProvider
)中查找,再去上一层依赖注入容器中查找。
这个函数在 EFCore 中用的很少,基本上只用于静态函数,或者非静态函数中传入 DbContext 实例时需要拿到某个服务时才会用到。
例如,如果是在写某个 EFCore 的拓展函数,传入只有 DbSet<T>
的实例,但我们想拿到这个 DbContext
,不用反射之类的奇怪功能,要如何拿到呢?通常可以用 dbSetInstance.GetService<ICurrentDbContext>().Context
拿到实例。
好了,容器都拿到了,该咋玩咋玩吧……
课后习题
已知数据库模型是通过 IModelCustomizer
进行构建的,需要达到这样的效果:
一个模块化的应用
每个模块可以向父容器注册很多个功能类似于
Action<ModelBuilder>
的东西希望在构建数据库的
IModel
时,对着ModelBuilder
执行这些操作
这样可以不修改 DbContext 本身的代码,而将所需的实体信息加载到 DbContext 的 Model 里。
参考答案:IDbModelSupplier设计 + AddDbContext部分