現在有很多系統除非太小，不然應該都會使用第三方開發的DI容器，來實現IoC。但是使用DI容器時免不了要對於物件的生命週期有一定的了解，不然到時候出現相關的問題就手忙腳亂了。因此這一篇文章就記錄了我使用Autofac時，遇到的memory leak的問題，並把所做的實驗記錄下來。
實驗的情境主要是run在console環境中，模擬類似windows service的情境，所以web的asp.net環境並不在此實驗的考慮範圍內。
這篇文章使用的原始碼連結如下:
GitHub repo url: https://github.com/RiceBen/AutofacExperiment
內文:
物件的生命週期與最初註冊物件的依賴是怎樣的方式，預設是InstancePerDependency這個方法，它會確保你每次呼叫Resolve方法時可以取得新的物件，並不會與其他呼叫端使用同一份實體。這個特性在大多數的時候都會符合需求。
因此在注入時我們先這樣寫:
ps.快照時間基本上都是10秒30秒各拍一次，執行超過50秒就結束實驗。
實驗一:
public class DAModules : Autofac.Module
{
protected override void Load(ContainerBuilder builder)
{
var assembly = Assembly.Load("NineYi.ERP.DA.ERPDB");
builder.RegisterType<deamonresourcerepository>()
.As<ideamonresourcerepository>()
.InstancePerDependency();
}
}
接下來就是我們這次的實驗目標的寫法:介面:
///實作:/// Iinterface of deamon resource repository /// public interface IDeamonResourceRepository: IDisposable { ////// Eat resource /// void ResourceMonster(); }
///接下來我們在呼叫端這樣寫:/// Deamon resource repository. /// /// <seealso cref="NineYi.ERP.DA.ERPDB.Deamon.IDeamonResourceRepository" /> /// <seealso cref="System.IDisposable" /> public class DeamonResourceRepository : IDeamonResourceRepository { ////// Gets the name. /// ////// The name. /// public string Name { get { return typeof(DeamonResourceRepository).FullName; } } ////// 序號 (為了輔助驗證取得的實體) /// public int Number { get; set; } ////// 執行與釋放 (Free)、釋放 (Release) 或重設 Unmanaged 資源相關聯之應用程式定義的工作。 /// public void Dispose() { Console.WriteLine(string.Format("{0} dispose!", this.Name)); } ////// Eat resource /// public void ResourceMonster() { this.Number += 1; Console.WriteLine(string.Format("DeamonResource Number:{0}", this.Number)); } }
static void Main(string[] args)
{
var builder = new ContainerBuilder();
builder.RegisterModule<NineYi.ERP.DA.ERPDB.Modules.DAModules>();
using (var container = builder.Build())
{
MemoryLeakMethod02(container);
}
}
///
/// 容易不自覺產生memory的語法
///
/// The container.///
/// 重點是使用InstancePerDependency作為物件的生命週期，這會導致每次都會產生一個完全新的實體出來，就算有呼叫dispose，但是autofac會握有一份參考，導致這份實體並不會被GC真正回收。
///
static void MemoryLeakMethod02(IContainer container)
{
using (var lifetimescope = container.BeginLifetimeScope())
{
while (1 == 1)
{
using (var resource = lifetimescope.Resolve<NineYi.ERP.DA.ERPDB.Deamon.IDeamonResourceRepository>())
{
resource.ResourceMonster();
System.Threading.Thread.Sleep(500);
}
}
}
}
接下來我們開啟Visual Studio的 Analyze -> Performance Profiler -> 勾選memory usage就可以開始觀察記憶體的使用了。
Profiler畫面(執行50+秒)：
執行畫面：
實驗結果一:雖然有呼叫dispose但是還是可以看到記憶體不斷飆升(兩份快照相比後者比前者多了20以上的物件)，因此可以預期的是不斷執行後一定會發生OOM的例外訊息
實驗二:
我們改用single instance看看是否真的只會有那麼一個實體被生成出來
protected override void Load(ContainerBuilder builder)
{
builder.RegisterType<deamonresourcerepository>()
.As<ideamonresourcerepository>()
.SingleInstance();
}
呼叫端則這樣寫:
static void Main(string[] args)
{
var builder = new ContainerBuilder();
builder.RegisterModule<NineYi.ERP.DA.ERPDB.Modules.DAModules>();
using (var container = builder.Build())
{
MemoryLeakMethod02(container);
}
}
///
/// 與實驗一是一樣的寫法，只有物件的生命中期使用方式不同
///
/// The container.///
/// 重點是使用SingleInstance作為物件的依賴方式，這會讓每次叫用的物件只會生成一份，所以看起來就沒有memory leak的問題發生。
///
static void MemoryLeakMethod02(IContainer container)
{
using (var lifetimescope = container.BeginLifetimeScope())
{
while (1 == 1)
{
using (var resource = lifetimescope.Resolve<NineYi.ERP.DA.ERPDB.Deamon.IDeamonResourceRepository>())
{
resource.ResourceMonster();
System.Threading.Thread.Sleep(500);
}
}
}
}
Profiler畫面(執行50+秒)：
執行畫面：
實驗結果二: 有呼叫dispose，不過也因為autofac握有一份參考，所以應該還是沒有真正釋放物件，不過因為依賴方式使用SingleInstance，所以執行再久並沒有memory leak的問題發生。
實驗三:
這次我們改用InstancePerLifetimeScope這個依賴方式
builder.RegisterType<deamonresourcerepository>()
.As<ideamonresourcerepository>()
.InstancePerLifetimeScope();
依據官方說明文件:這個依賴方式會讓同一個 lifetimescope 中取得相同類別的物件，會取用同一份實體。不同的 lifetimescope 就算呼叫同一個類別也會使用同一份實體，因此我們可以用同樣的情境來驗證是否正確。呼叫端我們這樣寫:
static void Main(string[] args)
{
var builder = new ContainerBuilder();
builder.RegisterModule<NineYi.ERP.DA.ERPDB.Modules.DAModules>();
using (var container = builder.Build())
{
MemoryLeakMethod02(container);
}
}
///
/// 與實驗一是一樣的寫法，只有物件的依賴方式不同
///
/// The container.///
/// 重點是使用InstancePerLifetimeScope作為物件的依賴方式，同一個scope下取得的實體將會相同。
///
static void MemoryLeakMethod02(IContainer container)
{
using (var lifetimescope = container.BeginLifetimeScope())
{
while (1 == 1)
{
using (var resource = lifetimescope.Resolve<NineYi.ERP.DA.ERPDB.Deamon.IDeamonResourceRepository>())
{
resource.ResourceMonster();
System.Threading.Thread.Sleep(500);
}
}
}
}
Profiler畫面(執行50+秒)：
執行畫面：
實驗解果三:有呼叫dispose，但是因為autofac擁有一份參考，所以應該沒有真正釋放次件，但是應為依賴方式為InstancePerLifetimeScope所以並不會產生新的實體出來占用記憶體。
實驗四:
我們回到一開始的物件依賴方式
builder.RegisterType<deamonresourcerepository>()
.As<ideamonresourcerepository>()
.InstancePerDependency();
但是接下來我們的呼叫端就改成這樣:
static void Main(string[] args)
{
var builder = new ContainerBuilder();
builder.RegisterModule<NineYi.ERP.DA.ERPDB.Modules.DAModules>();
using (var container = builder.Build())
{
MemoryLeakMethod02(container);
}
}
///
/// 使用Child Scope來管理這區域中產生的物件，可以確保物件在這個區域使用完畢後會被釋放
///
/// ///
/// 把using的範圍用在Lifetimescope，而不是產生出來的物件
///
private static void NoMemoryLeakMethod02(IContainer container)
{
using (var lifetimescope = container.BeginLifetimeScope())
{
while (1 == 1)
{
using (var childScope = lifetimescope.BeginLifetimeScope())
{
using (var resource = childScope.Resolve<NineYi.ERP.DA.ERPDB.Deamon.IDeamonResourceRepository>())
{
resource.ResourceMonster();
System.Threading.Thread.Sleep(500);
}
}
}
}
}
Profiler畫面(執行50+秒)：
執行畫面：
實驗結果四:我們可以發現dispose有被呼叫，而且記憶體也沒有逐漸上升，代表每個新產生的物件有確實的被回收了！這是因為我們這次的using是包在lifetimescope中，而不是產生出來的實體，在lifetimescope結束的當下，他會負責把在他當中產生的實體也一起回收，而在沒有人握有實體的參照，又呼叫dispose時GC就會把這份實體的資源給回收回去，因此就不會讓記憶體持續累積下去。
以上四組實驗我們可以發現一個基本的autofac在物件的生命週期中，所造成的影響。關於這個主題還有很多可以探討的問題，像是官網中還提到的另外幾種依賴的方式，還有不同的依賴方式適合用在什麼情境中，還有不同的應用系統適合用什麼樣的依賴方式。
對於Autofac有研究的人，歡迎在下方留言或是寄信給我一起討論，謝謝~!