EEPW论坛

驱动自动碎片收集 Java具有对无用存储单元进行碎片收集(garbage collection)的自动内存管理机制，因此Java程序员无须担心内存分配的释放。如果以前曾用过Java进行编程，那么与其他编程语言相比，无疑会对Java跟踪内存所需的时间留下深刻的印象。 在Java中，只需牺牲运行时间即可换来编程的简化，因为手工管理内存可以得到更为有效的实现方法。但当程序变得越来越大，手工管理就变得无能为力了。虽然好的手工管理通常能使堆栈的总长度降至最小，但这并不总是轻而易举的。在那些通常由数十名程序员完成的大型程序中，人为错误将引入足以降低性能等级的大量内存丢失，这时就需要自动碎片收集解决方案。 在对无用存储单元进行自动碎片收集过程中，一个优秀的程序员或许做得远比自动碎片收集器出色，但在需要众多程序员参与的大型项目中，则几乎不可能找到并修正所有的内存丢失。选择自动系统或许要求对性能进行折衷，而且自动碎片收集器有时也会出现混乱。Dobb博士在www.ddj.com 网站的“Java Q&A”上列出了许多灵活利用Java进行无用存储单元收集的方法。 尽管自动碎片收集对超大型程序的吸引力日益增强，但大多数嵌入式开发人员开发的系统并没有那么复杂。而在这些开发中，只有极少数开发人员需要接入包含无用存储单元自动碎片收集的编程环境，如Perl、Smalltalk或Java，因此大多数开发人员需要知道如何在采用malloc()和free()的C程序或采用new和delete的C++程序中跟踪内存丢失。 检测工具 查找内存丢失的工具很多，最常用的释放工具就是dmalloc和mpatrol，这些工具提供了记录并检查所有内存分配的调试版堆栈，从而有利于分析内存丢失和悬挂指针。dmalloc和许多类似的库还为malloc()和free()提供了一些不同情形下的替代形式。 在许多项目中，我负责跟踪内存丢失并提供所有内存丢失均已消除的证明。最初，我假定上面提及的一种工具可解决我的问题。然而，实际发现malloc()和free()的一种完全替代并不总是适用于嵌入式系统。例如，软件工程师可能对当前的实现相当满意，而只想简单地添加一些监控功能。如果选择了替代malloc()和free()的库，那么就不得不移植这些例行程序。 因为可用的自由库是面向Unix的，因而可通过调用sbrk()从操作系统获取内存块。有些操作系统中并没有这个调用(甚至实际上都没有操作系统)。在移植时，对于特定的处理器必须提及诸如指针大小和内存对齐这样的问题。本文用的编译器库中的malloc()和free()已经解决了这些问题，即编译器库已完全移植到正在使用的处理器上，因此希望避免这样的重复工作。对调试版malloc()和free()进行移植的另一问题在于，调试版通常假定可以将分析数据存入一个文件中。但本文工作的系统通常并不包含任何有效的文件系统，因此必须限制存储到只带有最少资源的设备上的数据量。 我也曾考虑利用现有的工具在台式机上运行部分代码。Compuware公司的Bounds Checker就是这样的工具，该工具专门针对窗视操作系统，但在特殊情形下，本文用的代码是标准的ANSI C，因此可以简单地在PC上进行编译并结合Bounds Checker库运行。Bounds Checker工具也将检查Win32 API的诸多部分，但只对堆栈分配感兴趣。 结果是让人失望的，Bounds Checker面临的最大障碍就在于该工具必须在程序退出后才能递交报告。在程序退出之前尚未释放的数据将被视为内存丢失。尽管这是一个合理定义，但并不适用于我的应用程序，因为与PC应用程序不同，嵌入式程序通常无需退出。 我用的代码包含一个连续执行的循环，为实现本测试的目的，可以在循环的末尾添加一些校验，以人为地退出程序。但不释放所有的内存资源而中断程序将导致Bounds Checker指示所有正在使用的内存此时正发生丢失。大多数内存只是简单地等待，以便在下一次循环中重新得到使用。只需要编写一个释放所有内存的退出程序段，就能使Bounds Checker获得更好的性能，但这样的程序段无法在实时系统中运行并将掩盖实际存在的问题。 由此可以得到如下结论：一旦明确了哪行代码存在疑问，就能用Bounds Checker标识出特定内存丢失的精确来源，因此要关注Bounds Checker的整体性能。 假定随着程序的运行，缓存链表数将增大或减少。因为链表可使程序找到每个缓存，因此可以在任意时间释放所有的缓存。如果程序存在漏洞，使一个应当移除并释放的缓存仍然留在链表中，那么链表将无限增长。如果程序删除整个链表，那么漏洞的痕迹将消失得无影无踪，而链表重新开始记录。在需要运行很长时间的系统中，链表最终将变得很大，直到耗尽所有的内存。 即便采用无用存储自动碎片收集器管理内存，类似的漏洞仍将成为障碍，因为严格地讲，额外的缓存并不是内存丢失，它们仍可以收回。为解决这类问题，我们希望确定总的内存使用率是否正在增加，而不管这些内存是否已经释放，或者是否可能释放这些内存。 内存使用率的测量 如果需要修改malloc()，理想情况下应当采用不同的名称取代所有的malloc()调用。我将其取名为mmalloc()，意即“measured malloc”。这样我们就能编写一个执行一些额外工作并调用常规malloc()的函数，这也可以通过其他途径实现，如采用#define取代malloc()，或在编译库中利用链接程序重命名malloc()函数。 这种方法的一个缺陷在于，不能对从我无法更改或重新编译的库函数中调用的malloc()进行监控。例如，标准库包含一个依次调用malloc()的函数strdup()，我们无法用malloc()调用加以取代，除非我们拥有正在使用的库的源代码。

测量使用率的第一步是简单地添加需要分配的内存并减去任何已经释放的内存。对于malloc()，这当然微不足道。假定定义了一个静态值G_inUse，那么下面的代码就能跟踪内存的分配： ========================== void *mmalloc(size_t size){ G_inUse += size; return malloc(size); } ========================== mfree()略微复杂一些，因为free()并不传递表示内存大小的变量。函数free()传递指向内存块的指针。通常表示释放内存大小的量隐藏在指针所指向数据块之前的数据头中，所以可以得到下面的函数： ========================== void mfree(void *p) { size_t *sizePtr=((size_t *) p)-1; G_inUse -= *sizePtr; free(p); } ========================== 因为在释放过程中或许不会使用这种转换，或者需要在略微不同的偏移位置存储表示释放内存大小的量，因此这种方法是无法移植的。 释放的内存大小或许并不与分配的内存匹配，malloc()的某些实现方法向上舍入为最接近的一个值。例如，如果要求分配11字节，而实际上却接收到了12字节。在这种情况下，12将存储在数据头中。因此分配和释放的数据块就能通过使用G_inUse－1实现平衡。欲了解更多信息，请查阅网站：www.dmalloc.com和www.cbmamiga.demon.co.uk/mpatrol/。

楼主所说的“堆栈”应该是指“堆”吧。

我们那里的一般看法是：尽量不使用malloc，静态分配内存。对于通讯缓冲区，自己写管理程序，根据具体情况具定管理算法的复杂性。对于GUI一类习惯于动态分配的东西，可以在系统初始化时统一分配出来，类似静态分配。