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