成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

漫談C#開發中的垃圾回收機制

開發 后端
今天我們漫談C#中的垃圾回收機制,本文將從垃圾回收機制的原理講起,希望對大家有所幫助。

GC的前世與今生

雖然本文是以.NET作為目標來講述GC,但是GC的概念并非才誕生不久。早在1958年,由鼎鼎大名的圖林獎得主John McCarthy所實現的Lisp語言就已經提供了GC的功能,這是GC的***次出現。Lisp的程序員認為內存管理太重要了,所以不能由程序員自己來管理。但后來的日子里Lisp卻沒有成氣候,采用內存手動管理的語言占據了上風,以C為代表。出于同樣的理由,不同的人卻又不同的看法,C程序員認為內存管理太重要了,所以不能由系統來管理,并且譏笑Lisp程序慢如烏龜的運行速度。的確,在那個對每一個Byte都要精心計算的年代GC的速度和對系統資源的大量占用使很多人的無法接受。而后,1984年由Dave Ungar開發的Small talk語言***次采用了Generational garbage collection的技術(這個技術在下文中會談到),但是Small talk也沒有得到十分廣泛的應用。

直到20世紀90年代中期GC才以主角的身份登上了歷史的舞臺,這不得不歸功于Java的進步,今日的GC已非吳下阿蒙。Java采用VM(Virtual Machine)機制,由VM來管理程序的運行當然也包括對GC管理。90年代末期.NET出現了,.NET采用了和Java類似的方法由CLR(Common Language Runtime)來管理。這兩大陣營的出現將人們引入了以虛擬平臺為基礎的開發時代,GC也在這個時候越來越得到大眾的關注。

為什么要使用GC呢?也可以說是為什么要使用內存自動管理?有下面的幾個原因:

1、提高了軟件開發的抽象度;

2、程序員可以將精力集中在實際的問題上而不用分心來管理內存的問題;

3、可以使模塊的接口更加的清晰,減小模塊間的偶合;

4、大大減少了內存人為管理不當所帶來的Bug;

5、使內存管理更加高效。

總的說來就是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算法。

一、Mark-Compact 標記壓縮算法 簡單把.NET的GC算法看作Mark-Compact算法

階段1: Mark-Sweep 標記清除階段

先假設heap中所有對象都可以回收,然后找出不能回收的對象,給這些對象打上標記,***heap中沒有打標記的對象都是可以被回收的

階段2: Compact 壓縮階段

對象回收之后heap內存空間變得不連續,在heap中移動這些對象,使他們重新從heap基地址開始連續排列,類似于磁盤空間的碎片整理

alt

Heap內存經過回收、壓縮之后,可以繼續采用前面的heap內存分配方法,即僅用一個指針記錄heap分配的起始地址就可以

主要處理步驟:將線程掛起=>確定roots=>創建reachable objectsgraph=>對象回收=>heap壓縮=>指針修復

可以這樣理解roots:heap中對象的引用關系錯綜復雜(交叉引用、循環引用),形成復雜的graph,roots是CLR在heap之外可以找到的各種入口點。GC搜索roots的地方包括全局對象、靜態變量、局部對象、函數調用參數、當前CPU寄存器中的對象指針(還有finalizationqueue)等。主要可以歸為2種類型:已經初始化了的靜態變量、線程仍在使用的對象(stack+CPU register)

Reachable objects:指根據對象引用關系,從roots出發可以到達的對象。例如當前執行函數的局部變量對象A是一個rootobject,他的成員變量引用了對象B,則B是一個reachable object。從roots出發可以創建reachable objectsgraph,剩余對象即為unreachable,可以被回收

alt

指針修復是因為compact過程移動了heap對象,對象地址發生變化,需要修復所有引用指針,包括stack、CPUregister中的指針以及heap中其他對象的引用指針

Debug和release執行模式之間稍有區別,release模式下后續代碼沒有引用的對象是unreachable的,而debug模式下需要等到當前函數執行完畢,這些對象才會成為unreachable,目的是為了調試時跟蹤局部對象的內容

傳給了COM+的托管對象也會成為root,并且具有一個引用計數器以兼容COM+的內存管理機制,引用計數器為0時這些對象才可能成為被回收對象

Pinnedobjects指分配之后不能移動位置的對象,例如傳遞給非托管代碼的對象(或者使用了fixed關鍵字),GC在指針修復時無法修改非托管代碼中的引用指針,因此將這些對象移動將發生異常。pinnedobjects會導致heap出現碎片,但大部分情況來說傳給非托管代碼的對象應當在GC時能夠被回收掉

二、 Generational 分代算法 程序可能使用幾百M、幾G的內存,對這樣的內存區域進行GC操作成本很高,分代算法具備一定統計學基礎,對GC的性能改善效果比較明顯

將對象按照生命周期分成新的、老的,根據統計分布規律所反映的結果,可以對新、老區域采用不同的回收策略和算法,加強對新區域的回收處理力度,爭取在較短時間間隔、較小的內存區域內,以較低成本將執行路徑上大量新近拋棄不再使用的局部對象及時回收掉

分代算法的假設前提條件:

1、大量新創建的對象生命周期都比較短,而較老的對象生命周期會更長

2、對部分內存進行回收比基于全部內存的回收操作要快

3、新創建的對象之間關聯程度通常較強。heap分配的對象是連續的,關聯度較強有利于提高CPU cache的命中率

.NET將heap分成3個代齡區域: Gen 0、Gen 1、Gen 2

alt

Heap分為3個代齡區域,相應的GC有3種方式: # Gen 0 collections, # Gen 1 collections, #Gen 2 collections。如果Gen 0 heap內存達到閥值,則觸發0代GC,0代GC后Gen 0中幸存的對象進入Gen1。如果Gen 1的內存達到閥值,則進行1代GC,1代GC將Gen 0 heap和Gen 1 heap一起進行回收,幸存的對象進入Gen2。2代GC將Gen 0 heap、Gen 1 heap和Gen 2 heap一起回收

Gen 0和Gen 1比較小,這兩個代齡加起來總是保持在16M左右;Gen2的大小由應用程序確定,可能達到幾G,因此0代和1代GC的成本非常低,2代GC稱為fullGC,通常成本很高。粗略的計算0代和1代GC應當能在幾毫秒到幾十毫秒之間完成,Gen 2 heap比較大時fullGC可能需要花費幾秒時間。大致上來講.NET應用運行期間2代、1代和0代GC的頻率應當大致為1:10:100。

三、Finalization Queue和Freachable Queue

這兩個隊列和.net對象所提供的Finalize方法有關。這兩個隊列并不用于存儲真正的對象,而是存儲一組指向對象的指針。當程序中使用了new操作符在Managed Heap上分配空間時,GC會對其進行分析,如果該對象含有Finalize方法則在Finalization Queue中添加一個指向該對象的指針。在GC被啟動以后,經過Mark階段分辨出哪些是垃圾。再在垃圾中搜索,如果發現垃圾中有被Finalization Queue中的指針所指向的對象,則將這個對象從垃圾中分離出來,并將指向它的指針移動到Freachable Queue中。這個過程被稱為是對象的復生(Resurrection),本來死去的對象就這樣被救活了。為什么要救活它呢?因為這個對象的Finalize方法還沒有被執行,所以不能讓它死去。Freachable Queue平時不做什么事,但是一旦里面被添加了指針之后,它就會去觸發所指對象的Finalize方法執行,之后將這個指針從隊列中剔除,這是對象就可以安靜的死去了。.net framework的System.GC類提供了控制Finalize的兩個方法,ReRegisterForFinalize和SuppressFinalize。前者是請求系統完成對象的Finalize方法,后者是請求系統不要完成對象的Finalize方法。

ReRegisterForFinalize方法其實就是將指向對象的指針重新添加到Finalization Queue中。這就出現了一個很有趣的現象,因為在Finalization Queue中的對象可以復生,如果在對象的Finalize方法中調用ReRegisterForFinalize方法,這樣就形成了一個在堆上永遠不會死去的對象,像鳳凰涅槃一樣每次死的時候都可以復生。

托管資源:

Net中的所有類型都是(直接或間接)從System.Object類型派生的。

CTS中的類型被分成兩大類——引用類型(reference type,又叫托管類型[managed type]),分配在內存堆上,值類型(value type)。值類型分配在堆棧上。如圖

alt

值類型在棧里,先進后出,值類型變量的生命有先后順序,這個確保了值類型變量在推出作用域以前會釋放資源。比引用類型更簡單和高效。堆棧是從高地址往低地址分配內存。

引用類型分配在托管堆(Managed Heap)上,聲明一個變量在棧上保存,當使用new創建對象時,會把對象的地址存儲在這個變量里。托管堆相反,從低地址往高地址分配內存,如圖

alt

.net中超過80%的資源都是托管資源。

非托管資源:

ApplicationContext,Brush,Component,ComponentDesigner,Container,Context,

Cursor,FileStream,Font,Icon,Image,Matrix,Object,OdbcDataReader,OleDBDataReader,

Pen,Regex,Socket,StreamWriter,Timer,Tooltip ,文件句柄,GDI資源,數據庫連接等等資源。可能在使用的時候很多都沒有注意到!

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

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

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

GC并不是實時性的,這會造成系統性能上的瓶頸和不確定性。所以有了IDisposable接口,IDisposable接口定義了Dispose方法,這個方法用來供程序員顯式調用以釋放非托管資源。使用using 語句可以簡化資源管理。

示例

  1.  /// <summary>    
  2.  /// 執行SQL語句,返回影響的記錄數    
  3.  /// </summary>    
  4.  /// <param name="SQLString">SQL語句</param>    
  5.  /// <returns>影響的記錄數</returns>    
  6.  public static int ExecuteSql(string SQLString)    
  7.  {    
  8.  using (SqlConnection connection = new SqlConnection(connectionString))    
  9. {    
  10.  using (SqlCommand cmd = new SqlCommand(SQLString, connection))    
  11.  {    
  12.  try   
  13.  {    
  14. connection.Open();    
  15. int rows = cmd.ExecuteNonQuery();    
  16.  return rows;    
  17.  }    
  18.  catch (System.Data.SqlClient.SqlException e)    
  19.  {    
  20.  connection.Close();    
  21.  throw e;    
  22.  }    
  23. finally   
  24.  {    
  25.  cmd.Dispose();    
  26.  connection.Close();    
  27.  }    
  28.  }    
  29.  }    
  30. }  

當你用Dispose方法釋放未托管對象的時候,應該調用GC.SuppressFinalize。如果對象正在終結隊列(finalization queue),GC.SuppressFinalize會阻止GC調用Finalize方法。因為Finalize方法的調用會犧牲部分性能。如果你的Dispose方法已經對委托管資源作了清理,就沒必要讓GC再調用對象的Finalize方法(MSDN)。附上MSDN的代碼,大家可以參考.

  1.  public class BaseResource : IDisposable    
  2.  {    
  3. // 指向外部非托管資源    
  4.  private IntPtr handle;    
  5. // 此類使用的其它托管資源.    
  6.  private Component Components;    
  7. // 跟蹤是否調用.Dispose方法,標識位,控制垃圾收集器的行為    
  8.  private bool disposed = false;    
  9.  // 構造函數    
  10. public BaseResource()    
  11. {    
  12. // Insert appropriate constructor code here.    
  13. }    
  14. // 實現接口IDisposable.    
  15. // 不能聲明為虛方法virtual.    
  16. // 子類不能重寫這個方法.    
  17.  public void Dispose()    
  18.  {    
  19.  Dispose(true);    
  20.  // 離開終結隊列Finalization queue    
  21.  // 設置對象的阻止終結器代碼    
  22.  //    
  23. GC.SuppressFinalize(this);    
  24. }    
  25.  // Dispose(bool disposing) 執行分兩種不同的情況.    
  26.  // 如果disposing 等于 true, 方法已經被調用    
  27.  // 或者間接被用戶代碼調用. 托管和非托管的代碼都能被釋放    
  28.  // 如果disposing 等于false, 方法已經被終結器 finalizer 從內部調用過,    
  29.  //你就不能在引用其他對象,只有非托管資源可以被釋放。    
  30. protected virtual void Dispose(bool disposing)    
  31.  {    
  32.  // 檢查Dispose 是否被調用過.    
  33.  if (!this.disposed)    
  34.  {    
  35.  // 如果等于true, 釋放所有托管和非托管資源    
  36.  if (disposing)    
  37.  {    
  38.  // 釋放托管資源.    
  39. Components.Dispose();    
  40.  }    
  41. // 釋放非托管資源,如果disposing為 false,    
  42.  // 只會執行下面的代碼.    
  43. CloseHandle(handle);    
  44. handle = IntPtr.Zero;    
  45.  // 注意這里是非線程安全的.    
  46. // 在托管資源釋放以后可以啟動其它線程銷毀對象,    
  47.  // 但是在disposed標記設置為true前    
  48. // 如果線程安全是必須的,客戶端必須實現。    
  49.  }    
  50. disposed = true;    
  51. }    
  52.  // 使用interop 調用方法    
  53. // 清除非托管資源.    
  54.  [System.Runtime.InteropServices.DllImport("Kernel32")]    
  55. private extern static Boolean CloseHandle(IntPtr handle);    
  56. // 使用C# 析構函數來實現終結器代碼    
  57. // 這個只在Dispose方法沒被調用的前提下,才能調用執行。    
  58.  // 如果你給基類終結的機會.    
  59.  // 不要給子類提供析構函數.    
  60.  ~BaseResource()    
  61.  {    
  62.  // 不要重復創建清理的代碼.    
  63. // 基于可靠性和可維護性考慮,調用Dispose(false) 是***的方式    
  64.  Dispose(false);    
  65.  }    
  66.  // 允許你多次調用Dispose方法,    
  67.  // 但是會拋出異常如果對象已經釋放。    
  68.  // 不論你什么時間處理對象都會核查對象的是否釋放,    
  69.  // check to see if it has been disposed.    
  70.  public void DoSomething()    
  71.  {    
  72. if (this.disposed)    
  73.  {    
  74. throw new ObjectDisposedException();    
  75.  }    
  76.  }    
  77. // 不要設置方法為virtual.    
  78.  // 繼承類不允許重寫這個方法    
  79.  public void Close()    
  80. {    
  81. // 無參數調用Dispose參數.    
  82. Dispose();    
  83.  }    
  84.  public static void Main()    
  85.  {    
  86. // Insert code here to create    
  87.  // and use a BaseResource object.    
  88.  }    
  89.  }  
 
GC.Collect() 方法

作用:強制進行垃圾回收。

GC的方法:

名稱

說明

Collect()

強制對所有代進行即時垃圾回收。

Collect(Int32)

強制對零代到指定代進行即時垃圾回收。

Collect(Int32, GCCollectionMode)

強制在 GCCollectionMode 值所指定的時間對零代到指定代進行垃圾回收。

GC注意事項:

1、只管理內存,非托管資源,如文件句柄,GDI資源,數據庫連接等還需要用戶去管理

2、循環引用,網狀結構等的實現會變得簡單。GC的標志也壓縮算法能有效的檢測這些關系,并將不再被引用的網狀結構整體刪除。

3、GC通過從程序的根對象開始遍歷來檢測一個對象是否可被其他對象訪問,而不是用類似于COM中的引用計數方法。

4、GC在一個獨立的線程中運行來刪除不再被引用的內存

5、GC每次運行時會壓縮托管堆

6、你必須對非托管資源的釋放負責。可以通過在類型中定義Finalizer來保證資源得到釋放。

7、對象的Finalizer被執行的時間是在對象不再被引用后的某個不確定的時間。注意并非和C++中一樣在對象超出聲明周期時立即執行析構函數

8、Finalizer的使用有性能上的代價。需要Finalization的對象不會立即被清除,而需要先執行Finalizer.Finalizer不是在GC執行的線程被調用。GC把每一個需要執行Finalizer的對象放到一個隊列中去,然后啟動另一個線程來執行所有這些Finalizer.而GC線程繼續去刪除其他待回收的對象。在下一個GC周期,這些執行完Finalizer的對象的內存才會被回收。

9、.NET GC使用"代"(generations)的概念來優化性能。代幫助GC更迅速的識別那些最可能成為垃圾的對象。在上次執行完垃圾回收后新創建的對象為第0代對象。經歷了一次GC周期的對象為第1代對象。經歷了兩次或更多的GC周期的對象為第2代對象。代的作用是為了區分局部變量和需要在應用程序生存周期中一直存活的對象。大部分第0代對象是局部變量。成員變量和全局變量很快變成第1代對象并最終成為第2代對象。

10、GC對不同代的對象執行不同的檢查策略以優化性能。每個GC周期都會檢查第0代對象。大約1/10的GC周期檢查第0代和第1代對象。大約1/100的GC周期檢查所有的對象。重新思考Finalization的代價:需要Finalization的對象可能比不需要Finalization在內存中停留額外9個GC周期。如果此時它還沒有被Finalize,就變成第2代對象,從而在內存中停留更長時間。

原文鏈接:http://www.cnblogs.com/springyangwc/archive/2011/06/13/2080149.html

【編輯推薦】

  1. 漫談C#開發中的反射機制
  2. 漫談C#開發中的ASP.NET頁生命周期
  3. 淺析C#延遲加載的運行機制和應用場景
  4. C#多線程中lock的用法
  5. 用C#實現HTTP協議下的多線程文件傳輸

 

責任編輯:彭凡 來源: 博客園
相關推薦

2017-06-12 17:38:32

Python垃圾回收引用

2017-03-03 09:26:48

PHP垃圾回收機制

2017-08-17 15:40:08

大數據Python垃圾回收機制

2010-09-25 15:33:19

JVM垃圾回收

2011-07-04 16:48:56

JAVA垃圾回收機制GC

2009-06-23 14:15:00

Java垃圾回收

2011-06-08 10:06:32

C#

2021-11-05 15:23:20

JVM回收算法

2023-03-26 22:48:46

Python引用計數內存

2024-10-28 13:18:54

2021-05-27 21:47:12

Python垃圾回收

2010-09-25 15:26:12

JVM垃圾回收

2010-09-16 15:10:24

JVM垃圾回收機制

2021-12-07 08:01:33

Javascript 垃圾回收機制前端

2010-10-13 10:24:38

垃圾回收機制JVMJava

2015-06-04 09:38:39

Java垃圾回收機

2011-06-28 12:39:34

Java垃圾回收

2016-12-01 11:20:42

2022-07-21 09:15:28

C++垃圾回收

2017-10-12 12:41:11

PHP圾回收機制變量容器
點贊
收藏

51CTO技術棧公眾號

主站蜘蛛池模板: 亚洲精品乱码久久久久久按摩观 | 日韩中文字幕视频在线观看 | 亚洲精品www久久久 www.蜜桃av | 亚洲国产精品va在线看黑人 | 中文在线一区二区 | 国产精品免费一区二区 | 欧美日韩国产一区二区三区 | 国产精品亚洲综合 | 欧美xxxⅹ性欧美大片 | 国产美女一区二区 | 伊人网综合 | 婷婷在线视频 | 日韩久久久久久 | 精品综合久久久 | 亚洲男人网| 中国美女撒尿txxxxx视频 | 亚洲97| 91精品久久久| 久久久久久久久99 | 国产精品区二区三区日本 | 精品一区二区三区在线观看 | 中文字幕爱爱视频 | 在线视频一区二区 | 超级乱淫av片免费播放 | 日韩精品一区二区三区中文字幕 | 精品在线一区二区三区 | 久久国产电影 | 国产免费又黄又爽又刺激蜜月al | 日韩综合在线 | 九九久久国产 | 先锋资源站 | 欧美中文字幕一区二区三区亚洲 | 欧美综合国产精品久久丁香 | 91在线精品一区二区 | 亚洲欧美在线视频 | 日韩综合在线 | 亚洲男人网 | 91视频官网| 久久国产成人精品国产成人亚洲 | 国产在线视频一区 | 懂色中文一区二区三区在线视频 |