set_new_handler本身不主动释放缓存，仅注册失败回调函数；必须在自定义new_handler中手动实现缓存释放逻辑，并须抛出std::bad_alloc或终止程序，否则将陷入无限重试循环。
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、代码审查。
所以典型模式是：
立即学习“C++免费学习笔记（深入）”；
- 在 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<std::shared_ptr<DataBlock>> g_cache;
<p>void emergency_cache_release() {
std::lock_guard<std::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
}</p><p>// 初始化时注册
int main() {
std::set_new_handler(my_new_handler);
// ...
}
std::set_new_handler 是进程全局状态，多线程下必须加锁或确保 handler 是无状态/可重入的 std::shared_ptr 或依赖其他堆资源，释放过程本身可能触发 new（比如析构中 log 写入 string），导致递归调用 handler —— 应避免在 handler 中做任何可能分配内存的操作 delete 指向缓存的裸指针，除非你 100% 确保这些对象不是由自定义 allocator 分配的；否则应走对应的 deallocate 路径 mallinfo 或 malloc_stats，但注意它们非标准且 Linux 特有），避免误伤 std::mutex cache_mutex;
std::vector<std::shared_ptr<DataBlock>> g_cache;
<p>void emergency_cache_release() {
std::lock_guard<std::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
}</p><p>// 初始化时注册
int main() {
std::set_new_handler(my_new_handler);
// ...
}真正难的不是注册 handler，而是设计出「可安全释放、释放后有效、且不引发二次分配」的缓存结构。很多项目最后发现，与其在 OOM 边缘挣扎，不如提前用 std::pmr::monotonic_buffer_resource 或容量限制+预分配策略把内存行为管住。
