C++智能指针构造方式 make_shared和new选择-C++-PHP中文网

C++智能指针构造方式 make_shared和new选择

P粉602998670

发布： 2025-08-30 08:43:01

原创

355人浏览过

优先选择make_shared，因其通过单次内存分配提升性能并增强异常安全；当需自定义删除器、管理数组或构造函数非公有时，则必须使用new配合shared_ptr。

c++智能指针构造方式 make_shared和new选择

C++智能指针，特别是

shared_ptr

登录后复制

的构造，在

make_shared

登录后复制

和直接使用

new

登录后复制

表达式之间做选择，这并非一个简单的优劣判断，而更多是基于具体场景的需求和考量。通常，我个人会倾向于

make_shared

登录后复制

，因为它在性能和异常安全方面提供了明显的优势。然而，在某些特定且重要的场景下，我们依然需要依赖

new

登录后复制

来配合

shared_ptr

登录后复制

的构造。

当我们谈论

shared_ptr

登录后复制

的构造时，核心问题其实是：是让

shared_ptr

登录后复制

自己去管理通过

new

登录后复制

分配的内存，还是通过

make_shared

登录后复制

一次性完成对象的构造和控制块的创建？

从我的经验来看，大多数时候，我都会倾向于

make_shared

登录后复制

。为什么呢？最直观的感受就是，它写起来更简洁，而且背后隐藏着一个非常重要的优化：单次内存分配。当我们写

new MyObject()

登录后复制

然后用

shared_ptr<MyObject> ptr(new MyObject());

登录后复制

时，实际上发生了两次内存分配：一次是为

MyObject

登录后复制

对象本身，另一次是为

shared_ptr

登录后复制

的控制块（里面包含引用计数、弱引用计数以及类型擦除的删除器等信息）。而

make_shared<MyObject>()

登录后复制

则聪明地将这两者合并成一次分配。这不仅仅是减少了一次系统调用开销，更重要的是，它能更好地利用缓存，减少内存碎片，在高性能场景下，这种差异是能感知到的。

不过，这也不是绝对的。比如，如果我的类构造函数是私有的，或者需要传递一个自定义的deleter（删除器），

make_shared

登录后复制

就显得力不从心了。这时候，我还是得老老实实地用

new

登录后复制

，然后将自定义deleter作为

shared_ptr

登录后复制

构造函数的第二个参数传进去。这就像是，

make_shared

登录后复制

提供了一个非常方便且高效的“套餐”，但如果你需要“定制服务”，就得自己动手了。

立即学习“C++免费学习笔记（深入）”；

make_shared

登录后复制

为何能提供性能优势？探究其底层机制

make_shared

登录后复制

的核心优势在于其内存分配策略。当我们使用

shared_ptr<T> p(new T(args));

登录后复制

时，C++运行时需要做两件事：

调用
```
new T(args)
```
登录后复制
来在堆上分配
```
T
```
登录后复制
类型的内存，并构造对象。
```
shared_ptr
```
登录后复制
的构造函数会在堆上再分配一块内存，用于存储控制块（control block）。这个控制块包含了引用计数、弱引用计数以及类型擦除的删除器等信息。这两次独立的内存分配，意味着两次系统调用，以及潜在的内存碎片问题。

而

make_shared<T>(args)

登录后复制

则不同。它进行的是一次性内存分配。它会计算好

登录后复制

对象所需空间和控制块所需空间的总和，然后一次性从堆上申请这么大一块连续的内存。在这块内存中，它会首先构造

登录后复制

对象，紧接着就是控制块。这种“合二为一”的做法带来了几个显而易见的优势：

减少内存分配次数： 从两次变为一次，直接降低了系统调用的开销。
提高缓存局部性： 对象和其控制块在内存中是相邻的，当访问对象时，控制块的数据很可能也已经被加载到CPU缓存中，从而提高访问效率。
减少内存碎片： 连续的内存块管理起来更高效，减少了小块内存反复分配和释放造成的内存碎片化问题。

从我的角度来看，这就像是打包服务。你单独买个商品，再单独买个包装盒，需要两个交易。而

make_shared

登录后复制

就是直接给你一个已经包装好的商品，一次性搞定。对于频繁创建大量

shared_ptr

登录后复制

的场景，这种优化是实打实的。

什么时候应该优先选择

make_shared

登录后复制

？实用场景分析

绝大多数情况下，

make_shared

登录后复制

都应该是你的首选，特别是当你满足以下条件时：

逻辑智能

InsiderX：打造每个团队都能轻松定制的智能体员工

查看详情

追求性能优化： 如果你的程序对性能敏感，需要频繁创建和销毁
```
shared_ptr
```
登录后复制
，
```
make_shared
```
登录后复制
的单次内存分配优势将非常明显。
注重异常安全： 考虑这个表达式：
```
f(shared_ptr<T>(new T()), shared_ptr<U>(new U()));
```
登录后复制
。如果
```
new T()
```
登录后复制
成功，但
```
new U()
```
登录后复制
抛出异常，那么
```
new T()
```
登录后复制
分配的内存可能永远无法被
```
shared_ptr
```
登录后复制
接管并释放，导致内存泄漏。而
```
make_shared
```
登录后复制
则不会有这个问题，因为它在一次操作中完成了对象的创建和智能指针的绑定。例如，
```
f(make_shared<T>(), make_shared<U>());
```
登录后复制
，即使第二个
```
make_shared
```
登录后复制
失败，第一个
```
make_shared
```
登录后复制
创建的对象也会被正确管理。这是我个人非常看重的一点，毕竟代码的健壮性比什么都重要。
对象构造函数是公开的：
```
make_shared
```
登录后复制
需要直接调用对象的构造函数。如果你的构造函数是私有的或保护的（例如，为了强制使用工厂方法），那么
```
make_shared
```
登录后复制
就无法直接使用。
不需要自定义删除器：
```
make_shared
```
登录后复制
不支持直接指定自定义删除器。如果你需要为
```
shared_ptr
```
登录后复制
提供一个非默认的删除逻辑（例如，释放一个C风格的资源句柄，或者将对象归还到对象池），那么你必须使用
```
new
```
登录后复制
表达式来构造对象，然后将自定义删除器作为
```
shared_ptr
```
登录后复制
构造函数的第二个参数。

简而言之，如果你只是想创建一个普通的

shared_ptr

登录后复制

来管理一个堆上的对象，并且没有特殊的删除需求，

make_shared

登录后复制

就是那个“无脑选”的选项。

new

登录后复制

与

shared_ptr

登录后复制

结合使用的不可替代场景与考量

尽管

make_shared

登录后复制

有很多优点，但

new

登录后复制

表达式配合

shared_ptr

登录后复制

的构造方式，在某些特定场景下依然是不可或缺的。

自定义删除器（Custom Deleter）： 这是最常见也是最重要的一个理由。当你的对象需要非标准的释放逻辑时，比如管理文件句柄、数据库连接、或者需要返回到对象池而不是直接
```
delete
```
登录后复制
时，
```
make_shared
```
登录后复制
就无能为力了。你必须使用
```
new
```
登录后复制
来创建对象，然后将自定义删除器作为
```
shared_ptr
```
登录后复制
的第二个构造函数参数传入。
```
#include <iostream>
#include <memory>
#include <cstdio> // For FILE*

struct FileCloser {
    void operator()(FILE* f) const {
        if (f) {
            fclose(f);
            std::cout << "File closed." << std::endl;
        }
    }
};
// 使用new和自定义删除器
std::shared_ptr<FILE> file_ptr(fopen("test.txt", "w"), FileCloser{});
// make_shared无法直接支持
// std::make_shared<FILE>(fopen("test.txt", "w"), FileCloser{}); // 编译错误
```
登录后复制
在我看来，这种场景下，
```
new
```
登录后复制
是唯一且正确的选择，它提供了
```
shared_ptr
```
登录后复制
的灵活性。
```
weak_ptr
```
登录后复制
的内存保留考量（特定情况）： 这是一个比较微妙的点。当一个
```
shared_ptr
```
登录后复制
的所有引用都消失了，但仍有
```
weak_ptr
```
登录后复制
指向它时，
```
make_shared
```
登录后复制
分配的内存会保留下来，直到最后一个
```
weak_ptr
```
登录后复制
也失效。这是因为
```
make_shared
```
登录后复制
将对象和控制块放在一起，如果提前释放对象，控制块就无法访问了。这意味着，即使对象已经逻辑上被销毁，其占用的内存可能仍然无法归还给系统，直到所有
```
weak_ptr
```
登录后复制
都过期。而使用
```
new
```
登录后复制
分配的对象，当
```
shared_ptr
```
登录后复制
的引用计数降到零时，对象内存会立即被释放。控制块的内存则会保留到
```
weak_ptr
```
登录后复制
计数为零。在某些内存极其敏感，且
```
weak_ptr
```
登录后复制
生命周期可能很长的情况下，这种差异可能值得考虑。不过，这通常是过度优化，除非你真的遇到了内存压力问题。
数组的
```
shared_ptr
```
登录后复制
管理： C++17之前，
```
shared_ptr
```
登录后复制
对数组的支持并不直接。虽然你可以通过
```
shared_ptr<int[]>
```
登录后复制
来管理数组，但
```
make_shared
```
登录后复制
没有对应的
```
make_shared<int[]>
```
登录后复制
版本。所以，如果你需要
```
shared_ptr
```
登录后复制
来管理一个动态分配的数组，你仍然需要使用
```
new[]
```
登录后复制
，并提供一个自定义删除器（或者依赖C++17后的
```
shared_ptr<T[]>
```
登录后复制
自动处理）。
```
#include <iostream>
#include <memory>

// C++11/14 管理数组
std::shared_ptr<int> arr_ptr_old(new int[10], [](int* p){ delete[] p; });
// C++17及以后，可以这样（但make_shared<int[]>(10) 仍不可用）
std::shared_ptr<int[]> arr_ptr_cxx17(new int[10]);
```
登录后复制
当然，对于数组，
```
std::vector
```
登录后复制
通常是更好的选择，但如果必须用
```
shared_ptr
```
登录后复制
管理原生数组，
```
new
```
登录后复制
是必经之路。