從C#垃圾回收(GC)機制中挖掘效能優化方案

雲霏霏發表於2014-09-26

  GC,Garbage Collect,中文意思就是垃圾回收,指的是系統中的記憶體的分配和回收管理。其對系統效能的影響是不可小覷的。今天就來說一下關於GC優化的東西,這裡並不著重說概念和理論,主要說一些實用的東西。關於概念和理論這裡只做簡單說明,具體的大家可以看微軟官方文件。

一、什麼是GC                                                                                             

  GC如其名,就是垃圾收集,當然這裡僅就記憶體而言。Garbage Collector(垃圾收集器,在不至於混淆的情況下也成為GC)以應用程式的root為基礎,遍歷應用程式在Heap上動態分配的所有物件[2],通過識別它們是否被引用來確定哪些物件是已經死亡的、哪些仍需要被使用。已經不再被應用程式的root或者別的物件所引用的物件就是已經死亡的物件,即所謂的垃圾,需要被回收。這就是GC工作的原理。為了實現這個原理,GC有多種演算法。比較常見的演算法有Reference Counting,Mark Sweep,Copy Collection等等。目前主流的虛擬系統.NET CLR,Java VM和Rotor都是採用的Mark Sweep演算法。(此段內容來自網路)

.NET的GC機制有這樣兩個問題:

  首先,GC並不是能釋放所有的資源。它不能自動釋放非託管資源。

  第二,GC並不是實時性的,這將會造成系統效能上的瓶頸和不確定性。

  GC並不是實時性的,這會造成系統效能上的瓶頸和不確定性。所以有了IDisposable介面,IDisposable介面定義了Dispose方法,這個方法用來供程式設計師顯式呼叫以釋放非託管資源。使用using語句可以簡化資源管理。

 

二、託管資源和非託管資源                                                                           

  託管資源指的是.NET可以自動進行回收的資源,主要是指託管堆上分配的記憶體資源。託管資源的回收工作是不需要人工干預的,有.NET執行庫在合適呼叫垃圾回收器進行回收。

      非託管資源指的是.NET不知道如何回收的資源,最常見的一類非託管資源是包裝作業系統資源的物件,例如檔案,視窗,網路連線,資料庫連線,畫刷,圖示等。這類資源,垃圾回收器在清理的時候會呼叫Object.Finalize()方法。預設情況下,方法是空的,對於非託管物件,需要在此方法中編寫回收非託管資源的程式碼,以便垃圾回收器正確回收資源。

         在.NET中,Object.Finalize()方法是無法過載的,編譯器是根據類的解構函式來自動生成Object.Finalize()方法的,所以對於包含非託管資源的類,可以將釋放非託管資源的程式碼放在解構函式。

 

三、關於GC優化的一個例子                                                                          

  正常情況下,我們是不需要去管GC這些東西的,然而GC並不是實時性的,所以我們的資源使用完後,GC什麼時候回收也是不確定的,所以會帶來一些諸如記憶體洩漏、記憶體不足的情況,比如我們處理一個約500M的大檔案,用完後GC不會立刻執行清理來釋放記憶體,因為GC不知道我們是否還會使用,所以它就等待,先去處理其他的東西,過一段時間後,發現這些東西不再用了,才執行清理,釋放記憶體。

  下面,來介紹一下GC中用到的幾個函式:

  GC.SuppressFinalize(this); //請求公共語言執行時不要呼叫指定物件的終結器。

  GC.GetTotalMemory(false); //檢索當前認為要分配的位元組數。 一個引數,指示此方法是否可以等待較短間隔再返回,以便系統回收垃圾和終結物件。

  GC.Collect();  //強制對所有代進行即時垃圾回收。

GC執行機制

  寫程式碼前,我們先來說一下GC的執行機制。大家都知道GC是一個後臺執行緒,他會週期性的查詢物件,然後呼叫Finalize()方法去消耗他,我們繼承IDispose介面,呼叫Dispose方法,銷燬了物件,而GC並不知道。GC依然會呼叫Finalize()方法,而在.NET 中Object.Finalize()方法是無法過載的,所以我們可以使用解構函式來阻止重複的釋放。我們呼叫完Dispose方法後,還有呼叫GC.SuppressFinalize(this) 方法來告訴GC,不需要在呼叫這些物件的Finalize()方法了。

  下面,我們新建一個控制檯程式,加一個Factory類,讓他繼承自IDispose介面,程式碼如下:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace GarbageCollect
{
   public class Factory : IDisposable
   {
      private StringBuilder sb = new StringBuilder();
      List<int> list = new List<int>();

      //拼接字串,創造一些記憶體垃圾
      public void MakeSomeGarbage()
      {
         for (int i = 0; i < 50000; i++)
         {
            sb.Append(i.ToString());
         }
      }

      //銷燬類時,會呼叫解構函式
      ~Factory()
      {
         Dispose(false);
      }

      public void Dispose()
      {
         Dispose(true);
      }

      protected virtual void Dispose(bool disposing)
      {
         if (!disposing)
         {
            return;
         }
         sb = null;
         GC.Collect();
         GC.SuppressFinalize(this);
      }
   }
}

只有繼承自IDispose介面,使用這個類時才能使用Using語句,在main方法中寫如下程式碼:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Diagnostics;

namespace GarbageCollect
{
   class Program
   {
      static void Main(string[] args)
      {
         using(Factory f = new Factory())
         {
            f.MakeSomeGarbage();
            Console.WriteLine("Total memory is {0} KBs.", GC.GetTotalMemory(false) / 1024);
         }

         Console.WriteLine("After GC total memory is {0} KBs.", GC.GetTotalMemory(false) / 1024);
         
         Console.Read();
      }
   }
}

執行結果如下,可以看到資源執行MakeSomeGarbage()函式後的記憶體佔用為1796KB,釋放後成了83Kb.

 

程式碼執行機制:

  我們寫了Dispose方法,還寫了解構函式,那麼他們分別什麼時候被呼叫呢?我們分別在兩個方法上面下斷點。除錯執行,你會發現先走到了Dispose方法上面,知道程式執行完也沒走解構函式,那是因為我們呼叫了GC.SuppressFinalize(this)方法,如果去掉這個方法後,你會發現先走Dispose方法,後面又走解構函式。所以,我們可以得知,如果我們呼叫Dispose方法,GC就會呼叫解構函式去銷燬物件,從而釋放資源。

 

四、什麼時候該呼叫GC.Collect                                                                      

  這裡為了讓大家看到效果,我顯示呼叫的GC.Collect()方法,讓GC立刻釋放記憶體,但是頻繁的呼叫GC.Collect()方法會降低程式的效能,除非我們程式中某些操作佔用了大量記憶體需要馬上釋放,才可以顯示呼叫。下面是官方文件中的說明:

  垃圾回收 GC 類提供 GC.Collect 方法,您可以使用該方法讓應用程式在一定程度上直接控制垃圾回收器。通常情況下,您應該避免呼叫任何回收方法,讓垃圾回收器獨立執行。在大多數情況下,垃圾回收器在確定執行回收的最佳時機方面更有優勢。但是,在某些不常發生的情況下,強制回收可以提高應用程式的效能。當應用程式程式碼中某個確定的點上使用的記憶體量大量減少時,在這種情況下使用 GC.Collect 方法可能比較合適。例如,應用程式可能使用引用大量非託管資源的文件。當您的應用程式關閉該文件時,您完全知道已經不再需要文件曾使用的資源了。出於效能的原因,一次全部釋放這些資源很有意義。有關更多資訊,請參見 GC.Collect 方法。
  在垃圾回收器執行回收之前,它會掛起當前正在執行的所有執行緒。如果不必要地多次呼叫 GC.Collect,這可能會造成效能問題。您還應該注意不要將呼叫GC.Collect 的程式碼放置在程式中使用者可以經常呼叫的點上。這可能會削弱垃圾回收器中優化引擎的作用,而垃圾回收器可以確定執行垃圾回收的最佳時間。

 

參考資料:http://stackoverflow.com/questions/538060/proper-use-of-the-idisposable-interface

 

相關文章