其實這篇文章跟上一篇是有點關聯的…… 我為了解決 Memory Leak ,抱著「反正我本來就還有另一個問題要靠 BackgroundWorker 來解決,不如碰碰運氣」的心態,將耗時又耗記憶體的那段程式改寫為 BackgroundWorker ,結果真的有用耶~ 所以我沒有嘗試 GC.Collect() ,因為用這種有副作用的 function 會覺得不太漂亮 :p
BackgroundWorker 的效果跟 Thread 差不多,但更容易使用,方法如下:
- 把 BackgroundWorker 元件拉進來,取名為
BGWorker1 。
- 將 WorkerReportsProgress 設為 True ,讓 BackgroundWorker 回報進度。
雙擊 DoWork 事件,然後如下撰寫:
private void BGWorker1_DoWork(object sender, DoWorkEventArgs e)
{
// 另外根據 sender 建立一個 BackgroundWorker
BackgroundWorker bw = sender as BackgroundWorker;
// 取出參數,我不知道怎麼改成能夠取多參數的版本… 此例中 YourFunction 的第二個參數是 int
int arg = (int)e.Argument;
// 開始執行你要的工作
e.Result = YourFunction(bw, arg);
// 處理使用者按下「取消」的動作
if (bw.CancellationPending)
{
e.Cancel = true;
}
}
雙擊 RunWorkerCompleted 事件,然後如下撰寫:
private void BGWorker1_RunWorkerCompleted(object sender, RunWorkerCompletedEventArgs e)
{
if (e.Cancelled)
{
// 使用者中止了執行
}
else if (e.Error != null)
{
// 執行中發生錯誤,可用 e.Error.Message 得到錯誤訊息
}
else
{
// 執行作業正常完成
}
}
雙擊 ProgressChanged 事件,然後如下撰寫:
private void BGWorker1_ProgressChanged(object sender, ProgressChangedEventArgs e)
{
// 用 e.ProgressPercentage 可以取得目前執行進度百分比(0-100)
}
比較實用的範例:
private long begin_tick = 0L;
private void BGWorker1_ProgressChanged(object sender, ProgressChangedEventArgs e)
{
// 取得工作開始的時間,記得要在 RunWorkerCompleted 中將 begin_tick 設回 0L
// C# 中有 function scope 的 static variable 嗎?
if (begin_tick.Equals(0L))
{
begin_tick = DateTime.Now.Ticks;
}
// 計算已執行時間
TimeSpan elapse_time = new TimeSpan(DateTime.Now.Ticks - begin_tick);
// 預估完整執行所需時間
long total_tick = elapse_time.Ticks * 100L;
// 避免 Division by Zero…… 這有更方便的寫法嗎?
if (!e.ProgressPercentage.Equals(0))
{
total_tick /= e.ProgressPercentage;
}
// 預估剩餘時間
TimeSpan remain_time = new TimeSpan(total_tick - elapse_time.Ticks);
// 預估完成時間
DateTime finish_time = new DateTime(DateTime.Now.Ticks + remain_time.Ticks, DateTimeKind.Local);
ProgressBar.Value = e.ProgressPercentage;
StatusLabel.Text = String.Format("{0}% (經過時間:{1:00}:{2:00}:{3:00} / 預估剩餘:{4:00}:{5:00}:{6:00} / 預估完成:{7})", e.ProgressPercentage, elapse_time.Hours, elapse_time.Minutes, elapse_time.Seconds, remain_time.Hours, remain_time.Minutes, remain_time.Seconds, finish_time.ToString("yyyy-MM-dd HH:mm:ss"));
}
至於 YourFunction 則類似這樣:
private void YourFunction(BackgroundWorker bw, int progress)
{
if (!BGWorker1.CancellationPending)
{
// 執行你要執行的作業
// 回報目前執行進度百分比(0-100),沒錯,你必須自己計算
BGWorker1.ReportProgress(progress);
}
}
傳入參數是陣列,使用 for 迴圈的範例:
private void YourFunction(BackgroundWorker bw, string[] argument)
{
int count = argument.Length;
for (int i = 0; i < count; i++) {
if (!BGWorker1.CancellationPending)
{
using (SomeClass obj = new SomeClass(argument[i])) {
BGWorker1.ReportProgress(i * 100 / count);
}
}
}
}
Dispose() do not free memory instantly
.NET 中有自動記憶體管理機制,稱為 GC 。在下的觀念還不是很清楚,所以這篇不敢談太多背後的原理 :p
GC 讓 Programmer 不能直接管理記憶體,在我看來這應該能稱作「將記憶體管理抽象化」。 GC 並不會在「將變數設為 NULL」或「呼叫某物件的 Destructor」時馬上歸還被佔用的記憶體,而會等到某個不明的條件1發生時才啟動回收機制。但也並不是說將變數設為 NULL 或呼叫 Destructor 完全沒用,當某個條件發生時,這些變數、物件所佔用的記憶體便會被釋出。
為了確保 Desturctor 釋放出該釋放的資源,我們可以實作 IDisposable 介面:
private bool disposed = false;
protected virtual void Dispose(bool disposing)
{
if (!disposed)
{
if (disposing)
{
// Release managed resources
}
// Release unmanaged resources
}
disposed = true;
}
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}
~YourClass()
{
Dispose(false);
}
實作了 IDisposable 介面之後,便可以在使用完物件時呼叫 obj.Dispose() 或者是使用 using 來將資源標記為「下次可以被釋放」。 using 的用法如下,這種寫法可以讓 Dispose() 自動地被呼叫:
using(YourClass obj = new YourClass())
{
// Do something
}
除了 Dispose() 以外, C# 中還有一個名為 Finalize() 的 Method ,但這個 Method 無法被覆寫,所以我沒有多加研究。
不過就算照著上面作完了,記憶體仍然必須等到某個條件發生時才會釋放,如果那個條件一直沒有達到,程式就還是會發生「記憶體不足」的問題。
To GC.Collect(), or not to GC.Collect()
有許多文章說,用 GC.Collect() 可以確實地釋放出記憶體。這裡有人做了實驗,他先將記憶體塞滿,當 OutOfMemoryException 發生時,便呼叫 GC.Collect(GC.MaxGeneration) 強制 GC 釋放資源,另有一篇文章建議寫成,不過根據他測試的結果,這還必須跟 gcServer 這個屬性配合才行。組態檔的寫法如下:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<runtime>
<gcServer enabled="false" />
</runtime>
</configuration>
不過 gcServer 該設成 true 或 false 則沒有明說。另有一篇文章提到,如果電腦的 CPU 是多核心,則 .NET 預設會採用 true ,也就是 Server Mode 。這種模式下記憶體達到釋放的門檻較高,容易發生門檻還未達到,記憶體便用罄的窘境。設成 false ,使用 Workstation Mode 可獲得改善。然而這篇文章談的是 ASP.NET ,我不確定在 Windows Form 應用程式中這個規則是否也能適用。
如果你寫的是 ASP.NET ,組態檔放在 %WINDIR%\Microsoft.NET\Framework\(版本)\Aspnet.config 。而 Windows Form 的組態檔則視執行檔檔名而定,若你的執行檔檔名是 hello.exe ,組態檔就放在同目錄下的 hello.exe.config 。
雖然 GC.Collect() 可能能夠解決問題,但必須注意不能過度使用,以免程式效能低落。確定要用 GC.Collect() 的話,有一篇文章提出了建議的寫法:
GC.Collect();
GC.WaitForPendingFinalizer();
GC.Collect();
剛才無聊時看了一下各實驗室的網站,然後覺得我之前作的實驗室網站實在並不很好看…… 所以重新設計了一下,我平常都沒有什麼得失心的,可是這次我不想輸!
不過如果堅哥不想改,那就還是不會改 XD
今天的 meeting 改到下午,所以我無聊了一個上午,當同學們陸陸續續出現時,我便興奮地跟大家分享我的進度 >ω< 堅哥也很驚訝我的進度怎麼突然變得這麼快…… 不過這都不是今天的重點!今天的重點是~ 堅哥說有一個計畫下來了,所以現在有很多經費,他提議要買液晶電視、家庭劇院這些設備,在這段討論途中我就不斷地穿插:「可是空有這麼好的設備,沒有東西來配合也沒用嘛~」,最後堅哥終於被我的怨念感動到,允許我們買 Wii 了!(我們也考慮過 PlayStation 3 和 XBOX360 ,最後由於 Wii 最便宜而勝出)
熊跟我說這樣我們就可以再把 Lab 網站改回 Wii 的版面,不過我想堅哥不會同意這種事的 XD
明天是已經延了一週的 meeting ,而我今天卻還沒有進度可以報告,所以我決定今天到 Lab 努力一天。最近進度會如此緩慢,「沒有方向」是其中一個原因,不過兩天前當我去跟熊催討決策樹程式時,我發現熊已經難以壓抑、幾乎要爆炸了,所以我就想:「嗯… 我還是自力更生吧!」。
今晚我本來的目標只是要實作完我的計分方法,並且找出計分方法中的問題,不過修改演算法好難,我改了一陣子就感到腸枯思竭,於是決定先研究決策樹。我去把 Weka 抓下來,然後照著 IKVM with Weka tutorial 這篇教學作,意外地非常簡單,而且因為 IKVM 用 Reflection 實作了 IntelliSense ,所以在 Visual C# 裡寫起 Java 就跟寫 C# 一樣自然, IntelliSense 不只是能減少打字的麻煩,某種程度上,它可以讓寫程式就像是一連串的選擇題 XD
不過最後我還是沒有在 C# 裡面寫 Java ,因為我打開 Weka 之後發現…… 我完全可以在 Weka 裡面完成我的實驗,不需要再寫一個新的、專門化但是功能較少的 GUI 。發現了這點之後,我便又回到計分方法的實作,並且將我現有的程式與計分模組整合,然後產生出資料丟給 Weka 。 Weka 竟然可以直接幫我作 K-fold cross-validation ,連 Recall、Precision、F-measure 也一併算給我,實在是超方便!結果今天的進度很意外地就超前了好多,幾乎算是已經把實驗作完,只剩下寫論文了 XD