这在于EF的context有没有直接/间接使用非托管资源，或者有没有直接/间接的析构方法（一般二者都同时出现）。如果它使用了，你主动调用的好处是尽早释放非托管资源，并且标准的Dispose实现会通知GC无需调用析构方法，让对象不需要进入析构队列，尽快真正释放。如果没有直接/间接使用非托管资源，也没有直接/间接的析构，那Dispose就基本没用了。EF的DbContext上的protected的Dispose的文档是这么写的： Disposes the context. The underlying ObjectContext is also disposed if it was created is by this context or ownership was passed to this context when this context was created. The connection to the database (DbConnection object) is also disposed if it was created is by this context or ownership was passed to this context when this context was created. reflector看了下EF6的代码，它内部在InternalContext上使用了析构，这意味着它间接使用了非托管资源，其实就是上面说的可能被这个DbContext拥有的DbConnection。以上，应该能看出尽快手动Dispose的好处，不要等着GC去释放DbConnection，而且官方的文档教程里面都是using的，你应该相信官方比其他人更懂得为什么吧。尽快释放资源是一个良好的习惯，尤其是在长时间并发运行的服务端，不要把资源的释放交给不知道什么时候会进行的GC。2楼给出的blog里面说的那个一个是11年的，现在的EF6的代码已经不是那样了，而且他也没有分析仅查询的情况下connection的处理，只是为了后面lazy loading就不释放context并不合理，应该是把需要的数据加载完成就主动dispose掉。另外，把DbContext控制在每请求一个可能会有问题，比如mvc或者web api，我一开始也是这么做的，但是后来需要写个action filter，在action之前处理一些东西用到context，如果是和action同样的context就得考虑不能缓存任何数据，否则action查询同样数据就不是新的了。还有就是如果在一个请求里面再开新的线程进行查询，那也算是一个请求之内的，使用同样的context会出问题，因为context不是线程安全的。而且这样做是主动延长了context的生命周期，如果自己不主动释放，要等到请求结束时释放IoC容器它才能释放。遇到过不少坑之后发现最好的做法就是每次用到都是新的。
http://www.cnblogs.com/mecity/archive/2011/07/17/2108508.html但有些人你和他争论也是没有用的~
用IOC把~ 一般提供其他控制生命周期的方式
builder.Register<IDbContext>(c => new NopObjectContext(dataSettingsManager.LoadSettings().DataConnectionString)).InstancePerHttpRequest();生命的周期 以一次http请求 不是.net的失去引用
Dispose不能释放托管的资源，它完全依赖GC，对你来说是透明的。你的“老大”估计是说对象调用了Dispose释放了非托管资源，但是自身没有被GC回收的状态，自己发明了什么“标记回收”“实际回收”，根本来说，还是他基本概念不清。就EF来说，调用Dispose绝对不会有问题，但是显得多此一举。
Disposes the context. The underlying ObjectContext is also disposed if it was created is by this context or ownership was passed to this context when this context was created. The connection to the database (DbConnection object) is also disposed if it was created is by this context or ownership was passed to this context when this context was created. reflector看了下EF6的代码，它内部在InternalContext上使用了析构，这意味着它间接使用了非托管资源，其实就是上面说的可能被这个DbContext拥有的DbConnection。以上，应该能看出尽快手动Dispose的好处，不要等着GC去释放DbConnection，而且官方的文档教程里面都是using的，你应该相信官方比其他人更懂得为什么吧。尽快释放资源是一个良好的习惯，尤其是在长时间并发运行的服务端，不要把资源的释放交给不知道什么时候会进行的GC。2楼给出的blog里面说的那个一个是11年的，现在的EF6的代码已经不是那样了，而且他也没有分析仅查询的情况下connection的处理，只是为了后面lazy loading就不释放context并不合理，应该是把需要的数据加载完成就主动dispose掉。另外，把DbContext控制在每请求一个可能会有问题，比如mvc或者web api，我一开始也是这么做的，但是后来需要写个action filter，在action之前处理一些东西用到context，如果是和action同样的context就得考虑不能缓存任何数据，否则action查询同样数据就不是新的了。还有就是如果在一个请求里面再开新的线程进行查询，那也算是一个请求之内的，使用同样的context会出问题，因为context不是线程安全的。而且这样做是主动延长了context的生命周期，如果自己不主动释放，要等到请求结束时释放IoC容器它才能释放。遇到过不少坑之后发现最好的做法就是每次用到都是新的。