有些程序并不需要管理它们的动态内存的使用。当需要内存时，它们简单地通过分配来获得，从来不用担心如何释放它。这类程序包括编译器和其他一些运行一段固定的（或有限的）时间然后终止的程序。当这种类型的程序终止时，所有内存会被自动回收。细心查验每块内存是否需要回收纯属浪费时间，因为它们不会再被使用。
其他程序的生存时间要长一点。有些工具如日历管理器、邮件工具以及操作系统本事经常需要数日及至数周连续运行，并需要管理动态内存的分配和回收。由于C语言通常并不使用垃圾回收器（自动确认并回收不再使用的内存块），这些C程序在使用malloc()和free()时不得不非常慎重。
堆经常会出现两种类型的问题：
1.释放或改写仍在使用的内存(称为：“内存损坏”)。
2.未释放不再使用的内存(称为：“内存泄露”)。
这是最难被调试发现的问题之一。如果每次已分配的内存块不再使用而程序并不释放它们，进程就会一边分配越来越多的内存，一边却并不释放不再使用的那部分内存。
避免内存泄露
每当调用malloc分配内存时，注意在以后要调用相应的free来释放它。
如果不知道如何调用free与先前的malloc相对应，那么很可能已经造成了内存泄露！
一种简单的方法就是在可能的时候使用alloca()来分配动态内存，以避免上述情况。当离开调用alloca的函数时，它所分配的内存会被自动释放。
显然，这并不适用于那些比创建它们的函数生命期更长的结构。但如果对象的生命期在该函数结束前便已经终止，这种建立在堆栈上的动态内存分配是一种开销很小的选择。有些人不提倡使用alloca，因为它并不是以后总可移植的方法。如果处理器在硬件上不支持堆栈，alloca()就很难高效地实现。
我们使用“内存泄露”这个词是因为一种稀有的资源正在被一个进程榨干。内存泄露的主要可见症状就是罪魁进程的速度很减慢。原因是体积大的进程更有可能被系统换出，让别的进程运行，而且大的进程在换进换出时花费的时间也更多。即使泄露的内存本省并不被引用，但它仍用可能存在于页面中（内容自然是垃圾），这样就增加了进程的工作页数量，降低了性能。另外需要注意的一点是，内存泄露往往比忘记释放的的数据结构要打，因为malloc()所分配的内存通常会圆整为下一个大于申请数量的2的整数次方（如申请212B,会圆整为256B）。在资源有限的情况下，即使引起内存泄露的进程并不运行，整个系统运行速度也会被拖慢。从理论上说，进程的大小有一个上限值，这在不同的操作系统中各不相同。在当前的SunOS版本中，进程的最大地址空间可以多达4GB。事实上，在进程所泄露的内存远未达到这个数量时，磁盘的交换区早已消耗殆尽。
如何检测内存泄露
观察内存泄露是一个两步骤的过程。首先，使用swap命令观察还有多少可用的交换空间：
/usr/sbin/swap -s
total:17228K bytes allocated + 5396K reserved=22626K used，29548K available.
在一两分钟内键入该命令三到四次，看看可用的交换区是否在减少。还可以使用其他一些/usr/bin/*stat工具如netstat、vmstat等。如发现波段有内存被分配且从不释放，一个可能的解释就是有个进程出现了内存泄露。