从0到1学习FreeRTOS：FreeRTOS 内核应用开发：（二十六）内存管理 NO.1 基本概念
目录
一、内存管理的基本概念：
二、内存管理方案详解：
（1）heap_1.c
（2）heap_2.c
（3）heap_3.c
（4）heap_4.c
（5）heap_5.c
一、内存管理的基本概念：
FreeRTOS 操作系统将内核与内存管理分开实现，操作系统内核仅规定了必要的内存管理函数原型，而不关心这些内存管理函数是如何实现的，所以在 FreeRTOS 中提供了多种内存分配算法（分配策略），但是上层接口（ API）却是统一的。这样做可以增加系统的灵活性： 用户可以选择对自己更有利的内存管理策略，在不同的应用场合使用不同的内存分配策略。
在嵌入式程序设计中内存分配应该是根据所设计系统的特点来决定选择使用动态内存分配还是静态内存分配算法，一些可靠性要求非常高的系统应选择使用静态的，而普通的业务系统可以使用动态来提高内存使用效率。静态可以保证设备的可靠性但是需要考虑内存上限，内存使用效率低，而动态则是相反。
FreeRTOS 内存管理模块管理用于系统中内存资源，它是操作系统的核心模块之一。主要包括内存的初始化、分配以及释放。
不同的嵌入式系统具有不同的内存配置和时间要求。所以单一的内存分配算法只可能适合部分应用程序。因此， FreeRTOS 将内存分配作为可移植层面（相对于基本的内核代码部分而言）， FreeRTOS 有针对性的提供了不同的内存分配管理算法，这使得应用于不同场景的设备可以选择适合自身内存算法。
FreeRTOS 对内存管理做了很多事情， FreeRTOS 的 V9.0.0 版本为我们提供了 5 种内存管理算法，分别是 heap_1.c、 heap_2.c、 heap_3.c、 heap_4.c、 heap_5.c，源文件存放于FreeRTOS\Source\portable\MemMang 路径下，在使用的时候选择其中一个添加到我们的工程中去即可。
FreeRTOS 的内存管理模块通过对内存的申请、释放操作，来管理用户和系统对内存的使用，使内存的利用率和使用效率达到最优，同时最大限度地解决系统可能产生的内存碎片问题。
二、内存管理方案详解：
统一的上层接口（ API）：
void *pvPortMalloc( size_t xSize ); //内存申请函数
void vPortFree( void *pv ); //内存释放函数
void vPortInitialiseBlocks( void ); //初始化内存堆函数
size_t xPortGetFreeHeapSize( void ); //获取当前未分配的内存堆大小
size_t xPortGetMinimumEverFreeHeapSize( void ); //获取未分配的内存堆历史最小值 FreeRTOS 提供的内存管理都是从内存堆中分配内存的。 从前面学习的过程中，我们也知道，创建任务、消息队列、事件等操作都使用到分配内存的函数，这是系统中默认使用内存管理函数从内存堆中分配内存给系统核心组件使用。
对于 heap_1.c、 heap_2.c 和 heap_4.c 这三种内存管理方案，内存堆实际上是一个很大的数组 ， 定 义 为 static uint8_t ucHeap[ configTOTAL_HEAP_SIZE] ， 而 宏 定 义configTOTAL_HEAP_SIZE 则表示系统管理内存大小，单位为字， 在 FreeRTOSConfig.h 中由用户设定。
对于 heap_3.c 这种内存管理方案， 它封装了 C 标准库中的 malloc()和 free()函数，封装后的 malloc()和 free()函数具备保护，可以安全在嵌入式系统中执行。因此， 用户需要通过编译器或者启动文件设置堆空间。
heap_5.c 方案允许用户使用多个非连续内存堆空间，每个内存堆的起始地址和大小由用户定义。 这种应用其实还是很大的，比如做图形显示、 GUI 等，可能芯片内部的 RAM是不够用户使用的，需要外部 SDRAM，那这种内存管理方案则比较合适。
（1）heap_1.c
heap_1.c 管理方案是 FreeRTOS 提供所有内存管理方案中最简单的一个，它只能申请内存而不能进行内存释放，并且申请内存的时间是一个常量，这样子对于要求安全的嵌入式设备来说是最好的，因为不允许内存释放，就不会产生内存碎片而导致系统崩溃，但是也有缺点，那就是内存利用率不高， 某段内存只能用于内存申请的地方，即使该内存只使用一次，也无法让系统回收重新利用。
heap1.c 方案具有以下特点：
① 用于从不删除任务、队列、信号量、互斥量等的应用程序（实际上大多数使用FreeRTOS 的应用程序都符合这个条件） 。
② 函数的执行时间是确定的并且不会产生内存碎片。
heap_1.c 管理方案使用两个静态变量对系统管理的内存进行跟踪内存分配。
NO.1 内存申请函数 pvPortMalloc()
内存申请函数就是用于申请一块用户指定大小的内存空间，当系统管理的内存空间满足用户需要的大小的时候，就能申请成功，并且返回内存空间的起始地址。
在使用内存申请函数之前，需要将管理的内存进行初始化，需要将变量pucAlignedHeap 指向内存域第一个地址对齐处，因为系统管理的内存其实是一个大数组，而编译器为这个数组分配的起始地址是随机的，不一定符合系统的对齐要求，这时候要进行内存地址对齐操作。比如数组 ucHeap 的地址从 0x20000123 处开始，系统按照 8 字节对齐，则对齐后系统管理的内存示意图具体见下图（来自野火论坛）。
在内存对齐完成后， 用户想要申请一个 30 字节大小的内存，那么按照系统对齐的要求，我们会申请到 32 个字节大小的内存空间，即使我们只需要 30 字节的内存。
NO.2 其他函数：
其实 heap_1.c 方案还有一些其他函数，只不过基本没啥用。 vPortFree()这个函数其实上面都没做，因为 heap_1.c 采用的内存管理算法中不支持释放内存。vPortInitialiseBlocks()仅仅将静态局部变量 xNextFreeByte 设置为 0，表示内存没有被申请。xPortGetFreeHeapSize()则是获取当前未分配的内存堆大小， 这个函数通常用于检查我们设置的内存堆是否合理，通过这个函数可以估计出最坏情况下需要多大的内存堆，以便合理的节省内存资源。
（2）heap_2.c
heap_2.c 方案与 heap_1.c 方案采用的内存管理算法不一样，它采用一种最佳匹配算法(best fit algorithm)，比如我们申请 100 字节的内存，而可申请内存中有三块对应大小 200 字节， 500 字节和 1000 字节大小的内存块，按照算法的最佳匹配，这时候系统会把 200 字节大小的内存块进行分割并返回申请内存的起始地址，剩余的内存则插回链表留待下次申请。Heap_2.c 方案支持释放申请的内存， 但是它不能把相邻的两个小的内存块合成一个大的内存块， 对于每次申请内存大小都比较固定的，这个方式是没有问题的，而对于每次申请并不是固定内存大小的则会造成内存碎片， 后面要讲解的 heap_4.c 方案采用的内存管理算法能解决内存碎片的问题，可以把这些释放的相邻的小的内存块合并成一个大的内存块。
同样的，内存分配时需要的总的内存堆空间由文件 FreeRTOSConfig.h 中的configTOTAL_HEAP_SIZE 配置，单位为字。 通过调用函数 xPortGetFreeHeapSize() 我们可以知道还剩下多少内存没有使用， 但是并不包括内存碎片， 这样一来我们可以实时的调整和优化 configTOTAL_HEAP_SIZE 的大小。
heap_2.c 方案具有以下特点：
- 可以用在那些反复的删除任务、队列、信号量、等内核对象且不担心内存碎片的应用程序。
- 如果我们的应用程序中的队列、任务、信号量、 等工作在一个不可预料的顺序，这样子也有可能会导致内存碎片。
- 具有不确定性，但是效率比标准 C 库中的 malloc 函数高得多
- 不能用于那些内存分配和释放是随机大小的应用程序。
heap_2.c 方案与 heap_1 方案在内存堆初始化的时候操作都是一样的，在内存中开辟了一个静态数组作为堆的空间，大小由用户定义，然后进行字节对齐处理。
heap_2.c 方案采用链表的数据结构记录空闲内存块，将所有的空闲内存块组成一个空闲内存块链表， FreeRTOS 采用 2 个 BlockLink_t 类型的局部静态变量 xStart、 xEnd 来标识空闲内存块链表的起始位置与结束位置，空闲内存块链表结构体具体见下面的代码。
typedef struct A_BLOCK_LINK {
struct A_BLOCK_LINK *pxNextFreeBlock;
size_t xBlockSize;
} BlockLink_t; pxNextFreeBlock 成员变量是指向下一个空闲内存块的指针。
xBlockSize 用于记录申请的内存块的大小，包括链表结构体大小。
NO.1 内存申请函数 pvPortMalloc():
heap_2.c 内存管理方案采用最佳匹配算法管理内存，系统会先从内存块空闲链表头开始进行遍历，查找符合用户申请大小的内存块（内存块空闲链表按内存块大小升序排列，所以最先返回的的块一定是最符合申请内存大小，所谓的最匹配算法就是这个意思来的）。当找到内存块的时候， 返回该内存块偏移 heapSTRUCT_SIZE 个字节后的地址， 因为在每块内存块前面预留的节点是用于记录内存块的信息， 用户不需要也不允许操作这部分内存。
在申请内存成功的同时系统还会判断当前这块内存是否有剩余（大于一个链表节点所需内存空间），这样子就表示剩下的内存块还是能存放东西的，也要将其利用起来。 如果有剩余的内存空间，系统会将内存块进行分割，在剩余的内存块头部添加一个内存节点，并且完善该空闲内存块的信息，然后将其按内存块大小插入内存块空闲链表中，供下次分配使用，其中 prvInsertBlockIntoFreeList() 这个函数就是把节点按大小插入到链表中。
随着内存申请， 越来越多申请的内存块脱离空闲内存链表， 但链表仍是以 xStart 节点开头以 xEnd 节点结尾， 空闲内存块链表根据空闲内存块的大小进行排序。每当用户申请一次内存的时候，系统都要分配一个 BlockLink_t 类型结构体空间，用于保存申请的内存块信息，并且每个内存块在申请成功后会脱离空闲内存块链表，申请两次后的内存示意图具体见下图。
NO.2 内存释放函数 vPortFree()：
分配内存的过程简单，那么释放内存的过程更简单，只需要向内存释放函数中传入要释放的内存地址，那么系统会自动向前索引到对应链表节点， 并且取出这块内存块的信息，将这个节点插入到空闲内存块链表中，将这个内存块归还给系统。下图为释放一个内存块
，下下图为内存释放完成示意图。
从内存的申请与释放看来， heap_2.c 方案采用的内存管理算法虽然是高效但还是有缺陷的，由于在释放内存时不会将相邻的内存块合并，所以这可能造成内存碎片，如果这种情况经常发生，就会导致每个空闲块都可能很小，最终在申请一个大块时就会因为没有合适的空闲内存块而申请失败，这并不是因为总的空闲内存不足，而是无法申请到连续可以的大块内存。
（3）heap_3.c
heap_3.c 方案只是简单的封装了标准 C 库中的 malloc()和 free()函数， 并且能满足常用的编译器。 重新封装后的 malloc()和 free()函数具有保护功能，采用的封装方式是操作内存前挂起调度器、完成后再恢复调度器。
heap_3.c 方案具有以下特点：
- 需要链接器设置一个堆， malloc()和 free()函数由编译器提供。
- 具有不确定性。
- 很可能增大 RTOS 内核的代码大小。
要 注 意 的 是 在 使 用 heap_3.c 方 案 时 ， FreeRTOSConfig.h 文 件 中 的configTOTAL_HEAP_SIZE 宏定义不起作用。 在 STM32 系列的工程中， 这个由编译器定义的堆都在启动文件里面设置， 单位为字节，我们具体以 STM32F10x 系列为例， 具体见下图。
（4）heap_4.c
采用最佳匹配算法以及合并算法
空闲内存块是以单链表的形式连接起来的
特点：
1.可用于重复删除任务、队列、信号量、互斥量等的应用程序
2.可用于分配和释放随机字节内存的应用程序
xFreeBytesRemaining：表示当前系统中未分配的内存堆大小。
xMinimumEverFreeBytesRemaining：表示未分配内存堆空间历史最小的内存值。
内存分配时需要的总的堆空间由文件FreeRTOSConfig.h 中的宏configTOTAL_HEAP_SIZE 配置，单位为字。 通过调用函数 xPortGetFreeHeapSize() 我们可以知道还剩下多少内存没有使用， 但是并不包括内存碎片。 这样一来我们可以实时的调整和优化 configTOTAL_HEAP_SIZE 的大小。
heap_4.c 方案的空闲内存块也是以单链表的形式连接起来的， BlockLink_t 类型的局部静态变量 xStart 表示链表头，但 heap_4.c 内存管理方案的链表尾部则保存在内存堆空间最后位置，并使用 BlockLink_t 指针类型局部静态变量 pxEnd 指向这个区域（而 heap_2.c 内存管理方案则使用 BlockLink_t 类型的静态变量 xEnd 表示链表尾）
heap_4.c 内存管理方案的空闲块链表不是以内存块大小进行排序的，而是以内存块起始地址大小排序， 内存地址小的在前，地址大的在后，因为 heap_4.c 方案还有一个内存合并算法， 在释放内存的时候，假如相邻的两个空闲内存块在地址上是连续的，那么就可以合并为一个内存块， 这也是为了适应合并算法而作的改变。
heap_4.c 方案具有以下特点：
- 可用于重复删除任务、队列、信号量、互斥量等的应用程序
- 可用于分配和释放随机字节内存的应用程序， 但并不像 heap2.c 那样产生严重的内存碎片。
- 具有不确定性，但是效率比标准 C 库中的 malloc 函数高得多。
NO.1 内存申请函数 pvPortMalloc()
heap_4.c 方案的内存申请函数与 heap_2.c 方案的内存申请函数大同小异，同样是从链表头 xStart 开始遍历查找合适的内存块，如果某个空闲内存块的大小能容得下用户要申请的内存，则将这块内存取出用户需要内存空间大小的部分返回给用户，剩下的内存块组成一个新的空闲块，按照空闲内存块起始地址大小顺序插入到空闲块链表中，内存地址小的在前，内存地址大的在后。在插入到空闲内存块链表的过程中，系统还会执行合并算法将地址相邻的内存块进行合并：判断这个空闲内存块是相邻的空闲内存块合并成一个大内存块，如果可以则合并，合并算法是 heap_4.c 内存管理方案和 heap_2.c 内存管理方案最大的不同之处，这样一来，会导致的内存碎片就会大大减少，内存管理方案适用性就很强，能一样随机申请和释放内存的应用中，灵活性得到大大的提高。
heap_4.c 内存初始化完成示意图：
其实， 这个合并的算法常用于释放内存的合并， 申请内存的时候能合并的早已合并，因为申请内存是从一个空闲内存块前面分割，分割后产生的内存块都是一整块的，基本不会进行合并， 申请内存常见的情况具体见下图。
在申请 3 次内存完成之后的示意图具体见下图（来自野火论坛）：
NO.2 内存释放函数 vPortFree()
heap_4.c 内存管理方案的内存释放函数 vPortFree()也比较简单， 根据传入要释放的内存块地址，偏移之后找到链表节点，然后将这个内存块插入到空闲内存块链表中，在内存块插入过程中会执行合并算法，这个我们已经在内存申请中讲过了（而且合并算法多用于释放内存中） 。最后是将这个内存块标志为“空闲” （内存块节点的 xBlockSize 成员变量最高位清 0）、再更新未分配的内存堆大小即可。
无法合并图（来自野火论坛）：
可合并图（来自野火论坛）：
（5）heap_5.c
heap_5.c 方案在实现动态内存分配时与 heap4.c 方案一样， 采用最佳匹配算法和合并算法，并且允许内存堆跨越多个非连续的内存区，也就是允许在不连续的内存堆中实现内存分配，比如用户在片内 RAM 中定义一个内存堆，还可以在外部 SDRAM 再定义一个或多个内存堆，这些内存都归系统管理。
假设我们为内存堆分配两个内存块，第一个内存块大小为 0x10000字节，起始地址为 0x80000000；第二个内存块大小为 0xa0000 字节，起始地址为0x90000000， vPortDefineHeapRegions()函数使用实例具体见代码清单。
用户在自定义好内存堆数组后，需要调用 vPortDefineHeapRegions()函数初始化这些内存堆，系统会已一个空闲内存块链表的数据结构记录这些空闲内存，链表以 xStart 节点构开头，以 pxEnd 指针指向的位置结束。 vPortDefineHeapRegions()函数对内存的初始化与heap_4.c 方案一样，在这里就不再重复赘述过程。以上面的内存堆数组为例，初始化完成后的内存堆示意图具体见下图。
而对于 heap_5.c 方案的内存申请与释放函数，其实与 heap_4.c 方案是一样的，此处就不再重复赘述。