Understanding the Disadvantages of Memory Management in .NETMemory is one of the critical resources of any application you develop. If memory is not handled properly, it might lead to many bugs and major performance issues. Most of the issues occur either because you don’t free memory when it is no longer required or you try to access memory which is already freed. You will come to know about the common problems of memory management in .NET by going through this article. Memory
is Limited: Memory that can be used by an application is very limited.
When the memory becomes full, your application cannot proceed with its
functionality.
When your program tries to allocate memory wherein the managed heap is already full, then OutOfBoundsMemoryException will be thrown. Though CLR initiates Garbage Collector automatically, you have to ensure that you explicitly close the unmanaged resources used in your program. Also ensure that you perform caching only for few minutes and for contents which are very expensive when reloaded. You can use Page Level Output Caching to cache the entire page and Fragment Caching to cache only certain portions and not the entire Page. Difficulty in Replicating Bugs: Incorrect Memory Management can lead to bugs. But most of the bugs will occur only in very specific cases and therefore replicating the bug in itself will be a hectic and time consuming job. Once debug is done, resolving the bug will require so much of analysis to decide on the correct approach to be followed. Hence while programming itself you ensure that memory is managed correctly and efficiently. Freeing and Utilization of Memory is Unpredictable: Though you set an object reference to null and close all opened connections, the memory allocated to those resources are not freed and reused immediately. It all lies in the hands of Garbage Collector and when it is triggered. Try to reuse object instances wherever possible instead of freeing the object and creating a new instance. You really don’t know when the object’s memory will be freed. Therefore be cautious, if not your program will end up in memory leaks or object destabilization. Memory Usage Based on Type: Number of resources accommodated in the memory is not an issue. But what matters is the type and assembly of resources. Based on the type of resource, required bytes are allocated in memory. For example, double requires 8 bytes and decimal requires 16 bytes. These are relatively less memory utilization. However usage of structure and references occupy more memory. Hence use them only when they are really required. Unmanaged Resources are Not Garbage Collected: Unmanaged resources like files, handles and streams are allocated in a different heap called unmanaged heap. Garbage Collection is automatically performed only on managed resources and not on unmanaged resources. Hence if you don’t explicitly clean them, memory remains allocated. You can use IDisposable interface and perform the clean up activity inside the Dispose () function. Occurrence of Memory Leaks: If you don’t free the memory that is no longer in use in your code, then Memory leaks will occur. Of course this situation will not occur for managed resources since garbage collector does the cleanup automatically. But it arises when unmanaged resources are not explicitly freed in your code. This cannot be handled by .NET runtime. How do you trace that Memory Leak might have occurred in your program? If the memory consumption of your program is continuously increasing during execution, then you have to analyze your code carefully to check for memory leaks. Object Destabilization: If you are trying to access an object in a memory location which is already freed, Object Destabilization occurs. This might lead to corruption of data since you might change some other data accommodated in the memory location assuming that it is your object. It might also lead to dangling references.
|