我的代码里将IServiceProvider放入ServiceLocator中遇到的问题。
注:以下所有例子都是Console里的结论,AspNetCore里不管怎么玩都没有问题,有其他帖子测试出在Asp.net Core里也存在问题,具体他怎么一个写法导致的没细研,在目前我自己项目中用到的范围内Web环境一切OK。
方案1:每次获取IServiceProvider 需要_services.BuildServiceProvider(); ;其中private static IServiceCollection _services; 为静态。
public static class ServiceLocator { private static IServiceCollection _services; public static IServiceProvider Instance { get { if (_services == null) return null; else return _services.BuildServiceProvider(); } } public static void Init(IServiceCollection services) { _services = services; } }
方案2:每次获取IServiceProvider 直接取IServiceProvider的静态属性; 其中public static IServiceProvider ServiceProvider { get; private set; }为静态。
public static class ServiceLocator { private static IServiceProvider _servicesProvider; public static IServiceProvider Instance { get { return _servicesProvider; } } public static void Init(IServiceCollection services) { _servicesProvider = services.BuildServiceProvider(); } }
EF6或dapper项目中使用Microsoft.Extensions.DependencyInjection1.0 时,用方案1正确,用方案2会出现内存泄露。
使用EF Core2.0时(强依赖于Microsoft.Extensions.DependencyInjection2.0),用方案2正确,用方案1会出现内存泄露。
使用EF Core2.0且用方案1时,可以把官方扩展方法AddDbContext替换为以下代码避免出现内存泄露:
var options = new DbContextOptionsBuilder<XXDbContext>().UseSqlServer("connstr").Options;
services.AddScoped(s => new XXDbContext(options)); 感谢Jeffcky提供此方法
目前我用EF Core2.0 ,使用了方案2,感觉存个静态的IServiceProvider也更合理。
刨根究底的事,等有空老衲深入研究下。
另:若使用像Orleans的Actor模型这类具有高度隔离性的东东,慎用Scoped级别的DbContext,一个DbContext同时跨多个Actor导致事务失效。