裝箱是隱式的;拆箱必定是顯式的,。
與簡(jiǎn)單的賦值操作相比,,裝箱和拆箱都需要進(jìn)行大量的數(shù)據(jù)計(jì)算。對(duì)值類型進(jìn)行裝箱時(shí),,CLR 必須重新分配一個(gè)新的對(duì)象,。拆箱所需的強(qiáng)制轉(zhuǎn)換也需要進(jìn)行大量的計(jì)算,,兩者相比,僅僅是程度不高,,并且也可能會(huì)出現(xiàn)類型轉(zhuǎn)換發(fā)生的異常情形,。如果你的操作正處于循環(huán)的中心,通過測(cè)試(如:Stopwatch),,你會(huì)很明顯的感覺到性能問題,。
static void Main(string[] args) { var i = 123; //System.Int32 //對(duì) i 裝箱(隱式) object obj = i; //對(duì) obj 進(jìn)行拆箱(顯式) i = (int)obj; Console.Read(); }
在這里,,我先將變量 i
(int 類型)進(jìn)行了裝箱,,并分配給對(duì)象 obj
。其次,,再次將對(duì)象 obj 進(jìn)行拆箱(即強(qiáng)轉(zhuǎn))并重新給變量 i(int 類型)賦值,。
直接通過反編譯得到的 IL 代碼,從 box 和 unbox 這兩個(gè)指令也可以看出具體在哪一步發(fā)生裝箱和拆箱操作,。
值類型和引用類型,,這兩者本來沒有多大的聯(lián)系(可能就是基類為 object),設(shè)計(jì)人員通過一種名為裝拆箱的操作使得這兩種類型創(chuàng)建了新的聯(lián)系,,讓任何值類型都可以當(dāng)成對(duì)象(引用)類型來進(jìn)行操作,。
裝拆箱其實(shí)就是值類型和引用類型兩者之間的類型轉(zhuǎn)換操作。這里,,我簡(jiǎn)單梳理一下這兩種類型:
?。?)值類型:整型:Int;長(zhǎng)整型:long,;浮點(diǎn)型:float,;字符型:char;布爾型:bool,;枚舉:enum,;結(jié)構(gòu):struct;它們統(tǒng)一繼承 System.ValueType,。
?。?)引用類型:數(shù)組,用戶定義的類,、接口,、委托,object,,字符串等,。
?。?)簡(jiǎn)單的堆棧圖:
裝箱就是值類型到 object 類型或者到該值類型所實(shí)現(xiàn)的接口類型所實(shí)現(xiàn)的一個(gè)隱式轉(zhuǎn)換過程(可顯式)。裝箱的時(shí)候會(huì)在堆中自動(dòng)創(chuàng)建一個(gè)對(duì)象實(shí)例,,然后將該值復(fù)制到新對(duì)象內(nèi),。
var i = 123; //System.Int32 //對(duì) i 裝箱(隱式)進(jìn)對(duì)象 o object o = i;
從圖可知,對(duì)象 o 存的是地址引用,,指向的是堆上的值,,這個(gè)值的類型和變量 i 一樣,也是 int 類型,,值(123)也就是從變量 i Copy 過來的一個(gè)副本值而已,。
【備注】裝箱默認(rèn)是隱式的,當(dāng)然,,你可以選擇顯式,,但這并不是必須的。
拆箱是從 object
類型到值類型,,或從接口類型到實(shí)現(xiàn)該接口的值類型的顯式轉(zhuǎn)換的一個(gè)過程,。
拆箱:檢查對(duì)象實(shí)例,確保它是給定值類型的一個(gè)裝箱值后,,再將該值從實(shí)例復(fù)制到值類型變量中,。
int i = 123; // 值類型 object o = i; // 裝箱 int j = (int)o; // 拆箱
要在運(yùn)行時(shí)成功拆箱值類型,被拆箱的項(xiàng)必須是對(duì)一個(gè)對(duì)象的引用,,該對(duì)象是先前通過裝箱該值類型的實(shí)例創(chuàng)建的,。
拆箱時(shí)需要注意,轉(zhuǎn)換出現(xiàn)異常的情形:
雖然,,decimal 類型可以直接強(qiáng)轉(zhuǎn)為 int 類型,,但從調(diào)式的結(jié)果來看,拆箱時(shí)是會(huì)引發(fā)“轉(zhuǎn)換無效”的異常,。要記住,,拆箱時(shí)強(qiáng)轉(zhuǎn)的值類型,應(yīng)以裝箱時(shí)的值類型一致,。
深藍(lán)醫(yī)生:簡(jiǎn)單說,,裝箱就是把值類型變成引用類型使用;拆箱就是將引用類型變成值類型使用,。然而,,大量使用值類型會(huì)引起變量值的大量拷貝,,反而降低運(yùn)行效率,。所以裝箱沒有那么可怕,這可以通過 EF的code first和SOD框架的code first代碼進(jìn)行測(cè)試(要有業(yè)務(wù)層代碼這種),,雖然SOD框架的實(shí)體類看起來都是“裝箱”過的,,但是它的性能不會(huì)輸給EF,。
lulianqi15:最后加的一句注意(decimal 類型可以直接強(qiáng)轉(zhuǎn)為 int 類型........應(yīng)以裝箱時(shí)的值類型一致),其實(shí)不太嚴(yán)謹(jǐn),,decimal 128位,,想想都不可能無緣無故轉(zhuǎn)換成32位的數(shù)據(jù),之所以能強(qiáng)制轉(zhuǎn)換,,是因?yàn)镈ecimal 自己實(shí)現(xiàn)了自定義強(qiáng)制轉(zhuǎn)換public static explicit operator int(decimal value),。回到最后例子的報(bào)錯(cuò),,JIT肯定是知道obj是Decimal(因?yàn)镈ecimal數(shù)據(jù)移動(dòng)到托管堆上后后還額外為其添加了類型對(duì)象指針及同步塊索引,,所以即使obj在ide里申明為object,不過jit是知道他就是Decimal)之所以發(fā)生異常的原因是CLR認(rèn)為在生成il時(shí)就認(rèn)為obj是object類型,,而object沒有實(shí)現(xiàn)explicit 指定重載(當(dāng)然可以自己實(shí)現(xiàn)),。所以就調(diào)用了object默認(rèn)的強(qiáng)制轉(zhuǎn)換,檢查類型指針的時(shí)候發(fā)現(xiàn)不合法就報(bào)錯(cuò)了,,那如果認(rèn)可Decimal可以強(qiáng)制轉(zhuǎn)換為int,,說到底最后在強(qiáng)制轉(zhuǎn)換報(bào)錯(cuò)的根本原因也只是object沒有實(shí)現(xiàn)explicit 指定重載。如果自定義類型自己實(shí)現(xiàn)了explicit,,那在轉(zhuǎn)換時(shí)也不用保證其運(yùn)行時(shí)類型與要轉(zhuǎn)換的類型一致,。