浅析嵌入式系统中大量小块内存申请释放的内存管理方案

其实我今天在这里要提到的这个方案己经有很多人提过，我之所以在这里再强调一下是因为尽管己经有很多人提过这种方案，但这个问题在我们设计过程中还是很经常碰到，并且并没有得到重视或得到较好的解决。

在很多情况下，我们可能会需要申请和释放很多小块内存，我们都知道，大量小块内存的申请和释放极有可能导致内存出现大量碎片，而且，每次申请内存内存耗用量并非只是我们申请的那个大小，它同时还需要分配一个内存信息块，如该块内存的大小等信息，如果是分页管理的内存，则每次都必须分配至少必须是系统最小内存页，因此大量申请小块内存必然导致内存的大量浪费，在非分页的内存管理系统中，大量碎片的产生，严重的话，甚致有可能导致实际使用内存不多，但系统却无内存可用状态。

在PC机上资源比较非富，因此，它的这个问题并非这么明显，但由于嵌入式系统是一种资源受限系统，内存是十分珍贵的资源，而且嵌入式系统由一资源受限，内存管理算法一般比较简陋，因此，在写应用代码时，如果何根据应用实际需求，对内存进行有效的管理利用是十分重要的一个问题。

当然，目前并没有一种能够完全解决内存碎片和内存浪费的方案，在很多种情况下，内存碎片和内存浪费是此消彼长的状态，不产生碎片也就导至内存浪费，不浪费内存了，也就容易产生碎片，在这里，我想给大家介绍一种常见的解决方案，以供参考。

 

大量小块内存的申请会导致的问题：

1. 内存碎片产生

2. 内存严重浪费

 

两种小块内存申请场景：

1. 每次申请的内存大小一致。

在很多情况下，我们会碰到需要申请很多大小一致的内存，比如说：链表就是一种十分典型案例，如果链表的节点很小，经过对链表的多次操作后，就会产生大量的内存浪费及可能出现大量的碎片，对于内存有进行分页管理的，碎片问题可以解决，但浪费可能更严重：

比如：链表节点是8字节，

对于一般的非分页内存管理系统来说，则每申请一个节点要同时在内存管理链表中添加4字节的内存起始地址，4字节的内存大小，即每个节点实际占用的内存是16字节，是我们所要申请内存的一倍大小，

对于分页管理的内存管理系统来说，假设最小的内存页为32(己经算是很小)个字节，则每个节点至少要在内存管理链表中添加一个4字节的内存页标识（可能是页号或页起始地址等，看如何实现），因为页大小是固定的，因此，不需要记录内存大小，那么每个节点实际占用的内存是32+4字节，是我们实际需要申请的内存的4倍。

如果我们链表操作频繁，那么，对于分页的系统来说，不会产生碎片，但会占用大量内存空间，但对于简单的内存管理系统来说就糟了，因为在系统里面可能有大量的我们释放的8字节大小的内存碎片，这些内存碎片由占用空间太小，也很少能用得上。

2. 每次申请的内存大小不一。

对于某些应用场景来说，我们可能需要大量的小块内存，但我们无法事先确定内存会是多小，根据不同的情况，会有不同需求出现。

内存管理方案：

在嵌入式系统中，操作系统本身的内存管理算法对于特定应用来说，一般都不是最优的，因此，为了更高效的管理内存，在需要使用大量内存的应用模块中，一般会再进行内存的二次管理。

由于己经是在特定的应用场景中，因此，我们在设计中，必定能够预测到我们会需要怎样的内存使用环境，是否需要使用大量小块内存，内存的大小是否固定，如果不固定，最大是多少，最小又会是多少。

对于我们己经固定大小的分配内存的管理，我们可以申请一个大内存块，并将这些分配成固定大小的小内存，应用程序可以从这个链表中来获取或归还内存块，当链表中所有内存块都被分配完时，可以再申请一个大内存块并分解成小内存块加入链表，依此类推，而当一个大内存块中的所有的内存块都被归还时，可以释放该大内存块，以减少对内存占用。

而对于内存大小无法固定的内存需求来说，我们可以从最小需求到最大需求，将内存需求分隔成若干个范围，将每个范围最大小作为这个范围内存需求的固定大小，并对每个大小的需求维护一个内存链表，并统一管理这个链表集合，应用程序申请时，就根据具体的需求对内存进行自动匹配。

当然，有些场景下，在实际应用过程中，可能多数情况下需要的都是小内存，但在特殊的情况下，可能会突然会需要一个较大的内存块，这个时候，链表集合中并没有适合大小的内存，怎么办呢？为了应付这种突发情况，在应用程序申请的内存超出我们预期范围，链表集合都无法满足需求时，我们可以将这种内存分配直接转交给系统，由系统的内存管理算法进行处理，即直接调用系统的内存分配/释放接口。

综合以上三种情况，我们就可以在实现一套灵活多变的内存二次管理算法来根据具体的应用进行配置，这套内存管理算法它链表个数可配置，链表节点大小可配置，可以自动计算需要分配的内存大小，可以适应不在链表集合范围内的内存分配需求。

这种管理算法网上应该有不少，我在下一次也会发布我自己的实现。