🌑

小羊儿的心情天空

我的博客 我的实验 友情链接

EFCore查缺补漏（一）：依赖注入

Feb 4, 2021 由 小羊

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

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

在这里可以看到：

  • 我们可以修改 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));
}

在这里可以看到：

  • 容器中可能具有很多个 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;
}

可以看到，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;
    }
}

可以观察到如下事实：

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

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

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

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部分

自豪地采用Hexo | 皖ICP备17014812号-1

GitHub LinkedIn Mail