5.2 分配策略、碎片演化与内存安全

5.2 分配策略、碎片演化与内存安全

本节摘要：堆的麻烦在时间维度上展开：碎片随运行日积月累，峰值在压力最大的时刻逼近上限，分配失败在 nobody watching 的时候发生。本节先解剖碎片的生长机理并给出量化观测手段，再部署"钩子、断言、熔断"三道防线，最后正面处理"动态分配要不要彻底放弃"的争论——安全编码规范为何限制它、FreeRTOS 的静态化路线长什么样、两种路线的真实代价对比。读完，你的堆从"碰运气的黑盒"变成"有仪表有保险的子系统"。

上一节选好了堆方案，本节让它安全地跑过产品的整个生命周期。先给一个数字感的锚：内存问题的高发期不在第一周，而在第三周到第三个月——碎片要时间生长，峰值要场景凑齐。所以本章的一切手段，本质都是在给"未来某个深夜"提前布防。

一、碎片的生长机理与量化观测

碎片怎么长出来的？看一个最小模型。堆一整块一千字节：先分配两块各两百（记为甲、乙），再分配一块六百（丙）；随后释放甲和丙。此刻空闲总量是八百字节，但它们是"两百加六百"两段，中间夹着在用的乙。若此时来了一个七百字节的请求——总空闲够，最大连续段不够，分配失败。这就是外部碎片：总量充足、形状不对。

生长的燃料是"长短交错"：系统里小对象（临时缓冲、短命任务）与大对象（长生命周期任务栈）交替分配释放，每轮都可能在大块之间楔入一个小钉子。方案二的缺陷是不拔钉子（不合并），方案四能把相邻空闲融合，但楔在两个在用块之间的钉子，谁都拔不掉——合并只救相邻，不救相隔。结论直接指向设计规范：控制对象尺寸的种类数量。全部按几种固定尺寸（如小、中、大三档）分配，钉子之间总能互相拼合，碎片率大幅下降——这就是对象池与尺寸分档的原理性依据。

观测手段两件套。空闲量统计：内核提供接口读当前空闲最小值的历史记录（自上电以来的最低空闲水位）——这个"历史最低"比"当前空闲"重要一个量级，它告诉你系统离死亡最近的一次有多近。块结构巡检：遍历堆的空闲链表，统计块数与每块大小，得到"空闲总量、最大连续块、块数"三元组。碎片率的实用定义：一减最大连续块与空闲总量之比。巡检放到低优先级任务里定期执行，数值进日志：碎片率随运行时间爬升的曲线，就是堆的体检心电图。

/* 堆体检：历史水位 + 当前碎片画像（周期低优先级任务中调用） */
void heap_check(void)
{
    HeapStats_t st;
    vPortGetHeapStats(&st);            /* 方案四与五提供 */
    /* 关键字段：历史最小空闲 当前空闲 最大空闲块 空闲块数 */
    log("heap min-ever=%u now=%u biggest=%u blocks=%u",
        (unsigned)st.xMinimumEverFreeBytesRemaining,
        (unsigned)st.xAvailableHeapSpaceInBytes,
        (unsigned)st.xSizeOfLargestFreeBlockInBytes,
        (unsigned)st.xNumberOfFreeBlocks);

    uint8_t frag = 100 -
        (uint8_t)(100u * st.xSizeOfLargestFreeBlockInBytes
                        / st.xAvailableHeapSpaceInBytes);
    if (frag > 40) {
        warn("fragmentation rising");  /* 碎片率超四成：进入治理流程 */
    }
}
​

二、三道防线：钩子、断言、熔断

分配失败的处理哲学是分层设防，每层回答一个问题。

**第一道，分配失败钩子——"失败发生时知道是谁"。**内核分配失败时若钩子开启，会调用你注册的钩子函数。开发期钩子的标准动作：记录失败时刻的系统快照（哪个任务在跑、堆水位、碎片画像）再停机等调试；量产期钩子改为降级策略（释放缓存、拒绝新连接、记录事件后继续运行）。部署要点：钩子里不许再碰堆（分配失败的世界里，再分配等于二次事故），只许写静态缓冲与硬件寄存器。

**第二道，断言——"越界与非法参数当场拦下"。**堆接口的断言检查块完整性：释放一个不存在的块、双重释放、块的头部校验失败，都会在断言处停机。这些错误几乎全部来自上层代码（野指针、重复释放、越界写穿了块头），断言把它们从"延迟爆炸的暗雷"变成"当场抓获的明枪"。量产版是否保留断言是经典争论：保留有性能代价，砍掉则暗雷复活——折中方案是保留释放路径的校验（便宜且抓大头），砍掉分配路径的乐观检查。

**第三道，上限熔断——"业务不许把内核饿死"。**给动态分配设一个应用层配额：业务代码（如连接任务）可用的堆份额封顶，配额之外的堆只留给系统关键对象。实现可以极简：一个计数器进出的门槛函数，所有业务侧分配先过门槛。它防的是最阴险的场景——业务内存泄漏慢慢吃光堆，最后死的是"创建定时器失败"这类系统调用，排障方向被带偏到内核。熔断把死亡现场限制在业务自己门口。

⚠️ 三道防线共同的死穴是"测不到就不发生"的侥幸。分配失败路径必须在开发期真实触发过：写一个专门的测试模式，故意灌满堆、验证钩子触发、验证降级策略执行、验证恢复路径（释放后系统继续正常服务）。没跑过这条路径的防线，只是装饰品。

三、要不要彻底放弃动态分配：一场有结论的争论

安全编码规范（航空、医疗、汽车领域的行业规范）对动态分配的态度接近敌视：运行期分配被禁止或严格限制，理由有三——碎片不可控（前文已证）、时间不可定（分配耗时与堆状态相关）、失败模式复杂（失败点分散在任意调用处）。这些规范不是教条，是事故换来的共识。FreeRTOS 对此的回应是静态化路线：全部内核对象提供静态创建接口——任务栈与控制块用全局数组、队列与信号量用静态缓冲，创建接口只做初始化零分配。第 1 章提过的静态分配支持开关打开后，动态接口甚至不会编入镜像。

两条路线的真实代价摆在一起看：

工程上的主流答案不是二选一，而是分层混合：内核对象与长生命周期任务全部静态（吃"确定性好测"的红利）；确有动态需求的边缘业务（连接池、缓存）走池化（上一节的对象池，把动态规约成静态）；真正任意的分配（如协议解析的临时缓冲）留在最外层，配额熔断加失败钩子看管。这个分层结构下，"动态"被圈禁在一个有围栏的角落，核心系统享受静态的确定性。

一个真实的重构案例。某医疗设备的固件原本全动态，认证评审要求消灭运行期分配。重构分三步：第一步盘点全部创建点，任务与队列共二十三个对象全部转静态创建（工作量两天，样板代码增加约两百行）；第二步把三个动态缓冲场景改为固定池（各一个，尺寸按最大并发定）；第三步关掉动态支持开关，链接器报告堆不再被引用，直接删掉堆配置。结果：随机存储器用量反而下降了——静态化逼着团队逐个核实每个对象的真实尺寸，砍掉了三处"拍脑袋翻倍"的栈深。解读：静态化的最大收益不是认证通过，而是那次被迫的全面盘点——动态分配最容易藏住"没人知道为什么开这么大"的历史遗留。变式：消费电子项目认证压力小、迭代快，全静态的样板代码反而是负担，动态为主加三道防线更划算——路线选择服从产品性质，不服从潮流。

四、内存安全的最后一环：越界写

碎片与耗尽是"堆自己"的病，越界写是"别人害的"病：申请了两百字节却写穿到两百四十，隔壁块的头部被改写，几天后那次释放触发断言——案发现场与作案现场相隔几天的执行时间。防御按成本递增三档：开发期堆调试版（分配时在块头块尾写校验图案，释放时验证，抓成功率最高）；运行期水位与块数巡检（块数异常增长是泄漏信号，最大块异常缩小是碎片或越界信号）；终极防线是硬件内存保护（第 7 章）——给堆区设写边界，越界的第一次写就触发异常，现场抓获。

三档手段各抓不同阶段：调试版抓开发期的代码缺陷，巡检抓运行期的慢性病，硬件保护抓漏网的重症。都部署，成本可控；只部署一档，总有一类病能溜过去。

本节要点回顾

• 碎片是形状病不是总量病：相邻可合并、相隔拔不掉，控制对象尺寸种类是原理性治理，池化与分档是落地手段；
• 历史最低空闲比当前空闲重要一个量级，碎片率等于一减最大连续块占比，体检三元组定期入日志；
• 三道防线各答一问：钩子答"谁失败了"，断言答"谁写坏了"，熔断答"谁越权了"——失败路径必须真实演练过；
• 静态与动态之争的工程答案是分层混合：核心静态、边缘池化、任意分配圈禁加围栏；
• 静态化的隐藏收益是被迫盘点，动态分配最容易藏住无据可查的尺寸历史；
• 越界写要在三个阶段分别设防：调试图案抓开发期、巡检抓慢性期、硬件保护抓漏网重症。

第 5 章收束。堆与栈两条内存战线都有了观测与防线。下一章把时间本身搬上手术台：软件定时器怎么组织回调、无滴答模式怎么把电池寿命翻倍、中断与任务的时序规则怎样保证事件不丢——三个主题共用一条时间轴。