记一次EF Core DBContext在Action委托中GC异常的问题.

今天在开发过程中发现.在savechanges的时候偶尔会抛出异常:cannot access a disposed object. a common cause of this error is disposing a context that was resolved from dependency injection and then later trying to use the same context instance elsewhere in your application. this may occur if you are calling dispose() on the context, or wrapping the context in a using statement. if you are using dependency injection, you should let the dependency injection container take care of disposing context instances.

异常说得很明显,通过依赖注入的dbcontext上下文已经被其他地方dispose了.所以无法再次dispose.

 

 

 

 

 

 

代码逻辑很简单,就是发送邮件后,调用委托通知tracking发送成功.然后保存到数据库.

按理说这段代码没问题,但就是报错了.

一开始以为是哪里没有await,所以导致task开的新线程没有被等待,从而导致提前gc.但代码就这么多,都检查过了没有遗漏的地方.排除

后来怀疑是dbcontext的生命周期问题,但dbcontext是servicelifetime.scoped.  同一个request中是单例的.排除

后来经过和同事交流,在代码结尾处加入task.completedtask.等待所有线程结束.

 

神奇的事情发生了,完美运行.不报错了.

那这样的话,就问题就只可能是定义的action<int> rollback委托的问题了.

 

 

 

 

 

 猛然发现,尽管我在代码中确实加入了async/await关键字

 

 

 但是这里的异步等待,只是异步等待委托内部的操作.并不等待action委托本身.也就是说,当我们执行委托里的方法时.开辟了一个新的线程去执行_dbcontext.savechangesasync()的方法.但是并没有等待它完成.

这时候主线程会立即执行下一步,也就是返回结果给controller层.  return ok()给前端.这个时候dbcontex立刻就会调用dispose.等到委托的方法调用完毕再次dispose的时候.自然而然的就会抛出异常啦.因为他之前已经被dispose了.

所有解决办法很简单

方法一 在代码结尾加入await task.completedtask  等待所有线程都结束.再返回.

方法二 讲action<int> 换成 func<int,task> 并在调用委托前 await 

 

经过这次问题,还是暴露出不少问题.

1:对async/await 还是有认识不足的地方.基础知识不扎实,导致了对委托的错误使用.

2:对自己的代码太过自信.没有做完整的测试.事实上 这里的代码我都没测试过就上了dev环境.认为很简单不会出问题的.做事还是太浮躁.

所以写一篇博客,用以自省