I feel like developers talk about memory leaks but when you ask them what that means many have no idea. To prevent these situations, let's decide on one.
Please no Wikipedia definitions...
What is your best definition of a memory leak and what is the best way to prevent them?
Definition: Failure to release memory after allocation
Mozilla has a great page on tools for tracking down memory leaks.
The process in which memory resource are allocated and not properly released once no longer required, often introduced through bad coding practices.
There are built in ways in some languages to help prevent them, although the best way to avoid them is through diligent observation of code execution paths and code reviews. Keeping methods short and singularly purposed helps to keep resource usage tightly scoped and less prone to get lost in the shuffle, as well.
Memory that is not deallocated when it is no longer needed, and is no longer "reachable". For instance, in unmanaged code, if I use "new" to instantiate an object, but I don't use "delete" when I'm done with it (and my pointer has gone out of scope or something).
The best way to prevent them probably depends on who you ask and what language you are using. Garbage collection is a good solution for it, of course, but there may be some overhead associated with this, which isn't a big deal unless you performance is your primary concern. Garbage collection may not always be available, again, depending on the language you are using.
Alternatively, you can make sure you have the appropriate deletes and/or destructors in place. There's a lot of methods and tools to detect memory leaks as well, but this will depend on the language and/or IDE you are using.
There are two ways a memory leak may be defined.
First, if data is not freed when there are no longer has any references to it, that data is unreachable (unless you have some corrupt pointer or read past the data in a buffer or something). Basically, if you don't free/delete data allocated on the heap, it becomes unusable and simply wastes memory.
There may be cases where a pointer is lost but the data is still accessible. For example, if you store the pointer in an int, or store an offset to the pointer (using pointer arithmetic), you can still get the original pointer back.
In this first definition, data is handled by garbage collectors, which keep track of the number of references to the data.
Second, memory is essentially leaked if it is not freed/deleted when last used. It may be referenced, and immediately free-able, but the mistake has been made not to do so. There may be a valid reason (e.g. in the case where a destructor has some weird side effect), but that indicates bad program design (in my opinion).
This second type of memory leaking often happens when writing small programs which use file IO. You open the file, write your data, but don't close it once you're done. The FILE* may still be within scope, and easily closeable. Again, there may be some reason for doing this (such as locking write access by other programs), but to me that's a flag of bad design.
In this second definition, data is not handled by garbage collectors, unless the compiler/interpreter is smart (or dumb) enough to know it won't be used any longer, and this freeing the data won't cause any side effects.
Allocated memory that cannot be used because the reference to it has been lost.
edit: This answer is wrong. I'm leaving it up as an example of how easy it is to be mistaken about something you think you know very well. Thank you to everyone who pointed out my mistake.
A memory leak is: A programming error. Your software borrows some memory from the system, uses it, and then fails to return it to the system when it has finished. This means that that particular chunk of memory can never be used by any other programs until the system is rebooted. Many such leaks could use up all of the available memory, resulting in a completely useless system.
To prevent memory leaks, practice RIIA, and always test your software. There are plenty of tools available for this task.
Memory Leak: Failing to free memory that you no longer need before either:
Best way to prevent Memory Leaks: Free memory as soon as it is no longer needed.
There are two definitions (at least for me):
Naive one: Failure to release unreachable memory, which can no longer be allocated again by any process during execution of allocating process. It can mostly be cured by using GC techniques or detected by automated tools.
Subtle one: Failure to release reachable memory, which is no longer needed for your program to function correctly. It is nearly impossible to be detected by automated tools or programmers who is not too familiar with the code. While technically it is not a leak, it has the same implications of the naive one. This is not my own idea only. You can come across projects that are written in a garbage collected language but still mentions fixing memory leaks in their changelogs.
All the definitions given here fail to address one borderline case:
You have a singleton that allocates memory upon creation and this memory is normally held as long as the program is running even though the current use is done and it's unknown whether any future use will ever be made or not. This is generally done because of the overhead of recreating it.
By the "fail to free when done with it" standard this would be considered a leak and I've seen leak-reporting tools call such things leaks as the memory was still in use. (And in fact the code may not contain code capable of cleaning the object up.)
However, I have encountered code of this nature in compiler libraries before even when the cost of recreating the object isn't all that great.
Leak or not?
In computer science, a memory leak is a particular type of unintentional memory consumption by a computer program where the program fails to release memory when no longer needed. This condition is normally the result of a bug in a program that prevents it from freeing up memory that it no longer needs.
Here are some techniques for preventing / detecting memory leaks:
Consider your algorithm in terms of memory consumption. Other respondents have mentioned the fact that you don't have to lose the pointer to an allocated item to leak memory. Even if your implementation contains zero pointer bugs, you can still effectively leak memory if you hold onto allocated items long after you actually need them.
Profile your application. You can use memory debugger tools like Valgrind or Purify to find leaks.
Black-box testing. Watch what happens to your compiled code after you feed it large data sets, or allow it to run for long periods of time. See if its memory footprint has a tendency to grow without limit.