寫C#程式也有一段時間了，算一算現在寫的這個程式已是第四個用C#寫的較有規模的程式。一直以來因為懶惰和玩不完的電動，都沒有好好去研究C#中資源釋放的問題，尤其後來這三次寫的程式都需要用到以C++寫成的Library（以C++/CLI寫一個Wrapper Class來包裝），有二次要用到Managed DirectX，對於各種資源的管理更顯得重要。所以這一次就稍微認真了點，去搜尋了一下C#資源釋放的相關文章來做個統整。
剛接觸C#沒多久的人，通常對於GC(Garbage Collector)都會跟我有一樣的茫然，「GC什麼時候會回收資源？」、「哪些東西會被GC回收？」、「太倚賴GC是不是會造成程式效率低落？」，以下就從基礎開始談起GC的運作機制。
剛接觸C#沒多久的人，通常對於GC(Garbage Collector)都會跟我有一樣的茫然，「GC什麼時候會回收資源？」、「哪些東西會被GC回收？」、「太倚賴GC是不是會造成程式效率低落？」，以下就從基礎開始談起GC的運作機制。
在執行.NET的程式時，對於不同型別，CLR(Common Language Runtime)會在不同的地方分配資源空間。對於實值型別(Value Type)，當宣告一個變數時，CLR會在Stack(堆疊)中配置一塊空間，設定該變數的值時，其值也直接存放於該空間中，如下圖：
而對於參考型別(Reference Type)，CLR則在Stack中配置一塊存放記憶體位址的空間，在初始化該型別的實體時(ex: new)，則在Heap(堆積)上配置該型別所需的空間，再將該空間的位址傳回給存放在Stack中的那塊空間，如下圖：
這些由CLR自動配置與管理的記憶體，被稱為Managed資源；反之，不受CLR管理的便被稱為Unmanaged資源（ex: Stream、與資料庫的連結、COM物件……等）。
而對於資源的釋放，CLR則主要以GC來回收已用不到的記憶體空間，這些空間便被稱為garbage。(上述的記憶體配置及GC的運作可參考MSDN: CLR的自動記憶體管理)
那麼garbage如何產生或被判定呢？
基本的原則是當該變數「不再有效」時，便會被視為garbage，具體的情況則包括超出該變數的有效範圍（ex:離開了對應的大括號的區域變數）、 將變數指定為null、重新指向其他物件（而原先指向的物件已無法被取得）、重新初始化…等，這時原先變數佔有的空間都會被CLR視為garbage而等待回收。
若變數為數值型別，則當其超出有效範圍時，CLR會直接回收它在Stack上所佔用的空間；若變數為參考型別，則CLR會先回收它在Stack上佔用的空間，而將Heap上的空間視為garbage，等待GC回收。若參考型別的變數在其有效範圍內重新初始化，則原先所指向的物件亦會被視為garbage。
然而，被視為garbage的變數，並不是馬上就被GC回收，而是根據GC內的演算法，依變數被判定的generation而有不同。在Managed Heap上的物件會被CLR分為三個generation：0、1、2，數字越大表示存活時間越長。這樣的設計乃是建構在「只壓縮部份的Heap會比一次壓縮整個Heap來得有效率」的事實上，因此將物件分成不同的層級，在回收時針對不同層級做回收，是.NET Framework考量效率後所採用的方法。
CLR會將新建立的物件擺在第0個generation，當GC進行gen 0的回收時，會將仍為有效的gen 0物件提昇至gen 1。而若gen 0的空間回收後仍不足以建立新物件，則GC會繼續檢查gen 1的物件，存留下來的gen 1物件會被提昇至gen 2（最高只到gen 2，故若gen 2被檢查後仍存活，只會停留在gen 2）。進行gen 1的回收時，也會進行gen 0回收；同理進行gen 2回收時，也會進行gen 1、gen 0的回收。在這樣的設計下，程式中常會應用到的區域物件與暫時物件因都屬於gen 0，故可確保被回收的頻率最高，對一般不會用到大量暫時物件的程式而言，不需擔心資源的浪費。
至目前為止，我們了解了Managed資源的回收機制，但還有至少二個問題殘留著：
「若是程式員希望在某個時間點確保Managed資源被回收，應該怎麼做？」
「若是類別中含有Unmanaged資源，又該如何釋放？」
對於這二個問題的回答，在這裡便開始要提到程式員如何撰寫明確釋放資源的函式了。在C++中，程式員撰寫類別的Destructor來達成類別資源的釋放，而在C#中，同樣有類似效果的函式有Finalize()與Dispose() ，而這二個函式也常令許多C#的初學者混淆，以下便解釋二者的差別：
前面提到Managed資源會自動被GC回收，但若類別中含有Unmanaged資源，則程式員除了撰寫該Unmanaged資源本身的釋放函式(如Destructor)之外，又該在何處確保這些釋放函式會被呼叫呢？答案就是C#類別的Finalize()函式中。然而，因Finalize()本身的存取層級是protected，所以在實作上，對於類別T，程式員是撰寫名為 「~T()」的函式（如同C++中的解構函式語法），該函式經過編譯後，編譯器便會產生類別T的Finalize()方法，並將函式的內容包在try 區塊中。
public class T
{
Unmgd un;
~T()
{
un.Release(); //假設Unmgd的釋放資源函式為Release()；亦可呼叫~Unmgd() }
}
然而，Finalize()的呼叫是不明確的，因為它只被GC給呼叫，亦即程式員只能預期GC在進行某個T的實體的回收時，會呼叫T.Finalize()，卻無法在程式員自己想要的特定位置呼叫Finalize()。另一方面，Finalize()也並非在GC對該物件進行第一次回收時便被呼叫，事實上，GC的第一次回收，僅是將該物件的參考移至FReachable Queue中，標示為不再使用，等到GC下一次的回收時，Finalize()才真正地被呼叫。從這些事實來看，程式員沒有辦法預期Finalize()究竟會在程式中的何處被呼叫，只能被動地等待GC去呼叫它。因此，為了讓程式員能明確執行Unmanaged資源釋放的工作，C#提供了另一個函式Dispose()。
Dispose()與Finalize()最大的不同，在於Dispose()是明確地在「程式員呼叫」與「using語句區塊結束時」二種情況下被呼叫的。也就是說，當程式員想確保某個類別T中的Unamaged資源會在某個特定位置被釋放掉時，他便可以實作IDisposable介面中的Dispose()函式；而為了提供程式員在操作常用的暫時物件上不會忘記呼叫Dispose()，C#中提供了using陳述式，確保在小括弧中的變數，在離開using區塊時，其Dispose()會被明確地呼叫。
using(T t = new T())
{
.........
} //<-此時T.Dispose()會被呼叫
當一個物件的Dispose()被呼叫後，亦即標示了這個物件為無效，則在第一次的GC回收行程中便會被回收到。值得一提的是，即使某個物件的Dispose()已經被呼叫過了，該物件的Finalize()仍然有可能再被GC給呼叫到，這是為了避免當Dispose()失敗時可能產生的資源浪費。然而，若Dispose()成功地執行了，則應該避免再讓GC去呼叫Finalize()，否則會造成程式效率的低落。因此在撰寫Dispose()函式時，必須記得在裡面加上一行GC.SuppressFinalize(this); 這可以告訴GC不需再去呼叫這個物件的Finalize()。
關於Dispose()的撰寫，我會再寫一篇文章來整理（因為這篇從過年前擺著到現在了，先早點po出來）。另外也會整理一篇有關C#程式要調用以C++寫成的函式庫時的幾種方法（尤其是Wrapper Class，有一些細節還是一直困惑著我，整理出來會弄得比較清楚）。
再看一個 更簡單的例子
「Box」處理整數變數 i，然後將此變數指派給物件 o。
int i = 123;
// The following line boxes i.
object o = i;物件 o 接著即可經 Unbox 處理，並指派給整數變數 i：
o = 123;
i = (int)o; // unboxing更多方法考參考MSDN
2013/9/5 補充 Boxing UNBoxing
參考連結
說明:
這個範例會使用 Boxing，將整數變數 i 轉換為物件 o。接著，儲存在變數 i 中的值會從 123 變更為 456。這個範例顯示原來的實值型別及 boxed 物件是使用獨立的記憶體位置，因此可以儲存不同的值。
class TestBoxing
{
static void Main()
{
int i = 123;
object o = i; // Implicit boxing
i = 456; // Change the contents of i
System.Console.WriteLine("The value-type value = {0}", i);
System.Console.WriteLine("The object-type value = {0}", o);
}
}
/* Output: The value-type value = 456
The object-type value = 123
*/
沒有留言:
張貼留言