关于DbContext能不能单次请求内唯一？DbContex需不需要主动释放？欢迎各路大侠来“参战”！...

基于上篇文章《HiBlogs》重写笔记[1]--从DbContext到依赖注入再到自动注入园友 &＃64;Flaming丶淡蓝&＃64; 吴瑞祥 提出了讨论和质疑&＃xff0c;吓得我连夜查询资料&＃xff08;玩笑~&＃xff09;。
本来重点是想分析“自动注入”和对“注入”有更深的理解。不过既然有疑问和讨论那也是很好的。总比时不时来篇“这个不行”“那个要死了”的好。
之所以没有在评论区马上回复&＃xff0c;是因为我确实不懂。所以下班后赶紧查阅相关资料。
我个人得出来的结论是&＃xff1a;DbContext可以单次请求内唯一&＃xff0c;且可以不主动释放。&＃xff08;其实当时心里也纳闷了。asp.net core就是这么干的啊&＃xff0c;如果有问题还玩个毛线啊&＃xff09;
相关资料&＃xff1a;http://blog.jongallant.com/2012/10/do-i-have-to-call-dispose-on-dbcontext/
这篇资料博客应该还是有一定的权威性的&＃xff0c;内容是EF团队解释回应。

Hello Jon,
The default behavior of DbContext is that the underlying connection is automatically opened any time is needed and closed when it is no longer needed. E.g. when you execute a query and iterate over query results using “foreach”, the call to IEnumerable.GetEnumerator() will cause the connection to be opened, and when later there are no more results available, “foreach” will take care of calling Dispose on the enumerator, which will close the connection. In a similar way, a call to DbContext.SaveChanges() will open the connection before sending changes to the database and will close it before returning.
Given this default behavior, in many real-world cases it is harmless to leave the context without disposing it and just rely on garbage collection.
That said, there are two main reason our sample code tends to always use “using” or dispose the context in some other way:
1. The default automatic open/close behavior is relatively easy to override: you can assume control of when the connection is opened and closed by manually opening the connection. Once you start doing this in some part of your code, then forgetting to dipose the context becomes harmful, because you might be leaking open connections.
2. DbContext implements IDiposable following the recommended pattern, which includes exposing a virtual protected Dispose method that derived types can override if for example the need to aggregate other unmanaged resources into the lifetime of the context.
By the way, with DbContext the pattern to open the connection manually and override the automatic open/close behavior is a bit awkward:
((IObjectContextAdapter)dbContext).ObjectContext.Connection.Open()
But we have a bug to make this easier as it used to be with ObjectContext before, e.g.:
dbContext.Database.Connection.Open()
Hope this helps,
Diego

谷歌翻译如下&＃xff08;英文不行&＃xff0c;不知道翻译是否正确&＃xff09;&＃xff1a;

乔恩&＃xff0c;
DbContext的默认行为是底层连接在需要时自动打开&＃xff0c;并在不再需要时关闭。例如&＃xff0c;当您执行查询并使用“foreach”迭代查询结果时&＃xff0c;对IEnumerable .GetEnumerator&＃xff08;&＃xff09;的调用将导致打开连接&＃xff0c;并且稍后再没有可用的结果&＃xff0c;“foreach”将会关闭调用Dispose在枚举器上&＃xff0c;这将关闭连接。以类似的方式&＃xff0c;调用DbContext.SaveChanges&＃xff08;&＃xff09;将在将更改发送到数据库之前打开连接&＃xff0c;并在返回之前关闭它。
鉴于这种默认行为&＃xff0c;在许多现实世界的情况下&＃xff0c;离开上下文而不处理它&＃xff0c;只依靠垃圾回收是无害的。
也就是说&＃xff0c;我们的示例代码往往总是使用“使用”或以其他方式处理上下文的两个主要原因&＃xff1a;
1.默认的自动打开/关闭行为相对容易被覆盖&＃xff1a;您可以通过手动打开连接来控制何时打开和关闭连接。一旦您在代码的某些部分开始执行此操作&＃xff0c;那么忘记使用上下文会变得有害&＃xff0c;因为您可能会泄露打开的连接。
2.DbContext根据推荐的模式实现IDiposable&＃xff0c;其中包括暴露一个虚拟保护的Dispose方法&＃xff0c;如果需要将其他非托管资源聚合到上下文的生命周期中&＃xff0c;派生类型可以覆盖。
顺便说一下&＃xff0c;用DbContext打开手动连接的模式&＃xff0c;覆盖自动打开/关闭的行为有点尴尬&＃xff1a;
&＃xff08;&＃xff08;IObjectContextAdapter&＃xff09;的DbContext&＃xff09;.ObjectContext.Connection.Open&＃xff08;&＃xff09;
但是&＃xff0c;我们有一个错误&＃xff0c;使之更容易&＃xff0c;因为它曾经与ObjectContext之前&＃xff0c;例如&＃xff1a;
dbContext.Database.Connection.Open&＃xff08;&＃xff09;
希望这可以帮助&＃xff0c;
迭戈

光说不练假把式&＃xff0c;我们还是亲自来测试一下吧。

我们测试分两种情况&＃xff1a;

• 1、主动释放DbContext
• 2、不释放DbContext
• 3、最好能用多线程模拟下并发
• 4、然后查看执行时数据库的连接数&＃xff0c;和程序执行完之后数据库的连接数。

测试代码&＃xff1a;

//模拟数据库的一些操作&＃xff08;为了相对真实&＃xff0c;包含了新增、修改和查询&＃xff09;
private static void DbOperation(BloggingContext db)
{db.Blogs.Add(new Blog(){Rating &＃61; 1,Url &＃61; "www.i.haojima.net"});db.SaveChanges();db.Blogs.First().Url &＃61; "www.haojima.net";db.SaveChanges();foreach (var item in db.Blogs.Take(10).ToList()){Console.WriteLine("查询到的博客id&＃xff1a;" &＃43; item.BlogId);}
}

条件输入&＃xff1a;

static void Main(string[] args)
{Console.WriteLine("是否主动释放DbContext&＃xff08;y/n&＃xff09;");var yes &＃61; Console.ReadLine();Console.WriteLine("请输入模拟并发量");var number &＃61; Console.ReadLine();SemaphoreSlim _sem &＃61; new SemaphoreSlim(int.Parse(number));

循环代码&＃xff1a;

var i &＃61; 0;
while (i <&＃61; 5000)
{Console.WriteLine("启动第" &＃43; i&＃43;&＃43; &＃43; "个线程");_sem.Wait();#region Threadnew Thread(() &＃61;>{if (yes &＃61;&＃61; "y"){using (BloggingContext bloggingContext &＃61; new BloggingContext())//主动释放{DbOperation(bloggingContext);}}else{BloggingContext bloggingContext &＃61; new BloggingContext();//不释放DbOperation(bloggingContext);}}).Start();#endregion_sem.Release();

查看连接数量&＃xff08;sql语句&＃xff09;&＃xff1a;

SELECT count(1) AS &＃39;连接到EFCoreDemoDB2数据库的数量&＃39; FROM
[Master].[dbo].[SYSPROCESSES] WHERE [DBID] IN ( SELECT [DBID]
FROM [Master].[dbo].[SYSDATABASES]
WHERE NAME&＃61;&＃39;EFCoreDemoDB2&＃39;
)

操作截图如下&＃xff08;你也可以下载demo代码自行测试&＃xff09;&＃xff1a;

主动释放、模拟200并发量

数据库看到的连接数最多的时候54个

不释放、模拟200并发量

数据库看到的连接数最多的时候56个

程序执行完成后&＃xff0c;连接自动释放了

【技巧】&＃xff1a;
我们使用ef或dbcontext的时候主要注意三个问题&＃xff1a;

• 1、多个线程不能访问同一个dbcontext
• 2、同一个跟踪实体不能被多个dbcontext操作
• 3、如果查询数据不需要被修改&＃xff0c;一定按需查询.select(t&＃61;>new Dto(){ })。最不济也要AsNoTracking().ToList()。
  一般也就不会出现奇怪的问题了。

【注意】运行测试的时候用命令行执行或者“开始执行不调试”

demo&＃xff1a;https://github.com/zhaopeiym/BlogDemoCode/tree/master/EFCoreDemo

当然&＃xff0c;我也不知道这种测试是否合理。如果园友有更好的测试方式可以提供。欢迎大家交流。