碎片问题详解.docVIP

内存碎片处理技术 内存碎片是个非常棘手的问题。怎么分配内存决定着内存碎片是否会、何时会、怎么会成为一个问题。 　　即使在系统中事实上仍然有许多空闲内存时，内存碎片还会最终导致出现内存用完的 情况。一个不断产生内存碎片的系统，不管产生的内存碎片多么小，只要时间足够长，就会将内存用完。这种情况在许多嵌入式系统中，特别是在高可用性系统中是不可接受的。有些软件环境，如 OSE 实时操作系统已备有避免内存碎片的良好工具，但个别程式员做出的选择仍然会对最终结果形成影响。 　　“碎片的内存”描述一个系统中所有不可用的空闲内存。这些资源之所以仍然未被使用，是因为负责分配内存的分配器使这些内存无法使用。这一问题通常都会发生，原因在于空闲内存以小而不连续方式出目前不同的位置。由于分配方法决定内存碎片是否是个问题，因此内存分配器在确保空闲资源可用性方面扮演着重要的角色。 　　编译时间和运行时间 　　在许多情况下都会出现内存分配问题。程式员能通过编译程式和链接程式，为结构、并集、数组和标量（用作局部变量、静态变量或全局变量）方面的数据分配内存，程式员还能在运行时间使用诸如malloc()调用命令动态地分配内存。当用编译程式和链接程式完成内存分配功能时，就不会出现内存碎片，因为编译程式了解数据寿命。掌控可供使用的数据寿命，好处在于能使数据以后进先出的方式叠加起来。这样就能使内存分配程式工作效率更高，而不会出现内存碎片。一般来说，运行时间内的内存分配是不可叠加的。内存分配在时间上是独立的，从而使得碎片问题难以解决。 图 1，内存碎片的几种形式。 　　内存分配程式浪费内存的基本方式有三种：即额外开销、内部碎片及外部碎片（图1）。内存分配程式需要存储一些描述其分配状态的数据。这些存储的信息包括所有一个空闲内存块的位置、大小和所有权，及其他内部状态详情。一般来说，一个运行时间分配程式存放这些额外信息最佳的地方是他管理的内存。内存分配程式需要遵循一些基本的内存分配规则。例如，所有的内存分配必须起始于可被4、8 或 16 整除（视 处理 器体系结构而定）的地址。内存分配程式把仅仅预定大小的内存块分配给客户，可能更有其他原因。当某个客户请求一个 43 字节的内存块时，他可能会获得 44字节、48字节 甚至更多的字节。由所需大小四舍五入而产生的多余空间就叫内部碎片。 　　外部碎片的产生是当已分配内存块之间出现未被使用的差额时，就会产生外部碎片。例如，一个应用程式分配三个连续的内存块，然后使中间的一个内存块空闲。内存分配程式能重新使用中间内存块供将来进行分配，但不太可能分配的块正好和全部空闲内存相同大。倘若在运行期间，内存分配程式不改动其实现法和四舍五入策略，则额外开销和内部碎片在整个系统寿命期间保持不变。虽然额外开销和内部碎片会浪费内存，因此是不可取的，但外部碎片才是嵌入系统研发人员真正的敌人，造成系统失效的正是分配问题。 　　定义内存碎片的方法有几种，其中最常用的是： 　　这一方法适用于外部碎片，但能修改这一公式使之包括内部碎片，办法是把内部碎片加入到分母中。内存碎片是个介于 0 和 1之间的分数。一个碎片为 1(100%)的系统就是把内存全用完了。如果所有空闲内存都在一个内存块（最大内存块）中，碎片为0%。当所有空闲内存的四分之一在最大内存块中时，碎片为 75%。例子如下：一个系统有 5M 字节的空闲内存，当他可用来分配的最大内存块为 50k 字节时，其内存碎片为99%。这个99%内存碎片实例来自研发嵌入式软实时系统期间出现的一种真实情况。当这种碎片程度发生一秒后，系统就崩溃了。该系统在碎片率达到 99%之前，已进行了约两周的连续现场测试。这种情况是怎么发生的？为什么会发现得如此晚？当然，系统都经过测试，但测试非常少超过两个小时。交付前的最后压力测试持续了一个周末。在这样短的测试周期内未必会产生内存碎片的后果，所以就发生了内存碎片需要多长时间才会达到临界值，这一问题非常难回答。对某些应用来说，在某些情况下，系统会在用完内存前达到一种稳定状态。而对于另一些应用来说，系统则不会及时达到稳定状态（图2）。只要消除不确定性因素和风险因素，不产生碎片的内存分配程式（图3）就能快速达到一种稳定状态，从而有助于研发人员夜晚安稳睡觉。在研发数月甚至数年不再重新启动的长期运行系统时，快速收敛到稳定状态是个重要因素。在比系统连续运行周期短的时间内，对系统进行适当的测试，这是必不可少的。 图 2，这一案例研究把最先适合内存分配程式用于一个嵌入系统项目。系统在现场测试中连续运行了两周，然后碎片率达到 99%。 图 3，一个不产生碎片的内存分配程式一旦试验应用程式的全部，他就能达到稳定状态。 　　非常难确定哪种内存分配算法更胜一筹，因为每种算法在不同的应用中各