The term "boxing" is very opaque, but it is easy to visualize what is actually going on by using the debugger. Write a little console mode application like this:
using System;
namespace ConsoleApplication1 {
class Program {
static void Main(string[] args) {
int value = 42;
object obj = value;
} // <== Breakpoint here
}
}
Set a breakpoint where indicated and press F5. When the breakpoint hits, use Debug + Windows + Memory + Memory 1. In the Address box, type "obj". You'll get a hex dump of the memory content of the object. Right-click the window and select "4-byte Integer", the best way to visualize the object in this case. You'll see something resembling this:
0x01CBF6BC 6e1a2d34 0000002a
The interesting parts here are 0x01CBF6BC, that's the address of the object on the garbage collected heap. The next hex number, 6e1a2d34 is the so-called "type handle", also known as the "method table pointer". That a 'cookie' that identifies the type of the object. System.Int32 in this case. Very important, it will be used later when the object is unboxed back to an Int32 to verify that the boxed value is actually an integer.
The next value you see, 0000002a, is the value of the boxed object. You can use Windows calculator in programmer mode to convert back to decimal, it is 42.
Experiment with this, using different values and different types to see how it affects the boxed object. You can modify the hex and see what effect it has on the obj value as displayed by the debugger.
The hex dump I gave you was for a 4 byte boxed value, boxing a double will take 8 bytes. Boxing a struct will take more bytes. There's also a part of the object header you can't see, the so-called syncblock, located at the address - 4. Try the lock statement to see that changing.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…