当前位置：首页 > news >正文

ARMCC内存分配异常处理与嵌入式开发实践

news 2026/6/1 17:03:08

1. ARM编译器中的内存分配异常处理机制

在嵌入式开发领域，内存管理一直是开发者需要面对的核心挑战之一。当使用Arm Compiler 5（ARMCC）进行C++开发时，内存分配失败时的处理方式会直接影响程序的健壮性。默认情况下，当堆内存耗尽时，标准的operator new会抛出std::bad_alloc异常，这在许多嵌入式场景中可能并不是最理想的行为。

1.1 标准C++的内存分配行为

C++标准定义了两种单对象内存分配形式的operator new：

// 形式1：可能抛出异常的版本 void* operator new(std::size_t) throw(std::bad_alloc); // 形式2：不抛出异常的版本 void* operator new(std::size_t, const std::nothrow_t&) throw();

这两种形式分别通过不同的语法调用：

// 形式1的调用方式 T* p1 = new T; // 形式2的调用方式 T* p2 = new(std::nothrow) T;

关键区别在于异常处理机制。当内存分配失败时：

形式1会尝试调用当前安装的new_handler函数（通过set_new_handler设置），如果new_handler无法释放更多内存，则会抛出std::bad_alloc异常
形式2同样会尝试调用new_handler，但如果最终仍无法分配内存，会捕获异常并返回NULL指针

重要提示：在未自定义new_handler的情况下（默认状态），形式1直接抛出std::bad_alloc，形式2直接返回NULL。

1.2 ARMCC的特殊处理机制

Arm Compiler 5在异常处理禁用的情况下（编译时关闭异常）会有特殊行为：

对于形式1（new T）：
- 内存分配失败时不会抛出异常（因为异常被禁用）
- 会调用std::terminate()
- 默认情况下std::terminate()会调用abort()，最终触发__rt_SIGABRT()
对于形式2（new(std::nothrow) T）：
- 行为与标准一致，返回NULL
- 不受异常开关影响

这种差异在嵌入式开发中尤为重要，因为许多嵌入式项目为了减小代码体积会禁用异常处理。

2. 实现NULL返回的内存分配方案

2.1 推荐方案：使用nothrow版本

最标准且可移植的方法是显式使用nothrow版本的operator new：

#include <new> // 必须包含此头文件以使用nothrow_t void foo() { int* p = new(std::nothrow) int[1000]; if (p == nullptr) { // 内存分配失败处理 error_handling(); return; } // 正常使用内存 // ... delete[] p; }

这种方式的优势在于：

符合C++标准，可移植性强
无论编译器是否启用异常处理都能正常工作
代码意图明确，易于维护

2.2 替代方案：--force_new_nothrow编译选项

Arm Compiler 5提供了一个非标准编译选项：

--force_new_nothrow

这个选项会强制所有new操作表现为nothrow版本，即使代码中使用的是普通new语法。但需要注意：

严重缺点：
- 非标准行为，降低代码可移植性
- 会改变所有new操作的行为，可能引入难以发现的bug
- 与第三方库配合使用时可能出现意外行为
适用场景：
- 遗留代码迁移时的临时解决方案
- 确定所有new操作都做了NULL检查的情况

实践建议：除非有非常特殊的需求，否则应避免使用此选项。新项目应当显式使用new(std::nothrow)语法。

3. 嵌入式系统中的最佳实践

3.1 内存分配失败处理策略

在资源受限的嵌入式系统中，建议采用以下策略：

关键组件使用静态分配：

// 替代动态分配 static uint8_t buffer[FIXED_SIZE];

必须使用动态内存时：

void critical_function() { auto p = new(std::nothrow) CriticalObject; if (!p) { system_emergency_handler(); return; } // ... 使用p }

实现自定义new_handler：

void my_new_handler() { // 尝试释放备用内存 if (release_emergency_memory()) return; // 无法恢复则记录错误并重启 log_error("Memory exhausted!"); system_reset(); } // 在程序初始化时 std::set_new_handler(my_new_handler);

3.2 内存分配监控技巧

堆使用量统计：

extern char __heap_base; // 堆起始地址（编译器特定） extern char __heap_limit; // 堆结束地址 size_t get_heap_usage() { // 简单但有效的堆使用量估算 return &__heap_limit - &__heap_base; }

重载operator new进行跟踪：

void* operator new(size_t size) { log_allocation(size); // 记录分配大小 void* p = malloc(size); if (!p) throw std::bad_alloc(); return p; }

定期内存健康检查：

void memory_health_check() { auto test = new(std::nothrow) uint8_t[TEST_SIZE]; if (!test) { trigger_warning("Memory low!"); } delete[] test; }

4. 常见问题与调试技巧

4.1 典型问题排查表

问题现象	可能原因	解决方案
程序意外终止	普通new失败且异常被禁用	改用new(std::nothrow)或启用异常处理
NULL指针崩溃	未检查new(std::nothrow)返回值	添加NULL检查逻辑
内存碎片化严重	频繁小内存分配/释放	使用内存池或对象池
堆大小不足	链接器配置的堆空间太小	调整分散加载文件中的堆设置

4.2 Keil MDK中的特殊配置

在Keil MDK环境中，还需要注意：

堆大小配置：
- 在Options for Target → Target选项卡中设置
- 或者在分散加载文件(.sct)中定义ARM_LIB_HEAP
异常处理启用：
```
--exceptions # 启用异常处理
```
运行时库选择：
- 使用标准C++库（如microlib）可能影响new的行为

4.3 调试内存分配失败

使用调试器断点：

// 在可能失败处设置断点 auto p = new(std::nothrow) BigObject; if (!p) { __breakpoint(0); // ARMCC内置函数 }

内存分配日志：

void* operator new(size_t size, const char* file, int line) { log("Allocating %d bytes at %s:%d", size, file, line); return _malloc_dbg(size, _NORMAL_BLOCK, file, line); } #define new new(__FILE__, __LINE__)