A memory leak occurs when a program fails to release memory that it has allocated but is no longer using and is not recoverable.
Introduction
A memory leak occurs when a program fails to release memory that it has allocated but is no longer using. In many cases, the memory cannot be referenced and will therefore never be recovered to be reallocated. Even in cases where the memory can be referenced, some other code may be causing it from being recovered. Memory leaks are particularly important for developers to be wary of, as they can be extremely difficult to debug. There are many established practices in code are put into place specifically for the purpose of avoiding memory leaks.
The Impact of Memory Leaks
Every running program or application, no matter the environment must have memory allocated to itself in order to (at least temporarily) store its data and even run its code. When an program with one or more memory leaks is run, this memory will be overlooked by the system because the system thinks that it is being used, either because it has been told or the requirements for dead memory have not been met. Depending on the intensity and veracity of the leak, this can potentially quickly result in the system being unable to allocate memory for other programs (even itself) causing poor performance and unintended faults. In some less modern environments, memory leaks have the capability to crash the system unexpectedly which can lead to other issues.
Managed-Memory Environments (Intentionally general)
A managed memory environment is one where a subsidiary environment is created to directly monitor memory usage, its allocation, recovery and reallocation to programs that run within it. For many developers, this is desirable because it allows developers to build their applications and trust that the proper amount of memory will be allocated when needed and released when not. The most common of these is the Run-time Environment, which allows (and sometimes forces) programs to run in its memory space. In reality, the memory manager is just another program that runs on behalf of the system, often called the Garbage Collector.
Garbage Collectors can be system-specific or even language-specific, requiring that programs written in a particular language always run in a managed-memory space. Due to the fact that the memory manager is a program, it looks for indicators of unused memory to determine whether recovery is needed. Each memory manager has specific criteria that it checks, the most common of which is when neither the program nor any of its code reference (via a pointer) a specific block of memory. Without regard to the specific environment semantics, the most general practice for leak prevention is: Remove any reference that is no longer in use. This means to either a) release all pointers or b) set explicit object references to null (depending on the language).
Unmanaged-Memory Environments (Intentionally general)
An unmanaged-memory environment is when a program directly requests memory from the system and is responsible for releasing the memory itself. The most widely-known example of this native code in C or C++. As a result of the popularity of these languages, malloc() has become a key indicator of running in an unmanaged memory environment.
Unmanaged Memory Environments are desirable for many developers, because the program has direct control over the use of its memory space. The developer can preempt data intensive operations and request memory blocks before they are immediately needed, easing some processor strain. Additionally, they typically have a more intimate knowledge of how the memory is being used by their program and can release memory with relative certainty that it is unused.
While, there are many practices established dedicated to the avoidance of leaks, the credo is always the same: Watch what you're using, clean up what you are not. In practice, this simply means for every allocation the program makes, ensure there is at least a release of the same size before the program exits.
Avoiding Memory Leaks
Most memory leaks are caused by code practices or techniques that are not complementary to the mechanisms by which the environment allocates and frees memory. As software technology has progressed, the term environment has become more fluid as many languages have their own mechanisms to assist the system in managing memory. Even though there may be semantics that are environment-specific, most leak prevention is based on simple practices that depend on the type of memory environment the program is working in. In general, avoiding memory leaks requires two essential components:
- An awareness of the environment that the program will be running in
- Some comprehension of how language that the program is developed in allocates and frees memory
Due to the dependency on the memory environment and language semantics, the majority of information on memory leaks is environment-specific. Good practices may require specific research on the operating system and the language semantics, or general research on the type of memory environment and development model. Refer to the documentation for the operating system and the programming language for more detailed information.
