有興趣的同學可以參考如下系列文章，都是針對dump分析的實戰和總結：
Windbg DUMP分析（原創匯總）
http://www.cnblogs.com/LoveOfPrince/p/6653341.html
記一次內存泄漏DUMP分析
http://www.cnblogs.com/LoveOfPrince/p/6032523.html
-------------------------------------------------回歸正題----------------------------------------------------------------------
前些天某個服務，線上CPU經常飆到很高，且其它服務間歇性的無法讀寫數據庫。
攻城獅們查了幾天，沒有明顯發現。
后來，他們拋了一個dump給我，初步分析只有該服務使用了公司內基於EF自建的倉儲，問題應該在這里。
苦於沒有該倉儲的代碼權限，且手上事情較多，就先讓他們自己查下該倉儲。
第二天順手要了該倉儲的代碼，又抓了幾個dump，基本敲定，細節如下：
1.托管線程堆棧大多停留在如下，且占用不少耗時。
DatabaseLogFormatter.Executing 000000000e6bbfb8 0000000077c2bd7a [HelperMethodFrame: 000000000e6bbfb8] 000000000e6bc100 000007fe99238fc0 System.Data.Entity.Infrastructure.Interception.DatabaseLogFormatter.Executing[[System.__Canon, mscorlib]](System.Data.Common.DbCommand, System.Data.Entity.Infrastructure.Interception.DbCommandInterceptionContext`1<System.__Canon>) 000000000e6bc160 000007fe99238ec6 System.Data.Entity.Infrastructure.Interception.DatabaseLogFormatter.ReaderExecuting(System.Data.Common.DbCommand
2.進一步分析，二代齡要回收的對象太多。
Heap 0 generation 0 has 35 finalizable objects (000000000f312ec0->000000000f312fd8) generation 1 has 4 finalizable objects (000000000f312ea0->000000000f312ec0) generation 2 has 48152 finalizable objects (000000000f2b4de0->000000000f312ea0) Ready for finalization 0 objects (000000000f312fd8->000000000f312fd8) ------------------------------ Heap 1 generation 0 has 12 finalizable objects (000000001165a780->000000001165a7e0) generation 1 has 3 finalizable objects (000000001165a768->000000001165a780) generation 2 has 49727 finalizable objects (00000000115f9570->000000001165a768) Ready for finalization 0 objects (000000001165a7e0->000000001165a7e0) ------------------------------ Heap 2 generation 0 has 19 finalizable objects (00000000115a4c30->00000000115a4cc8) generation 1 has 9 finalizable objects (00000000115a4be8->00000000115a4c30) generation 2 has 42725 finalizable objects (00000000115514c0->00000000115a4be8) Ready for finalization 0 objects (00000000115a4cc8->00000000115a4cc8) ------------------------------ Heap 3 generation 0 has 18 finalizable objects (000000000f36a9b8->000000000f36aa48) generation 1 has 14 finalizable objects (000000000f36a948->000000000f36a9b8) generation 2 has 44483 finalizable objects (000000000f313b30->000000000f36a948) Ready for finalization 0 objects (000000000f36aa48->000000000f36aa48)
且這些對象大都是EF相關的。
MT Count TotalSize Class Name 000007fef694bb40 3162 227664 System.Reflection.Emit.DynamicResolver 000007fef68e76d0 36109 866616 System.WeakReference 000007fe987e9f40 35941 4887976 System.Data.Entity.Core.EntityClient.EntityConnection 000007fe987d75f0 37157 5053352 MySql.Data.MySqlClient.MySqlConnection 000007fe987e7d58 35952 6615168 System.Data.Entity.Core.Objects.ObjectContext 000007fe98814690 35952 8053248 System.Data.Entity.Internal.LazyInternalContext
3.如上來看，疑點還是在倉儲這塊。
跟蹤堆棧，來看MySqlConnection的話，考慮XDbContext : IDisposable的銷毀方式是不是不夠直接徹底。
這里讀的連接沒有銷毀，印證了上述推斷，再讓他們檢查一下該服務中有沒有正確使用該倉儲即可。
是不是有點成就感...我是不是應該先去找個妹子、結束單身才是正事啊😭