Prevent. NET application memory overflow (OOM) measures

Bulk and paging

In a typical Internet Web application, the data volume is large and high concurrency, without paging, or do not batch processing, always take out a lot of user data, it is easy to cause memory overhead, system memory is tight. For example, we sometimes do file operations, read the contents of the file should consider the size of the file.

Use caution with static

Using too many static applications 1:30 will not be a memory leak compared to the usual memory shortage caused by big data queries. With the operation of the system, more and more static things, memory overhead is greater, due to GC recycling strategy, invalid static account of the memory is not easy to release, over time caused by insufficient memory.

Two party libraries, three-way library, unmanaged resources, priority use of Dispose mode

Every time you call someone else's resources, you should be alert: Use your class library to take my (memory).
If you are familiar with automatic memory management, familiar with GC, understand the Dispose mode, then you will be able to call other people's resources when thinking or using a bit better, or force to assign a null is a little bit, believe that some good programming habits can make automatic memory management more effective.

Reduce the string Temp object

For example, for string + =, there are many applications in which this operation is endless. We all know that the + = operation creates a lot of temporary string objects that are prone to memory space because of the CLR's hosting of strings. If it is a high-concurrency Web application, and string operations are everywhere, and the length of the string is indeterminate, the front-end page of a variety of splicing, over time, memory consumption will be a major problem. The CLR's optimized handling of strings makes the strings not recycled, and a memory leak is more likely to occur if the string operations are frequent, the temporary string is longer (for example, greater than or equal to 85000 bytes) and the large object heap is allocated.
Many people may think of how to optimize the program to reduce the probability of generating a string's temporary object. Right, the appearance of StringBuilder is a logical.

Beware of Large objects

1. Any object greater than or equal to 85000 bytes is automatically treated as a large object, and large objects are allocated from a special large object heap. The large object heap, like the small object heap, is terminated and disposed, but the GC recycle algorithm never does memory compaction of the large object heap (Large object heap) because it wastes too much CPU time to move 85000 bytes or larger chunks of memory down the heap;
2. In. NET, the CLR uses generation-based (generation) garbage collection, the large objects are always considered part of the 2nd generation (generation), the GC analyzes which objects are unreachable, prioritizes the No. 0 and 1th generations, and the objects of the 2nd generation are generally considered to survive for a long time.
It is because of the two reasons mentioned in 1 and 2 (mainly the 1th one) that it is easy to cause memory fragmentation during garbage collection. It is recommended that a foreigner write a widely circulated article for reference: The dangers of the LOH.
As the application runs, if the Loh causes more memory fragmentation, the memory usage degradation can be very serious, such as when we are in the Web application + = splicing string (see 4th of the analysis), if the number of temporary objects is greater than or equal to 85000 bytes, then the amount of user to go up, As the system runs, the risk of an oom recovery becomes higher as the GC recovers more pressure.
Although the memory fragmentation caused the oom to seem to have no solution, but if the person writing the program to carefully analyze the problem, and try to proactively reduce the frequency of creating large objects, then the memory leaks may be reduced, good enough robust program can not completely solve oom, But we can completely minimize the likelihood of a risk happening.
A sufficiently qualified coder must be prepared and experienced enough to analyze and solve oom problems, there are many tools for analyzing and checking oom such as ants memory Profiler, and you can also analyze the RAM dump file by debugging a tool such as WinDbg. Use these tools, so that oom can not hide and lose the solution.

Prevent. NET application memory overflow (OOM) measures