嵌入式内存为何碎裂？分配峰值怎么压？

内存报警通常来得很晚，因为系统在崩之前往往还能正常跑上很久。嵌入式软件一旦把堆碎片和瞬时峰值都交给运行时去碰运气，故障就会表现成难复现的申请失败、任务异常复位，甚至某次版本升级后才冒出来的随机死机。

堆碎片不是简单的“总剩余不够”，而是可用空间被切成了错误形状。消息长度、协议包体、日志字符串和临时缓冲若都是可变长申请，释放顺序又随外部事件变化，堆里很快会留下大量彼此隔开的空洞。此时监控里看到的空闲总字节也许还很多，但真正需要的大块连续区已经拿不到了。缓存对齐和对象头开销也会把可用大块进一步切碎，账面空闲并不等于可分配能力。更危险的是，这类问题常在长时间运行后才显现，短测试和冷启动压力都很难覆盖，所以团队容易误以为只是偶发越界或某个驱动不稳。

更可控的做法，是尽量让不同生命周期的对象住进不同池里。固定长度报文、控制块、日志片段和大块升级缓冲分别管理，短命对象不要和长命对象共享同一个自由链；必须可变长时，也要给长度做分档，避免所有尺寸在同一堆上互相切割。连错误回退路径也应固定占位，否则异常时才临时申请的大块最容易失败。嵌入式系统若把“申请方便”放在“布局可预测”之前，碎片问题迟早会从资源层面反咬功能层。

峰值水位则提醒你，很多崩溃并不是平均内存高，而是某个时间窗口内多条路径叠加。一次固件升级也许会同时打开解包缓冲、校验缓冲和通信重传；一次异常上报可能让日志缓存、告警队列和存储写回同时冲高。尤其在联网重连和升级恢复同时发生时，几个平时分开的峰会突然叠在一起。若只看平时稳态占用，就会低估真正的最坏场景。嵌入式产品里常见的“这个功能单独测都没问题，一合起来就炸”，本质上就是峰值账没有按场景做并集。

压峰值不能只靠把 RAM 做大，而要先消除不必要的生命周期重叠。能流式处理的，不要全量展开；能零拷贝传递的，不要在每层各留一份；必须保留历史时，也要限制日志和重传缓存的上界，而不是让异常场景自己膨胀。资源上限最好直接写进协议和日志策略，而不是留给现场配置自由增长。真正有效的资源优化，往往不是把单个模块磨得更省，而是让几个高峰永远不要在同一时刻相遇。

排查时最好保留按场景分段的水位曲线，而不是只看一个系统最大值。记录每类池的峰值时间点、失败申请尺寸和对应业务状态，再和升级、联网、异常恢复等场景对齐，通常能看出究竟是碎片先逼死了大块申请，还是多个模块在同一窗口把峰值推高。这比事后猜哪条任务越界要高效得多。只要把这条时间线补出来，很多“随机内存故障”都会变成可以预测的容量问题，整改方向也更明确。

所以，内存稳定性先取决于对象如何分家，后取决于峰值是否被提前预算。把堆当成最后手段，而不是默认收纳箱，系统才会长跑稳定。