细聊.Net Core中IServiceScope的工作方式

前言

    自从.Net Core引入IOC相关的体系之后，关于它的讨论就从来没有停止过，因为它是.Net Core体系的底层框架，你只要使用了.Net Core的时候就必然会用到它。当然关于使用它的过程中产生的问题也从来没停止过。我对待问题的态度向来都是，如果你踩到了坑，说明你还没有足够了解它，所以我们对它认知的突破，很多时候是遇到了问题并解决了问题。今天的话题呢，也是一个群友在研究.Net Core作用域的过程中产生的疑问，博主呢对这个问题也很有兴趣，就借此机会探究了一下，把自己研究结果分享给大家。

简单演示

在日常的开发中使用CreateScope()或CreateAsyncScope()的场景可能没有那么多，但是在ASP.NET Core底层的话这是核心设计，在上篇文章中提到过，ASP.NET Core会为每次请求创建一个Scope,也就是咱们这次提到的作用域。使用的方法有很简单，本质就是IServiceProvider的一个扩展方法。咱们今天主要说的就是ServiceLifetime.Scoped这个比较特殊的生命周期，在Scope内是如何工作的，原始点的写法其实就是

IServiceCollection services = new ServiceCollection();
services.AddScoped(provider => new() { Id = 1, Name = "yi念之间", Sex = "Man" });

IServiceProvider serviceProvider = services.BuildServiceProvider();
using (IServiceScope serviceScope = serviceProvider.CreateScope())
{
    var personOne = serviceScope.ServiceProvider.GetService();
    Console.WriteLine(person.Name);
}

如果在ASP.NET Core框架里那玩法就多了，只要有IServiceProvide的地方都可以使用CreateScope()或CreateAsyncScope()方法，简单演示一下，但是如果感觉自己把握不住的话还是提前自己试验一下

[HttpGet]
public async Task JudgeScope([FromServices]IServiceProvider scopeProvider)
{
    using IServiceScope scope = HttpContext.RequestServices.CreateScope();
    Person person = scope.ServiceProvider.GetService();

    await using (AsyncServiceScope scope2 = scopeProvider.CreateAsyncScope())
    {
        Person person2 = scope2.ServiceProvider.GetService();
    }
    return person;
}


源码探究


通过上面的示例，我们可以看到其实关于IServiceScope的操作部分就是三个核心。


    

  • 通过CreateScope()或CreateAsyncScope()方法创建服务作用域。
    • 

  • 使用GetService相关的方法创建需要的对象实例。
    • 

  • 用完了作用域之后通过使用Dispose()或者DisposeAsync()方法(using的方式同理)释放作用域。
    • 



先说AsyncServiceScope


为了怕大家心里有疑虑，因为使用CreateScope()方法创建出来的是IServiceScope实例，使用CreateAsyncScope方法创建的是AsyncServiceScope实例。咱们这里先来说一下AsyncServiceScope和IServiceScope的关系，看了之后大家就不用惦记它了,先来看一下CreateAsyncScope()方法的定义[点击查看源码??]


public static AsyncServiceScope CreateAsyncScope(this IServiceProvider provider)
{
    return new AsyncServiceScope(provider.CreateScope());
}



方法就是返回AsyncServiceScope实例,接下来来看一下这个类的定义[点击查看源码??]


public readonly struct AsyncServiceScope : IServiceScope, IAsyncDisposable
{
    private readonly IServiceScope _serviceScope;

    public AsyncServiceScope(IServiceScope serviceScope)
    {
        //AsyncServiceScope也是IServiceScope实例构建起来的
        _serviceScope = serviceScope ?? throw new ArgumentNullException(nameof(serviceScope));
    }

    //ServiceProvider也是直接在IServiceScope实例中直接获取的
    public IServiceProvider ServiceProvider => _serviceScope.ServiceProvider;

    //同步释放
    public void Dispose()
    {
        _serviceScope.Dispose();
    }

    //异步释放
    public ValueTask DisposeAsync()
    {
        //因为IAsyncDisposable的ServiceProvider能继续创建作用域
        //使用CreateScope或CreateAsyncScope方法
        if (_serviceScope is IAsyncDisposable ad)
        {
            return ad.DisposeAsync();
        }
        _serviceScope.Dispose();

        return default;
    }
}



通过源码我们可以看到AsyncServiceScope本身是包装了IServiceScope实例，它本身也是实现了IServiceScope接口并且同时IAsyncDisposable接口以便可以异步调用释放。相信大家都知道，实现了IDispose接口可以使用using IServiceScope scope = HttpContext.RequestServices.CreateScope()的方式，它编译完之后其实是


IServiceScope scope = HttpContext.RequestServices.CreateScope();
try
{
  //具体操作
}
finally
{
    scope.Dispose();
}



实现了IAsyncDisposable接口可以使用await using (AsyncServiceScope scope2 = scopeProvider.CreateAsyncScope())的方式，它编译完的代码则是


AsyncServiceScope scope2 = scopeProvider.CreateAsyncScope();
try
{
  //具体操作
}
finally
{
    await scope2.DisposeAsync();
}



打消了这个疑虑，相信大家对它们的关系有了了解，本质就是包装了一下IServiceScope实例。


由创建开始


接下来我们可以专心的看一下IServiceScope相关的实现，IServiceScope的创建则是来自IServiceProvider的扩展方法CreateScope()，首先看下它的定义[点击查看源码??]


public static IServiceScope CreateScope(this IServiceProvider provider)
{
    return provider.GetRequiredService().CreateScope();
}



好吧，短短的一行代码，我们可以得到两个比较重要的信息


    

  • 首先获取到的IServiceScopeFactory实例，看过上篇文章的可以知道，默认情况通过IServiceScopeFactory实例获取的是根容器的实例。
    • 

  • 其次IServiceProvider的CreateScope扩展方法，本质是调用的IServiceScopeFactory的CreateScope方法。
    • 



接下来我们就看看下IServiceScopeFactory默认实现类中关于CreateScope()方法的定义，在ServiceProviderEngineScope类中[点击查看源码??]


internal ServiceProvider RootProvider { get; }
public IServiceScope CreateScope() => RootProvider.CreateScope();



这里毫无疑问了RootProvider属性里的实例都是来自根容器，而CreateScope()方法则是调用的ServiceProvider的CreateScope()方法。看下ServiceProvider类的CreateScope方法定义

[点击查看源码??]


private bool _disposed;
internal IServiceScope CreateScope()
{
    //判断当前ServiceProvider是否被释放
    if (_disposed)
    {
        //如果已经释放则直接抛出异常
        ThrowHelper.ThrowObjectDisposedException();
    }
    //创建ServiceProviderEngineScope实例
    return new ServiceProviderEngineScope(this, isRootScope: false);
}



通过上面的代码我们可以看到CreateScope()方法，本质是创建了一个ServiceProviderEngineScope方法实例。通过创建的这一行代码，好巧不巧又可以得到两个重要的信息。


    

  • 一是ServiceProviderEngineScope构造函数的第一个参数，传递的是当前的ServiceProvider实例。
    • 

  • 二是ServiceProviderEngineScope构造函数的第二个参数叫isRootScope值给的是false，说明当前ServiceProviderEngineScope实例不是根作用域，也就是我们说的子作用域。
    • 



大致看一下ServiceProviderEngineScope构造函数的实现[点击查看源码??]


internal sealed class ServiceProviderEngineScope : IServiceScope, IServiceProvider, IAsyncDisposable, IServiceScopeFactory
{
    internal Dictionary ResolvedServices { get; }
    internal object Sync => ResolvedServices;
    internal ServiceProvider RootProvider { get; }
    public bool IsRootScope { get; }
    //IServiceProvider的ServiceProvider属性则是赋值的当前实例
    public IServiceProvider ServiceProvider => this;
    public ServiceProviderEngineScope(ServiceProvider provider, bool isRootScope)
    {
        //用来存储当前作用域管理的对象实例
        ResolvedServices = new Dictionary();
        //创建当前实例的根容器
        RootProvider = provider;
        //标识当前作用域是否是根容器
        IsRootScope = isRootScope;
    }
}



下大致看一下，因为接下来会涉及到ServiceProviderEngineScope这个类。到目前为止涉及到了两个比较重要的类ServiceProvider和ServiceProviderEngineScope，它们都是实现了IServiceProvider接口。看起来有点乱的样子，不过我们可以姑且这么理解。ServiceProvider是IServiceProvider的直系实现类，作为IServiceProvider根容器的实现。ServiceProviderEngineScope是用于，通过IServiceProvider创建作用域时表现出来的实例，也就是非根容器的实例。


探究获取方法


关于上面的介绍，我们其实探究了一点serviceProvider.CreateScope(),接下来我们就需要看一下关于获取的相关操作，也就是GetService方法相关，它的使用形式是serviceScope.ServiceProvider.GetService()。上面我们提到过ServiceProviderEngineScope的ServiceProvider属性实例则是当前ServiceProviderEngineScope的实例，所以我们直接去看ServiceProviderEngineScope的GetService方法[点击查看源码??]


internal sealed class ServiceProviderEngineScope : IServiceScope, IServiceProvider, IAsyncDisposable, IServiceScopeFactory
{
    private bool _disposed;
    internal ServiceProvider RootProvider { get; }
    public object GetService(Type serviceType)
    {
        //判断当前实例是否释放
        if (_disposed)
        {
            //如果已经释放则直接抛出异常
            ThrowHelper.ThrowObjectDisposedException();
        }

        return RootProvider.GetService(serviceType, this);
    }
}



看着挺乱的，各种跳转各种调用。不过本质只设计到两个类ServiceProvider和ServiceProviderEngineScope，先说明一下，省的大家看着整蒙圈了。通过最后一句代码，我们又能得到两个比较重要的信息。


    

  • ServiceProviderEngineScope的GetService方法，本质是在调用RootProvider的GetService方法。通过前面咱们的源码分析可以知道RootProvider属性的值是ServiceProvider实例也就是代表的根容器。
    • 

  • 调用RootProvider的GetService方法的时候传递了当前ServiceProviderEngineScope实例。
    • 



接下来就可以直接找到ServiceProvider的GetService方法了，看一下里面的具体相关实现[点击查看源码??]


public sealed class ServiceProvider : IServiceProvider, IDisposable, IAsyncDisposable
{
    private bool _disposed;
    private ConcurrentDictionary> _realizedServices;
    private readonly Func> _createServiceAccessor;
    internal ServiceProviderEngine _engine;

    internal ServiceProvider()
    {
      _createServiceAccessor = CreateServiceAccessor;
      _realizedServices = new ConcurrentDictionary>();
    }

    internal object GetService(Type serviceType, ServiceProviderEngineScope serviceProviderEngineScope)
    {
        //判断当前实例是否释放
        if (_disposed)
        {
            ThrowHelper.ThrowObjectDisposedException();
        }
        //缓存获取服务实例委托的字典，值为要获取实例的类型，值是创建实例的委托
        //_createServiceAccessor本质是CreateServiceAccessor方法委托
        Func realizedService = _realizedServices.GetOrAdd(serviceType, _createServiceAccessor);
        OnResolve(serviceType, serviceProviderEngineScope);
        DependencyInjectionEventSource.Log.ServiceResolved(this, serviceType);
        //执行realizedService委托，传递的是ServiceProviderEngineScope实例
        var result = realizedService.Invoke(serviceProviderEngineScope);
        System.Diagnostics.Debug.Assert(result is null || CallSiteFactory.IsService(serviceType));
        return result;
    }

    private Func CreateServiceAccessor(Type serviceType)
    {
        //获取ServiceCallSite，其实就是获取要解析对象的实例相关信息
        ServiceCallSite callSite = CallSiteFactory.GetCallSite(serviceType, new CallSiteChain());
        if (callSite != null)
        {
            DependencyInjectionEventSource.Log.CallSiteBuilt(this, serviceType, callSite);
            OnCreate(callSite);
            //咱们当前讨论的是Scope周期对象的问题，这个方法描述的是生命周期为ServiceLifetime.Singleton的情况，可以跳过这个逻辑
            //如果是单例情况，则直接在根容器中直接去操作对象实例，和当前的ServiceProviderEngineScope无关
            if (callSite.Cache.Location == CallSiteResultCacheLocation.Root)
            {
                object value = CallSiteRuntimeResolver.Instance.Resolve(callSite, Root);
                return scope => value;
            }
            //解析ServiceCallSite里的信息
            return _engine.RealizeService(callSite);
        }

        return _ => null;
    }
}



这里我们看下CallSiteFactory.GetCallSite方法，先来说一下这个方法是做啥的。我们要获取某个类型的实例(可以理解为我们演示示例里的Person类)，但是我们注册类相关的信息的时候(比如上面的services.AddScoped(provider => new() { Id = 1, Name = "yi念之间", Sex = "Man" }))涉及到几种方式，比如AddScoped和Add(Func)，我们需要知道创建类型实例的时候使用哪种方式(比如我们的Person是使用委托的这种方式)，ServiceCallSite正是存储的类型和如何创建这个类型的工厂相关的信息。我们来看一下GetCallSite方法的核心操作[点击查看源码??]


private readonly ConcurrentDictionary _callSiteCache = new ConcurrentDictionary();

private ServiceCallSite TryCreateExact(ServiceDescriptor descriptor, Type serviceType, CallSiteChain callSiteChain, int slot)
{
    if (serviceType == descriptor.ServiceType)
    {
        //要获取的类型会被包装成ServiceCacheKey
        ServiceCacheKey callSiteKey = new ServiceCacheKey(serviceType, slot);
        //在缓存中获取ServiceCallSite实例，可以理解为设计模式中的享元模式
        if (_callSiteCache.TryGetValue(callSiteKey, out ServiceCallSite serviceCallSite))
        {
            return serviceCallSite;
        }

        ServiceCallSite callSite;
        //根据ServiceDescriptor.Lifetime包装ResultCache
        var lifetime = new ResultCache(descriptor.Lifetime, serviceType, slot);
        //ServiceDescriptor就是我们添加到IServiceCollection的最终形式
        //我们注册服务的时候本质就是在IServiceCollection里添加ServiceDescriptor实例

        //AddScope()这种形式
        if (descriptor.ImplementationInstance != null)
        {
            callSite = new ConstantCallSite(descriptor.ServiceType, descriptor.ImplementationInstance);
        }
        //AddScope(Func)形式
        else if (descriptor.ImplementationFactory != null)
        {
            callSite = new FactoryCallSite(lifetime, descriptor.ServiceType, descriptor.ImplementationFactory);
        }
        //AddScope()形式
        else if (descriptor.ImplementationType != null)
        {
            callSite = CreateConstructorCallSite(lifetime, descriptor.ServiceType, descriptor.ImplementationType, callSiteChain);
        }
        else
        {
            throw new InvalidOperationException(SR.InvalidServiceDescriptor);
        }
        //将创建的ServiceCallSite缓存起来
        return _callSiteCache[callSiteKey] = callSite;
    }
    return null;
}



而解析ServiceCallSite实例的方法RealizeService(ServiceCallSite)则是在ServiceProviderEngine类中，看一下相关实现[点击查看源码??]


 public override Func RealizeService(ServiceCallSite callSite)
{
    int callCount = 0;
    return scope =>
    {
        //核心代码是Resolve方法,这里的scope则是ServiceProviderEngineScope
        //即我们上面通过CreateScope()创建的实例
        var result = CallSiteRuntimeResolver.Instance.Resolve(callSite, scope);
        if (Interlocked.Increment(ref callCount) == 2)
        {
            _ = ThreadPool.UnsafeQueueUserWorkItem(_ =>
            {
                try
                {
                    _serviceProvider.ReplaceServiceAccessor(callSite, base.RealizeService(callSite));
                }
                catch (Exception ex)
                {
                   //省略掉非核心代码
                }
            },
            null);
        }
        return result;
    };
}



上面我们看到的RealizeService()方法返回的是一个委托，而调用这个委托的地方则是上面源码中看到的realizedService.Invoke(serviceProviderEngineScope)，核心操作在CallSiteRuntimeResolver.Instance.Resolve()方法，Resolve方法的核心逻辑在VisitCallSite()方法，看一下它的实现方式[点击查看源码??]


protected virtual TResult VisitCallSite(ServiceCallSite callSite, TArgument argument)
{
    if (!_stackGuard.TryEnterOnCurrentStack())
    {
        return _stackGuard.RunOnEmptyStack((c, a) => VisitCallSite(c, a), callSite, argument);
    }

    switch (callSite.Cache.Location)
    {
        //ServiceLifetime.Singleton单例情况
        case CallSiteResultCacheLocation.Root:
            return VisitRootCache(callSite, argument);
        //ServiceLifetime.Scoped作用域情况，也就是咱们关注的情况
        case CallSiteResultCacheLocation.Scope:
            return VisitScopeCache(callSite, argument);
        //ServiceLifetime.Transient瞬时情况
        case CallSiteResultCacheLocation.Dispose:
            return VisitDisposeCache(callSite, argument);
        case CallSiteResultCacheLocation.None:
            return VisitNoCache(callSite, argument);
        default:
            throw new ArgumentOutOfRangeException();
    }
}



因为我们关注的是CallSiteResultCacheLocation.Scope这种情况所以我们重点关注的是VisitScopeCache()这段方法逻辑，CallSiteRuntimeResolver的VisitCache()方法[点击查看源码??]


protected override object VisitScopeCache(ServiceCallSite callSite, RuntimeResolverContext context)
{
    //咱们关注的是Scope的情况，所以重点在VisitCache方法
    return context.Scope.IsRootScope ?
        VisitRootCache(callSite, context) :
        VisitCache(callSite, context, context.Scope, RuntimeResolverLock.Scope);
}

//这里的serviceProviderEngine参数就是我们传递进来的ServiceProviderEngineScope实例
private object VisitCache(ServiceCallSite callSite, RuntimeResolverContext context, ServiceProviderEngineScope serviceProviderEngine, RuntimeResolverLock lockType)
{
    bool lockTaken = false;
    //获取ServiceProviderEngineScope的Sync属性
    object sync = serviceProviderEngine.Sync;
    //获取ServiceProviderEngineScope的ResolvedServices属性
    Dictionary resolvedServices = serviceProviderEngine.ResolvedServices;
    //加锁
    if ((context.AcquiredLocks & lockType) == 0)
    {
        Monitor.Enter(sync, ref lockTaken);
    }

    try
    {
        //判断ServiceProviderEngineScope的ResolvedServices的属性里是否包含该类型实例
        //当前作用域内只有一个实例，所以缓存起来
        if (resolvedServices.TryGetValue(callSite.Cache.Key, out object resolved))
        {
            return resolved;
        }
        
        //当前Scope没创建过实例的话则创建
        resolved = VisitCallSiteMain(callSite, new RuntimeResolverContext
        {
            Scope = serviceProviderEngine,
            AcquiredLocks = context.AcquiredLocks | lockType
        });
        //判断当前类型实例是否是IDispose想实例
        serviceProviderEngine.CaptureDisposable(resolved);
        //给ServiceProviderEngineScope的ResolvedServices的属性添加缓存实例
        resolvedServices.Add(callSite.Cache.Key, resolved);
        return resolved;
    }
    finally
    {
        if (lockTaken)
        {
            Monitor.Exit(sync);
        }
    }
}

protected virtual TResult VisitCallSiteMain(ServiceCallSite callSite, TArgument argument)
{
    //比如我们上面的services.AddScoped(provider => new() { Id = 1, Name = "yi念之间", Sex = "Man" })
    //对应的Kind则是CallSiteKind.Factory
    switch (callSite.Kind)
    {
        case CallSiteKind.Factory:
            //调用了VisitFactory方法
            return VisitFactory((FactoryCallSite)callSite, argument);
        case  CallSiteKind.IEnumerable:
            return VisitIEnumerable((IEnumerableCallSite)callSite, argument);
        case CallSiteKind.Constructor:
            return VisitConstructor((ConstructorCallSite)callSite, argument);
        case CallSiteKind.Constant:
            return VisitConstant((ConstantCallSite)callSite, argument);
        case CallSiteKind.ServiceProvider:
            return VisitServiceProvider((ServiceProviderCallSite)callSite, argument);
        default:
            throw new NotSupportedException(SR.Format(SR.CallSiteTypeNotSupported, callSite.GetType()));
    }
}

protected override object VisitFactory(FactoryCallSite factoryCallSite, RuntimeResolverContext context)
{
  //调用我们注册的services.AddScoped(provider => new() { Id = 1, Name = "yi念之间", Sex = "Man" })
  //FactoryCallSite的Factory即是provider => new() { Id = 1, Name = "yi念之间", Sex = "Man" }
  //context.Scope则是我们通过CreateScope创建的实例
  //返回的结果就是调用当前委托得到的实例即我们实例中的Person实例
  return factoryCallSite.Factory(context.Scope);
}



回过头来说一下咱们上面展示的代码，被调用执行的地方就是GetService方法里的realizedService.Invoke(serviceProviderEngineScope)的这段代码。上面的执行逻辑里涉及到了ServiceProviderEngineScope里的几个操作，比如ResolvedServices属性和CaptureDisposable()方法，看一下相关的代码


internal sealed class ServiceProviderEngineScope : IServiceScope, IServiceProvider, IAsyncDisposable, IServiceScopeFactory
{
    internal IList Disposables => _disposables ?? (IList)Array.Empty();
    private bool _disposed;
    private List _disposables;
    internal Dictionary ResolvedServices { get; }
    public ServiceProviderEngineScope(ServiceProvider provider, bool isRootScope)
    {
        ResolvedServices = new Dictionary();
    }

    internal object CaptureDisposable(object service)
    {
        //判断实例是否实现了IDisposable或IAsyncDisposable接口，因为这种需要在当前作用域是否的时候一起释放
        if (ReferenceEquals(this, service) || !(service is IDisposable || service is IAsyncDisposable))
        {
            return service;
        }

        bool disposed = false;
        lock (Sync)
        {
            //判断当前作用域是否释放
            if (_disposed)
            {
                disposed = true;
            }
            else
            {   //如果满足则添加到_disposables待释放集合，以便作用域释放的时候一起释放
                _disposables ??= new List();
                _disposables.Add(service);
            }
        }
        
        //如果当前作用域已经被释放则直接释放当前实例
        if (disposed)
        {
            //前提是服务实例是实现IDisposable或IAsyncDisposable接口的
            if (service is IDisposable disposable)
            {
                disposable.Dispose();
            }
            else
            {
                Task.Run(() => ((IAsyncDisposable)service).DisposeAsync().AsTask()).GetAwaiter().GetResult();
            }

            ThrowHelper.ThrowObjectDisposedException();
        }

        return service;
    }
}


上面关于ServiceProviderEngineScope类中涉及到GetService()方法的相关逻辑已经展示的差不多了，涉及到的比较多，而且看着比较乱。不过如果理解了思路还是比较清晰的，咱们来做一下一个大概的总结。


    

  • 首先，需要获取ServiceCallSite，在方法GetCallSite()中，其实就是获取要解析对象的实例相关信息。我们需要知道创建类型实例的时候使用哪种方式(比如我们的Person是使用委托的这种方式)，其中也包括该对象创建的类型、创建工厂、生命周期类型。
    • 

  • 然后，得到ServiceCallSite实例之后，我们就可以通过实例创建的信息去创建信息，在方法RealizeService()里。根据不同类型创建方式和生命周期，判断如何创建对象，即对象存放位置。
    • 

  • 最后，如果是单例模式，则在根容器中解析这个对象，位置当然也是存储在根容器中，全局唯一。如果是瞬时模式，则直接返回创建的对象实例，不进行任何存储，但是需要判断实例是否实现了IDisposable或IAsyncDisposable接口，如果是则加入当前ServiceProviderEngineScope实例的_disposables集合。如果是Scope模式就比较特殊了，因为Scope需要在当前ServiceProviderEngineScope中存储保证当前作用域唯一，则需要添加到ResolvedServices属性的字典里，同时也需要判断是否需要添加到_disposables集合里。
    • 



这就可以解释ServiceProviderEngineScope针对不同生命周期的存储方式了，单例的情况创建和存储都是在根容器中，瞬时的情况下则每次都创建新的实例且不进行存储，Scope的情况下则是存储在当前的ResolvedServices中享元起来可以在当前作用域内重复使用。


关于结束释放


前面咱们看了下关于作用域创建，在做用户获取对象的相关逻辑。接下来我们来看一下三件套的最后一个步骤，释放逻辑相关的。这个逻辑比较简单，上面咱们或多或少的也说过了一点，释放分为同步释放和异步释放两种情况，咱们看一下同步释放的相关实现[点击查看源码??]


internal Dictionary ResolvedServices { get; }
internal object Sync => ResolvedServices;
private bool _disposed;
private List _disposables;
public void Dispose()
{
    List toDispose = BeginDispose();

    if (toDispose != null)
    {
        for (int i = toDispose.Count - 1; i >= 0; i--)
        {   
            //模仿栈模式，最后创建的最先释放
            if (toDispose[i] is IDisposable disposable)
            {
                //释放的正式实现了IDisposable接口的对象
                disposable.Dispose();
            }
            else
            {
                throw new InvalidOperationException(SR.Format(SR.AsyncDisposableServiceDispose, TypeNameHelper.GetTypeDisplayName(toDispose[i])));
            }
        }
    }
}

private List BeginDispose()
{
    //本质就是锁住当前存储对象的集合，不允许进行任何操作
    lock (Sync)
    {
        //如果已经释放过了则直接返回
        if (_disposed)
        {
            return null;
        }

        DependencyInjectionEventSource.Log.ScopeDisposed(RootProvider.GetHashCode(), ResolvedServices.Count, _disposables?.Count ?? 0);
        //先把释放标识设置了
        _disposed = true;

    }
    //判断是否是根容器释放
    if (IsRootScope && !RootProvider.IsDisposed())
    {
        RootProvider.Dispose();
    }

    return _disposables;
}


其实主要逻辑就是循环释放_disposables里的所有对象，也就是实现了IDisposable接口的对象。接下来咱们再来看一下异步释放的相关逻辑。


public ValueTask DisposeAsync()
{
    List toDispose = BeginDispose();

    if (toDispose != null)
    {
        try
        {
            for (int i = toDispose.Count - 1; i >= 0; i--)
            {
                object disposable = toDispose[i];
                //判断是否是实现了IAsyncDisposable接口的对象
                if (disposable is IAsyncDisposable asyncDisposable)
                {
                    //获取DisposeAsync方法返回值也就是ValueTask
                    ValueTask vt = asyncDisposable.DisposeAsync();
                    if (!vt.IsCompletedSuccessfully)
                    {
                        return Await(i, vt, toDispose);
                    }
                    //阻塞等待DisposeAsync执行完成
                    vt.GetAwaiter().GetResult();
                }
                else
                {
                    ((IDisposable)disposable).Dispose();
                }
            }
        }
        catch (Exception ex)
        {
            return new ValueTask(Task.FromException(ex));
        }
    }

    return default;

    static async ValueTask Await(int i, ValueTask vt, List toDispose)
    {
        //等待DisposeAsync方法里的逻辑执行完成
        await vt.ConfigureAwait(false);
        i--;

        for (; i >= 0; i--)
        {
            object disposable = toDispose[i];

            if (disposable is IAsyncDisposable asyncDisposable)
            {
                //等待DisposeAsync执行完成
                await asyncDisposable.DisposeAsync().ConfigureAwait(false);
            }
            else
            {
                ((IDisposable)disposable).Dispose();
            }
        }
    }
}


其实核心逻辑和同步释放是一致的，只是IAsyncDisposable接口中的DisposeAsync()方法返回的异步相关的ValueTask所以需要进行一些等待相关的操作。不过本质都是循环释放_disposables里的数据，而这些数据正是当前作用域里里实现了IDisposable或IAsyncDisposable接口的实例。




使用CreateScope()或GetService()方法的时候，都会判断当前作用域是否释放，而这个标识正是在Dispose()或DisposeAsync()置为true的。我们上面文章中的那个异常的引发点也正是这里，也正是因为作用域被释放了表示为置为true了，所以GetService才会直接抛出异常。




群友问题解答


关于ServiceProviderEngineScope重要的相关实现，咱们上面已经大致的讲解过了。其实探索它的原动力就是因为群友遇到的一些关于这方面的疑问，如果了解了它的实现的话便能轻松的解除心中的疑问，还原一下当时有疑问的代码


IServiceCollection services = new ServiceCollection();
services.AddScoped(provider => new() { Id = 1, Name = "yi念之间", Sex = "Man" });

IServiceProvider serviceProvider = services.BuildServiceProvider();
Person person = null;
using (IServiceScope serviceScope = serviceProvider.CreateScope())
{
    person = serviceScope.ServiceProvider.GetService();
    Console.WriteLine(person.Name);
}
if (person == null)
{
    Console.WriteLine("Person被回收了");
}



代码大致描述的就是当时的这么一个场景，这里毫无疑问哈，完全判断不出来Person是否已经被回收。通过上面的源码咱们就可以知道，无论是掉用ServiceProviderEngineScope的是Dispose()或DisposeAsync()方法(using上面咱们说过了就是语法糖)，其实都是调用了当前作用域内实现了IDisposable或IAsyncDisposable接口的实例里的Dispose()或DisposeAsync()方法。


    

  • 即使当前实例实现了IDisposable或IAsyncDisposable接口，且调用了实例内的Dispose()或DisposeAsync()方法，也不意味着当前对象已经被释放了，因为我们用Dispose方法里多半是这个对象里引用的非托管代码的释放工作，并不意味这当前对象被释放了。
    • 

  • IServiceScope实现类ServiceProviderEngineScope里ResolvedServices属性享元的实例，也就是生命周期为ServiceLifetime.Scoped的实例。这些实例何时被回收是取决于两点，一是当前实例的访问是否超出当前作用域，二是当前对象是否有被引用。上面的示例中IServiceScope实例虽然已经超出作用了(因为在using括号之外了)，但是Person外出的栈里还引用着ResolvedServices字典里Person对象的实例，所以GC即垃圾回收机制并不会回收这个实例，因为它还在被引用。那就意味着它不能被释放，也就不存在Person实例被回收这么一说了。
    • 



所以，上面的问题说起来就是IServiceScope主要解决的是对象取的问题，也就是我用我的字典属性保留了需要保留的对象实例，可以释放被声明可以释放的操作(比如非托管资源的释放)。但是作用域本身的回收和内部管理的对象的回收是交给GC来负责的。




细想一下就会明白了，托管对象的回收本身就是垃圾回收处理的，就和你自己写单例模式或者直接new一个对象实例的时候，你也没考虑对象的回收问题，因为垃圾回收机制已经帮你处理了。




总结


    在.Net Core体系中IOC一直是核心模块，且关于Scope的作用域的问题，一直会有人产生疑问，想更深刻的了解一下还是得多拿一些时间研究一下。有些知识不是靠一时半会的学就能牢牢地掌握，需要日常不断的积累和不断的解决问题，才能掌握的更多。因为设计到的源码比较多，而且不熟悉的话可能不是很好理解，所以还需要平时的积累，积累的越多能解决的问题越多，才能避免入坑。好了大致总结一下


    

  • 当我们使用CreateScope()或CreateAsyncScope()创建出ServiceProviderEngineScope或AsyncServiceScope实例的时候，即我们通常描述的作用域。这个实例里包含了ResolvedServices属性和Disposables属性，分别保存当前作用域内即生命周期为ServiceLifetime.Scoped实例和实现了IDisposable或IAsyncDisposable接口的实例。
    • 

  • 使用GetService()方法在当前作用域内获取实例的时候，会根据服务注册时使用的生命周期判断是否加入到当前作用域里享元的实例。其中单例来自于根容器，瞬时的每次都需要创建新的实例所以不需要保存，只有生命周期为ServiceLifetime.Scoped才保存。瞬时的和Scope的对象创建出来的时候都会判断是否实现了IDisposable或IAsyncDisposable接口，如果是则加入到Disposables属性的集合里用于释放。
    • 

  • 当前作用域被释放的时候，即调用IServiceScope实例Dispose()相关方法的时候，会遍历Disposables集合里的对象进行Dispose相关方法调用，并不是回收托管到当前作用域内的对象，因为对象何时被回收取决于GC即垃圾回收机制。
    • 



好了到这里差不多，欢迎大家多多交流。寒冬已至，希望大家都有御寒的方法。分享一下看到过的一句话。你能得到的最牢靠的一定得是依靠你自身实力建立起来的，而不是你所处的平台建立起来的，因为依赖平台建立起来的，离开这个平台会打折。




  ??欢迎扫码关注我的公众号??
						  
					  
						
							


						

							
							
			.NETCoreDI源码探究							
						



						

						
						


						

						
					
					

					
					

						
相关

						

				
						
			

																
								

										
pycahrm 使用.editorconfig文件设置每行最大数量警告配置

									
									

								 

        

								

							
							

																
								

										
一、Asp.Net Core WebAPI——修改默认监听端口

									
									

								 

        

								

							
							

																
								

										
Managing Difficulties（处理困难）

									
									

								 

        

								

							
							

																
								

										
SuperEdge 和 FabEdge 联合在边缘 K8s 集群支持原生 Service 云边互访和 PodIP 直通

									
									

								 

        

								

							
							

																
								

										
google icons 的使用 和 css 设置图标为 loading 状态

									
									

								 

        

								

							
							

																
								

										
.net core 2.2 部署CentOS7（3）安装Xshell操控CentOS7

									
									

								 

        

								

							
							

																
								

										
.net core 部署在Centos 7/8 的几个小坑

									
									

								 

        

								

							
							

																
								

										
通俗易懂，什么是.NET?什么是.NET Framework？什么是.NET Core?

									
									

								 

        

								

							
							

																
								

										
C++11 并发指南五(std::condition_variable 详解)

									
									

								 

        

								

							
							

																
								

										
.NET Core3.1 Dotnetty实战第二章

									
									

								 

        

								

							
							

																
								

										
SLF4J: Class path contains multiple SLF4J bindings

									
									

								 

        

								

							
							

																
								

										
ceryx+redis实现nginx动态路由功能、动态管理upstream

									
									

								 

        

								

							
							
            
            
            
                                    
           
  			
						

					

					
				

				

														
					
					

					
									

					
									   
标签

										

										
    
										

									

										
										

									

					

					
				


			
		
		
		
			


						





	

	
一品网 冀ICP备14022925号-6