大家好,我是小康。
C++为什么推荐使用 make_shared 而不是 new 构造 shared_ptr?
看到这个问题,我想起了之前帮同事定位的一个线上bug。那是一个偶发的内存泄漏,最后追查发现就是因为不当使用shared_ptr(new T())导致的异常安全问题。当时如果用了make_shared,这个bug根本不会出现。
所以今天就系统地聊聊这个看似简单、实则暗藏玄机的话题。
简单说:性能更好、更安全、代码更简洁。
作为一个写了多年C++的老司机,我见过太多因为不理解make_shared和new的区别而踩坑的代码。 下面我会从原理到实践,把这个问题讲透。
一、核心区别:一次分配 vs 两次分配
先上结论:这是最重要的区别。
使用 new 的方式:
std::shared_ptr<Widget>sp(newWidget());这种方式至少需要两次内存分配:一次为 Widget 对象分配内存,另一次为 shared_ptr 的控制块(存储引用计数等信息)分配内存。
内存布局大概是这样的:
[Widget对象] <--- 第一次分配 ... [控制块(引用计数等)] <--- 第二次分配使用 make_shared 的方式:
autosp=std::make_shared<Widget>();make_shared 通常只执行一次内存分配,将对象和控制块放在连续的内存块中。
[控制块 + Widget对象] <--- 一次分配搞定性能提升有多大?
- 减少一次内存分配/释放操作
- 减少内存碎片
- 提升缓存局部性(控制块和对象在一起,CPU缓存命中率更高)
在高性能场景下,这个差异是相当可观的。如果你的程序频繁创建 shared_ptr,这个优化积累起来效果明显。
二、异常安全性:这个更致命
来看一个经典的坑:
voidprocessWidget(std::shared_ptr<Widget>sp,intpriority);// 调用方式1:使用 new (危险!)processWidget(std::shared_ptr<Widget>(newWidget()),computePriority());// 调用方式2:使用 make_shared (安全)processWidget(std::make_shared<Widget>(),computePriority());问题出在哪?
在第一种方式中,如果 computePriority() 抛出异常,可能导致内存泄漏。
为什么?因为C++对函数参数的求值顺序是未定义的,可能的执行顺序:
new Widget()- 分配内存computePriority()- 抛出异常!std::shared_ptr<Widget>(...)- 永远不会执行
结果:Widget 对象被分配了,但 shared_ptr 还没构造,内存泄漏!
而 make_shared 是异常安全的,因为它在单个操作中完成内存分配和 shared_ptr 构造。
三、代码简洁性
// 繁琐且容易出错std::shared_ptr<SomeVeryLongTypeName>sp1(newSomeVeryLongTypeName(arg1,arg2,arg3));// 简洁优雅autosp2=std::make_shared<SomeVeryLongTypeName>(arg1,arg2,arg3);不需要重复类型名称,使用auto一步到位。代码可读性和维护性都更好。
四、make_shared 的局限性
当然,make_shared也不是万能的,有几个场景必须用new:
1. 需要自定义删除器
// make_shared 不支持自定义删除器autosp=std::shared_ptr<FILE>(fopen("file.txt","r"),&fclose);2. 构造函数是私有的
make_shared 要求构造函数必须是公有的,因为它不是类的成员函数。
classSingleton{private:Singleton(){}public:staticstd::shared_ptr<Singleton>create(){// 这里不能用 make_sharedreturnstd::shared_ptr<Singleton>(newSingleton());}};3. weak_ptr 生命周期问题
如果有 weak_ptr 长期持有引用,使用 make_shared 可能导致对象内存无法及时释放,因为对象和控制块在同一内存块中。
举个例子:
autosp=std::make_shared<HugeObject>();// 假设这个对象很大std::weak_ptr<HugeObject>wp=sp;sp.reset();// 对象被销毁,但...// 只要 wp 还活着,整个内存块(包括 HugeObject 的空间)都无法释放!如果用new方式,对象内存和控制块分开,对象销毁后就能立即释放内存。
五、最佳实践总结
默认情况下,优先使用 make_shared:
autosp=std::make_shared<T>(args...);只有在以下情况考虑 new:
- 需要自定义删除器
- 需要调用私有/保护构造函数
- 对象很大 + 有长生命周期的 weak_ptr
- 需要使用大括号初始化(C++20前的限制)
六、补充:类似的建议
对于unique_ptr,也有类似的建议:
// 推荐autoup=std::make_unique<T>(args...);// 而不是std::unique_ptr<T>up(newT(args...));原因相同:异常安全 + 代码简洁。
写在最后
看完这篇回答,你可能对 C++ 的智能指针有了更深的理解。但坦白说,玩C++,光了解C++语言特性远远不够的,一定要多做项目。
纸上得来终觉浅,绝知此事要躬行。只有在实际项目中遇到过内存泄漏、野指针、性能瓶颈,你才能真正理解为什么要用智能指针,为什么要用 make_shared。
不知道做啥项目的朋友可以看我最近开设的C++项目实战课程:
从7月到现在,我陆续完成了9个C++硬核项目实战课程,已经带领230+同学从零开始实现这些项目。这些同学中有985、211的,也有普通本科的,大家都收获满满。
现有课程列表:
- 线程池- 理解多线程编程的基础
- 高性能日志库- 学习异步IO和性能优化
- 高性能内存池- 深入理解内存管理
- 多线程下载工具- 综合运用网络编程和并发控制
- MySQL连接池- 掌握数据库连接管理
- 内存泄漏检测器- 实战内存管理和调试技术
- ReactorX项目- 学习高性能网络编程框架
- 无锁栈+无锁队列(SPSC/MPMC)- 深入无锁编程和并发数据结构
- 工业级智能指针(shared_ptr)- 从零实现 shared_ptr,彻底理解引用计数和智能指针的内部机制
每个项目都是从0到1手把手带你实现,不只教你怎么用,更教你为什么这么设计,如何优化性能,怎么处理边界情况。
对C++项目实战感兴趣的同学可以加我微信详聊:jkfwdkf,备注[项目实战]。
觉得有帮助的话,点个赞和关注再走吧~ 你的支持是我持续输出优质内容的动力!
其他硬核C++项目实战:
从Reactor到网络库:10天打造生产级C++高性能网络库
网上的 shared_ptr 都是玩具?我用半个月造了个工业级的 !
手把手带你实现MPMC无锁队列:6天从Facebook Folly到自研Thunder Queue
C++无锁编程进阶实战:手把手打造极速 SPSC 队列!
C++无锁编程终极实战:手把手带你实现工业级无锁栈!
ReactorX项目火了!腾讯/字节面试官都在问的Reactor模式,终于有人讲透了
被内存泄漏折磨疯了的我,写了个工具,现在同事都来借用…
手撸线程池才是C++程序员的硬实力!7天手把手带你从0到1完整实现
从 0 到 1 实现高性能日志库 MiniSpdlog — 这可能是最适合新手的日志系统实战项目 !
三周肝出4000行代码,我的内存池竟然让malloc"破防"了!性能暴涨7.37倍背后的技术真相
手撸4200行MySQL连接池,8天带你搞定后端核心组件!
终于有人把C++多线程下载工具讲透了!7天手把手带你写出专业级工具