EFCore查缺补漏(一):依赖注入

前段时间,在群里潜水的时候,看见有个群友的报错日志是这样的:

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()));
        });

        // ...
    }

    // ...
}

看,这个调用堆栈是不是对上味儿了。

接下来我将介绍这个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;
}

在这里可以看到:

  • 我们可以修改 DbContextOptionsDbContext 的生命周期为 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));
}

在这里可以看到:

  • 容器中可能具有很多个 DbContextOptions 实例,可以通过 IEnumerable<DbContextOptions> 拿到全部;这一设计是由于一个依赖注入容器中可以加入多个 DbContext 类型
  • 对于每一个特性类型的 DbContext (以下写为 MyDbContext),都会有一个 DbContextOptions<MyDbContext> 与之对应
  • 我们在构造函数处用到的 DbContextOptionsBuilderMicrosoft.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;
}

可以看到,DbContextOptionsBuilder.UseApplicationServiceProvider 实际上是被执行过的,并且恰好指向父依赖注入容器。

此时会发现,我们在单元测试时,不创建依赖注入容器而直接实例化 DbContext 的时候,是没有这一步的。这就是为什么两者有时表现不同,例如直接实例化 Builder 拿到 Options,并且没有 UseLoggerFactoryUseApplicationServiceProvider 时,它不会有日志输出。至于日志那部分是怎么构建的呢,暂且按下不表。

而我们会看到网上有些文章说,因为某某原因,选择 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;
    }
}

可以观察到如下事实:

  • 除了外部的 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
- IMemoryCache

Scoped:
- 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()
    {
        ... 此处省略
    }
}

嗯,这个逻辑很好盘,而且 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

CoreOptionsExtensionlong GetServiceProviderHashCode() 会包括 IMemoryCacheSensitiveDataLoggingEnabledDetailedErrorsEnabledWarningsConfiguration、通过 ReplaceService 修改的那些服务。

可以注意到,其中有些控制的是 Singleton 服务或者决定了实例化的结果,例如 UseMemoryCacheUseSqlServerReplaceService,如果每次拿到的 DbContextOptions 实例中的 IMemoryCache 或者数据库类型不一样,那么此时肯定需要构建一个新的依赖注入容器。而有些东西控制的是 Scoped 服务,例如 UseLoggerFactoryUseModel、数据库连接字符串,在一般场景下是不需要重新构建容器的。

也就是说,如果不动态改变分割线上方的那些状态,并且你使用的第三方插件编写很科学,是不会每次都构建新的内部容器的。

内部容器如何取得 ILoggerFactory?

内部的服务当然是从内部容器构建的了。

先以 ILoggerFactory 为例,看看为什么 EFCore 能拿到父容器的 ILoggerFactory

回到上面 EntityFrameworkServicesBuilder,我们可以看到一行

TryAdd<ILoggerFactory>(p => ScopedLoggerFactory.Create(p, null));

转到这个函数,我们可以看到

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);
}

即:先看 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部分

发表评论

电子邮件地址不会被公开。 必填项已用*标注