FAST-LIVO2内存优化实践：解决高内存占用问题的技术分析

背景与问题现象

在SLAM系统开发中，内存管理是影响系统稳定性和长期运行能力的关键因素。FAST-LIVO2作为香港大学Mars实验室开发的新型激光-视觉惯性里程计系统，其官方测试数据显示在8分钟数据序列处理中内存占用应维持在3-5GB范围内。然而部分开发者反馈在实际部署时出现了异常高的内存消耗（40-45GB），这一现象明显偏离设计预期。

问题定位与验证

通过社区协作排查，我们发现该问题与内存分配器mimalloc的使用存在直接关联。多位开发者在不同硬件平台（包括Ryzen 5 5600+GTX 1660S和i9-1340P集成显卡平台）上复现了以下现象：

1. 启用mimalloc时：处理487秒HIT_Graffiti_Wall序列内存峰值达40.1GB
2. 禁用mimalloc后：相同数据集内存占用稳定在4-5GB范围
3. Docker环境测试（未启用mimalloc）：内存占用仅1.2-7GB

技术原理分析

mimalloc作为高性能内存分配器，其设计特点是通过预分配内存池和缓存优化来提升分配效率。这种机制在特定场景下可能导致：

• 内存碎片控制策略激进，保留较多空闲内存
• 线程本地缓存未及时释放
• 与PCL点云库的内存管理机制存在潜在交互问题

FAST-LIVO2相比前代产品的重大改进在于采用了稀疏地图结构，理论上应具备更好的内存效率。但当与mimalloc结合时，两者的内存管理策略可能产生叠加效应，导致观测到异常高的内存占用。

解决方案与优化建议

1. 基础解决方案
   移除mimalloc依赖后重新编译：

   rm -rf mimalloc/
   catkin clean
   catkin build
   

2. 进阶优化方案
   在config文件中启用滑动窗口地图模式：

   map_sliding_en: true  # 默认false使用全局地图
   

   该模式将内存消耗控制在动态波动范围内，避免持续增长。

3. 系统配置建议

   • 对于嵌入式设备，推荐使用默认参数（point_filter_num=1）
   • 高性能平台可适当增加point_filter_num参数（但需实测验证）
   • 监控工具推荐：使用htop或glances实时观察内存变化

实践验证结果

开发者测试数据对比：

配置环境	序列时长	内存占用	RViz内存占用
带mimalloc	487s	40.1GB	7GB
无mimalloc	487s	4.5GB	6.8GB
滑动窗口模式	连续运行	稳定在3-5GB	-

总结与最佳实践

FAST-LIVO2作为新一代SLAM系统，其内存效率已显著优于R3LIVE等前代产品。开发者在部署时应注意：

1. 优先采用原生内存管理方案，暂不建议启用mimalloc
2. 长期运行时启用滑动窗口模式
3. 定期检查点云降采样参数（point_filter_num）的合理性
4. 对于资源受限设备，建议配合Docker环境部署以隔离内存管理问题

该案例典型体现了SLAM系统中内存分配器选择对系统稳定性的重要影响，也为其他基于点云处理的实时系统提供了宝贵参考经验。