Managed heap Memory allocation optimization

Memory issues overview As with CPUs, memory is also an important hardware resource that directly affects the performance of the server. In general, if the server is low on memory, it causes the following two problems to occur:

1. Cause the server to write some of the data that would otherwise be written to memory and write it to the hard disk. This not only increases CPU and disk I/O operations, but also extends the time it takes to read the data.

2. Blocking the use of some cache policies.

For memory shortage, the fastest and most direct way is to buy the memory bar added to the server. However, the problem is that there is a hidden trouble is: If the new memory, the server is facing the problem of insufficient memory, we can not indefinitely add memory, then we must from the site itself to solve the problem, such as from the server configuration, the site of the Code analysis, optimization.

Managed resource Optimization

For managed resources, it is no stranger to believe that you are, simply, a resource created on the managed heap of C #, or an object that is generated through new. Before we dive in, let's take a look at the "Object life cycle"

The life cycle of an object

When we create an object with the New keyword, the object is assigned to the CRL managed heap. This managed heap is in memory. And this allocation of object space is very fast, because each time in the last side of the managed heap to draw a certain amount of space to give this object, do not need to find a suitable size of space on the heap. If, when the managed heap is ready to allocate space for an object, the space above the managed heap is found to be too small to be allocated to the new object, the CLR starts to run the garbage collection mechanism. We know that the garbage collection mechanism cleans up those objects that are not referenced on the managed heap, and compresses the existing objects on the managed heap. But one thing needs to be clear: if there is garbage collection at this time, some unused objects are cleared, but only the next time the garbage collection is done, the objects that were purged from the last GC are actually removed from memory (at this point, there are some "object recovery" topics that are not discussed).

Here are some garbage collection topics to tell.

The "generation" of the object

When the CLR is garbage collected, the garbage collector goes back to the managed heap to check if objects can be recycled, which is a very resource-intensive process. To prevent every garbage collection from facilitating all objects on the managed heap, the CLR divides the objects above the managed heap into "generations", for example, the first generation, the second generation. Then, every time the managed heap is conveniently scanned, it scans for objects in a "generation", which is a good performance.

On the managed heap, the object can be divided into three "generations": 0 generations, 1 generations, 2 generations, only this three generations. Each object starts with the 0 generation. Each time an object is garbage collected, and the object is still in use, the object's "generation" increases by 1 generations. For example, if a 0-generation object undergoes a garbage collection, his generation is 1 generations, and if it is a 1-generation object, it will eventually become 2 generations. 　　 　　If the object itself is already 2 generations, no matter how many times the garbage collection (if the object is always in use), then this object is 2 generations. In the CLR garbage collection, one thing to remember: "The greater the number of generations, the less likely it is to be recycled." And some performance optimizations are based on this.

Each time the CLR is in a garbage collection, it takes priority to scan the No. 0 generation of objects, so some new, temporarily used objects can be cleared immediately. In contrast, the garbage collector scans the 1th generation of objects for no more than the No. 0 generation, and scans the 2nd generation of objects less frequently. So, the longer the object survives, the harder it is to be recycled, and it always occupies the CLR's memory resources.

It is also important to note that if the CLR decides to scan the 1th generation, it also scans the No. 0 generation object, and if the CLR scans the 2nd generation, then the No. 0, 1th objects will be scanned.

So, here's what we can do: we try to avoid turning objects that need to be recovered immediately into long-lived objects. Popular Point says is: If an object has already survived in 0 generations, and then use up the recycling, we do not let this object has survived to the 1th generation, even 2nd generation. This is basically the idea of programming: instantiating objects as late as possible, releasing objects as early as possible.

Large Object Heap (Large Objecet heap)

We've covered some of the topics of "heap" before, and the CLR has another heap in the CLR in addition to the general heap above (the heap where the general new object allocates space): a heap that is dedicated to placing objects larger than 85k, large objects.

If the object is larger than 85k when the object is new, the CLR will place the object on the Loh. If the Loh does not have enough space at this time, then the CLR starts the garbage collector to scan the Loh heap and the 2nd generation object on the general heap, as we said before, if we scan the 2nd generation object, and then scan the 1th generation, No. 0 generation, then the actual equivalent of scanning the entire managed heap, the performance impact can be imagined.

And do not want to that general heap, in the Loh above the object is garbage collector recycling, the above large objects will not be compressed, then loh this heap there may be some "space debris", and then allocate new large objects, it is necessary to find space, and even to defragment, You can think of our computer's disk defragmentation.

Managed heap Memory allocation optimization