一、“老生常談”值類型與引用類型 眾所周知,.NET類型系統由 類、結構、枚舉、介面 和 委托 組成。而根據記憶體分配的方式來區分,所有的類型又被分為 值類型 與 引用類型。 一說到值類型,大多數人都會自信地說,“值類型不就是 int,float,double...還有...額...還有啥來著?”。然 ...
一、“老生常談”值類型與引用類型
眾所周知,.NET類型系統由 類、結構、枚舉、介面 和 委托 組成。而根據記憶體分配的方式來區分,所有的類型又被分為 值類型 與 引用類型。
一說到值類型,大多數人都會自信地說,“值類型不就是 int,float,double...還有...額...還有啥來著?”。然後開始支支吾吾,似懂非懂,就像當初剛剛畢業的我面對面試官的提問,並且號稱自己已有一年使用c#編程的經驗(慚愧,慚愧)。
值類型的確是包括了int,float...這些c#預定義的數值數據類型,它們也有共同的名稱,叫做結構。結構和枚舉都屬於值類型,它們都隱式派生自System.ValueType。簡而言之,System.ValueType的作用是確保所有派生類型(如任何結構)都分配在棧上而非垃圾回收堆上。創建和銷毀分配在棧上的數據都很快,因為它的生命周期是由定義的作用域決定的。值類型就像是富土康在暑假期間招的學生臨時工一樣,直接從各個勞務中介那裡一批批地拉進工廠,不需要像正式工那樣複雜的入職手續,非常方便的就能上流水線操作,解決人力需求,別問我為什麼知道這麼多。
有同學可能會問 int、float 怎麼會是結構?easy,你把游標在vs中放在 int 上,你自然就會明白了。
由於值類型基於值的語法,結構(也包括所有數值數據類型 int、float 等,以及任何枚舉或自定義結構)的生命周期是可以預測的。當結構變數離開定義域的範圍是,他就會立即從記憶體中移除:
1 //本地變數在方法返回時彈出棧 2 static void func() 3 { 4 //“int”其實是 System.Int32 結構 5 int i = 0; 6 7 //Point 是結構類型 8 Point p = new Point(); 9 10 }//“i”和“p”在這裡彈出棧 11
引用類型則被創建在堆記憶體中,堆記憶體就像是一個混亂的監獄,這裡的一切不再像棧那樣井然有序,這時就必須要有一個管理者來維持秩序。當我們new一個類對象的時候,在堆記憶體中就會相應地開闢出一塊空間來存放這個對象並返回該對象的引用(引用實際上可以用指向對象的指針來理解,有學習過c指針的同學會有同感),每次訪問對象時,都是通過引用(指針)來找到相應的對象進行操作。剛創建的類對象好比就是被扔進監獄里的一個犯人,而每個犯人都有自己的牢房號,當有家屬要來探訪犯人時,獄警就會根據牢房號來找到對應的犯人,這裡的“牢房號”指的就是對象的引用(指針)。
ok,繼續用監獄的犯人來打比方,A犯人的刑期已到,到了刑滿釋放的日子了(A對象的資源要被釋放),那麼監獄的管理者到時自然就會讓獄警給A犯人登記出獄。然而這背後一切的秩序都是神秘的監獄管理者在管控著,堆記憶體中的神秘的管理者就是CLR(Common Language Runtime),它管理著托管堆中所有的對象資源,當對象的資源需要被釋放時GC(Garbage Collection)就會回收對象的資源。
相比於值類型簡單的入棧出棧的資源分配使用方式,引用類型資源的分配使用是在較為複雜的CLR的管理下由GC執行垃圾回收機制。那有人就會問了:那既然值類型的性能高於引用類型,為什麼不全都用值類型呢?或者換一種問法,我是不是可以在任何場合下肆無忌憚地使用值類型呢?
那麼試想一種情況:我自定義一個struct 類型作為一個方法的參數會發生什麼呢?由於值類型在賦值的時候都是賦值傳遞的,那麼每次調用都會發生全欄位的賦值,這是不可接受的,這也是典型的值類型誤用場景。而相對應地,引用類型在賦值的時候採用的是引用傳遞,傳遞的是對象的引用(指針),而指針變數保存的是一個指向堆記憶體中對象的地址,頂多只是一個int32的值,相較於一些複雜的結構類型來說,複製一個int的值比對結構的全欄位進行賦值要簡單的多。
說了這麼多還是不如畫張圖來的實在,下麵兩張圖分別描述了在 調用參數為類類型(引用類型)函數 與 調用參數為結構類型(值類型)函數 時記憶體中的情況:
通過上面兩張圖可以很直觀的看出值傳遞和引用傳遞的區別:值傳遞是將值類型變數的值複製一個副本然後賦值給對應的函數參數,引用傳遞則是將對象的引用(指針)複製一個副本再賦值傳遞給對應的函數參數。
ok,也很簡單嘛,值傳遞是賦值傳遞值類型數據本身,引用傳遞就是賦值傳遞對象的引用(指針)。理解了值傳遞和引用傳遞的原理,那麼下麵大家就帶著對原理的掌握來嘗試解釋下麵代碼執行的結果,廢話不多說,上代碼:
1 class People 2 { 3 public string Name; 4 public string Info; 5 } 6 7 static void Main(string[] args) 8 { 9 People newPeople = new People() { Name = "老大", Info = "老大在Main函數中被創建" }; 10 11 func1(newPeople); 12 Console.WriteLine($"Name:{newPeople.Name}|Info:{newPeople.Info}"); 13 14 func2(ref newPeople); 15 Console.WriteLine($"Name:{newPeople.Name}|Info:{newPeople.Info}"); 16 17 Console.Read(); 18 } 19 20 static void func1(People p) 21 { 22 p = new People() { Name = "老二", Info = "老二在func函數中被創建" }; 23 } 24 25 static void func2(ref People p) 26 { 27 p = new People() { Name = "老三", Info = "老三在func函數中被創建" }; 28 }
運行結果:
對這個運行結果嘗試著用前面所掌握的原理來解釋一遍:
在調用 func1函數 時,傳入的參數為 newPeople變數值 的副本,參數 p 是一個只存在於 func1函數棧 中的 People對象 的引用(指針),在func1函數體中被重新賦值為一個新創建的 (Name=“老二”)People對象 的引用(指針),但是並不影響Main函數中 newPeople 變數的值,所以 newPeople 所指向的對象依然是 (Name=“老大”)People對象;
在調用 func2函數 時,傳入的參數 p 為newPeople變數的引用(指針),於是就可以通過 p 來直接改變 Main函數棧中 newPeople變數 的值,newPeople的值被改為在 fun2函數中創建的 (Name=“老三”)People對象 的引用(指針),所以newPeople指向的是(Name=“老三”)People對象。
func1函數的參數傳遞被稱為按值傳遞引用類型,func2函數的參數傳遞則被稱為按引用傳遞引用類型(在c語言中被稱作“指針的指針”)。希望此時你的腦海中已經能清晰地構建出記憶體變化的圖像,如果能像我一樣畫出記憶體的變化圖,那麼你就對值傳遞和引用傳遞就已經瞭然於胸了。
這裡再貼上一張值類型與引用類型的對比圖(一目瞭然):
二、裝箱與拆箱
大家都知道在C#中所有的類型都繼承自System.Object,可以說Object類是所有類型的老祖宗。也正是基於這個原理,會有下麵這段代碼:
1 class Box 2 { 3 static void Main(string[] args) 4 { 5 int a = 5; 6 7 func(a); //在傳入int變數a之前,CLR對變數a的值進行裝箱,返回object引用 8 } 9 10 static void func(object o) 11 { 12 //將引用拆箱為相應的int 13 int i = (int)o; 14 } 15 }
這段代碼的看點在於:函數func的參數類型為object,由於c#中所有的類型都隱式繼承自System.Object,所以參數 o 可以接收任意類型的傳入參數,在函數中再根據不同的傳入參數類型進行不同的處理,這在不清楚傳入參數類型的情況下是非常有用的。當然,這段代碼的用途顯而易見,大家一看就能明白,可是如果結合上面所講的值傳遞與引用傳遞的原理,細心的同學可能會發現一個不合理的地方。
不合理的地方在於:函數的參數類型為object,System.Object 歸根結底是一個引用類型,按道理說在傳遞參數時賦值傳遞的應該是保存在堆記憶體中對象的引用,但是在這裡我們看到的是函數參數o竟然接收的是一個值類型!再回想前面值傳遞的原理,值類型在賦值時會複製一個副本賦值傳遞給值類型參數,而這裡的函數參數o又不是值類型的參數,總之,這個地方很詭異!那麼,在這裡的值類型數據傳參賦值給引用類型參數的背後,是誰在作祟??
答案是,CLR在這裡進行了裝箱(box)操作。
裝箱可以正式定義為:顯示地將值類型分配給 System.Object 變數的過程。當我們對一個值進行裝箱時,CLR就會在堆記憶體中分配新的對象並且將值類型的值(這裡是 5)複製到那個實例上。因此,返回給我們的就是新分配在堆上的對象的引用,這個返回的引用被賦值給了 函數func 的 參數o。使用這項技術,就不需要使用一組包裝類來把棧數據臨時當成分配在堆上的對象進行處理。
相反的操作可以通過拆箱(unbox)來實現。拆箱就是把保存在對象中的值轉換回棧上的相應值類型。CLR首先會驗證收到的值類型是否等價於裝箱的類型,如果是,就將值賦值回本地棧變數上;如果嘗試將數據拆箱為不正確的變數,將拋出 InvalidCastException 異常。也就是說,拆箱必須回到合適的數據類型。
當C#編譯器發現裝箱/拆箱語法時,所生成的CIL代碼包括 box/unbox 操作碼。如下所示:
.method private hidebysig static void Main (string[] args) cil managed { .maxstack 1 .entrypoint .locals init ( [0] int32 ) IL_0000: nop IL_0001: ldc.i4.5 IL_0002: stloc.0 IL_0003: ldloc.0 IL_0004: box [mscorlib]System.Int32 IL_0009: call void boxing.Box::func(object) IL_000e: nop IL_000f: ret }
.method private hidebysig static void func (object o) cil managed { .maxstack 1 .locals init ( [0] int32 ) IL_0000: nop IL_0001: ldarg.0 IL_0002: unbox.any [mscorlib]System.Int32 IL_0007: stloc.0 IL_0008: ret }
看到這有人會說:好吧,裝箱拆箱我懂了,可是這個東西......知道當然更好,不知道好像也沒什麼影響,畢竟這一切操作都是CLR在背後自動完成的,不需要我們自己做什麼。其實不然,知道了裝(拆)箱,對實際的編程還是具有一定指導意義的,可以看一下下麵這個例子。
在.NET平臺最初發佈時,程式員常常使用 mscorlib.dll 中的System.Collections 命名空間。該命名空間提供了很多類來管理和組織大量的數據。常用的集合類包括 ArrayList、Hashtable、Queue、Stack ...... 在當時很多.NET程式都使用這些集合類來構建,但是事實證明使用這些類型會造成相當多的問題。
ArrayList類的部分定義如下:
1 public class ArrayList : IList, ICollection, IEnumerable, ICloneable 2 { 3 ... 4 public virtual int Add(object value); 5 public virtual void Remove(object obj); 6 public virtual void Insert(int index, object value); 7 public virtual object this[int index] { get; set; } 8 }
通過上面這段ArrayList類的部分方法成員我們發現:
1、ArrayList在操作增刪改查數據的過程中是類型不安全的,不管傳入的數據是什麼類型,最後通過索引取出來的數據都是由object類來接收,所以這就要求你事先必須知道你存進這個數據的時候它是什麼類型的,當強制轉換時如果錯判了類型則會引發異常。
2、第二個問題則是關於性能方面的,當在使用ArrayList類進行Add操作時,如果傳入的數據類型為值類型,那麼就會發生 裝箱 ,相應地在使用索引取出操作時,為了獲取原數據類型的數據便於操作,又必須進行 拆箱 操作,我們同時要意識到的是ArrayLIst這個類本來就是為了管理和組織大量的數據,重點在於“大量”,如果只是個別的值類型數據進行裝(拆)箱,那倒也還好,但是在使用ArrayList處理大量的值類型數據時,那麼你就不得不註意程式的性能了,畢竟 裝(拆)箱 過程要消耗的資源可不小。
當然,問題總會被解決的,如果你現在需要集合類來幫助你管理和組織大量的數據,那麼你的首選當然是 泛型集合 咯。
最後自己在這立個Flag! 由於自己現在處於畢業的第一份工作中,其實自己對來到的這家公司並不是很滿意,原因是這家公司不是一家純互聯網公司,但崗位是WEB開發,平常的工作就是配合產線解決問題之類,很少開發,維護工作居多。剛來3個多月,但是看到這裡用的技術我懵逼了,什麼朝代了還在用webform?對自己的未來感到深深的擔憂,自己的技術生涯何去何從。。。所以,不能墮落,要努力學習,為不遠的將來出坑做好準備。於是,我打算從現在起每周至少寫一篇技術博客,一個是為了促進自己不斷學習的步伐;再一個就是希望能多總結多交流,從中獲益。相信技術能帶給我想要的一切!加油。