C++为什么推荐使用 make_shared 而不是 new 构造 shared_ptr?

大家好，我是小康。

看到这个问题,我想起了之前帮同事定位的一个线上bug。那是一个偶发的内存泄漏,最后追查发现就是因为不当使用 shared_ptr(new T()) 导致的异常安全问题。当时如果用了 make_shared,这个bug根本不会出现。

所以今天就系统地聊聊这个看似简单、实则暗藏玄机的话题。

简单说:性能更好、更安全、代码更简洁。

作为一个写了多年C++的老司机,我见过太多因为不理解 make_shared 和 new 的区别而踩坑的代码。下面我会从原理到实践,把这个问题讲透。

一、核心区别:一次分配 vs 两次分配

先上结论:这是最重要的区别。

使用 new 的方式:

cpp 复制代码

std::shared_ptr<Widget> sp(new Widget());

这种方式至少需要两次内存分配:一次为 Widget 对象分配内存,另一次为 shared_ptr 的控制块(存储引用计数等信息)分配内存。

内存布局大概是这样的:

plain 复制代码

[Widget对象]  <--- 第一次分配
    ...
[控制块(引用计数等)]  <--- 第二次分配

使用 make_shared 的方式:

cpp 复制代码

auto sp = std::make_shared<Widget>();

make_shared 通常只执行一次内存分配,将对象和控制块放在连续的内存块中。

plain 复制代码

[控制块 + Widget对象]  <--- 一次分配搞定

性能提升有多大?

减少一次内存分配/释放操作
减少内存碎片
提升缓存局部性(控制块和对象在一起,CPU缓存命中率更高)

在高性能场景下,这个差异是相当可观的。如果你的程序频繁创建 shared_ptr,这个优化积累起来效果明显。

二、异常安全性:这个更致命

来看一个经典的坑:

cpp 复制代码

void processWidget(std::shared_ptr<Widget> sp, int priority);

// 调用方式1:使用 new (危险!)
processWidget(std::shared_ptr<Widget>(new Widget()), 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 构造。

三、代码简洁性

cpp 复制代码

// 繁琐且容易出错
std::shared_ptr<SomeVeryLongTypeName> sp1(new SomeVeryLongTypeName(arg1, arg2, arg3));

// 简洁优雅
auto sp2 = std::make_shared<SomeVeryLongTypeName>(arg1, arg2, arg3);

不需要重复类型名称,使用 auto 一步到位。代码可读性和维护性都更好。

四、make_shared 的局限性

当然,make_shared 也不是万能的,有几个场景必须用 new:

1. 需要自定义删除器

cpp 复制代码

// make_shared 不支持自定义删除器
auto sp = std::shared_ptr<FILE>(fopen("file.txt", "r"), &fclose);

2. 构造函数是私有的

make_shared 要求构造函数必须是公有的,因为它不是类的成员函数。

cpp 复制代码

class Singleton {
private:
    Singleton() {}
public:
    static std::shared_ptr<Singleton> create() {
        // 这里不能用 make_shared
        return std::shared_ptr<Singleton>(new Singleton());
    }
};

3. weak_ptr 生命周期问题

如果有 weak_ptr 长期持有引用,使用 make_shared 可能导致对象内存无法及时释放,因为对象和控制块在同一内存块中。

举个例子:

cpp 复制代码

auto sp = std::make_shared<HugeObject>();  // 假设这个对象很大
std::weak_ptr<HugeObject> wp = sp;

sp.reset();  // 对象被销毁,但...

// 只要 wp 还活着,整个内存块(包括 HugeObject 的空间)都无法释放!

如果用 new 方式,对象内存和控制块分开,对象销毁后就能立即释放内存。

五、最佳实践总结

默认情况下,优先使用 make_shared:

cpp 复制代码

auto sp = std::make_shared<T>(args...);

只有在以下情况考虑 new:

需要自定义删除器
需要调用私有/保护构造函数
对象很大 + 有长生命周期的 weak_ptr
需要使用大括号初始化(C++20前的限制)

六、补充:类似的建议

对于 unique_ptr,也有类似的建议:

cpp 复制代码

// 推荐
auto up = std::make_unique<T>(args...);

// 而不是
std::unique_ptr<T> up(new T(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天手把手带你写出专业级工具