靠谱：保证实时的动态内存分配

五一在家没有出门，研究了一下 TLSF 动态内存分配算法。

缘起

要说清楚TLSF，得从动态内存分配开始说起。动态内存分配是所有系统中都要考虑的问题，我们从学C语言开始就知道用的malloc函数就是用来申请动态内存的。其基本原理就是malloc时系统从堆中拿出一块内存分配给你用，用完之后通过free再还回去。

这个过程有点像借钱，比如最近疫情手头紧，没钱吃饭了，于是找朋友malloc点钱去吃饭，比如说10块吧，等我打工挣了钱再free给朋友，这就是动态分配，而朋友就是那个拥有很多钱（内存）的壕。

那么问题就来了，既然朋友是个壕，必然有很多钱，我去malloc 10块钱的时候，他可能没有零钱，都是100的，于是他直接扔给了我100，我拿着这100也不敢都花了，毕竟现在疫情紧张能有饭吃就不错了，标准都是10块，所以其实还有90块给我是浪费掉了，明明这90块还可以再去帮助9个像我这样的，于是资源利用效率就降低了。朋友虽然壕，但架不住我这样的人多啊，资源慢慢就被耗尽，还利用率低，系统就开始卡了。

这就是现在嵌入式系统经常遇到的问题：资源有限。物联网的发展带火了嵌入式系统，因为价格便宜，但同时也导致资源有限，不好好用有可能就跑不动了，换高端的又要多花钱，所以需要研究如何更有效的利用资源。动态内存分配就是用来管理分配内存资源的。

如何来管理分配内存呢？其实这就是我的朋友壕怎么管钱的问题。壕的钱太多，所以借钱的人也多，为了记住谁借了多少，壕就要记账，于是他就会有一个账本。比如我之前找他借10块，他给了我100，于是他就会在账本上记上这100已经借出了。借钱的人一多，可能每个人要借的钱有多有少，有的借10000，有的借200，有的借42，各种各样的需求都有。朋友开始一笔一笔按顺序记，后来慢慢发现有不少人每次都借10000，这个人借了10000还回来，那个人正好来借10000，于是不用把这10000放回去了，直接借给那个人更方便，方便了自己管理。于是朋友壕想到了一个办法，规定了借钱的规格，比如借钱只能借10、100、1000、10000，其他的数量都不借，他自己只需要把钱按这个规格提前分好，然后用几个链表来管理就可以了。这就是一种动态分配内存的方法。

碎片

前面说的朋友的这个方法好不好呢？比一笔一笔的顺序记肯定要好多了。但是会有个问题：比如我要借20，按朋友的规格，没有20的，我只能借100，其实浪费了80，这80我也不用，朋友想用却用不上，这就是内部碎片。可以想象，随着长时间的使用，因为每个人的需求各种各样，内部碎片可能会越来越多，造成了整体利用率下降。

前面说了那80是内部碎片，既然有内部碎片，就肯定有外部碎片。外部碎片不太好用钱来举例，因为它涉及到了内存连续的问题。我们知道系统中没有碎片的时候内存都是连续的，假设有三个进程分别申请了相连的1，2，3三块内存，而进程2因为执行完毕，把内存2释放了，此时1和3之间就空出了一块内存，如果这块空出的区域无法满足其他进程申请的需要，那它就只能一直在这空着，造成了浪费，这就是外部碎片。

长时间的使用会导致越来越碎片化，那这些碎片怎么解决呢？

对于内部碎片，一个很容易想到的办法就是把借钱的规格分得更细，比如规格可以有1，2，3，4，…，10000，这样借钱的数量只要在这个范围内（我们只考虑借整数元的情况），就不会有内部碎片产生。但是这个代价就是原本只要几个链表就可以管理的，现在需要10000个链表，朋友壕觉得太累了。于是考虑折中的方法，不要分那么多规格，就分一些常用的规格，比如总有人借42块，就定一个42的规格，于是链表数量也不会那么多。但是总有不符合规格的，所以也还是会有碎片，只是碎片不会那么多。这就是Linux内核中slab机制所采取的办法。

对于外部碎片，可以用著名的伙伴算法。其思想是把分配的规格定为2的幂次，即1，2，4，8，16，32，64，128，256，512，1024，2048，…，这样链表的数量不多。用的时候，若要分配内存，就给能满足要求的最小的，比如申请42，就给64，若没有64的，就找128的，拆成2个64的，给一个，留一个；若128的也没有，就继续往上找，以此类推。若找到头若还找不到，则分配失败。释放内存的时候，则看紧邻的内存块是否空闲，若为空闲，则进行合并。因为小块都是大块2分出来的，所以紧邻的一定有一块跟它一样大，就等着合并那一块，合并成一块大的之后还可以再看紧邻的是否空闲，若是可以再合并，以此类推。这就是为什么规格要为2的幂次。这样就不会产生外部碎片了。Linux内核中就采取了这个办法。很明显，这种方式虽然能够完全避免外部碎片的产生，但却产生了内部碎片。所以Linux内核才用了slab机制来优化。

实时

动态内存分配的另一个问题是实时性。比如前面讲的伙伴算法，若是最坏的情况，申请1可能要一直找到2048去，然后要不断拆出来。当然这种情况很少见，所以平均来说效率还不错。对于Linux这种实时性要求不高的系统来说，也就一直用着了。

但对于一起实时嵌入式系统来说，实时性的要求就高得多，举个没那么恰当的例子，比如刹车系统平均响应时间是0.1s，但最坏情况下可能要2s，这种刹车你敢用吗？实时系统需要有可预期的时间保证，必须要保证在最坏的情况下多少时间内操作要完成。我们要说的TLSF就可以保证其最坏执行（分配、释放）时间是 $O(1)$ 的。

TLSF (Two-Level Segregate Fit)

终于说到TLSF了。TLSF号称实现了三大目标：实时性（可预期的时间保证）、执行速度快、利用率高（碎片少）。怎么实现的呢？结合下图来说。

在划分的规格上，TLSF改进了伙伴算法，它分了两层，第一层（图中First Level）跟伙伴算法一样，也是采用2的幂次，但这样很容易产生很多内部碎片，所以TLSF进行了第二层（图中Second Level）划分，比如64这一级规格，再细分为8个区间，64-71，72-79，80-87，88-95，96-103，104-111，112-119，120-127，这样虽然不能完全没有碎片，但碎片可以尽量小，同时也尽量不会浪费内存，保证了内存的利用率。

为了方便管理，对每一层都用位图来表示相应的规格是否有空闲块，每种规格的空闲块都用一个链表来管理。相关结构体代码如下，其中fl_bitmap和sl_bitmap分别是第一层和第二层位图，matrix是所有规格的链表。

typedef struct TLSF_struct {
   
   
    /* the TLSF's structure signature */
    u32_t tlsf_signature;

#if TLSF_USE_LOCKS
    TLSF_MLOCK_T lock;
#endif

#if TLSF_STATISTIC
    /* These can not be calculated outside tlsf because we
     * do not know the sizes when freeing/reallocing memory. */
    size_t used_size;
    size_t max_size;
#endif

    /* A linked list holding all the existing areas */
    area_info_t *area_head;

    /* the first-level bitmap */
    /* This array should have a size of REAL_FLI bits */
    u32_t fl_bitmap;

    /* the second-level bitmap */
    u32_t sl_bitmap[REAL_FLI];

    bhdr_t *matrix[REAL_FLI][MAX_SLI];
} tlsf_t