Compare the binning and object.

Compare the binning and object.

See this interview question:

int  i = 10;
object obj = i;
int j = (int) obj;

Analyze the memory processing in program execution.

First, we can see that this program defines three local variables, and the local variables will be defined in the stack. The first variable is relatively simple, because I is an integer variable, therefore, the value of variable I is directly stored in the stack.

The assignment of obj in the second row is a little more complicated. Because obj is of the object type and this is a reference type, it must be a reference to an object stored in the stack, it cannot be a value. In this case, the well-known packing occurs. CLR creates an object in the heap and saves the value of variable I in this object, it also saves the type of this value. Here it is an integer type. At this time, there will be two 10 in the memory, one is saved in the stack, and the other is saved in the heap.

Some people think that the value saved in the object in the heap is the value of j in the stack. We can verify this problem. If so, we can modify the value of I, so obj should also change. We can add two rows after the second row to check I.

i = 99;
Console.WriteLine( obj );

You can check whether obj has changed.

When the third line is executed, assign a reference type object to a value type variable j. In this case, another famous event occurs: unpacking, CLR checks whether the binning type matches, then reads the value saved in it from the heap object, and saves the value to variable j in the stack. So far, there are three 10 in the memory, two in the stack, and one in the heap. :

If we add another line for the above program:

object obj2 = i;

So what will happen?

Some people think that the heap is actually a binning object in the second line. In this case, obj2 references this object. The structure of the memory is as follows:

It is a little complicated to verify this problem, because we cannot assign values to obj, and assign values to another object. This boxed object does not have any way for us to modify the value without changing the object.

However, we still have a way to check whether they are the same object.

First, we can consider the HashCode of the Object and define the GetHashCode method on the Object base class to return the Hash code of the Object, generally, we can compare the HashCode of an object to determine whether the referenced object is the same. Then, we can use the following statement to check.

Console.WriteLine( obj.GetHashCode() );
Console.WriteLine( obj2.GetHashCode() );

However, unfortunately, you will see 10 output twice. Are they the same object? We can't say that.

HashCode is mainly used when an object acts as a dictionary key to determine whether the keys are the same. However, sometimes we want different objects to be treated as the same key, therefore, the GetHashCode method is actually a virtual method and can be overwritten by the type. In the integer type, this method has been overwritten, so you will see that the HashCode returned with the same value as the integer is the same.

For example, if you have two 10 Yuan, the two yuan are obviously not the same, but their face prices are the same, no matter which one you use to store it in the bank, the bank will write down the deposit of 10 yuan for you, which is called equal value, that is, the same value. The Object base class also defines the Equals method. This Equals method is used to determine the same value. Therefore, after rewriting the GetHashCode method, you should also rewrite the Equals method to ensure the comparison of equal values.

Back to our problem, we obviously need to judge whether the values are equal. Is there any other way? Yes, the Object base class also has a static method ReferenceEquls, which is used to compare whether two objects are actually the same Object instance. This is called reference equality. Therefore, the following code can be easily used to complete this task.

Console.WriteLine( Object.ReferenceEquals( obj, obj2 ) );

The problem has basically been solved. But how does CLR know whether these two objects are the same? In the system, once every object is generated in the application domain, CLR will assign a unique HashCode. Although we can rewrite GetHashCode, this internal HashCode still exists, defined in the namespace System. runtime. the RuntimeHelpers helper class in the ComilerServices namespace can help us solve this problem. Its static method GetHashCode can accept an object reference and return the underlying HashCode of this object.

Using the following code, we can see that the HashCode of the two objects is really different.

Console.WriteLine(System.Runtime.CompilerServices.RuntimeHelpers.GetHashCode(obj));
Console.WriteLine(System.Runtime.CompilerServices.RuntimeHelpers.GetHashCode(obj2));

The actual memory structure should be as follows:

The complete code is as follows:

int i = 10;
object obj = i;
int j = (int)obj;
object obj2 = i;

Console.WriteLine(obj.GetHashCode());
Console.WriteLine(obj2.GetHashCode());

Console.WriteLine(Object.ReferenceEquals(obj, obj2));
Console.WriteLine(System.Runtime.CompilerServices.RuntimeHelpers.GetHashCode(obj));
Console.WriteLine(System.Runtime.CompilerServices.RuntimeHelpers.GetHashCode(obj2));