Shulou(Shulou.com)06/02 Report--

This article shows you how to verify the effect of fixed keywords, the content is concise and easy to understand, can definitely brighten your eyes, through the detailed introduction of this article, I hope you can get something.

When talking about the performance of String connection operations, unsafe operations are involved, while unsafe operations are bound to involve pointers, so the fixed keyword arises at the historic moment. The fixed keyword is used to pin a reference address, because we know that CLR's garbage collector will change the address of certain objects, so references to those objects will change after changing the address. This change is unconscious for programmers and is therefore not allowed in pointer operations. Otherwise, the address we have reserved before will not be able to find the object we need after GC. Now let's do a little experiment to verify the effect of the fixed keyword.

Of course, this experiment is very simple, and it may make you laugh. First, let's prepare a SomeClass class:

Public class SomeClass {public int Field;}

Then prepare a piece of code:

Private static unsafe void GCOutOfFixedBlock () {var a = new int; var c = new SomeClass (); fixed (int* ptr = & c.Field) {PrintAddress ("Before GC", (int) ptr);} GC.Collect (2); fixed (int* ptr = & c.Field) {PrintAddress ("After GC", (int) ptr) }} private static void PrintAddress (string name, int address) {Console.Write (name + ": 0x"); Console.WriteLine (address.ToString ("X"));}

In the GCOutOfFixedBlock method, we first allocate an int array of length 100, and then create a new SomeClass object. The purpose of creating a new array is to create "garbage" to change the position of the SomeClass object in the heap when the GC.Collect method is called. Because garbage collection occurs outside the fixed code block, the values we print out before and after are different:

Before GC: 0x1A058C0

After GC: 0x1975DF4

It is worth noting that this code must be compiled in Release mode and optimized when CLR executes the code, so that CLR will find that the an array is already garbage during garbage collection (because the later code will not use it), so it will be recycled-- otherwise the effect of the address change will not be seen. So, let's rewrite a piece of code:

Private static unsafe void GCInsideFixedBlock () {var a = new int; var c = new SomeClass (); fixed (int* ptr = & c.Field) {PrintAddress ("Before GC", (int) ptr); GC.Collect (2);} fixed (int* ptr = & c.Field) {PrintAddress ("After GC", (int) ptr);}}

The results are as follows:

Before GC: 0x1B558C0

After GC: 0x1B558C0

Because the GC occurs inside the fixed code block, the c object is pin on the heap, so the address of the c object remains the same before and after the GC, which is what fixed does. So, what is the result of running the following code?

Private static unsafe void Mixed () {var a = new int; var C1 = new SomeClass (); var c2 = new SomeClass (); fixed (int* ptr1 = & c1.Field) {PrintAddress ("Before GC", (int) ptr1);} fixed (int* ptr2 = & c2.Field) {PrintAddress ("Before GC (fixed)", (int) ptr2) GC.Collect (2);} fixed (int* ptr1 = & c1.Field) {PrintAddress ("After GC", (int) ptr1);} fixed (int* ptr2 = & c2.Field) {PrintAddress ("After GC (fixed)", (int) ptr2);}} the above is how to verify the effect of fixed keywords. Have you learned any knowledge or skills? If you want to learn more skills or enrich your knowledge reserve, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.