应优先使用智能指针管理动态内存:std::unique_ptr确保单所有权自动释放,std::shared_ptr配合std::weak_ptr解决共享与循环引用,仅底层场景才谨慎使用new/delete并封装于RAII类中。

new/delete 容易导致内存泄漏和悬垂指针
手动调用 new 分配堆内存后,必须严格配对 delete;一旦分支遗漏、异常抛出、提前 return,delete 就可能被跳过。比如函数中多个 return 路径,或 try/catch 里只在部分分支释放,就会留下泄漏。
更危险的是重复 delete 或访问已 delete 的指针——C++ 不会报错,但行为未定义,常见表现为随机崩溃或数据错乱。
- 异常发生时,
new后的清理代码可能根本不会执行 - 多线程环境下,裸指针共享 + 手动
delete极难保证安全释放时机 - 拷贝对象时若含裸指针成员,浅拷贝会导致多个对象指向同一块内存,谁先
delete谁就制造悬垂指针
std::unique_ptr 自动管理单所有权
std::unique_ptr 在栈上创建,析构时自动调用 delete(或自定义 deleter),无需人工干预。它禁止拷贝,只支持移动,天然表达“唯一拥有者”语义。
适用于:资源只被一个对象持有、生命周期与作用域绑定明确的场景(如工厂函数返回、容器元素、类成员)。
立即学习“C++免费学习笔记(深入)”;
std::unique_ptrptr = std::make_unique (42); // 函数结束时自动 delete,无需写 delete ptr.get(); // 即使中间抛异常,也会栈展开触发析构
- 比裸指针零开销(无引用计数,不额外分配控制块)
-
std::make_unique比直接new更安全:避免 new 成功但构造失败时的泄漏 - 可配合
std::move转移所有权,转移后原指针变空,杜绝重复释放
std::shared_ptr 解决共享所有权问题
当多个对象需要共同持有同一块资源时,裸指针无法安全计数,而 std::shared_ptr 用原子引用计数保证线程安全的释放时机:最后一个 shared_ptr 析构时才真正 delete。
但要注意循环引用——两个 shared_ptr 互相持有对方所指对象,计数永不归零,造成泄漏。
- 用
std::weak_ptr打破循环:它不增加引用计数,访问前需调用lock()检查对象是否还存在 - 不要用裸指针或
get()结果长期保存——它不延长生命周期,容易变成悬垂指针 - 避免从裸指针构造
shared_ptr(如shared_ptr),应优先用(new T) make_shared,减少一次内存分配
哪些情况仍可能需要 new/delete?
极少数底层场景绕不开:编写自定义内存池、实现容器内部存储、与 C API 交互(如接收 void* 并需用 delete 释放)、或性能敏感且能完全掌控生命周期的嵌入式模块。
即便如此,也建议把 new/delete 封装在 RAII 类内部,对外暴露智能指针接口,而不是让调用方直面裸操作。
- 现代 C++ 项目中,95% 以上的动态内存应由
unique_ptr或shared_ptr管理 - 禁用
new/delete并非教条,而是把“谁负责释放”这个易错问题,交给编译器和类型系统强制约束 - 最容易被忽略的一点:智能指针不能解决所有资源管理问题——文件句柄、GPU 显存、数据库连接等,仍需各自对应的 RAII 封装,不能指望
shared_ptr自动 fclose











