C++ set_new_handler怎么在内存耗尽时清理缓存-C++-PHP中文网

set_new_handler本身不主动释放缓存，仅注册失败回调函数；必须在自定义new_handler中手动实现缓存释放逻辑，并须抛出std::bad_alloc或终止程序，否则将陷入无限重试循环。

c++ set_new_handler怎么在内存耗尽时清理缓存

set_new_handler 能否用于主动释放缓存？

不能直接“用于”清理缓存，set_new_handler 只是注册一个函数，在 operator new 申请失败时被调用。它本身不触发内存回收，也不知道你的缓存存在——你得在 handler 里手动写释放逻辑。

这个 handler 的唯一职责是：让下一次 operator new 有机会成功（比如释放一部分缓存、卸载非关键资源、或抛出异常）。如果 handler 返回，而内存仍不足，C++ 会再次调用它；如果它不返回（如抛出异常或 abort），则 new 失败流程结束。

为什么 handler 里释放缓存后还要 throw bad_alloc？

因为 C++ 标准规定：set_new_handler 注册的函数不应返回（即必须抛出异常、调用 std::abort 或无限循环）。如果它正常返回，运行时会再次尝试分配，再调用 handler，形成死循环。

C++ Code Review Master

组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。

下载

所以典型模式是：

在 handler 中尝试释放部分缓存（如清空 LRU 队列后半段）
如果释放后仍无法确认内存已腾出足够空间，必须抛出 std::bad_alloc
不要试图“重试 new”，那是调用方（比如 new 表达式所在函数）该处理的事

实际写 handler 时容易踩的坑

`std::set_new_handler` 是进程全局状态，多线程下必须加锁或确保 handler 是无状态/可重入的

缓存对象若持有 `std::shared_ptr` 或依赖其他堆资源，释放过程本身可能触发 new（比如析构中 log 写入 string），导致递归调用 handler —— 应避免在 handler 中做任何可能分配内存的操作

handler 中不能调用 `delete` 指向缓存的裸指针，除非你 100% 确保这些对象不是由自定义 allocator 分配的；否则应走对应的 deallocate 路径

释放缓存前建议检查是否真的处于内存压力下（例如通过 `mallinfo` 或 `malloc_stats`，但注意它们非标准且 Linux 特有），避免误伤

一个最小可行 handler 示例

std::mutex cache_mutex;
std::vector<:shared_ptr>> g_cache;
<p>void emergency_cache_release() {
std::lock_guard<:mutex> lk(cache_mutex);
size_t keep = g_cache.size() > 10 ? g_cache.size() - 5 : 0;
g_cache.erase(g_cache.begin() + keep, g_cache.end());
// 注意：这里没调用 new/delete，只移动 shared_ptr，安全
}
void my_new_handler() {
emergency_cache_release();
throw std::bad_alloc{}; // 必须抛出，不能 return
}</:mutex></p>
<p>// 初始化时注册
int main() {
std::set_new_handler(my_new_handler);
// ...
}</p></:shared_ptr>

真正难的不是注册 handler，而是设计出「可安全释放、释放后有效、且不引发二次分配」的缓存结构。很多项目最后发现，与其在 OOM 边缘挣扎，不如提前用 std::pmr::monotonic_buffer_resource 或容量限制+预分配策略把内存行为管住。